3des cipher and DH group size

[mancha]

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

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

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

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

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

--mancha