Subject: [saag] Recommended Usages of SHA-512/224, SHA-512/256 (draft-dang-turner-sha-512-224-256-00.txt)

From: "Dang, Quynh" <[email-masked]>
Date: Thu, 23 May 2013 07:23:46 -0400

Hi everyone,

I just submitted an individual draft which I and Sean wrote together discussing recommended uses of SHA-512/224 and SHA-512/256. Below is the link to the ID.

http://www.ietf.org/id/draft-dang-turner-sha-512-224-256-00.txt

Your comments will be appreciated.

Regards,
Quynh.

---

From: Russ Housley <[email-masked]>
Date: Thu, 23 May 2013 09:39:34 -0400

Quynh:

Has NIST assigned OIDs for these hash algorithms?  If so, it would be good to include them in this draft, even as an appendix.

Russ

On May 23, 2013, at 7:23 AM, Dang, Quynh wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Matthew Chalmers <[email-masked]>
Date: Thu, 23 May 2013 09:47:41 -0500

They appear to be mentioned here:

http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html#Hash

Secure Hash Algorithm object identifiers

id-sha256 OBJECT IDENTIFIER ::= { hashAlgs 1 }

id-sha384 OBJECT IDENTIFIER ::= { hashAlgs 2 }

id-sha512 OBJECT IDENTIFIER ::= { hashAlgs 3 }

id-sha224 OBJECT IDENTIFIER ::= { hashAlgs 4 }

id-sha512-224 OBJECT IDENTIFIER ::= { hashAlgs 5 }

id-sha512-256 OBJECT IDENTIFIER ::= { hashAlgs 6 }

On Thu, May 23, 2013 at 8:39 AM, Russ Housley <[email-masked]> wrote:

> Quynh:
>
> Has NIST assigned OIDs for these hash algorithms?  If so, it would be good
> to include them in this draft, even as an appendix.
>
> Russ
>
>
> I just submitted an individual draft which I and Sean wrote together
> discussing recommended uses of SHA-512/224 and SHA-512/256. Below is the
> link to the ID.
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 May 2013 10:47:10 -0700

The document makes an assumption that someone signing a message knows the algorithm capabilities of everyone who is intended to verify that signature. That seems like a very, very bad assumption.

Defining a new hash algorithm whose benefit is to be part of a signature algorithm implies that all verifiers will have the new algorithm in their implementations. In online protocols with negotiation, that's acceptable (but still a bit onerous). However, if these signatures are also meant to be used in protocols with no negotiation (such as PKIX and CMS), then adding a new signature algorithm needs to be done only if the advantage (in this case, speed of one part of the verification) greatly outweighs the disadvantage of some verifiers having to fail completely.

To date, it is extremely rare to hear "we can't use SHA256 in this signature algorithm because it is too slow". This proposal seems to be based on optimization, not actual need.

These balances should be covered in the document, probably in the introduction.

These seem like useful algorithms for very slow roll-out, particularly if we later discover attacks on the key tables in SHA-256 that don't apply to SHA-512. However, a document that defines new algorithms but doesn't cover the operational aspects of widespread failure to validate seems incomplete.

--Paul Hoffman

---

From: Sam Hartman <[email-masked]>
Date: Thu, 23 May 2013 14:50:15 -0400

>>>>> "Paul" == Paul Hoffman <[email-masked]> writes:

    Paul> The document makes an assumption that someone signing a
    Paul> message knows the algorithm capabilities of everyone who is
    Paul> intended to verify that signature. That seems like a very,
    Paul> very bad assumption.  Defining a new hash algorithm whose
    Paul> benefit is to be part of a signature algorithm implies that
    Paul> all verifiers will have the new algorithm in their
    Paul> implementations. In online protocols with negotiation, that's
    Paul> acceptable (but still a bit onerous). 

Having just spent two months debugging what ended up being a bug in how
some verifiers reported the absence of SHA-256 support (and the shocking
lack of SHA-256 support in places where I was kind of hoping it would be
present by now), i'd like to agree with Paul that this assumption is
really bad.  The bar to overcome for adding a new hash algorithm in
offline verification can be really high in practice.