Disclaimer: the text you refer to is a description of what the protocol does, without indicating the motivation behind it. This response follows in the same line.
According to this diagram in official documentation:
Each message does not use the persistent key directly, but a new key derived from it. Both participants have this key, but there is another parameter, variable, which is used in the derivation process, and which the other party (the recipient) does not have access to. Therefore, in order for the recipient to be able to decipher the message, it is necessary to pass to it the parameters used in the encryption, so that it can derive the same key and then use it. This is done using an external, unencrypted header:
Before a message (or a concatenated message) is being transmitted on a network using a transport protocol, which is encrypted in a certain way, and an external header is added at the top of the message which is: a key identifier 64-bit ( that uniquely identifies an authorization key for the server as well as the user) and a message key 128-bit.
Thus, the recipient receives information from which secret key should be used, and that nonsecret parameter (the "message key", which should not be called "key", but finally...) should be used next to it to derive the true key. With this he can redo the key used to decrypt the encrypted data.
A user key along with the message key defines a real 256-bit key and a 256-bit boot vector, which is what encrypts the message using AES-256 encryption, with infinite garble extension (IGE).
The KDF ("key derivator function") then used in the secret key and "key" message derives the decryption key. However, instead of using a random IV ("initialization vector") - the most usual - it uses KDF itself to derive IV as well. I don’t have the knowledge to comment on that, but second that answer to an old question of mine on security.SE, the output of a KDF is good enough to produce two separate keys - which leads me to conclude that it is also good enough to derive an IV (since it has more "relaxed" security features than a key - it just has to be unique, not secret).
IGE is a mode of operation, used to transform a block cipher (such as AES) into a stream cipher. Block ciphers act on single blocks of a fixed size (128 bits in the case of AES), stream ciphers encrypt data of arbitrary size.
Note that the initial part of the message is encrypted contains variable data (session, message ID, sequence number, server salt) which obviously influences the message key (and therefore the AES and iv key).
It is simply saying that if you mess with anything in the message - including its metadata - the message "key" will change (since it is a hash of all this). Which is good, because it avoids replay Attacks (as already explained by Maniero in your related question). Two identical messages, but sent at different times (and therefore with timestamps different) will be encrypted differently, giving no useful information to the attacker.
The message key is defined as the 128-bit lower-order SHA1 of the message body (including session, ID message, etc.) messages of various parts are encrypted as a single message.
As already explained, the message and its meta-data are hashed to derive the message "key". The hash SHA-1 has an output of 160 bits, but only the 128 bits "right" (lower order/lower order) are used (ex.: "2fd4e1c6 7a2d28fc ed849ee1 bb76e739 1b93eb12").
Responding to your specific doubts (which have not yet been covered in the above explanation):
it joins these two keys? type A + B = AB?
Yes it joins, but not through a simple arithmetic operation, but rather providing both as input for a KDF. This is to ensure the avalanche effect - the change of a single bit whether in one key or the other must cause all output bits to have a 50% chance of changing.
This user key is the key identifier?
If cryptography is end-to-end, then it is assumed that each participant of the communication has a shared secret, unknown by the intermediary(s). There may be more than one secret. Then each message indicates which the key that was used in that message, so the recipient can decrypt it.
Now I’m in doubt whether it’s the left or right bytes in the hexadecimal representation... Endian confuses me... P
– mgibsonbr
Hi, I answer you with more questions haha (I’m sorry), when it says that each message is not encrypted with the persistent key you mean that it does not use the DH key that he created in the conversation directly.?
– Elaine
@user3715916 I will call the DH key from
dh. Instead of him establishing aivseparate and makeAES(dh,iv,mensagem)he doeschave,iv = KDF(dh + msg_key)and thenAES(chave,iv,msg_key). I mean, he doesn’t use the DH key directly, and yes indirectly.– mgibsonbr
But if it passes the parameter to another, can’t this protection be considered null? If it will pass through the network..
– Elaine
But one component of key generation is secret. Assuming a decent KDF (read about the Avalanche Effect), only knowledge of the nonsecret component (the
msg_key) does not help in discovering the final result (thechaveand theiv). Not without the help of the secret component (thedh). Even if this "message key" was not used, it would still be necessary to pass an additional parameter without protection, IV. Why don’t they just do it, I don’t know (reiterating, I have no knowledge of the motivation behind the protocol), but the way it is is not bad...– mgibsonbr
See why I’m fascinated by this? Haha, I’ve been researching KDF and PHP, I haven’t had much success but this is for another question. The message key is a hash (made with sha-1) of the content to be encrypted, correct? Like, can’t this hash be broken? Because as it will go through the network it’s broken down the encryption walls will be in vain. If that’s what I think, there’s an algorithm that they published themselves showing how the key and iv is created.
– Elaine
If I am not mistaken, I read that after decrypting the data makes a hash of them and then it makes a comparison to avoid the CPA, is valid this check does not think ?
– Elaine
@user3715916 What do you call "broken"? Reversing the hash (finding a message that, after hashed, gives that hash) is impractical - this is called pre-image resistance, and is a feature of every well-done hash. That’s why it’s not so important whether this hash is secret or not (and the salt in the internal header also helps). As for the algorithm that shows how the key and iv are created, it is the same as shown in the diagram, no? (i.e. KDF in the key and in the
msg_key) What is CPA? Chosen-Plaintext Attack? I don’t see any relation between one thing and another, but I also don’t know the protocol in depth.– mgibsonbr
I only mentioned a few points, so they didn’t connect much. What would be salt? Telegram mentions this server salt a lot. I never find the sense. See core.telegram.org/mtproto/Description in the part "Defining AES Key and Initialization Vector" it shows an algorithm for key definition and yes CPA is "Chosen-Plaintext Attack" from what I understand this attack is the modification of the encrypted string in order to change its real function, and a solution would be to use msg_key (which is the message hash) for comparison on the server afterwards, not?
– Elaine
"server salt" translates to "salt of server", ie a salt that comes from the server. About what is salt, I think this deserves a separate question, no? But for a quick reference, in that reply the salt is mentioned and its usefulness is briefly explained. I do not know if Chosen-Plaintext Attack That’s what you said, but anyway this discussion in comments is already too extensive... Why not open a new question like the one you made for Chosen-Ciphertext Attack?
– mgibsonbr
hahah agree, thank you!
– Elaine