ietf
[Top] [All Lists]

Re: Fwd: Re: [saag] Fwd: Last Call: <draft-moonesamy-sshfp-ed25519-01.txt> (Using ED25519 in SSHFP Resource Records) to Informational RFC

2014-05-02 12:54:20
Hi Rene,
At 09:05 01-05-2014, Rene Struik wrote:
I had a brief look at the draft document
draft-moonesamy-sshfp-ed25519-01. Please find my comments below:

Thanks for the review.  I'll acknowledge you in the draft.

Section 1 & 2:
The paper [Ed25519] defines a set of signature algorithms, but also
specifies a concrete instantiation Ed25519-SHA512 (see Section 2 of the
paper). It is not clear whether the draft wants to use
Ed25519-SHA512 or that scheme with another hash function. A disadvantage

I'll suggest the following text change to Section 1 to clarify what has been implemented:

  The Ed25519 [Ed25519] signature algorithm, specifically Ed25519-SHA-512,
  has been implemented in OpenSSH.

of using Ed25519-SHA512 is that this may require implementation of both
SHA-256 and SHA-512 (witness Section 2 of the internet draft). Would it

Yes.

make sense to use, e.g., SHA-512/256 for fingerprinting instead of
SHA-256 (or get rid of SHA-512, at the expense of having to tweak
Ed25519 somewhat). Tweaking Ed25519 could be done as follows: for

Section 2 mentions a SHA-256 fingerprint as an example as the current implementation uses existing code for that. The draft does not specify the fingerprint type to be used. It may make sense to use SHA-512. However, that would have to be done in a Standards Track RFC to cover the public key algorithms which have already been registered. There are also some other changes which have been suggested during the discussions about this draft.

ephemeral private keys one can simply use as hash function SHA-256
(since the curve has very close to a power of two number of elements
biases are close to zero, so Bleichenbacher-style attacks do not apply);
instead of using SHA-512(k) use SHA-256(k,0) || SHA-256(k,1). The use of
hash functions for generation of ephemeral and static private keys does
not influence interoperability; only the choice of hash function for the
Schnorr-style signing equation does, since affecting the signature
component s.

I'll discuss the above with the people who wrote the code.

Section 6.2:
Please replace the informative reference [Ed25519]
<http://ed25519.cr.yp.to/ed25519-20110926.pdf> by the permanent reference
[Ed25519] D. Bernstein, T. Lange, P. Schwabe, B-Y. Yang, High-Speed
High-Security Signatures, J. of Cryptographic Engineering, Vol. 2,
September 26, 2011.

There was a short discussion about the reference on the ietf-ssh mailing list. I'll switch to the above with some minor edits.

Regards,
S. Moonesamy
<Prev in Thread] Current Thread [Next in Thread>