3des cipher and DH group size

[Hubert Kario]

----- Original Message -----
> From: "mancha" <mancha1 at hush.com>
> To: openssh-unix-dev at mindrot.org
> Sent: Friday, 14 February, 2014 7:49:21 PM
> Subject: Re: 3des cipher and DH group size

Why you're completely ignoring any of my suggestions for a compromise?

I already stated few times that I consider the changes that better align
openssh to NIST SP 800-57 to be a good thing.

My main point is that the changes don't follow this recommendation to the
letter and because of that interoperability suffers.
 
> Hubert Kario <hkario <at> redhat.com> writes:
> > > P=NP is still unsolved. Having more pigeons than holes is not.
> > 
> > You're telling one thing, multiple established standards tell another.
> > 
> > If this was as easy as pigeonhole principle, someone would have called it
> > by now. So unless you have at least one paper with hard math that says
> > the same thing, I'm saying "not true".
> 
> http://lmgtfy.com/?q=initialization+vector+birthday+paradox

Let's see, the second top result (Computer and Information Security Handbook
by John R. Vacca) has this text in it:

> Using electronic code book mode on a message longer than a single
> block leaks a bit per block.

So even when I use no IV what so ever, encrypting few blocks is secure.

Another first page result, the "Stream Cipher" by Andreas Klain says:

> As a practical consequence we must require that an initialization vector
> is never used twice. If we want to use 2^k sessions the birthday paradox
> forces us to work with an initialization vector of length 2^2k.

I already said "it mostly influences how much plaintext you can
encrypt with the same key":
http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-February/032182.html

So I still consider "IV size == cipher security" as not true.

Both IV size and block size have impact on security of the cipher, but they
are not as simple as security_estimate=min(IV_size, block_size, key_size) or
security_estimate=max(IV_size, block_size, key_size)!

> > > Poor cryptographic decisions should be corrected not emulated and
> > > perpetuated.
> > 
> > People's lives depend on security of systems that at best provide 80 bit
> > of security.
> > 
> > I'm saying that there is no point of using anything past 128 bit
> > with default settings if this hampers interoperability.
> > 
> > That's a 281474976710656 times difference!
> > 
> > You really don't see that?
> 
> You might be one of the few people left who are advocating for weak
> cryptographic primitives. Were you also upset when OpenSSL deprecated
> MD2?

I'm advocating for using sensible *sets* of cryptographic primitives.

using 3DES, 2k RSA, 2k DH together with SHA-1 makes sense (mostly because MD5 is deprecated)
using 3DES, 2k RSA, 7k DH together with SHA-1 does not make sense
using AES-128, 3k RSA, 2k DH together with SHA-1 does not make sense

> > > Who knows what "normal person" or "relatively secure" mean. That's
> > > why we develop standards and objective guidelines instead.
> > 
> > "normal person" - people that don't know about existence or purpose
> > of /etc/ssh/moduli
> > 
> > "relatively secure" - 128bit, a.k.a. SECRET as used by NATO.
> > 
> > Using 7k DH with 3DES and AES-128 is not the effect of those guidelines.
> > 
> 
> I choose standards and objective guidelines over your personal
> definitions of "relatively secure" and "normal person".

The standards say quite explicitly: iff 3DES => 2k DH. iff AES-128 => 3k DH.
They don't say if SHA-1 MAC => 7k DH.

But that's what current code is doing.

FIPS (it even has "Standard" in the name) says that we shouldn't use
DH with keys over 3072 bits, ever. Why you're not following it?
 
> > > > At 128 bit ECRYPT II recommends 3248 bit DH, not 7168.
> > > > ENISA also recommends 3072 bit DH at 128 bit security level[1].
> > > 
> > > At 128 bits of security, NIST recommends 3072 bit DH and ECRYPT
> > > II recommends 3248 bit DH.
> > > 
> > > if(3248>3072) printf("math is nice\n");
> > 
> > that's less than 4 bit difference in security level, you really want
> > to argue about "times 16" difference?
> > 
> 
> Huh? My initial statement was that ECRYPT II recommends higher DH
> bit sizes than NIST at every security level. Why exactly do you
> keep debating this provable fact? FYI: facts are stubborn things.

The other fact is that the "112 bits" security of 3DES is not entirely equal
the security of "112 bits" of ~2k RSA or DH (be it the NIST or ECRYPT II value).
They require different hardware and different breakthroughs in mathematics
for cracking.

The values are just estimates, and you're insisting on using the
exact values of those estimates.

I also said that if you consider the higher values from ECRYPT II to be
more trustworthy estimates I don't have a problem with using even much
higher values.

You're nitpicking and completely ignoring my main point.

> > > > 
> > > > That was the first thing I tried, unfortunately, not supported by
> > > > the cryptlib server in question.
> > > 
> > > Sorry to hear cryptlib breaks yet another RFC. RFC 4253 requires
> > > Oakley group 14 support.
> > 
> > I'm not saying that it is RFC compliant. I'm saying that openssh
> > can interoperate with it without compromising security.
> 
> Fix what's broken so it works with what's not broken. Don't break
> things that aren't broken so they work with what's broken.

I don't see how insisting on usage of DH <= 4k if and *only* if
the ciphers are 3DES or AES-128 is "breaking things".

Why you're ignoring the fact that it's the original change to dh param
size calculation that did break things? We are discussing a fix for
this new breakage introduced in openssh 6.5.

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