[tptacek]

Regarding IGE: Gligor and Donescu, 1999; a summary on a mailing list of the attack:

https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG...

Long story short: you get integrity protection from IGE by relying on the fact that a bit error anywhere in the stream will irrevocably corrupt the rest of the stream, so you create an authentication code by sticking an all-zeroes block or (like I think Telegram does) a message digest to the end of the stream.

But it's possible with carefully chosen errors to first corrupt an IGE stream and then recover it, so that the remainder of the message after the corruption (including the "MAC" tag) will remain intact.

IGE is an extremely weird, and, at this point I'll venture: bad choice for a 2013-2014 cryptosystem.

[TelegramApp]

We use SHA1 (see 'message key' here: https://core.telegram.org/mtproto/description). IGE is used instead of CBC.

[sillysaurus2]

There are certain data (session, message ID, session message, server salt) that are contained in the initial part of the unencrypted message; the message key must be the same as the 128 lower-order bits of the SHA1 of the message body (including session, message ID, etc.)

Not even HMAC-SHA1, just "SHA1"? So you leave yourself open to length extension attacks? http://en.wikipedia.org/wiki/Length_extension_attack

[tptacek]

I believe they are using SHA1 with IGE mode, giving each message a trailer that is the SHA1 hash of the message.

[nialo]

Disclaimer: I am not a cryptographer, and have only gotten to #40 in Matasano's challenges.

They appear to be trying to use encrypt and mac, and not as far as I can tell relying on IGE mode to provide authentication. See the "Message Key" and "Important Tests" sections here: https://core.telegram.org/mtproto/description

There is also not, as far as I can tell from reading the protocol description above and the source code here: https://github.com/ex3ndr/telegram-mt/blob/master/src/main/j... (in particular the EncryptedMessage method, lines 447 to 460) any sort of key in the MAC, it's just SHA-1 of the plaintext. It's also not encrypted as far as I can tell, it's listed in the unencrypted "external header" in the protocol description.

I can't think of an attack from this, but the fact that an adversary can generate a valid MAC for _any message_ by simply SHA-1'ing it seems really scary.

[TelegramApp]

Kindly take at look at this technical FAQ that we've assebmled based on the conversations on Hacker News and elsewhere: http://core.telegram.org/techfaq

[sillysaurus2]

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.)

[tptacek]

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.

[TelegramApp]

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