Subject: Re: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5

From: denis bider <[email-masked]>
Date: Fri, 13 Nov 2015 12:53:10 +0000

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: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
Subject: RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5

denis bider <[email-masked]> 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.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 15 Nov 2015 10:49:49 +0000

>http://isg.rhul.ac.uk/~kp/SandPfinal.pdf

Ah, OK, I was thinking of the original attack(s) that motivated the suggestion
to use CTR.

>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).

Hmm, I wouldn't necessarily call it a feasible attack, more a certificational
weakness (meaning the protocol doesn't meet its design requirements).

>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.

Same here, I do a lot more rigorous checking than OpenSSH (as described in the
paper) does, checking lengths, packet types, and padding size, and the
disconnect notification is an empty string.  As you say though, the problem
isn't necessarily your code but the other side.  OTOH I think that an
implementation that does little checking and so is particularly vulnerable
probably won't know about using CTR mode either...

Peter.