ed25519_sign() is significantly different from current libsodium/SUPERCOP ref10 implementations (and generates incompatible output)

[rdeker]

In working with your implementation, I was doing some testing against other code I have that uses libsodium, and noted that the ed25519 signatures produced by each were entirely different. After some digging, I noted that the implementation of ed25519_sign() you provide does not match the current libsodium/SUPERCOP ref10 (20141124) implementations.

I have an updated version that is interoperable that I'd be happy to submit if you'd like.

[19h]

@rdeker Please share any ideas and work. That will help everyone involved :-)

[rdeker]

I've forked this project and have one with a couple of fixes available at https://github.com/rdeker/ed25519 . To date I haven't heard anything in response to my pull request.

[orlp]

Sorry for the late response. I finally got around to checking this. ed25519_sign is not significantly different from SUPERCOP's ref10, I simply have a different representation of the private key.

ref10 stores the private key by storing the seed (32 bytes) and public key (32 bytes) as the 'private key'.

I instead straight up store the hashed seed (64 bytes) as the private key to not have to re-hash the seed on every sign operation.

So if you simply use the 64 bytes from the ref10 'private key' as the private key in this library you will end up with incorrect results.

If you wish to convert a ref10 private key to a private key for this library you can use:

void ref10_to_lib(unsigned char *private_key, const unsigned char *ref10_private_key) {
    sha512(ref10_private_key, 32, private_key);
    private_key[0] &= 248;
    private_key[31] &= 63;
    private_key[31] |= 64;
}

[orlp]

See also this previous question about this exact topic: #1 (comment)

[dmjones]

@orlp Is it worth putting some info about this prominently on the main README.md? This tripped me up for quite a while, until I dug into closed issues. I imagine a lot of people will expect this to play nicely with other implementations.

(Note: I completely understand why you do what you do, but it may be missed by many).