3des cipher and DH group size

[Damien Miller]

On Tue, 4 Feb 2014, Hubert Kario wrote:

> Hi all!
> 
> Continuing the discussion from https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/032037.html
> 
> I have looked at the changes made to implement automatic selection of DH
> groups and there are few changes confusing to me, to say the least.
> 
> Especially 1.97~1.96 rev diff of kex.c:
> 
> > +		 dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher));
> 
> Why "MAX("? Why security of chosen dh moduli should match the _most_
> secure primitive? Since DH KEX is computationally expensive (think smartphones),
> shouldn't we try to use as small DH parameters as possible?

I think that it's reasonable for users, when they select a cipher of a
given strength, to expect that ssh actually provides enough key material
to properly use it.

> > + 		dh_need = MAX(dh_need, newkeys->enc.block_size);
> 
> This is plain confusing. Which cipher's security level is influenced by its
> block size?

All of them because of the the birthday bound. In OpenSSH's case, this is
a noop since all our ciphers have key_len >= block_size.

> +		dh_need = MAX(dh_need, newkeys->enc.iv_len);
> 
> I'd also say that the relationship between IV size and and security estimate
> is a bit more complex. I.e. IV of size 96 bits won't lower the security level
> of whole system to 96 bits.

Really? If a cipher requires a random IV of a certain size then I think
we should be ensuring that the key exchange output can actually provide
it. But again, this is a nop; we don't currently have any ciphers where
iv_len > key_len;

> +		dh_need = MAX(dh_need, newkeys->mac.key_len);
> 
> Shouldn't this use mac.mac_len? I mean MACs like hmac-md5-96 provide
> 96 bits of security, not the 128 bits from key size.

While truncated MACs are common, I've never heard of anyone recommend
truncating the key along with it.

-d

[1] https://anongit.mindrot.org/openssh.git/commit/dh.c?id=df62d71e64d29d1054e7a53d1a801075ef70335f