I'm looking into EdDSA. According to the paper, signing of a message M, using private key (a, k), corresponding to public key A, is essentially
r = H(k | M), with k the second half of the private key R = rB, with B the specified generator of the curve, S = ((r + H(R | A | M) a) mod l, l is the curve order
with some rules to encode R, A, S as strings. H is typically sha-512.
If M is the original, arbitrarily long, message to be signed, this breaks the common structure that you can first compute a message digest, and then apply the secret key to produce a signature. But this doesn't work above, because the complete message has to be hashed twice, first with the secret prefix k, next with the prefix R | A, and any hashing without the private key available is useless. And even worse, one has to buffer the complete message because the prefix of the second hash depends on the output of the first hash.
Or should M itself be a digest of the message to be signed? That will enable a more main-stream signature interface, where the inputs to the signature function are the private key and the short message digest.
Regards, /Niels
On Sun, 2014-08-31 at 21:12 +0200, Niels Möller wrote:
I'm looking into EdDSA. According to the paper, signing of a message M, using private key (a, k), corresponding to public key A, is essentially
r = H(k | M), with k the second half of the private key R = rB, with B the specified generator of the curve, S = ((r + H(R | A | M) a) mod l, l is the curve order with some rules to encode R, A, S as strings. H is typically sha-512. If M is the original, arbitrarily long, message to be signed, this breaks the common structure that you can first compute a message digest, and then apply the secret key to produce a signature.
That is indeed quite different from any other signature scheme. I don't know whether eddsa is going to be standardized or not, but it is certainly being discussed in irtf. Maybe raising that issue there would make more sense.
Or should M itself be a digest of the message to be signed? That will enable a more main-stream signature interface, where the inputs to the signature function are the private key and the short message digest.
M would most probably be protocol related and at least for TLS it is often something short, but other protocols may differ.
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
That is indeed quite different from any other signature scheme. I don't know whether eddsa is going to be standardized or not, but it is certainly being discussed in irtf. Maybe raising that issue there would make more sense.
Where, more precisely, do you suggest I ask about this? cfrg@irtf.org ?
M would most probably be protocol related and at least for TLS it is often something short, but other protocols may differ.
For a start, I think it makes sense to have sign and verify functions that take the complete arbitrary-length message as an argument, and no attempt at any _update function. With the expecation that short messages are what people will be using (and then a flexible input size is nice), and that applications for signing large messages with eddsa will likely do their own message digest before invoking the eddsa functions.
Regards, /Niels
On Sun, 2014-08-31 at 21:41 +0200, Niels Möller wrote:
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
That is indeed quite different from any other signature scheme. I don't know whether eddsa is going to be standardized or not, but it is certainly being discussed in irtf. Maybe raising that issue there would make more sense.
Where, more precisely, do you suggest I ask about this? cfrg@irtf.org ?
Yes, this is the e-mail of the CFRG.
regards, Nikos
Nikos Mavrogiannopoulos nmav@gnutls.org writes:
On Sun, 2014-08-31 at 21:12 +0200, Niels Möller wrote:
I'm looking into EdDSA. According to the paper, signing of a message M, using private key (a, k), corresponding to public key A, is essentially
r = H(k | M), with k the second half of the private key R = rB, with B the specified generator of the curve, S = ((r + H(R | A | M) a) mod l, l is the curve order with some rules to encode R, A, S as strings. H is typically sha-512. If M is the original, arbitrarily long, message to be signed, this breaks the common structure that you can first compute a message digest, and then apply the secret key to produce a signature.
That is indeed quite different from any other signature scheme. I don't know whether eddsa is going to be standardized or not, but it is certainly being discussed in irtf. Maybe raising that issue there would make more sense.
I asked djb, who pointed to the "Maximum security" paragraph close to the end of http://blog.cr.yp.to/20140323-ecdsa.html. As I understand it, the point is resilience to hash collisions: Collisions in the hash function doesn't automatically make signature forgeries possible. Quoting that post. "Using Ed25519 to sign H(m), rather than m, would mean hashing m only once (at the expense of collision resilience), but again the safest option is the default."
Regards, /Niels
nettle-bugs@lists.lysator.liu.se
-
Nikos Mavrogiannopoulos -
nisse＠lysator.liu.se