prefer etm MACs #66

Closed
bkw opened this Issue Jan 7, 2015 · 5 comments

Comments

Projects
None yet
4 participants
@bkw
Contributor

bkw commented Jan 7, 2015

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?

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Jan 7, 2015

Member

@atomic111 what do you think?

Member

chris-rock commented Jan 7, 2015

@atomic111 what do you think?

@chris-rock

This comment has been minimized.

Show comment
Hide comment
@chris-rock

chris-rock Jan 7, 2015

Member

@bkw thank you very much for bringing this up

Member

chris-rock commented Jan 7, 2015

@bkw thank you very much for bringing this up

@stribika

This comment has been minimized.

Show comment
Hide comment
@stribika

stribika Jan 7, 2015

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.

stribika commented Jan 7, 2015

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.

@arlimus

This comment has been minimized.

Show comment
Hide comment
@arlimus

arlimus Jan 12, 2015

Member

@bkw Thanks for bringing this up!
@stribika Thank you for your great blog post! It helped a lot in getting the hang of EtM.

We've been discussion the new mac priority since last week. It should be updated this week, if all goes well.

Member

arlimus commented Jan 12, 2015

@bkw Thanks for bringing this up!
@stribika Thank you for your great blog post! It helped a lot in getting the hang of EtM.

We've been discussion the new mac priority since last week. It should be updated this week, if all goes well.

arlimus added a commit to dev-sec/ssh-baseline that referenced this issue Jan 13, 2015

reprioritize etm macs
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>

@arlimus arlimus referenced this issue in dev-sec/ssh-baseline Jan 13, 2015

Merged

reprioritize etm macs #41

arlimus added a commit to dev-sec/puppet-ssh-hardening that referenced this issue Jan 13, 2015

reprioritize etm macs
    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>

arlimus added a commit that referenced this issue Jan 13, 2015

reprioritize etm macs
    See:

    * #66
    * https://stribika.github.io/2015/01/04/secure-secure-shell.html

Signed-off-by: Dominik Richter <dominik.richter@gmail.com>

@arlimus arlimus closed this Jan 14, 2015

@arlimus

This comment has been minimized.

Show comment
Hide comment
@arlimus

arlimus Jan 14, 2015

Member

inclued in chef-ssh-hardening v1.0.3

Member

arlimus commented Jan 14, 2015

inclued in chef-ssh-hardening v1.0.3

arlimus added a commit to dev-sec/ssh-baseline that referenced this issue Oct 15, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment