3des cipher and DH group size

[mancha]

Hubert Kario <hkario <at> redhat.com> writes:
> > I'll leave the particulars of birthday collisions and how
> > they link IV length and block size to security level as an
> > exercise to the reader.
> 
> <sarcasm>"Proving that P is equal NP is trivial and left as an exercise
> to the reader"</sarcasm>
> 
> I already asked for literature on the subject. No book or standard
> I read stated anything to the effect of "IV size" == "security estimate".

P=NP is still unsolved. Having more pigeons than holes is not.

> > I would be extremely uncomfortable if security
> > infrastructure I relied on constrained its cryptographic
> > primitives - potentially to the detriment of overall
> > security - in order to facilitate use with phones,
> > consumer-grade routers, or other devices characterized
> > by limited processing power.
> 
> People have been doing that for the past 60 years in cryptography.
> 
> 95% of Internet still uses SHA-1 certificates! Including
> online banking.

Poor cryptographic decisions should be corrected not emulated and
perpetuated.

> All my suggestions are already way past the levels any normal person or
> business needs. Those people that actually require higher
> security won't be using defaults if they have any clue
> what so ever.
> 
> I want the defaults to be relatively secure and provide maximum
> interoperability.

Who knows what "normal person" or "relatively secure" mean. That's 
why we develop standards and objective guidelines instead.

> Security levels above 128 bit realistically have any meaning
> only if algorithms are broken or quantum computers
> come into play.
> 
> In both cases all bets are off.

That's a longer debate. My point is OpenSSH already deviates
its equivalences downwards from NIST recommendations at the high
end of the spectrum.

> 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");
 
> > Finally, if HW/SW limitations of embedded devices or
> > non-compliant servers is of major concern and you want to
> > force a 2048-bit DH modulus, why not use Oakley group 14?
> > That's an RFC 4253 REQUIRED.
> 
> 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.

--mancha