You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to this omission, this code will accept an arbitrary small prime, resulting in the confidentiality of secret chats being fully compromised. That is, if the Telegram server is broken into, the secret chats between CuteGram clients could be degraded to be equivalent to plaintext, even if the two clients know each other, check SHA-1 hashes of the msg_key etc. Admittedly, a compromise on the Telegram server may not be likely, but it is well within the threat model of the protocol.
Am I wrong? Is this check being done somewhere else?
If not, it should be trivial to add the check in CryptoUtils::checkDHParams using BN_num_bits
Best,
Karthik
The text was updated successfully, but these errors were encountered:
prosecco
changed the title
Received Diffie-Hellman group should be checked for size
Received Diffie-Hellman group should be checked for prime size
Nov 8, 2015
The code for verifying the received Diffie-Hellman parameters from the server seems to not check the size of the prime, even though it correctly performs primality checks for this value (See https://github.com/Aseman-Land/libqtelegram-aseman-edition/blob/master/util/cryptoutils.cpp#L174).
This violates the MTProto spec that asks that the prime be 2048 bits long with leading bit set to 1 (see "Validation of DH parameters" https://core.telegram.org/mtproto/security_guidelines)
Due to this omission, this code will accept an arbitrary small prime, resulting in the confidentiality of secret chats being fully compromised. That is, if the Telegram server is broken into, the secret chats between CuteGram clients could be degraded to be equivalent to plaintext, even if the two clients know each other, check SHA-1 hashes of the msg_key etc. Admittedly, a compromise on the Telegram server may not be likely, but it is well within the threat model of the protocol.
Am I wrong? Is this check being done somewhere else?
If not, it should be trivial to add the check in CryptoUtils::checkDHParams using BN_num_bits
Best,
Karthik
The text was updated successfully, but these errors were encountered: