> 1. The biggest problem is that the SHA1 digest of a message is not an authenticator of that message, because an attacker can generate the same digest given only the contents of the message.
Please note that a message to be encrypted would not only contain the actual text sent, but also at least the server salt, session id, message sequence number, message length and precise time.
This complete data set could be theoretically obtainable only from either server or client memory, therefore the fact that an attacker has this kind of data implies that a successful attack had already taken place. Hence the question — why didn't that attacker take the auth_key right away?
On top of that, the present setup doesn't present any identifiable threats, because even if you could get a message with a given SHA1, you would still not know which message was really transmitted out of the possible matching set (or rather out of the 2^(L-160) messages for a message with the length of L bits).
Regardless of this fact, we do agree that strengthening this point would be logical in view of possible future developments in code-breaking. Thank you.
> 2. The last time your cryptosystem was discussed on HN, I provided a link to a thread in which Jutla laid out a simple, devastating attack on the mode in ASCII text in a mailing list post. You didn't respond.
I'm afraid, this is not true. You must mean this comment [0], and we did respond, days ago.
Today I can only repeat that we do not use IGE as MAC. The attack described there [1] is irrelevant for our setup. A question for you, by the way: is your position that using CBC instead of IGE in our case would make the protocol more secure or less secure?
[0] https://news.ycombinator.com/item?id=6918015
[1] https://groups.google.com/forum/#!topic/sci.crypt/4bkzm_n7UG...
> 3. Technical attributes of your RSA usage appear incompetent. RSA padding is not optional; 80% of the RSA implementations on the Internet are insecure because they use the default padding (PCKS1v1.5) which was carefully designed (in the 90s) to resist attacks, but missed some. You use ad-hoc padding.
We thanked you for feedback on padding two days ago [2] and noted that we were in the process of strengthening this point by moving to OAEP.
Still, the random padding already in use in MTProto is rather robust. The reason for this is that the RSA in DH is only used one way and ONLY with the public key. An attack on the private key would not be possible in this case, since it is not being used for transmission. So the sole possible attack would be MITM, which would imply deciphering RSA in real-time. If you are aware of other attacks that could harm this design, please tell us.
For the moment getting the RSA key with a microphone in traditional setups that store private RSA keys on client devices looks like a more real threat than what is described above. In our case private RSA keys are neither stored, nor used on the client.
[2] https://news.ycombinator.com/item?id=6918634