OpenSSH and CBC

Gerhard Wiesinger lists at wiesinger.com
Tue Jun 16 21:14:39 AEST 2015


On 16.06.2015 11:52, Gerhard Wiesinger wrote:
> On 15.06.2015 21:31, Christian Weisgerber wrote:
>> On 2015-06-15, Gerhard Wiesinger <lists at wiesinger.com> wrote:
>>
>>> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is
>>> CBC therefore considered as broken and unsecure (in general or SSH
>>> implementation)?
>> CBC modes in SSH use the last encrypted block of the previous packet
>> as the IV for the next packet.  The protocol is specified this way.
>
> As the new IV depends on the (unknown) key and an unbroken crypto/hash 
> algorithms I don't see any problem with this assuming normal behaviour 
> with new keys on a new connection and correct implementation. Am I wrong?
>
>>
>>> I also read a lot of references (see below) but still not clear to me
>>> what's the actual "security status" of CBC and why it has been removed
>>> in general.
>> These are pertinent:
>>
>>> http://www.kb.cert.org/vuls/id/958563
>> http://www.openssh.com/txt/cbc.adv
>>
>
> But that should be already covered by:
> http://www.openssh.com/txt/release-5.2
> We believe that these attacks are rendered infeasible by these changes.
>
> BTW: If you didn't know, here you find the details about the attacks 
> (already in my link list):
> http://isg.rhul.ac.uk/~kp/SandPfinal.pdf
> I think it was unknown at the time OpenSSH 5.2 was released.
> E.g. some assumptions are wrong: After at most 2^14 connections ...
> With each new ssh connection I will have a new symmetrical key so the 
> assumption is not feasible.
>
> Also: One of the main challenges for building an exploit based on our 
> proof-of-concept code would be to find a service which tolerates SSH 
> connection failures and reconnects on these failures.
> I think such assumptions are just theoretical.
> Also according to the paper encrypt then-MAC schemes are also 
> vulnerable (which are considered secure): But it is not hard to see 
> that this construction would still be vulnerable to our attacks.
>
> There is another paper available: Some Fixes To SSH
> https://eprint.iacr.org/2013/151.pdf
>
> BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they 
> disclose packet length.
> https://wiki.mozilla.org/Security/Guidelines/OpenSSH
> Any comments on this?
>

Jan answered me, as the packet length is transmitted in plaintext, see:
http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html

Ciao,
Gerhard

-- http://www.wiesinger.com/



More information about the openssh-unix-dev mailing list