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: "mancha" <mancha1 at hush.com>, openssh-unix-dev at mindrot.org
> Sent: Saturday, 15 February, 2014 12:39:39 AM
> Subject: Re: 3des cipher and DH group size
> 
> On Fri, 14 Feb 2014, Hubert Kario wrote:
> 
> > Suite B for secret (effectively 128 bit security) communication
> > allows use of AES only in GCM or CTR mode. RFC 6239
> > specifies that SSH in Suite B must use AES in GCM mode.
> > IV of AES 128 in GCM mode as used in SSH is 12 octets (96bit).
> > 
> > How do you explain this disparity?
> 
> Since you seem disinclined to go and read about AES-GCM for yourself,
> I'll point out that the remaining 32 bits are an implicit block counter.
> 
> See https://tools.ietf.org/html/rfc5647 section 7.1

Yes, I know that. The point I was arguing is that exact size of IV
is not the exact upper limit for security estimate of the cipher.

I've read both the SSH and IPsec RFCs related to AES GCM.
They both refer to the truncated value as IV. Quite rightfully so, as
those remaining bits are completely predictable to the attacker.
The other thing is that for 256 bit or 196 bit keys, they still use "only"
128 bit as the combined "IV".

This is also how iv_len field for aes-gcm ciphers is defined and used
in openssh. Its value for aes-gcm is 12 octets:

cipher.c:97:

    { "aes128-gcm at openssh.com",
            SSH_CIPHER_SSH2, 16, 16, 12, 16, 0, 0, EVP_aes_128_gcm },
    { "aes256-gcm at openssh.com",
            SSH_CIPHER_SSH2, 16, 32, 12, 16, 0, 0, EVP_aes_256_gcm },

The same value of 12 octets is used to calculate the proposed dh size:

kex.c:518:
        dh_need = MAX(dh_need, newkeys->enc.iv_len);

Similar situation is with regards of block_size. As it was already
stated, both are a noop. What's worse, they are confusing since the
relation between IV, block size and cipher security level is not this
simple and certainly those sizes are not the upper or lower bound.

That's why I think the code as proposed by Darren Tucker is closest to
being the best.

In depth rationale and proposed code follow.

Since breaking MAC requires most resources (requires real-time
attack on the hash), it is therefore the least likely to be successfully
performed. Breaking DH or cipher on the other hand can be done offline
and provide useful information even decades after the connection took place.
Breaking the host keys doesn't give such information and is useful 
only for online attacks, so attacks on RSA, ECDSA are second most likely.

As such, binding the size of DH parameters to specific block ciphers
makes the most sense.

This can be done in two ways. Either by adding new column to ciphers[],
which I don't think is particularly clean. Or by reusing key_len value
as the security estimate and providing an exception mechanism,
noting in the ciphers[] definition that such exception mechanism (cipher_seclen())
exists is important!

Since there are no differences between ENISA and NIST recommendations
and the differences between ECRYPTII and NIST are insignificant for the
values we can use (because of protocol limitations), I think we should use
NIST recommendations for DH - block cipher equivalence.
I also think that we should not propose DH sizes below 2048 bit in any case,
as recommended in SP 800-131A.

So, I think that the code in kex.c in kex_choose_conf() should look like this:

        dh_need = 14;
        dh_need = MAX(dh_need, cipher_seclen(newkeys->enc.cipher));
    }
    kex->we_need = need;
    kex->dh_need = dh_need;

And code in cipher.c should look like this:

u_int
cipher_seclen(const Cipher *c)
{
    if (strcmp("3des-cbc", c->name) == 0)
        return 14;
    if (strcmp("chacha20-poly1305 at openssh.com", c->name) == 0)
        return 32;
    return cipher_keylen(c);
}


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