Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

["Jim Schaad" <[e-mail]>]

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Thursday, May 05, 2016 1:05 PM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

Jim:

>> 2.  We need to get a definition of how to use SHAKE256 from someplace 
>> if we are going to say use the same hash algorithm throughout as that 
>> is what
>> Ed448 uses.  It would be worthwhile to specify what hash algorithms 
>> should be used with each of the different signature algorithms given 
>> that it is not clear from the name of the algorithm identifier.
> 
> This document references draft-irtf-cfrg-eddsa-05, and that document 
> includes this reference for SHAKE256:
> 
>   [FIPS202]  National Institute of Standards and Technology, U.S.
>              Department of Commerce, "SHA-3 Standard: Permutation-Based
>              Hash and Extendable-Output Functions", FIPS 202, August
>              2015.
> 
> I'm not sure what more you think is needed.
> 
> [JLS] To start with, I think we need to get a reference for an OID for 
> the
> SHAKE256 algorithm from NIST (or internally) since that is needed as 
> one of the authenticated attributes.

Based on other traffic on this list, I hope that NIST will assign the OID.

[JLS] They have assigned an OID for SHAKE256, I just don't know if it was
done "correctly" for our purposes.  We will need to work that out. I still
need to look at and think about Quynh's response to my message.

> I worry that since we have changed this set of identifiers from saying 
> X with Y to just saying X that there is going to be a degree of people 
> missing which algorithm is being used as a hash algorithm for this.

We need to do the same thing with this document and
draft-ietf-curdle-pkix-eddsa.

I have started a separate thread on this mail list.  Let's have the
discussion on that thread, and then put the conclusion in both documents.

> A second worry is that SHAK256 is defined as being an XOF function and 
> not a hash function.  I think it might make more sense to say that we 
> should be using SHA3-256 rather than SHAKE256.  In any event the OID 
> assigned on the NIST web site does not make any statements about the 
> size of output of
> SHAKE256 and if we are going to use it as a hash algorithm here we 
> need to do that.  Suffice it to say that I don't think that using 
> SHAKE256 as a hash algorithm here is sufficiently defined.

Doesn't this need to be addressed in draft-irtf-cfrg-eddsa?

[JLS] No, I am not worried about how SHAKE256 is being used in the EdDSA
process (it is fully defined there), I am looking at the use of SHAKE256
when it is placed in the digestAlgorithm attribute of the SignerInfo
structure.  In this case the length of the output needs to be specified
(i.e. how long is the message digest signed attribute).  This is defined for
hash algorithms, but is not defined for XOF functions.

Russ