Interview: Security and Architecture of TeleGuard

Question:
The 404 Media article claims that private keys of TeleGuard users are transmitted to servers and could potentially be used to read user communications. How do you respond to this?

Answer:
This claim does not reflect the actual technical reality. The keys referenced are not used for message encryption. End-to-end encryption is based on separate symmetric keys (Salsa20), which are generated and remain exclusively on users’ devices and are never available to the server in a usable form.

Question:
Why is an RSA key used at all?

Answer:
The RSA key is used exclusively within the invitation and contact establishment mechanism. It enables the initial exchange of key material between users.

It is used only once to establish a secure connection and does not play any role in the actual encryption of messages.

Question:
The video shows that a man-in-the-middle attacker can apparently steal keys and decrypt messages. Is that correct?

Answer:
The video shows a technically possible, but artificially constructed scenario. All components involved—clients and analysis tool—run on the same device. This gives the attack system access to information that would not be available under real-world conditions. This setup is not representative of real-world use cases.

Question:
You say an attacker would need a "decrypted private RSA key." What does that mean exactly?

Answer:
The private RSA key is not freely accessible; it is processed securely.
To actually use it, additional requirements would be necessary—in particular, access to user data, client-side derivation processes, and control over the timing of communication. Without this combination, the key is practically unusable for an attacker.

Question:
How exactly is this RSA key protected? And does the server have access to all the necessary information for decryption?

Answer:
The key is transmitted exclusively in a protected form. The server merely acts as a transport instance. It does not possess the complete information necessary to reconstruct the key independently. Crucial parts of the processing and derivation are performed exclusively on the client side.

Question:
Is it factually correct that a man-in-the-middle attacker can ultimately decrypt messages using the RSA mechanism?

Answer:
Under realistic conditions: no.
Such an attack would require a combination of several highly complex prerequisites—including access to endpoints, successful network manipulation at the right time, and additional internal knowledge. Therefore, the portrayal of it as a "trivial" attack is inaccurate.

Question:
Why do you not publish a full whitepaper, as other messaging services do?

Answer:
At present, we do not provide a comprehensive public whitepaper covering the entire architecture.

However, our security model is based on well-established principles:

• End-to-end encryption using Salsa20
• Initial key exchange via RSA within the invitation process
• Secure transport via HTTPS/TLS

We are continuously evaluating how to provide more detailed technical documentation in the future.

Question:
Has TeleGuard undergone an independent security audit?

Answer:
So far, TeleGuard has not undergone a fully public, independent security audit with a published report.

Such audits involve significant organizational and financial effort. As we deliberately avoid monetization models such as advertising, tracking, or selling user data, our available resources are limited.

Nevertheless, our architecture is continuously reviewed internally, and we are in contact with security-conscious third parties and the community. We do not rule out independent audits in the future.

Question:
Your FAQ mentions both HTTPS and end-to-end encryption. How do these interact?

Answer:
These are two complementary but distinct mechanisms:

• HTTPS/TLS secures the transport channel between client and server
• End-to-end encryption (Salsa20) protects the actual message content

Messages are encrypted on the sender’s device and can only be decrypted on the recipient’s device.

The RSA mechanism is used solely for the initial key agreement and not for message encryption.

Question:
You announced that the “legacy mechanism” will be removed. Why is that?

Answer:
This mechanism originates from an earlier stage of development and was introduced for compatibility with older devices.

While it does not pose a real security risk, it can be misinterpreted. Therefore, it is being removed. This has already been implemented in Android and desktop clients; iOS will follow shortly.

Question:
How do you respond to regulatory requirements, for example in Switzerland?

Answer:
As a Swiss-based service, TeleGuard is subject to applicable legal frameworks.

At the same time, a key principle applies:
We can only provide data that actually exists.

TeleGuard does not store sensitive user data such as message content, locations, IP addresses, phone numbers, or email addresses. Therefore, the scope of any possible disclosure is inherently limited.

Question:
Finally, how do you view criticism from media and external experts?

Answer:
We welcome well-founded, objective criticism.

At the same time, it is essential to distinguish between theoretical scenarios and realistic attack vectors and to present technical matters accurately.

Our goal remains unchanged: to provide maximum privacy for our users while maintaining transparent and responsible communication.

Additional Statement on the 404 Media Video

In this context, we would like to address the video published by 404 Media once again.

It did not accurately depict the actual situation and therefore unfortunately presented a distorted picture of our technical expertise and the safety of our product.

Unfortunately, 404 Media's chosen communication channel was also not ideal: A single support request with a very short response time does not do justice to the complexity of such a topic and does not correspond to the usual procedure for responsible security reporting.

Regarding the video again:

The scenario presented is based on an artificially created test environment. In the case shown, the hypothetical attacker had access to the private keys of both communication partners. However, this was only possible because the creation of the accounts, the sending of the invitations, and the subsequent communication all took place on the same device.

The analysis and attack system used was directly connected to this device and was therefore able to access information in a simulated man-in-the-middle (MITM) situation that would not be available under real-world conditions.

A comparable scenario under realistic conditions would require an attacker to simultaneously gain access to both endpoints—either physically or through compromising software—and additionally perform targeted network manipulations (e.g., DNS spoofing or intrusions into provider infrastructure), coordinating all of this precisely at the time of the invitation process.

The scenario shown in the video is therefore not comparable to realistic operational conditions.