IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5
I'm not sure we're referring to the same attack. The most critical SSH + CBC attack I can think of right now is this:
http://isg.rhul.ac.uk/~kp/SandPfinal.pdf
This requires only a MITM position and allows recovery of up to 32 plaintext bits once per about ~200k intercepted connections. That's perfectly feasible if the connections are being automatically retried over some time without supervision (which is not unusual in deployment).
Our defense against this is to not obviously leak info about whether the result of packet length decryption was something sensible or not. But it may be that most implementations don't do this.
----- Original Message -----
From: Peter Gutmann
Sent: Thursday, November 12, 2015 20:49
To: denis bider
Cc: ietf-ssh%netbsd.org@localhost ; djm%mindrot.org@localhost ; terrafrost%gmail.com@localhost ; thierry.moreau%connotech.com@localhost
Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5
denis bider <ietf-ssh3%denisbider.com@localhost> writes:
>We default to CTR mode only now, given that OpenSSH disabled CBC last year,
>and our customers want to follow external recommendations, which are to
>disable CBC.
I've never used CTR for the reason I mentioned earlier, it may be worse than
the problem it's meant to be fixing. If you look at Wei Dai's attack, it's
pretty difficult to actually carry out, it's a chosen-plaintext attack that
assumes an attacker controls the plaintext, and requires that they wait around
observing a huge number of packets to get a collision on the bits they don't
control. Yeah, it's a theoretical weakness, but not one I'm losing much sleep
over.
OTOH CTR mode, which is a keystream generator (KSG), gives the attacker
complete control over the decrypted plaintext. Because of SSH's unfortunate
choice of MAC-then-encrypt, the victim has to act on attacker-controlled
metadata in order to verify the MAC and discover that the data was in fact
manipulated. Try the same thing in CBC mode and you'll just end up garbling
the block.
So my staying with CBC isn't laziness, it's because I consider the practical
(not theoretical, I mean CTR even has a security proof) risks of CBC to be
lower than CTR.
Peter.
Home |
Main Index |
Thread Index |
Old Index