Why is there a warning about encrypt-and-mac?
Closed this issue · 5 comments
We tested some of our OpenSSH servers with ssh-audit and noticed a couple of "using encrypt-and-MAC mode" warnings. I am a cryptography expert and I do not understand why there is a warning? I do not know of any security weaknesses in encrypt-and-mac. E.g. "hmac-sha2-256" is a perfectly safe algorithm. Why is there a warning? One should never use mac-then-encrypt, but this is not the case here? Can you explain about that?
Give https://moxie.org/2011/12/13/the-cryptographic-doom-principle.html a read
Edit (01Jan2022): came here to get this link and it was dead, updated to the new format
Hello, Plloi and thanks for your answer. This is exactly what I meant: Moxie (and other cryptographers) say that MAC-then-Encrypt is a very bad idea. However, hmac-sha2-256 is "Encrypt-then-MAC" which Moxie describes in his blog post as "The third way, 'encrypt-then-authenticate,' is optimal because it does not violate the doom principle." So, there should be no warning about an "optimal" way to handle HMACs.
I'm not an expert so I may be wrong, but i believe the ssh implementation of hmac-sha2-256 is encrypt-and-MAC, there is a separate option hmac-sha2-256-etm that is encrypt-then-MAC
Hi, Shaun and thank you for showing me where to look. I knew about "MAC-then-encrypt" and "Encrypt-then-MAC" but I did not know what "encrypt-and-MAC" meant. I could not find anything about that in the OpenSSH documentation. As I read here this means to calculate the MAC of the clear text and append it to the encrypted text. This is wrong, of course. The only save way to go is "encrypt-then-MAC" which appends the MAC of the encrypted text. So, thanks for pointing this out and, yes, you are right, one should only use the options ending in "-etm" and now I understand the warning. You made my day :-).
No problem, glad i could help