Export the has_small_order() function introduced in libsodium commit c190574c

[lmctv]

This would help in solving in a sensible way the PyNaCl issue pyca/pynacl#331, since we'll be able to distinguish a general error from an invalid incoming public key. Further, this will let us check generated keys compliance.

[jedisct1]

That one is going to stay private, if it stays at all.

Ed25519 keys can be checked with crypto_core_ed25519_is_valid_point() that does a couple more checks. A crypto_core_x25519_is_valid_point() counterpart performing similar checks might be added later.

[lmctv]

+1 on adding the crypto_core_x25519_is_valid_point(); a possible alternative would be a API to convert x25519 points to raw ed25519 ones, which would then allow to apply the crypto_core_ed25519_is_valid_point() checker.

[jedisct1]

Yes, but the sign of the X coordinate has to be provided, which doesn't make such an API easy to use.

Ed25519->X25519 doesn't have this issue, and Ed25519 keys can now be used for DH.

[mimoo]

question: isn't it bad to use the same key to sign and to do ECDH? Recommendations usually tend to go towards "don't use the same key for different things".

[lmctv]

I forgot the sign problem; unfortunately, the context of pyca/pynacl#331 is the x25519 DH exchange in the box construction; now I am +2 on suggesting a crypto_core_x25519_is_valid_point public API ;-)

[lmctv]

@mimoo you should generate different ed25519 keys for different usages even though you could properly use them both in signing and in DH exchange.

[jedisct1]

Using different keys is highly recommended, for a couple reasons:

• The interaction between different constructions sharing the same key is not well studied, if at all. Security analysis of individual primitives always ignore such scenarios.
• Signing and encryption keys may need different life cycles.
• This limits the implications of a single key being compromised.

On the other hand, I can't remember of a single paper about an attack due to a unique key being used both for signing and encryption. Hence, we cannot assume that it's safe to do so, neither can we assume that it is unsafe.

Whenever possible, different keys should thus be used.

Scalar multiplication in Ed25519 was not specifically implemented to share the same key for signing and encryption, although this satisfies a very common request. But as a required piece along with point addition and elligator to perform blinding, implement AKEs, etc.

[jedisct1]

crypto_core_curve25519_is_valid_point() added.

[lmctv]

Great, thanks. I'll add a PyNaCl PR with bindings as soon as this gets released.

[jedisct1]

It may be reverted. I'm still not convinced that it is useful.

The only reason curve25519_scalarmult() can fail is a public key in a small order group. There can't be any other reason for the function to return -1, as it doesn't perform any memory allocation.

[lmctv]

The problem in my case comes from the box construction, and the fact that the same error code might stem from a failure in crypto_secretbox_xsalsa20poly1305_open and from using an invalid point as a public key.

[jedisct1]

I see. But why would an application need to make the distinction between an incorrect public key, and an incorrect public key representing a small order point?

And for this particular use case, performing a dummy scalar multiplication is something you can already do to perform that check.