-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 03.07.2014 14:08, schrieb Hubert Kario: > ----- Original Message ----- >> From: "Benny Baumann" <be...@geshi.org> To: >> openbsd-t...@openbsd.org, openssl-dev@openssl.org Sent: >> Wednesday, 2 July, 2014 8:49:18 PM Subject: [PATCH] >> LibReSSL/OpenSSL: Adjust/remove keysize restrictions >> >> Hi folks, >> >> I know the following patches will cause a controversy just like >> the issues they resolve caused me and several other people >> headaches when debugging them. >> >> But first things first. The attached patches (intentionally) do >> the following two things: >> >> 1. Adjust the limit for maximum allowed size of a received public >> key to be increased from 516 bytes (just barely enough for 4 KBit >> RSA public keys) up to 8200 bytes (enough for 64KBit RSA keys >> with some minor margin) >> >> 2. Remove the crippling of the DH/DSA routines for working with >> at most 10kBit parameters. > > Current general recommendation is that if you require more than 128 > bit security you shouldn't be using RSA or DHE in the first place > but use ECC. It's a recommendation. But it doesn't hurt to have alternatives at hand.
Also with the NIST curves most likely backdoored there might exist people that don't consider them their first option. - Given Curve25519 not being in the affected versions this bug refers to (everything before 1.0.2*). > > Just generating 16k DH params takes inordinate amount of time. Point taken - Although you won't do that every other SSL connection just for fun. DH parameters are lng-term and thus you'd probably keep them for at least 2-3 years if not even longer. > With 4096 bit DH parameters I'm getting less than 20 key exchanges > a second with a fast i7 CPU. I'd hazard a guess that with 16k DH > you'll be able to do less than 1 key exchange a second. You won't use such a config on a high traffic site; that's for sure. In my case the config is for server-to-server connections between XMPP servers - and thus rate-limited by default. > > That's a very neat way to DoS your server. Done wrong most crypto is a neat way to shot your feet and rip your legs off while at it. > > I won't even mention the whole issue of actually configuring TLS > for more than 128 bit security... > The most difficult thing in getting the configuration above 128 bit was less to generate appropriate key material, but to figure out in which ways the cipher suite setup API breaks - having GnuTLS less broken in this regard than OpenSSL. (Valid for recent versions of GnuTLS) SECURE256:-CIPHER-ALL:+COMP-DEFLATE:-MAC-ALL:!MD5:!ANON-DH:-3DES-CBC:-CAMELLIA-256-CBC:!CAMELLIA-128-CBC:-AES-256-CBC:!AES-128-CBC:+VERS-TLS1.2:+VERS-TLS1.1:+AEAD:+SHA512:+SHA384:+SHA256:+AES-256-GCM:+SHA1:+VERS-TLS1.0:-DHE-RSA:-RSA:+DHE-RSA:+DHE-DSS:+RSA:+SRP:+CAMELLIA-256-CBC:+AES-256-CBC:-VERS-SSL3.0:%SERVER_PRECEDENCE Not to mention that SECURE_256_ still contains 192 bit ciphers. Kind regards, Benny Baumann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJTtmWWAAoJEPHTXLno4S6t5bcP/0O0aGQZtz2z69rgp3KXIokS ls0rcMNbg8waebSgfl/6bVI4nLQNwRSFJwfElDzWR1BCtNjRpiWtFGcQqczfuGV5 mIsNsNQdvm6PwnPLqCfrf/O4nq5ibR8p3PfVBCdUZaTTmW8YS7Kj53z1B4wqRfxw 85kcY1ZxcpHUgxoyzoDK/cBoWvPqieqZ6RKxxXkDXN/XObwTwb/pid3aLbspmJrs yrP1Bsyh2LoDuua7rfS2g1nI0MaUxQD1sGqhVWK/1ugeWFrMNDRhAgSdqnuGtroN SIwpvWWCufEXG0hxpitqwocn23nZ+nd7SMqWWlzR3/eCREor3J4xhlMHKY48OALd Ab+BsNEfSjBfGsOg74Sp8PyEwZQvZex7yOudm+RR0r1ktnKJskEZwHqH+t3NJzSf Rn6Z4ToPi9QSw/y4C0U/joWhBZI+e23MEa4FKY7r7FXnbxyRSUc2rgEEyXdYa4mW zcvRc5JMTaee1W1vYRf2N1ZWQPpyv2rMu26x6f50HRPttMRky/LFdy2KAL/+SaqA MjRUaKodnNNVkhGeEfC0lQB+cDQ5ZAv+TOEj2oblSb3VjRNiYzsf3sCZ+KQn+oQ0 xdiapES/mgmFrGQswSJQDb3ROMPjzm1lS1WG457L7BGyNptqmvJE5tfpv23yEkwP tcTadAeK/3z9ey8mgx6h =+zK7 -----END PGP SIGNATURE----- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
