Re: On 2K keys and SHA-256

[Benny Baumann]

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  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  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  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  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

[Jakob Bohm]

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

[Jeroen de Neef]

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 :

> 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

[Viktor Dukhovni]

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

[Jeroen de Neef]

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 :

> > 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

[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.

/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

[Benny Baumann]

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  Twitter: RichSalz
> 
>  
> 




signature.asc
Description: OpenPGP digital signature

RE: On 2K keys and SHA-256

[Salz, Rich]

> 
> 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{,���

Re: On 2K keys and SHA-256

[Jeffrey Walton]

On Mon, Sep 8, 2014 at 5:59 PM, Salz, Rich  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.

No complaints from me for 1K or 2K, but...

$ cd openssl-1.0.1i
$ grep -R 512 * | grep -v -i sha
...
apps/dhparam.c:#define DEFBITS512
apps/enc.c:#define SIZE(512)
apps/gendh.c:#define DEFBITS512
apps/gendsa.c:#define DEFBITS512
apps/req.c:#define DEFAULT_KEY_LENGTH512
...

*

The change of the default hash could be painful because its currently
hard coded in some places. It may (or may not) effect signing
behavior. The potential problem is down level clients may not be able
to interop because they can't make a selection. (I encountered it some
time ago, but I don't have a reference because I don't recall the
details).

Jeff
__
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

[Richard Moore]

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  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
>
>
>