This provides a more direct interface to the crypto_scalarmult function.
By default, this function includes some bit-twiddling, which, to the
best of my understanding, ensures the integer provided as the left
operand of the multiplication operation fits within a specific limit.
(I believe this limit is the order of NaCl's standard group element,
but am not entirely certain). This change allows a user to pass in
an integer which is not subject to this bit-twiddling and can be passed
in wholesale.
The reason NaCl provides this API is to intentionally make it
easy-to-use for the purposes of computing public keys from private keys
or for performing Diffie-Hellman. The API it provides now makes it
quite difficult to do anything wrong yet still get a correct answer.
If we split this function in half, however, we can expose some
power-user functionality. Specifically I need this to implement
semiprivate keys:
https://gist.github.com/tarcieri/4760215
I've been double checking my implementation against a similar version in
SAGE for the past week or so trying to figure out what's wrong, and
today it was pointed out to me that NaCl's scalar multiplication
function automatically performs bit-twiddling for you.
I would love to continue to experiment with semiprivate keys on top of
NaCl. I have no serious intentions of actually using them as part of a
cryptosystem until there's some sort of proof of their security, or at
the very least, some reasonably educated guesses as to its security
properties.
That said, I would love to have this API. If there's worries about
exposing power-user APIs like this, perhaps we can be a bit more
"shouty" in the API name?
crypto_scalarmult_dangerously_direct_access() ? ;)
The crypto_sign_seed_keypair function is analagous to
crypto_sign_keypair, except it generates a keypair for a seed instead of
a random keypair.
I think this name makes more sense than crypto_sign_publickey.
This adds a new API crypto_sign_publickey, which works similarly to the
existing crypto_sign_keypair() API, but supports a 32-byte
user-specified seed value (k).
This API is necessary for implementing Ed25519 test vectors, for
example, since we need to pass in a known seed to ensure we're
computing the public key correctly.
The name and implementation are largely borrowed from Brian Warner's
python-ed25519 library. See:
https://github.com/warner/python-ed25519/blob/d42d4b7049baf323e7113359f4f6bf88703543bc/src/ed25519.c#L21
That said, perhaps a different name would be more descriptive, since it
still returns a keypair, not just the public key? Or perhaps that's
needless bikeshedding since this name is already in use.
Mangix