Re: On 2K keys and SHA-256
Hi Rich, Am 08.09.2014 23:59, schrieb Salz, Rich: We are considering changing the default keysize (RSA, DSA, DH) from 1K to 2K, and changing the default signing digest from SHA-1 to SHA-256. May I suggest 4096 bit with SHA-256. That way you have a security level of = 128 bit for both primitives and as the weakest link counts ... Also: attacks only get better over time. We’ve already committed this to HEAD/master. We would like to make this change in the upcoming 1.0.2 release as well. Several downstream distributions, such as Debian, have already done this. Microsoft has already announced deprecation of SHA-1 certificates, and Google just recently posted a fairly aggressive plan for Chrome. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... Does anyone have strong objections? The only objection I have regarding this change is that originally intended one reflects only the bare minimum of the chosen primitives that you can widely use without being deprecated. Why aren't people thinking ahead for a moment and try to set defaults more to the middle of the practical range*. *for digests this unfortunately is SHA-256 through SHA-256 as GnuTLS 2.x (available on most Debian Stable boxes) barfs on anything else like SHA-384 or SHA-512. Kind regards, BenBE. -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me mailto:rs...@jabber.me Twitter: RichSalz signature.asc Description: OpenPGP digital signature
RE: On 2K keys and SHA-256
May I suggest 4096 bit with SHA-256. I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see much deployment because of the computational cost. At least, that's how we see things at my employer. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... If you can point me to patches, email, or whatever I can try to make sure those links get seen by folks in charge. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: On 2K keys and SHA-256
I think that 3K-RSA is the next step after 2K-RSA, and I am sure that the computational costs of a 4K-RSA certificate is much of an obstruction with current hardware and I think that it isn't a problem at all a couple years in the future. 2014-09-09 14:18 GMT+02:00 Salz, Rich rs...@akamai.com: May I suggest 4096 bit with SHA-256. I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see much deployment because of the computational cost. At least, that's how we see things at my employer. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... If you can point me to patches, email, or whatever I can try to make sure those links get seen by folks in charge. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: On 2K keys and SHA-256
On Tue, Sep 09, 2014 at 05:54:15PM +0200, Jeroen de Neef wrote: I think that 3K-RSA is the next step after 2K-RSA, and I am sure that the computational costs of a 4K-RSA certificate is much of an obstruction with current hardware and I think that it isn't a problem at all a couple years in the future. Have any numbers to back that up? The performance ratios are likely similar for recent and not so recent CPUs: signverifysign/s verify/s rsa 1024 bits 0.000385s 0.25s 2599.2 40210.7 rsa 2048 bits 0.002494s 0.78s401.0 12762.7 rsa 4096 bits 0.017500s 0.000284s 57.1 3527.3 On my CPU the sign/s ratios for the two steps are 6.5 and 7.0, which are quite significant. The performance gulf between 1024 and 4096 is rather wide, while the security gain from 2048 to 4096 is far from clear. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: On 2K keys and SHA-256
No, I do not have numbers to back it up, that is why my guess is that 3K-RSA is the next step after 2K-RSA. It also depends on what data you are planning to transport, and in what kind of organisation you are. 2014-09-09 18:21 GMT+02:00 Viktor Dukhovni openssl-us...@dukhovni.org: On Tue, Sep 09, 2014 at 05:54:15PM +0200, Jeroen de Neef wrote: I think that 3K-RSA is the next step after 2K-RSA, and I am sure that the computational costs of a 4K-RSA certificate is much of an obstruction with current hardware and I think that it isn't a problem at all a couple years in the future. Have any numbers to back that up? The performance ratios are likely similar for recent and not so recent CPUs: signverifysign/s verify/s rsa 1024 bits 0.000385s 0.25s 2599.2 40210.7 rsa 2048 bits 0.002494s 0.78s401.0 12762.7 rsa 4096 bits 0.017500s 0.000284s 57.1 3527.3 On my CPU the sign/s ratios for the two steps are 6.5 and 7.0, which are quite significant. The performance gulf between 1024 and 4096 is rather wide, while the security gain from 2048 to 4096 is far from clear. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: On 2K keys and SHA-256
On 09/09/2014 14:18, Salz, Rich wrote: May I suggest 4096 bit with SHA-256. I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see much deployment because of the computational cost. At least, that's how we see things at my employer. There was (some years ago) a heated debate between Certicom/NSA and the rest of the crypto community regarding the RSA sizes needed to match a given symmetric key security level. I don't know if it was ever resolved, but I guess some are going to use the old Certicom list to choose their RSA key sizes. Another, related problem is the large amount of patent FUD (and maybe real issues too) regarding the ECC patent situation, causing many applications to only use traditional RSA, DSA and DH, rather than their ECC counterparts. Until this problem is truly resolved for everybody (not just the OpenSSL project and the US Government), supporting even painfully slow RSA, DSA and DH key lengths is a practical necessity. Note that the only public guidance I have found on this was written by the NSA, which affects it credibility in the current international political climate. One problem which I recently encountered when using stunnel for a dedicated long running session is that OpenSSL 1.0.1 apparently rejects large client keys with SSL_accept: 1408E098: error: 1408E098:SSL routines:SSL3_GET_MESSAGE:excessive message size, which forced me to downgrade from 6K RSA to 4K RSA for the client auth. But this was for a dedicated link where the CPU overhead was acceptable. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... If you can point me to patches, email, or whatever I can try to make sure those links get seen by folks in charge. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: On 2K keys and SHA-256
Hi Rich, Am 09.09.2014 14:18, schrieb Salz, Rich: May I suggest 4096 bit with SHA-256. I think the next step after 2K-RSA is ECC, and that 4K RSA isn't going to see much deployment because of the computational cost. At least, that's how we see things at my employer. And Chrome+Firefox still happily uses MD5 to sign SPKAC after offering you to create Low (512), Medium (1024) or High (2048) grade encryption keys (patch available for ages BTW) ... If you can point me to patches, email, or whatever I can try to make sure those links get seen by folks in charge. Sure, there are 6 related bugs when searching for keygen on Mozilla's Bugzilla that effect the problem: Key size spec for KEYGEN tag: https://bugzilla.mozilla.org/show_bug.cgi?id=495876 (potentially doing a comma list of asymm+size - e.g. rsa2048,dsa2048,... - might be an option working for every cipher with ecc-* to wildcard all EC curves or !dsa to prohibit any DSA keys might be an option). 1024 bit option should be removed: https://bugzilla.mozilla.org/show_bug.cgi?id=649910 (or the default options modified to more sane values like 2048, 3072 and 4096) Automated tests for KEYGEN tag https://bugzilla.mozilla.org/show_bug.cgi?id=698315 (IIRC this one was the blocker for some of the other issues) Some more automated tests for KEYGEN tag https://bugzilla.mozilla.org/show_bug.cgi?id=960888 (IMHO low prio, but probably related) SPKAC signed with MD5withRSAencryption https://bugzilla.mozilla.org/show_bug.cgi?id=549460 (would be nice if this was done with SHA-2 - or I'd prefer using a setting to select between MD5 up to SHA-3, but optional on that setting) Increase options offered by KEYGEN tag https://bugzilla.mozilla.org/show_bug.cgi?id=495836 (IMHO one of the oldest issues in the list) For Chrome I can fire up a search on the bugtracker too if you like, but the issues should be similar. Also, when we are at client certificates: please remove the limit of sent client certificates: If I happen to have a certificate with such a long key (and Firefox happily imports them) you shouldn't get into trouble while using them. Will file a bug for the exact behaviour when I get around to it (related to the #747453 issue in Debian). Regards, BenBE. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org signature.asc Description: OpenPGP digital signature
Re: On 2K keys and SHA-256
No objection at all. Perhaps it might be worth checking that the other defaults are sane too at the same time though. e.g. x509 versions etc. Rich. On 8 September 2014 22:59, Salz, Rich rs...@akamai.com wrote: We are considering changing the default keysize (RSA, DSA, DH) from 1K to 2K, and changing the default signing digest from SHA-1 to SHA-256. We've already committed this to HEAD/master. We would like to make this change in the upcoming 1.0.2 release as well. Several downstream distributions, such as Debian, have already done this. Microsoft has already announced deprecation of SHA-1 certificates, and Google just recently posted a fairly aggressive plan for Chrome. Does anyone have strong objections? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rs...@jabber.me Twitter: RichSalz
RE: On 2K keys and SHA-256
No complaints from me for 1K or 2K, but...
Oh, sorry, this would be 1.0.2 and HEAD only. Not 1.0.1 or earlier.
--
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: rs...@jabber.me Twitter: RichSalz
:��IϮ��r�m
(Z+�K �+1���x ��h[�z�(Z+� ��f�y�� �f���h��)z{,���
