TeleGuard (Messenger from Swisscows)

I’ve been noticing a lot of chatter lately about the Teleguard app from Swisscows being promoted as a safer alternative to Session, but the official site offers almost no details. There’s no clear information whether the code is open‑source, or any independent security audits to back up those claims. Could anyone point me to a public repository or documentation confirming its open‑source status?

I’m also curious about the people or organization behind the app and whether they have a proven track record in privacy‑focused development.

Finally, does anyone know what’s driving the recent surge in popularity?

Thanks!

Who told you it’s good app? It’s literally walking red flag. Closed source, centralized, almost impossible to delete account, it’s based on some device id or other deep storage. You can clear all data from phone it will still be there.

+ swiss doesn’t mean much nowadays, 20 years ago maybe, today it’s more marketing catch imo

Unless any entity relying on Swiss can also truly back it up with all that’s needed to trust a privacy product

This one was discussed previously:

implements its encryption so poorly that an attacker can trivially access a user’s private key and decrypt their messages, multiple security researchers told 404 Media. TeleGuard also uploads users’ private keys to a company server, meaning TeleGuard itself could decrypt its users’ messages, and the key can also at least partially be derived from simply intercepting a user’s traffic, the researchers found.

The CEO responded to the claims in 404’s article: This is our official response to 404 Media

"Dear Joseph,

Frankly, we were, to put it mildly, extremely surprised by the superficial and unsubstantiated nature of the publication, particularly given that it originates from a source presenting itself as an objective media outlet. While we understand that provocative headlines and content may be intended to generate attention and public reaction, we would reasonably expect that material addressed to a broad audience meets basic standards of diligence, substantiation, and evidentiary support. We also take this opportunity to remind the authors of their responsibility when disseminating information that may be false, misleading, and potentially harmful to the reputation of the parties concerned.

With regard to the allegations concerning the purported insecurity of encryption in TeleGuard, we state as follows:

“TeleGuard … implements its encryption so poorly that an attacker can trivially access a user’s private key and decrypt their messages.” This assertion is factually incorrect, misleading, and presented in an unjustifiably categorical manner. TeleGuard employs encryption algorithms that conform to established industry standards (including, inter alia, Salsa20). Any statement suggesting trivial compromise of private keys is without factual basis.

“TeleGuard also uploads users’ private keys to a company server, meaning TeleGuard itself could decrypt its users’ messages, and the key can also at least partially be derived from simply intercepting a user’s traffic.” This statement reflects a fundamental misunderstanding of the underlying technical processes. The data transmitted to the server consists of a hashed representation, not a usable private key. The actual private key remains encrypted on the user’s device using the user’s password. Accordingly, it is not accessible to TeleGuard, nor can it be decrypted via interception of network traffic, absent compromise of the user’s credentials.

For the avoidance of doubt, the referenced “keys” are used solely for user invitation mechanisms and play no role in message encryption. They do not, under any circumstances, enable access to the content of user communications.

The following statement is particularly concerning and is categorically rejected: “The app has also repeatedly been linked to child abusers, with one local media outlet reporting TeleGuard is ‘notorious’ among prosecutors for child sexual abuse material.”

This allegation attempts to associate TeleGuard with criminal activity of the most serious nature. We unequivocally deny any such association. TeleGuard has never supported, facilitated, or condoned illegal activities of any kind, and we are prepared to defend this position in any competent jurisdiction.

We fully acknowledge that encrypted and anonymous communication tools, like any technology, may be subject to misuse. Upon receipt of valid reports from competent authorities concerning unlawful activity, the relevant user accounts are promptly blocked. Due to the technical architecture of the service, it is not possible to access the content of user communications without access to the user’s device.

In order to substantiate the claims made in the publication, we invite the referenced “security experts” to provide verifiable, reproducible evidence of the alleged vulnerabilities, including demonstrable access to user correspondence. For this purpose, we are prepared to provide a test account under controlled conditions.

In the absence of such evidence, the allegations presented must be regarded as speculative and without sufficient factual foundation.

We do not assert that TeleGuard is entirely free from defects; no technical system can make such a claim. However, we affirm that we exercise all reasonable care and diligence to ensure that the service operates in accordance with the standards represented to our users.

We further reiterate that TeleGuard and its parent company, Swisscows, are firmly committed to the protection of user privacy. At no time have we intentionally compromised, nor will we intentionally compromise, the security of user data.

We also note that modern communication infrastructures are inherently complex and continuously evolving. Data transmission involves multiple transformations and intermediary systems, each of which may present potential vulnerabilities or points of failure, whether due to malicious activity or human error.

As developers, we consider it our responsibility to continuously monitor, assess, and address such risks. While issues may arise, we maintain that responsible disclosure practices require that identified vulnerabilities be communicated directly to developers prior to public dissemination, allowing for timely remediation.

We remain open to constructive and well-founded criticism and consider it an important component of ongoing improvement. However, we expect such criticism to be based on verifiable facts and presented in a fair and objective manner, rather than relying on anonymous or undisclosed sources.

We remain available to engage in a substantive and fact-based dialogue with qualified experts and to address specific, demonstrable concerns. However, we categorically reject unfounded allegations of incompetence or intentional misconduct.

Sincerely, The TeleGuard Team"

These are in no way mutually exclusive. You can use Salsa20 but it you don’t know how to use Salsa20 you will break your system’s security. As the anonymous independent researcher said, TeleGuard uses a fixed nonce. Trail of Bits confirmed that finding. The key was derived from the users hard coded public user ID so the key was hard coded too.

