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

Hi Jim,

To hash the signedAttributes value, SHAKE256/512 would be great.

For ed25519 and ed448 EdDSA signatures, hash algorithm OID should be null/absent. For ed25519ph and ed448ph, the hash algorithm is the prehash function: SHA512 for ed25519ph and SHAKE256/512 for ed448ph. 

Regards,
Quynh. 

________________________________________
From: Curdle <curdle-bounces@ietf.org> on behalf of Jim Schaad <ietf@augustcellars.com>
Sent: Thursday, May 5, 2016 8:39 PM
To: 'Russ Housley'
Cc: curdle@ietf.org
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Thursday, May 05, 2016 5:08 PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: curdle@ietf.org
Subject: Re: [Curdle] Comments on draft-housley-cms-eddsa-signatures

On May 5, 2016, at 4:47 PM, Jim Schaad <ietf@augustcellars.com> wrote:

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

I was not understanding you issue until now.

You are worried about this:

       Compute SHAKE256(dom(F, C) || prefix || M, 114), where M is the
       message to be signed, .

Maybe we just make M = SHA512(ValueOnly(DER(SignedAttrs)))

Russ

[JLS]  No that is not what I am worried about.  What I am worried about is

  SignerInfo ::= SEQUENCE {
      version CMSVersion, --  == 1 or 3
      sid SignerIdentifier,  -- Identifier of the signer
      digestAlgorithm DigestAlgorithmIdentifier,  --- AlgorithmIdentifier(
{hashAlgs 12}, absent )
      signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, { contains
Attribute{ aa-messageDigest, SET OF { OCTET STRING { SHAKE256(Message Body)
}}
      signatureAlgorithm SignatureAlgorithmIdentifier,  -- id-edDSA
      signature SignatureValue, -- cryptographic result of eddsa with
                --  SHAKE256(dom(F, C) || prefix || DER(SignedAttrs), 114)
                --      where DER(SignedAttrs) = M just as would be
expected.
      unsignedAttrs [1] IMPLICIT Attributes
          {{UnsignedAttributes}} OPTIONAL }

The length of SHAKE256(Message Body) is not defined nor is there any place
for it to be specified by a parameter.   Specifically one needs to be able
to say that the messageDigest = SHAKE256(Message Body, 114)  (Or maybe just
57? If you want to do some type of size matching since the EdDSA uses a
double width hash algorithm internally)

Jim

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle