They are identical for all implementations of a given primitive and
it's bound to always be the case.
We will eventually pick suitable implementations at run-time, so
these won't make any sense.
Remove implementation names/versions macros as well.
These should be functions, not macros.
Just to cope with that Visual Studio thing that still doesn't support C99.
I hate that because some libraries can redefine "bool" in an incompatible way.
It's okay. Until we have that in an exported prototype.
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() ? ;)
