Hacker News new | comments | show | ask | jobs | submit login

Ah. In case anyone else was wondering why this works, it's because IGE has the property that if you corrupt the ciphertext, the plaintext is corrupted all the way from that point forwards. Therefore, appending the SHA1 of the message body is enough to check the integrity. (Appending a block of zeroes would be enough, too.)

Except that IGE mode is broken.

How broken is it here? Who knows. Professional cryptographers would use an AEAD mode with a security proof, or the generic composition of a cipher (w/proof) with ciphertext encrypted by a MAC (w/proof). Instead, this system uses a '70s block mode (that nobody else uses) and a hash function from the '90s.

In order to clarify a few points in our setup, we've added this scheme to the protocol description page [0],[1].

We are indeed using well-known older algorithms, created in the days when bandwidth and processing power were both a much rarer commodity. This has valuable side-effects for modern-day mobile development, provided one takes care of the known drawbacks.

The weakspots of the said algorithms are also well-known, and have been exploited for decades. We used these algorithms in such a combination that, to our best knowledge, prevents any known attack from possibly succeeding. Although we’d be grateful to see any evidence of the contrary (so far absent from this thread) and update our system accordingly.

While other ways of achieving the same cryptographic goals, undoubtedly, exist, we feel that the present solution is both robust and also sucсeeds at our secondary task of beating unencrypted messengers in terms of delivery time and stability.

[0] ­­– https://core.telegram.org/img/mtproto_encryption.png [1] - http://core.telegram.org/mtproto/description

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact