[Cfrg] draft-irtf-cfrg-eddsa-00

[Simon Josefsson <[e-mail]>]

Dear WG,

We have posted the following draft to describe EdDSA, based on the
EdDSA/Ed25519 description in draft-josefsson-eddsa-ed25519 and the
EdDSA2 paper.

   https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-00

Feedback is welcome.

There are at least two main areas I believe the WG will need to discuss:

1) The 912-bit wide internal hash function to use for Ed448.  In the
   EDDSA2 paper we proposed SHA-512/912 because we thought use of SHA512
   would be more convenient in existing deployments than SHAKE256.

   However, given that 1) some implementers thought the IV-modification
   we proposed would be difficult to implement in some APIs, and 2) some
   implementers (including at least one smartcard implementer, which
   typically are more constrained than software-only developers)
   appeared to be fine with SHAKE256 even though it is newer, I believe
   we should treat this as an open issue.  Options include:

     1) SHA-512/912 as described in
        http://ed25519.cr.yp.to/eddsa-20150704.pdf

     2) Straightforward use of SHAKE256, also discussed in the previous
        paper.

     3) Home-cooked SHA2-based variant such as:

          Truncate-912-bits(SHA512("0" | M) | SHA512("1" | M))

     4) Less home-cooked SHA2-based variant such as the RFC 5869 HDKF.

   Thoughts?  Other options?  Strengths and weaknesses of the above?

   Personally I am currently in favor of chosing SHAKE256 for Ed448.

2) Naming of the pre-hashed variants of Ed25519 and Ed448 and the
   relationship between PureEdDSA and HashEdDSA.

   For this draft I chose the short but still (barely) readable names
   Ed25519ph and Ed448ph.  In the EDDSA2 paper we used
   'SHA-512-Ed25519-SHA-512' which might be shorted to 'SHA-512-Ed25519'
   since the internal hash function is already settled on.  Still, I
   believe 'SHA-512-Ed25519' is a quite unreadable name and the
   important part, Ed25519, is lost.  Using 'Ed25519-SHA-512' to refer
   to the pre-hash variant seems confusing given that it is already in
   use to describe Ed25519 with SHA-512 as the internal hash.

   The 'Ed25519ph' name variant came up during discussions related to
   the PKIX EdDSA draft.

   I believe we definitely should not use the name 'Ed25519' to describe
   what we are doing in the pre-hash variant since that is already well
   established in deployment to refer to, eh well, Ed25519.  So another
   name is needed.

   Does someone have a better suggestion, or can we settle on
   'Ed25519ph' and 'Ed448ph'?

The document is not ready, and our primary main open work items are as
below.  If anyone has suggested improvements here, they are welcome.

1) Test vectors and sample code for Ed448 and the pre-hash variants.

2) Align terminology and notation with cfrg-curves.  Perhaps this is
already in good shape, but it might be that a lot of work is required to
harmonise terminology.  Someone has to review both documents for
consistency.

3) We need to abstract the Ed25519 description somewhat so that it can
describe Ed448 too, but not abstract it all the way to the generic EdDSA
which is already described.  Otherwise the document will repeat large
chunk of text to describe Ed25519 and Ed448 which is mostly identical.

4) Security Considerations, especially related to cross-protocol attacks
(i.e., when you use the same key in pure mode or different pre-hashes).

Of course, any other feedback is welcome.

Thanks,
/Simon