> The Telegram key exchange is described in the "Key Generation" section of Telegram's end-to-end API docs. Concretely, Alice requests the DH parameters (p, g)

> The Telegram key exchange is described in the "Key Generation" section of Telegram's end-to-end API docs. Concretely, Alice requests the DH parameters (p, g) from Telegram, painstakingly verifies them, computes a random a value, and sends g^a mod p to Telegram. Bob receives (p, g, g^a mod p), similarly computes b and g^b mod p, and sends the latter back (along with a truncated hash of the derived key, for some reason). I assume the reason is that the recipient of the truncated hash can validate that they've derived the same key without exposing it. This makes it way more straightforward to reject invalid keys. Truncating the hash is pointless but I get why they'd do it - it doesn't "hurt" since ultimately decryption will (hopefully) fail with an invalid key and this is just a shortcut to commit to a specific key. Otherwise, a really interesting example of thinking "I'll add a nonce here, that'll make things safer!" and getting the exact opposite result.