Add a compile-time switch to use secret key values directly

[deemru]

• The library can be built with ED25519_NOSHA512SK defined in order to use secret key values directly without internal sha512 hashing.

[jedisct1]

Hi Dmitrii,

I understand that such a hack may be a way to implement some protocol, but having a given function behave in incompatible ways according to how the library is compiled can only be a source of trouble.

Especially here, since this is even not necessary. The crypto_scalarmult_ed25519(), crypto_scalarmult_ed25519_noclamp(), crypto_scalarmult_ed25519_base() and crypto_scalarmult_ed25519_base_noclamp() functions are already present in the API to multiply a point by a scalar.

[tarcieri]

I've had a lot of conversations with various cryptographers about this sort of API. If it were to be added, I don't think this is the way to do it (instead I'd recommend adding a new function, and then making the existing one call that after expanding the seed value with SHA-512).

One thing to note is the independence of the private scalar and the nonce prefix are important to the security proofs, and my understanding is that's the rationale for the SHA-512-based derivation (as opposed to say, hashing the private scalar, perhaps in conjunction with a domain separator, in order to produce the nonce prefix).

I don't know of any insecurities which arise from the aforementioned approach (i.e. hashing the scalar, not this PR), but to me any potential benefits you'd get out of control of the private scalar are lost due to the cofactor and associated "clamping".

The main reason I think you'd want this sort of API is to use a derived scalar, and more specifically one which leverages commutative group operations so you could perform some corresponding derivation on public points. If that's the case, I'd recommend using Ristretto (also supported by this library) instead, as it's a prime order group and therefore all you need to worry about is the scalar being uniformly random modulo p. There are a few different signature systems are available (although the jury is still out on a "winner").

Otherwise, deriving scalars correctly requires quite a bit of theatrics, and must be done in such a way that the subsequent clamping operation is effectively a no-op, which adds a great deal of incidental complexity as opposed to using a prime order group where none of this is an issue.

[deemru]

@jedisct1 @tarcieri thanks for response.

The practical usage of this PR is actually refer to the php libsodium support.

Currently there is no way to sign with a pure curve25519 keys, but some blockchain solutions need that.

With this PR i can do signs in 0.2 ms instead of 100 ms on a pure php.

Details:

• Checks for support: https://github.com/deemru/Curve25519/blob/7b2a570c46162cc2861c382f03bdd0be6c824674/src/Curve25519.php#L42
• Signs: https://github.com/deemru/Curve25519/blob/7b2a570c46162cc2861c382f03bdd0be6c824674/src/Curve25519.php#L75

[jedisct1]

Instead of building a modified library that disguises a function as another existing function, you can add bindings for crypto_scalarmult_ed25519_base() to the PHP module.