Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03

From: Russ Housley <[email-masked]>
Date: Mon, 10 Apr 2017 14:59:55 -0400

Jim:

Sorry, I flagged this message in my inbox, and then I missed it when I made the update earlier today.

> Section 3.1 - I would like to have a brief discussion on the integer value
> that is being used with the id-shake256-len OID when it is being used as a
> digest algorithm.  The value of 512 means that the signature security is
> going to be the same as is currently setup for Ed25519.  To have the same
> dynamic as Ed25519 does, this should be 448*2 so that after birthday attacks
> the same size of value would be provided.

RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used.  Reading a bit more carefully, I see that the output is 114 octets or 912 bits.

I suggest that we align with these values.  That is:

   When signing with Ed448, the message digest
   algorithm MUST be SHAKE256 [FIPS202] with a 912-bit output value.

and

   When using the id-shake256-len algorithm identifier, the parameters
   MUST be present, and the parameter MUST contain 912, encoded as a
   positive integer value.

> Section 4 - I thing that it should also be highlighted that this is a
> greater problem for when using the Signed-data without signed attributes as
> the value signed is more constrained in the other case.

I suggest:

4.  Implementation Considerations

   The EdDSA specification [EDDSA] includes the following warning.  It
   deserves highlighting, especially when signed-data is used without
   signed attributes and the content to be signed might be quite large:

      PureEdDSA requires two passes over the input.  Many existing APIs,
      protocols, and environments assume digital signature algorithms
      only need one pass over the input, and may have API or bandwidth
      concerns supporting anything else.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Mon, 10 Apr 2017 12:09:26 -0700

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Monday, April 10, 2017 12:00 PM
> To: Jim Schaad <[email-masked]>
> Cc: curdle <[email-masked]>
> Subject: Re: Review of draft-ietf-curdle-cms-eddsa-signatures-03
> 
> Jim:
> 
> Sorry, I flagged this message in my inbox, and then I missed it when I
made the
> update earlier today.
> 
> > Section 3.1 - I would like to have a brief discussion on the integer
> > value that is being used with the id-shake256-len OID when it is being
> > used as a digest algorithm.  The value of 512 means that the signature
> > security is going to be the same as is currently setup for Ed25519.
> > To have the same dynamic as Ed25519 does, this should be 448*2 so that
> > after birthday attacks the same size of value would be provided.
> 
> RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used.  Reading
> a bit more carefully, I see that the output is 114 octets or 912 bits.
> 

Yes - this is what I wanted to do.  This is what Sean was supposed to run
past Tanya and the question was "Did the fact that it was SHAKE256 limit the
number of bits despite the added output length?"  

> > greater problem for when using the Signed-data without signed
> > attributes as the value signed is more constrained in the other case.
> 
> I suggest:
> 

This looks good.

Jim

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 10 Apr 2017 22:21:24 +0300

> a bit more carefully, I see that the output is 114 octets or 912 bits.

Nitpick: Only true of no-prehash versions. The prehash itself uses
SHAKE256 with 512-bit input.

>    MUST be present, and the parameter MUST contain 912, encoded as a

The hash algorithm is internal detail of EdDSA, unless you are talking
about doing prehashing at "application" level (which certainly a valid
approach).

On security of using just 512-bit hash there, SHAKE256 does not promise
resistance above 2^256 for any attack, which it reaches at 512-bit output
(collision resistance being the limiting factor). And the security
level of the curve certainly isn't above 2^256.

So 512-bit hash should be entierely adequate for application-level
prehash (just don't use SHA3-512, it is hilariously slow).

-Ilari

---

From: Russ Housley <[email-masked]>
Date: Mon, 10 Apr 2017 15:31:49 -0400

> prehash (just don't use SHA3-512, it is hilariously slow).

CMS supports signatures with and without signed attributes.  In most cases, signed attributes are present.  When signed attributes are present, the message-digest attribute MUST be one of the attributes.  It was signed to work like this:

    IF (signed attributes are absent)
    THEN md = Hash(content)
    ELSE message-digest attribute = Hash(content);
         md = Hash(DER(SignedAttributes))

    Sign(md)

So, I think you are saying that a 512-bit output was sufficient, which is what was present in the earlier text:

   When using the id-shake256-len algorithm identifier, the parameters
   MUST be present, and the parameter MUST contain 512, encoded as a
   positive integer value.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Mon, 10 Apr 2017 12:33:29 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, April 10, 2017 12:21 PM
> To: Russ Housley <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; curdle <[email-masked]>
> Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03
> 
> > > value that is being used with the id-shake256-len OID when it is
> > > being used as a digest algorithm.  The value of 512 means that the
> > > signature security is going to be the same as is currently setup for
> > > Ed25519.  To have the same dynamic as Ed25519 does, this should be
> > > 448*2 so that after birthday attacks the same size of value would be
> provided.
> >
> > RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used.
> > Reading a bit more carefully, I see that the output is 114 octets or 912 bits.
> 
> The hash algorithm is internal detail of EdDSA, unless you are talking about
> doing prehashing at "application" level (which certainly a valid approach).

Yes, this is doing a version of prehashing at the "application" level.  This is feature of CMS where the content is hashed and placed in a structure which is then signed.

> (collision resistance being the limiting factor). And the security level of the
> curve certainly isn't above 2^256.
> 
> So 512-bit hash should be entierely adequate for application-level prehash
> (just don't use SHA3-512, it is hilariously slow).

Ok - so it would make sense to limit the output to 512-bits for Ed448 based on what you are saying.  No additional security is obtained from getting a longer output value.

Jim