3des cipher and DH group size

mancha mancha1 at hush.com
Sun Jan 26 00:31:25 EST 2014


Darren Tucker <dtucker <at> zip.com.au> writes:
> 
> On Fri, Jan 24, 2014 at 05:28:03PM +0100, Petr Lautrbach wrote:
> > On 01/21/2014 05:14 PM, Petr Lautrbach wrote:
> > > Hello everybody,
> > > 
> > > An issue was reported in RH bugzilla [1] about the size of the used DH
> > > group  when combined with the 3des-cbc cipher. OpenSSH uses the
> > > actual key length for the size estimation. This is probably fine as far
> > > as the cipher has the same number of bits of security as the key
> > > length. But this is not true for 3TDEA where the key size is 168 resp
> > > 192 but it's security is only 112.
> > > 
> > > Given that the key size in openssh is set to 192, DH group size is
> > > estimated to 7680. But according to NIST SP 800-57, the size of DH key
> > > should be 2048 so openssh doesn't follow that  and it might cause
> > > problems with key exchanges with some servers.
> > > 
> > 
> > It was confirmed that openssh can't connect to the server with a server
string
> > 'SSH-2.0-cryptlib' using diffie-hellman-group-exchange-sha1 and 3des-cbc
with
> > SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192).
> 
> Thanks for the patch.  Since we are so close to the 6.5 release I have
> committed a smaller change that should still resolve the problem
> (confirmed by checking the debug output for the requested group sizes).
> 
> Thanks.

Hi.

Not sure I'd characterize this commit as a "smaller change". It has
a much larger algorithmic footprint than Petr's patch.

Pre-commit, the dh group size requested was a function of
max(enc.key_len, enc.block_size, enc.iv_len, mac.key_len).

Post-commit, it is only a function of enc.key_len (or 14 for 3des).

Was this intended?

--mancha



More information about the openssh-unix-dev mailing list