----- Original Message ----- > From: "Damien Miller" <djm@xxxxxxxxxxx> > To: "Hubert Kario" <hkario@xxxxxxxxxx> > Cc: "mancha" <mancha1@xxxxxxxx>, openssh-unix-dev@xxxxxxxxxxx > 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@xxxxxxxxxxx", SSH_CIPHER_SSH2, 16, 16, 12, 16, 0, 0, EVP_aes_128_gcm }, { "aes256-gcm@xxxxxxxxxxx", 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@xxxxxxxxxxx", 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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