Salsa20 is a stream cipher that with fixed key and nonce generates always the same keystream. When you encrypt two messages with say keystream you have a classic two-time pad vulnerability.

Because

PT1 ⊕ KS = CT1
and
PT2 ⊕ KS = CT2

Where ⊕ denotes the bitwise XOR operation.

Attacker that intercepts CT1 and CT2 can perform

CT1 ⊕ CT2 = PT1 ⊕ PT2

to cancel out the keystream. Natural languages have enough internal structure and rules to allow figuring out which two plaintext messages were XORed together. This attack was famously used during WW2 as part of Project Venona to decrypt Russian ciphertexts, when the company producing one-time pads messed up and reused pads.

The correct move would’ve been to say “That’s bullshit, we know to use unique nonces with Salsa20, here’s a code snippet”, but they just tried to imply the app is great simply because of the primitive selection, which as we just saw, doesn’t mean shit of you don’t know what you’re doing.

Someone once said: Cryptography is nightmare magic math that cares about the color of the pencil you write it with. You can have perfectly correct C-code and still fuck up because your compiler optimized the source code into machine code that doesn’t run in constant time.


There’s no documentation discussing the security properties. But, the little they reveal, reveals a lot of how little they seem to know about this stuff.

Using Salsa20 in the first place is a bit telling, as they fail to list the full scheme. An expert choice would be XChaCha20-Poly1305 as it’s as per djb, improving on Salsa20 diffusion with zero downsides. It’s also using 192-bit random eXtended nonces, and it’s an AEAD construction.

Only an amateur would slap Salsa20 sticker on their product and call it the best when the author of Salsa20 disagrees on whether Salsa20 is best because they bothered to refine it to ChaCha20.

Note that (X)Salsa20-Poly1305 would be perfectly fine but “Salsa20” with fixed nonce and key is a complete failure. If the lack of authentication algorithm in the name means there is no authentication, it’s another massive issue: stream ciphers are vulnerable to bit-flip attacks so in the absence of documentation, it’s completely uncertain if TeleGuard is KPA-secure.

Using RSA in the first place reeks of amateur work.

  • Using RSA omits forward secrecy. If the private key leaks, all messages can be decrypted retrospectively
  • The RSA key size is also not disclosed, nor is the version it RSA-OAEP or some crappy #1 v1.5?
  • Also it’s not post-quantum. I think this is something that slowly needs to be brought into comparison charts.
  • RSA usage implies there’s also no break-in key recovery that Diffie-Hellman ratchet provides. Which shows the company is apparently oblivious to the literature of the field given that OTR-messaging used DH ratchets 22 years ago.

Then there’s the rest of the claims

As per the reports, TeleGuard’s keys are derived from the user’s password, and that the password is the user’s public user ID, and that the user ID alone could be used to download RSA private keys from TeleGuar’s API.

The company claimed that what was uploaded to the server is the hash of the private key. This is what a modern hash would look like

ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb

This is what an RSA private key would look like

-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDOol3pLrK55z51
oTNcaTixj5YvEQYw54AEbFKamUEWjelzCR2NJomtFqF7A43HqXH5OUY+8rrBzvN6
zfaITJMu40v88Wo822Baj/zdKuxDKS3x/w0enDd4NwYVvqrZ4NKerY42pY9+FTlZ
c/hzqOvGdCox5sPDPEm+KbdfKWuVslDnJiZqkb1hCrqBnhlUciWlX3etzjxFMpMF
[...]
YYrVDEdiYIH1M4sIT9uApU+6B7GocTDQI/y2Du91iNxWcgjdVWxSp6mjnkuDoE8Z
e57x6lgNHjiAWdDTQu+hCpziMUMAR5IUzIbdhvwNAoGBAJrohAwZuF9kDQ2aeKok
nFed3Tao9R/iidHZwRvVeio9esW+ZaFXI/oM1OjCTPx8LN/psK7EXcw0pcn3zftN
bT55IhDcZ/cJzkajbpInbaWZJKx7KsJVIkCbtd1p+UxcKmkvVc5HK6OSzjZU9D4A
rxp9PJcVjfe4PGXTxkHC9/zQ
-----END PRIVATE KEY-----

Now, I for one would like to know why the company thinks an independent security researcher, and and entire team of experts from Trail of Bits, a computer security audit company can’t tell these two apart.

Why would these researchers think a hash represents an RSA key? An X25519 private key could be mistaken for a 32-byte hash because they’re both raw strings. But an RSA private key has structure. It will have specific length, and it will contain revealing fields like the public exponent 65537.

There’s no way Trail of Bits was confused about what the API yielded.


The invitation to have the researchers to prove TeleGuard is insecure in some controlled setting is laughable and shows they have no idea how the field works. It’s the complete opposite.

Cryptographic systems are assumed broken until they’re shown to be secure. You document how your protocol works, and you release the source code so that anyone can check you’re telling the truth.

The guys make grandiose claims nobody can check because the code is closed source.

They are amateurs.

tl;dr Absolutely do not use TeleGuard.

They both are correct, people trading child porn use Teleguard like news show but Teleguard helps out the FBI arrest those users and Teleguard does not support or condone illegal activities. One thing does not take the other, nobody lied.

A foreign law enforcement officer got TeleGuard to hand over a small string of code the company had used to send push alerts - the pop-up notifications that announce instant messages and news updates - to the suspect’s phone.