TeleGuard Under Fire: What’s Really Behind the Security Allegations?

In recent weeks, the messenger TeleGuard has increasingly come under public scrutiny. The trigger was an article by the portal 404 Media, which alleged a serious security vulnerability: supposedly, users’ private keys could be stored on servers and misused to decrypt communications.

But how valid are these accusations? And how does encryption in TeleGuard actually work?

The Core Criticism: Can Messages Be Read?

The central allegation is serious: private keys—an essential component of secure communication—are said to be transmitted to servers. From this, it is concluded that operators could theoretically gain access to encrypted messages.

TeleGuard strongly rejects this claim.

According to the company, this criticism is based on a misunderstanding of technical processes—particularly in relation to an older mechanism for device synchronization.

How TeleGuard Encryption Actually Works

To understand the situation, it helps to look at the messenger’s architecture:

  • End-to-end encryption using the Salsa20 algorithm is used for actual communication.
  • A unique symmetric key is generated for each contact.
  • These keys are created exclusively on users’ devices—and remain there.

This means that even if servers were compromised, messages could not be decrypted because the relevant keys are never stored there.

The Controversial Point: An RSA Key for Invitations

The criticism focuses on a different part of the system: an RSA key pair used within the invitation system.

This key has a clearly limited function:

  • It is not used for message encryption
  • It is used only to initialize contacts
  • It is temporary and purpose-specific

As part of further development—especially to support multiple devices per user—a portion of this key was temporarily stored on servers in encrypted form. This allowed new user devices to access existing contacts.

Important:
The private key is never stored in plain text, but only transmitted and stored in encrypted form.

More Devices, More Complexity

Originally, TeleGuard was designed as a “one device per account” system. With growing user demands—such as using smartphones and desktops simultaneously—this model had to be expanded.

This transition introduced technical challenges, particularly in securely synchronizing keys across multiple devices.

The criticized solution was part of a transitional phase (“legacy support”), which is now rarely needed and will soon be completely phased out.

Can These Keys Be Misused?

The answer is clear: no.

Even in the hypothetical case that someone gains access to the mentioned RSA key, it would not be possible to:

  • Decrypt messages
  • Read communication content

The reason: the actual encryption is based on separate, independent keys (Salsa20) that never leave the device.

Misunderstandings About “Hashes” and Passwords

Another point of discussion concerns the transmission of “hash values” and the role of credentials.

Here, too, there appears to be a misinterpretation. The key points are:

  • The transmitted data is not related to message encryption
  • It is used solely for the invitation system
  • Access is not possible without proper authorization or compromised credentials

Technical Issue or Communication Misunderstanding?

This case illustrates how complex modern encryption systems are—and how easily technical details can be misinterpreted.

What remains clear:

  • The actual end-to-end encryption is not affected
  • The criticized mechanism is limited, temporary, and not responsible for messages, but only for synchronizing contacts