Subject: Support for hash algorithms other than SHA-1

From: Russ Housley <[email-masked]>
Date: Wed, 22 Jun 2005 09:45:25 -0400

Section 3.4.3.2 of RFC 3851 says:

    The SHA-256, SHA-384, and SHA-512 algorithms [FIPS180-2] are not
    currently recommended in S/MIME, and are included here for
    completeness.

I think it is time to revisit this decision.  I think the standard needs to 
accept longer hash functions, at least with the RSA signature algorithm.

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 23 Jun 2005 13:15:09 +1200

>accept longer hash functions, at least with the RSA signature algorithm.

I'm not sure if this is meant as a call for votes, but making at least SHA-256
a SHOULD gets my grunt of approval.

(The reason for specifically mentioning SHA-256 is that the larger ones require
64-bit ops that are painful to handle on a number of systems).

Peter.

---

From: Tony Hansen <[email-masked]>
Date: Wed, 22 Jun 2005 22:35:52 -0400

See draft-eastlake-sha2-00.txt for complete implementations of the
entire SHA suite of hashes, for both 32-bit as well as 64-bit systems.

	Tony Hansen
	[email-masked]

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 23 Jun 2005 15:38:22 +1200

Tony Hansen <[email-masked]> writes:

>See draft-eastlake-sha2-00.txt for complete implementations of the entire SHA
>suite of hashes, for both 32-bit as well as 64-bit systems.

The problem isn't the lack of implementations (I'm already using Brian
Gladman's very nice implementation), it's that -384 and -512 are horribly
inefficient on the majority of systems.  Even -256 is painful on register-
starved x86 (so we're talking 95% of the planet here), but it's the most
reasonable tradeoff of the lot.  So I'd support -256 SHOULD, -384 and -512
MAY.

Peter.

---

From: Blake Ramsdell <[email-masked]>
Date: Sat, 25 Jun 2005 01:41:13 -0700

On Jun 22, 2005, at 8:38 PM, Peter Gutmann wrote:
> So I'd support -256 SHOULD, -384 and -512
> MAY.

What about 224 and 513 and 637... ;)

So I think that there's a few aspects to this:

* Create / determine reference for a specification that explains the 
SHA > 1 algorithms.

* Create / determine reference for a specification that explains the 
use of those digest algorithms in a signature context (that is, 
combined with an asymmetric algorithm of some sort).

* Create a profile for CMS that binds algorithm identifiers to 
signature algorithms.

* Update MSG spec with a SHOULD / MUST / whatever for the final 
algorithms.

Is there something to be done for the CERT profile also?

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Jun 2005 13:51:59 -0400

>Is there something to be done for the CERT profile also?

The needed OIDs have already been published in RFC 4055:

       sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 }

       sha256WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 11 }

       sha384WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 12 }

       sha512WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 13 }

I think it is just a matter of deciding which ones are MUST, SHOULD, and MAY.

I would advocate the use of MUST- and SHOULD+ as was done in the IPsec 
WG.  MUST- means that the algorithm is currently required for 
interoperability, but it is likely to drop to a SHOULD whenever the 
specification is updated.  SHOULD+ means that the algorithm is likely to be 
elevated to a MUST the next time around. I like this approach because it 
tells product planners what to expect.

So, building on what Peter Gutmann suggested:

       sha1WithRSAEncryption would be a MUST-

       sha224WithRSAEncryption would be a MAY

       sha256WithRSAEncryption would be a SHOULD+

       sha384WithRSAEncryption would be a MAY

       sha512WithRSAEncryption  would be a MAY

Unfortunately, I do not have a similar recommendation for DSA.  SHA-1 still 
seems to be the only supported one-way hash function.  I expect that to 
change soon, but it has not happened yet.

Russ

---

From: Blake Ramsdell <[email-masked]>
Date: Mon, 27 Jun 2005 12:58:19 -0700

On Jun 27, 2005, at 10:51 AM, Russ Housley wrote:
> Unfortunately, I do not have a similar recommendation for DSA.  SHA-1 
> still seems to be the only supported one-way hash function.  I expect 
> that to change soon, but it has not happened yet.

"As yet unwritten DSA variant, SHOULD+"

I still find myself somewhat annoyed by the MUST- SHOULD+ approach, 
though I do understand that as a "clue for future revisions" it has 
some value.

