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, dtucker at zip.com.au, "Petr Lautrbach" <plautrba at redhat.com>
> Sent: Thursday, 13 February, 2014 5:08:15 AM
> Subject: Re: 3des cipher and DH group size
> 
> On Wed, 12 Feb 2014, Hubert Kario wrote:
> 
> > The previous version did bind cipher to DH sizes so this expectation was
> > met.
> 
> Yes, but using obsolete symmetric/DH group size equivalences.

By "previous" I mean the version of the patch that didn't effectively use
HMAC key size as the requested DH param size.
I do not mean the previous version of OpenSSH.

Let me be clear: what I want to see is 2048 bit DH when 3des is selected,
3072 bit DH when AES-128 is selected and 7680 bit DH when AES-192 is
selected. I also very much like that the new OpenSSH uses better algorithms
for selecting the DH key size.

But we also have to remember that openssh is not used in a vacuum, so
interoperability is just as important as security. If I'm forced to
use old version of OpenSSH (possibly with known bugs) to connect to a server
that implements only a small subset of crypto OpenSSH is able to use,
all this work is for nought.

> > Problem is, that now when you're running in FIPS mode the chosen HMAC
> > in worst case is sha1-based so the DH moduli end up being 7680 bits in
> > size even when the selected cipher is 3DES:
> 
> Which is the correct recommended length for a 160-bit key according to
> NIST.

It would be recommended if we were talking about symmetric encryption.
But we're talking about MAC.

See NIST SP 800-57, rev 3, pages 63-65.

Table 2:
Appropriate D-H parameter size for 3DES (112 bits) is 2048, for AES-128 is
3072.

Now, if you take a look at Table 3, you can see that if you want to use
appropriate HMAC with those symmetric algorithms you can use *any*
SHA-family hash, from SHA-1 up to SHA512.

Reading further, section 5.6.3, if I use SHA-512 HMAC with 2048 bit RSA
keys and AES-128 cipher I don't magically get a system with 512 bits of
security. I get a system that has only 112 bits of security (see point 1
and 2 therein) because 2048 bit RSA is the weakest link.

So like I already said, there is no point in choosing DH parameters
based on security of the most secure primitive used, because it does not
increase the security of the system as whole. What we *need* to do is make
sure that the chosen DH parameters don't *lower* the security of the system.

> 
> (It's ironic that you're effectively arguing to ignore NIST advice to
> make FIPS mode work)

SP 800-57 rev 3, section 5.6.1 Comparable Algorithm Strengths, point 3:

> Column 3 indicates the minimum size of the parameters associated
> with the standards that use finite-field cryptography (FFC). Examples
> of such algorithms include DSA as defined in [FIPS186] for digital
> signatures, and Diffie-Hellman (DH) and MQV key agreement as defined
> in [SP800-56A], where L is the size of the public key, and N is the
> size of the private key. The largest key size *approved* in [FIPS186]
> is (L = 3072, N = 256), and the largest key size *approved* in
> [SP800-56A] is (L = 2048, N = 256).

As you can see, any DH over 3072 bit in size is *not* FIPS compliant.

So while I think that introducing a top bound (especially such low)
for a crypto system is excessive, cryptlib refusing 7680 bit DH is in
the clear as far as FIPS is concerned.

> > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent
> > 
> > as a result, connection to cryptlib server in FIPS mode doesn't work.
> 
> We can't help other broken implementations.
> 
> Easy workarounds include using ECDH and specifying explicit KexAlgorithms.

Problem is, it doesn't support ECC. And while it can be argued that it is
broken (protocol-wise), it still can be used securely according to the
newest standards.



As for security estimation of truncated HMAC and using key vs using the hmac
output size I recommend reading SP 800-107, section 5.1 in particular:

> Truncating the message digest can impact the security of an application. By
> truncating a message digest, the expected collision resistance strength is
> reduced from L/2 to λ/2 (in bits). For the example in item 2 above, even
> though SHA-256 provides 128 bits of collision resistance, the collision
> resistance provided by the 96-bit truncated message digest is half the
> length of the truncated message digest, which is 48 bits, in this case. 
> The truncated message digest of λ bits provides an expected preimage
> resistance of λ bits, not L bits, regardless of the hash function used.

So using only the key size as the security estimate of HMACs is completely wrong!

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