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