I've still looking at eddsa, and how to design the interface. I think we need some structs ed25519_sha512_private_key and ed25519_sha512_public_key, which can keep track of "expanded" keys. And a low-level function, possibly like
void _eddsa_sign (const struct ecc_curve *ecc, const struct nettle_hash *H, const uint8_t *pub, void *k1, const mp_limb_t *k2, size_t length, const uint8_t *msg, uint8_t *signature);
where
ecc is the curve,
H the hash function,
pub is the public key as a string (I don't quite like it, but it is needed in the hashing, and it seems inefficient to have to recompute it from the private key)
k1 is a context struct for the hashing, updated with the secret prefix. And destroyed in the process, so if the caller want's to sing several messages, it should keep a copy.
k2 is the secret scalar
The output is produced as a string, not a pair of bignums, since that's how eddsa is specified.
It's possible to also have an all-in-one functions, say,
ed25519_sha512_sign (const uint8_t *key, size_t length, const uint8_t *msg, uint8_t *signature);
One thing that's a bit unclear is in which form applications will store private keys. Will they be *only* the private key (256 bits, according to the spec), or will they be kept together with the public key? If the public key is not included, it has to be recomputed (which will be pretty fast, but I think it's desirable to do it once, when the key is read, not for each signature created). It could be an optional input somewhere in the interface.