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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
