----- Original Message -----
> From: "mancha" <mancha1@xxxxxxxx>
> To: openssh-unix-dev@xxxxxxxxxxx
> Sent: Friday, 14 February, 2014 5:32:16 PM
> Subject: Re: 3des cipher and DH group size
>
> 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.
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".
> > > 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.
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?
> > 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.
"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.
> > 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.
thing is, that the high end of the spectrum is not important to
normal people. And if you need 256 bit security you'll have to use
ECC anyway. As such, SSH's DH KEX inability to work with anything that
provides more than 128bit or 192bit of security is moot anyway.
> > 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?
OK, then let's round ECRYPT II recommendations up and use them like this:
3des - 3072 bit DH
aes-128 - 4096 bit DH
aes-192 - 8192 bit DH
aes-256 - 8192 bit DH (because of protocol limitations)
That will be compatible with such broken implementations when using
2 popular block ciphers and still provide more security than old
versions of OpenSSH and meet NIST recommendations in all cases
but aes-256.
> > > 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.
I'm not saying that it is RFC compliant. I'm saying that openssh
can interoperate with it without compromising security.
--
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
