prefer etm MACs #66
Comments
|
@atomic111 what do you think? |
|
@bkw thank you very much for bringing this up |
|
My reason for saying that is things tend to go wrong when you use primitives for things they were not designed to do. When using EtM you have a security proof conditional on the security of the cipher and the MAC. In case of E&M, we are assuming the MAC doesn't leak anything about the plaintext. I think this is true for HMAC, I have no idea about UMAC. The attack is exploiting the potential timing difference between decryption failure and verification failure. I think this is not a problem if we use CTR ciphers because decryption can't fail. It is possible to implement E&M correctly but it's nearly impossible to screw up EtM. You have a bunch of "I think"s and that should not be reassuring because I am not a real cryptographer. We don't know how but we do know that the NSA is breaking SSH. They either found some bug like that or they have a mathematical advantage that reduces the effective security from 128 bits to something breakable. In the first case, EtM is more important, in the second case the security margin from the extra bits can save your data. I suspect the first. |
See: * dev-sec/chef-ssh-hardening#66 * https://stribika.github.io/2015/01/04/secure-secure-shell.html Signed-off-by: Dominik Richter <dominik.richter@gmail.com>
See:
* dev-sec/chef-ssh-hardening#66
* https://stribika.github.io/2015/01/04/secure-secure-shell.html
Signed-off-by: Dominik Richter <dominik.richter@gmail.com>
See:
* #66
* https://stribika.github.io/2015/01/04/secure-secure-shell.html
Signed-off-by: Dominik Richter <dominik.richter@gmail.com>
|
inclued in chef-ssh-hardening v1.0.3 |
See: * dev-sec/chef-ssh-hardening#66 * https://stribika.github.io/2015/01/04/secure-secure-shell.html Signed-off-by: Dominik Richter <dominik.richter@gmail.com>
Our order of MACS currently is this (on my ubuntu-14.04 system)
https://stribika.github.io/2015/01/04/secure-secure-shell.html by @stribika recommends the following order:
Leaving aside the fact that he includes umac-128@openssh.com (which we don't), I find it interesting that he prefers the use of Encrypt-then-MAC over longer key lengths. Not being a cryptographer, I'm somewhat cargo-culting this argument, but "Only Encrypt-then-MAC should be used, period" is a strong statement by somebody who obviously is more knowledgable about these matters than I am.
What do you guys think?
The text was updated successfully, but these errors were encountered: