Assumption of `random_bytes` makes distribution hard

[TomMD]

I desire to cabalize (make into a Haskell library by way of FFI bindings) ed25519-donna for my own use. In doing so I would rather leverage your repository as-is instead of either applying patches as part of a build process or forking and maintaining the changes in a separate repository.

To me, the issues with wrapping FFI around ed25519 all stem from the assumption of OpenSSL, which I can't assume my users have or want. The two issues are SHA512 and RAND_bytes.

• SHA512: I can use the reference implementation, but it shouldn't be an issue to provide my own and define the right symbol as you have documented. Thank you.
• RAND_bytes: The assumption that a cryptographic random number source is available at this low a level is hard to deal with. It would be easier if the interface were divided up into two parts: one that needs RAND_bytes (existing open_batch) and one that accepts sufficient randoms passed in as an argument (open_batch_pure). The first could call the second and possibility be omitted by CPP, morally NO_OPENSSL or some such.

What are your thoughts? I'd be happy to submit a pull-request that pulls out the pure code into an open_batch_pure function and add the mentioned CPP option.

[floodyberry]

Are you able to use a wrapper around /dev/urandom & CryptGenRandom? That would require locks to stay threadsafe though. But then I don't think OpenSSL is threadsafe. ffffff

Or providing a callback to open_batch that generates the random numbers? I don't know if that would be possible through the FFI or not.

[TomMD]

I'd prefer not to - my other use case isn't even on an OS at all (http://www.smaccmpilot.org) so making CPP to choose between N static OSes seems less sensible than accepting entropy up-front.

A call back is a little frustrating in an FFI context (slower due to thread issues), but I can see how that would be appealing given the library design and could work with it.

My main preference remains a two-layer interface with the top-level abstraction being randoms (from who knows where) and the second being pure with an array of random values of sufficient length:

int ed25519_sign_open_batch(const unsigned char **m, size_t *mlen, const unsigned char **pk, const unsigned char **RS, size_t num, int *valid);
int ed25519_sign_open_batch_pure(const unsigned char **m, size_t *mlen, const unsigned char **pk, const unsigned char **RS, size_t num, int *valid, unsigned char **rands);

Obviously the programmer becomes responsible for more invariants if/when they use the next-lower layer interface.

Whatever way you go, it's obviously your library and your call while I'm a minor user and re-distributor. Thanks for providing the library.