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

["Dang, Quynh (Fed)" <[e-mail]>]

Hi Jim, Russ and all,

NIST currently plans to allow the SHAKEs to be used. Please see the document attached to the email John Kelsey sent out on 4/8/2016 with the email titled Customized shake. The uses of SHAKE256 in the EdDSA with Ed448 are good (prehash and without prehash versions).

SHAKE256 is used as a prf in the PureEdDSA with ed448 and a prf produces different output sizes depending on the needs.

If an OID for SHAKE256 with some specific output length is needed, NIST can help, just let us know!

Regards,
Quynh.

________________________________________
From: Curdle <[e-mail]> on behalf of Jim Schaad <[e-mail]>
Sent: Monday, May 2, 2016 2:45:19 PM
To: 'Russ Housley'
Cc: [e-mail]
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

Russ,

Comments inline.

jim

-----Original Message-----
From: Curdle [mailto:[e-mail]] On Behalf Of Russ Housley
Sent: Monday, May 02, 2016 10:32 AM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]
Subject: [Curdle] Comments on draft-housley-cms-eddsa-signatures

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.

> 1.  I am not sure that I see a great deal of benefits for doing both the
> pre-hash version and pure version of EdDSA.   Specifically, the use of the
> pre-hash version really only seems to make sense if one does not use
> signed attributes.  However, I think that this is a case which would
> never occur for this signature algorithm.

Right.  Since signed attributes are the most common use with CMS, it is
probably better to just make use of PureEdDSA.

I suggest adding this text to Section 2 of the document:

   One of the parameters of the EdDSA algorithm is the "prehash"
   function.  This may be the identity function, resulting in an
   algorithm called PureEdDSA, or a collision-resistant hash function,
   resulting in an algorithm called HashEdDSA.  In most situations the
   CMS SignedData includes signed attributes, including the message
   digest of the content.  Since HashEdDSA offers no benefit when signed
   attributes are present, only PureEdDSA is used with the CMS.

And, then change Section 2.1 like this:

   When the id-EdDSAPublicKey onject identifier is used, the
   AlgorithmIdentifier parameters field MUST contain EdDSAParameters to
   specify a particular set of EdDSA parameters:

      EdDSAParameters ::= ENUMERATED {
        ed25519   (1),    -- PureEdDSA
        ed25519ph (2),    -- HashEdDSA; not used in the CMS
        ed448     (3),    -- PureEdDSA
        ed448ph   (4) }   -- HashEdDSA; not used in the CMS

[JLS] Both of those changes look very reasonable.


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

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.

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.

> 3.  In section 3 para 2: This sentence does not necessarily make sense
> for the pure version of EdDSA.  In some sense there is no hash
> function which is used on the signedAttribute value.  I don't know
> that it needs to be fixed, but it might be somewhat confusing.

You are talking about this paragraph:

   The same one-way hash function SHOULD be used for computing the
   message digest on both the eContent and the signedAttributes value if
   signedAttributes are present.

I think the principle is correct.  I'm not sure how to address your comment.

[JLS] Yeah, I am not sure how to address my comment here either.  The
problem as stated above is that there is no explicit hash function that is
used as a pre-hash to the signature so people might not know what hash
algorithm to be using here.


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

Russ

_______________________________________________
Curdle mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/curdle