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

[Russ Housley <[e-mail]>]

Jim:

> Jim Schaad sent me some comments on this document.  Since I have asked this
> working group to adopt this draft, I have gotten Jim's permission to respond
> to the comments on list.

Dropping items 1 and 3 since they seem to be resolved.

See below for the continued discussion of items 2 and 4.

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

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

>> 4.  In section 4, the problem with EdDSA is worse for the use of 
>> different algorithms than what you are stating.  It is possible to do 
>> some interesting forgeries if you cross between the pre-hash and not 
>> pre-hash versions with the Ed25519 curve since there is no context 
>> difference between them.  This has to be forbidden not just strongly
>> suggested.
> 
> Does the removal of HashEdDSA resolve this one?
> 
> [JLS] Yes that would deal with this issue.  However, given that currently
> the difference is just a field in the enumeration it should probably have a
> security consideration about it.  If we can change the PKXI draft so that
> the pre-hash and pure versions using different OID identifiers, then this
> because much cleaner and less of a worry.  It would currently be potentially
> necessary to make a RFC 2119 statement about the enumeration which is not
> proposed above.

Hopefully the direction for this will emerge from the discussion on the other thread.

Russ