Personally, I would upgrade 384 and 512 to SHOULD (no "+"). The 
semantic of that is "there may exist valid reasons in particular 
circumstances to ignore". If you can't do 64-bit easily or the 
performance makes you crabby, then you can invoke that clause. I don't 
really feel strongly enough about it to fight for this though.

Are there any reasons besides implementation ease to promote or 
discourage the SHA-512-derived algorithms? Is there any cryptographic 
history with SHA-256 that makes us nervous (besides the obvious 
'strength in length' argument)?

Blake

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Jun 2005 13:28:54 -0700

At 9:45 AM -0400 6/22/05, Russ Housley wrote:
>I think it is time to revisit this decision.  I think the standard 
>needs to accept longer hash functions, at least with the RSA 
>signature algorithm.

3.4.3.2 of 3851 is discussing the micalg parameter. Maybe we should 
instead be discussing RFC 3370, which doesn't mention SHA-224, -256, 
-384, or -512 at all. That is, 3851 is fine as far as it goes.

>       sha512WithRSAEncryption  would be a MAY

RFC 3370 needs to be expanded to say how all those work. (If we let 
Peter do it, you can imagine what he'll say about the utility or even 
the existence sha224WithRSAEncryption...) I'm OK with those settings 
if you use the words from the IPsec work.

>Unfortunately, I do not have a similar recommendation for DSA. 
>SHA-1 still seems to be the only supported one-way hash function.  I 
>expect that to change soon, but it has not happened yet.

So....., what do we do? Update 3370 without changing DSA, then 
upgrade it again when the DSA change comes down? Wait for the DSA 
change?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Jun 2005 16:50:15 -0400

Paul:

I suggest that we start the update(s), and hope that the DSA situation gets 
sorted out before we are done.  If not, let DSA remain as it is until it 
does get sorted out.

This is consistent with the "walk, do not run" approach to dealing with the 
one-way hash function issues.

Russ

At 04:28 PM 6/27/2005, Paul Hoffman wrote:
>So....., what do we do? Update 3370 without changing DSA, then upgrade it 
>again when the DSA change comes down? Wait for the DSA change?

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Jun 2005 17:44:55 -0700

At 12:58 PM -0700 6/27/05, Blake Ramsdell wrote:
>discourage the SHA-512-derived algorithms?

Flinging unnecessary options at implementers and users does not help 
get use or interoperability. If someone believes that there is a real 
class of users for whom a collision attack that requires *more than* 
2^128 work exists, I'd like to hear it.

--Paul Hoffman, Director

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Jun 2005 16:59:28 +1200

Blake Ramsdell <[email-masked]> writes:

>I still find myself somewhat annoyed by the MUST- SHOULD+ approach, though I
>do understand that as a "clue for future revisions" it has some value.

I rather like it actually, I wish it had already been in use during the AES
transition to provide implementation guidance for pending changes.

>Personally, I would upgrade 384 and 512 to SHOULD (no "+"). The semantic of
>that is "there may exist valid reasons in particular circumstances to
>ignore". If you can't do 64-bit easily or the performance makes you crabby,
>then you can invoke that clause. I don't really feel strongly enough about it
>to fight for this though.

I would argue strongly for just having a single algorithm to support, and
preferably the one that shows at least adequate performance (they're bad
enough on register-starved x86 already).  The problem with making -512 et al a
SHOULD is that (a) you then have to support three different rather sizeable
blocks of code, and (b) as with AES, if you give them the option the plebs are
going to demand the -512 version because real crypto algorithms go to 11.  If
there's strong demand for something other than -256, I'd say only have -512,
again using the AES precedent as an example: Cryptographers are happy with
AES-128, the tinfoil-hat/bigger-is-better brigade want AES-256, and no-one
cares about the in-between value.  It'll be the same for SHA2.

Peter.

---

From: Blake Ramsdell <[email-masked]>
Date: Mon, 27 Jun 2005 22:12:02 -0700

On Jun 27, 2005, at 9:59 PM, Peter Gutmann wrote:
>> semantic of
> I would argue strongly for just having a single algorithm to support

Sounds like a trend to me.

So Russ's's elaboration on your suggestion, resummarized by me here:

>       sha512WithRSAEncryption  would be a MAY

Seems to reflect where you, Paul, Russ and I come down on this.

Blake