« first day (1615 days earlier)      last day (3066 days later) » 

e-sushi
e-sushi
11:41 PM
@SEJPM Thanks for sharing that one… happens to come handy in a discussion I had yesterday. 8}
 
e-sushi
e-sushi
11:52 PM
@SEJPM As for your question about correct interpretation, check: core.telegram.org/… and co.
> Q: How are MTProto messages authenticated?
> All Telegram apps ensure that msg_key is equal to SHA-1 of the decrypted message. It is important that the plaintext always contains message length, server salt, session_id and other data not known to the attacker.
> It is crucial that AES decryption keys depend both on msg_key, and on auth_key, known only to the parties involved in the exchange.
> Q: Are you doing Encrypt-then-MAC, MAC-then-Encrypt or Mac-and-Encrypt?
> Our scheme is closer to MAC-and-Encrypt with an essential modification. Namely, the encryption key and iv are hash-dependent.
> - We use SHA1 for integrity check
> - The SHA1 in question is for raw unencrypted data.
> - The message key is SHA1-dependent.
> - Note that the AES key and iv depend on that SHA1.
> The resulting data-dependent variable key denies all common attacks.
> Q: Why don't you go for a standard encrypt-then-MAC approach?
> Using encrypt-then-MAC, e.g. involving GCM (Galois Counter Mode), would enable the receiving party to detect unauthorized or modified ciphertexts, thus eliminating the need to decrypt them in case of tampering — at the cost of performing an HMAC computation / verification for each message.
> Provided that all MTProto clients ensure that SHA1(plaintext) = msg_key before accepting the message, and that the plaintext always contains message length, server salt, session_id and other data not known to the attacker, using encrypt-t…
 

« first day (1615 days earlier)      last day (3066 days later) »