3des cipher and DH group size

[Hubert Kario]

----- Original Message -----
> From: "Damien Miller" <djm at mindrot.org>
> To: "Hubert Kario" <hkario at redhat.com>
> Cc: openssh-unix-dev at mindrot.org
> Sent: Tuesday, 4 February, 2014 11:42:31 PM
> Subject: Re: 3des cipher and DH group size
> 
> 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.

I agree with that. Thing is I don't see a reason to use key exchange that
provides much more keying material that the cipher can use.

If I'm trying to connect to old, embedded, SSH server that implements crypto in
hardware the difference between 2048 bit and 3076 bit DH may be the
difference between working and not working. As the patches
stand now, I'm unable to force SSH to suggest 2048bit DH, no matter which
combination of key exchanges, MACs, host keys or ciphers I use.

If the cipher provides 112 bits of security, hash provides 96 bits of
security and host key provides 80 bits of security there is no reason
to select key exchange that provides 128 bits of security, is there?

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

How does birthday bound on block size affect block ciphers? Can you point
me to some literature on this? From what I know, a cipher with block_size > key_size
would produce biased output.

> > +		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?

Well, IV is used to provide randomness in case of key-plaintext pair
reuse/collision. So it mostly influences how much plaintext you can
encrypt with the same key.

I mean, how else would AES-GCM ciphers (which use 96bit IVs) be
considered secure (let alone state of the art) if that wasn't the case?

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

I meant that truncated mac doesn't provide the same security as
non-truncated version. So making sure that there are at least 128 bits
of entropy in key of a MAC with 96 bit output is not necessary.
There's a KDF between DH output and MAC input.

As far as I read the code, dh_need is used to calculate the needed
amount of entropy/security margin, not the actual amount of bits needed
to feed to different primitives, the "need" variable is used for that, isn't it?

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


-- 
Regards,
Hubert Kario
BaseOS QE Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic