RE: New version of rsa-sha2-256 draft: Back to PKCS#1 v1.5
Peter Gutmann <[email protected]>
| Newsgroups | gmane.ietf.secsh |
|---|---|
| Message-ID | <9A043F3CF02CD34C8E74AC1594475C73F4B64A2E@uxcn10-5.UoA.auckland.ac.nz> |
denis bider <[email protected]> writes: >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 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.