Telegram consistently states that they use ‘encryption’ to ‘secure chats’ and to ‘maintain user privacy’. Although these statements are technically correct, it is somewhat comparable to taking an achievement of ‘secure exchange’ directly from those whom are using the application, the broader world of participants. Such ‘secure exchange’ as is claimed to be achieved is not something that Telegram, as a service or application, can be said to inherently be providing.

First of all, Telegram‘s idea of encryption centers around client-server encryption. It is imperative to note that this is not client-to-client encryption. On their website, in their own ‘advanced FAQ’ section, Telegram states that they use Key Derivation Function (KDF) to generate users’ AES keys. This KDF generated key is then also further used to encrypt users’ messages, as in specifically those messages that are sent on or via Telegram itself. These KDF key encrypted, user messages are stored on the Telegram server(s). So far so good.

However, those with accounts and exchanging messages through Telegram can use multiple devices for their account and even maintain ‘syncs’ with their varied Telegram chats. This raises a highly significant, impactful consideration: If the Telegram users’ messages are stored and encrypted on the Telegram servers, with people able to fetch and decrypt them using various devices, then the keys to these encrypted messages are also stored on the Telegram servers. Logically then, we may deduce that the Telegram databases host both the keys and content.

Let’s assume that Telegram encrypts their database (DB). If anyone hacks their DB, that hacker won’t have access to those stored chats unless they too have the encryption keys to the content (chats), themselves. Yet if Telegram DB’s also have the users’ encryption keys – then – if the hacker wanted to, this positioning of keys and information would mean that they can decrypt all the conversations stored in the DB. This is easy. The hacker has access to both the encrypted content alongside the capacity to decrypt such, just by using the keys on the same DB. This is obviously not really a good scenario if attempting to provide a ‘secure and private’ application or service.

Telegram only provides E2EE in secret chats. They use Diffie-Hellman key exchange to share keys which is good but, not to the level of the signal algorithm.

When using Telegram‘s ‘secret chat’ – the other party first needs to accept a ‘secret chat’ request. This is a not a feature but rather a limitation of using Diffie-Hellman. The chats using this are volatile. Content is lost when the data is cleared or the device is changed. This is the same issue as faced by WhatsApp. The only way around this volatility is for the hosts to backup the users’ chats, say on a cloud server. Such backups are stored as unencrypted messages. With NEST, we simply do not have these issues.

Telegram‘s File Transfer

Telegram says that the application itself supports 1.5GB of file transferring (FTP). This is a nice feature to have. But this FTP protocol is not secure, particularly to the level at which it is being praised to. It is impossible to have a file as big as 1.5 GB support E2EE. My guess, Telegram is using server encryption protocols to encrypt the files in-transfer and store these on their server(s). This means that during such an FTP exchange, Telegram also has access to the file. In their FAQ section on their website, found here, they are very vague about this process. The file encryption standards and details actually used are not explained in detail.

True or Genuine End-to-End Encryption (G-E2EE), is attained when the hosting application does not have access to the users’ exchanged content. If this definition of G-E2EE is accepted, then Telegram ultimately and absolutely fails at achieving it.

Mr. D. Singh [NEST / CHIEF ARCHITECT]