The Monero vulnerability was related to "key images". When signing a transaction to spend an output, a unique EC point called a "key image" is produced as a result of the signature. This key image uniquely identifies the private key of the output being spent (without revealing which output in the ring that private key is associated with). Therefore, if the spender ever attempts to spend that output again in another ring signature, they will be forced to declare the same key image again, and the network will be able to see that there has been a double-spend attempt.
However, because Ed25519 (and Curve25519) have a co-factor, there are 8 large subgroups (because the co-factor is 8). This means that you could spend an output, nudge the key image into the wrong subgroup, and under certain circumstances pretend that a second signature has a different key image.
The fix for this was very easy - you just need to validate each key image to ensure it is in the correct large subgroup. To do this, you just multiply it by the group order and check that the result is the point at infinity (the "zero" point).
Therefore, if you are designing new EC schemes, Ristretto255 would be helpful to avoid the risk of forgetting to validate points in all necessary places.
The designers of X25519 were well aware of this issue, which is why X25519 clears the lower 3 bits of the private key used during key exchange. This forces the private key to be a multiple of 8, which means that the result of X25519 will be in the correct large subgroup even if it was provided with an invalid EC point in the wrong large subgroup.
The bottom line is that X25519 has already been designed to prevent the problem that Ristretto255 was designed to prevent. Since X25519 has been very widely examined for vulnerabilities, the risk of introducing a vulnerability by implementing a new form of ECDH in Ristretto255 would be higher than the risk of just using a widely used and audited X25519 implementation.
Is crypto_scalarmult_ristretto255 a drop in replacement for crypto_scalarmult?
Ristretto255 is not supposed to be interoperable with Curve25519. It is supposed to provide you with safe, equivalent methods while hiding implementation details from you and ensuring all safety checks are in place. Therefore, if you would normally use crypto_scalarmult for your own ECDH mechanism (or other EC scheme), you would now use crypto_scalarmult_ristretto255 instead.
crypto_box_easy_ristretto255
, but I wouldn't recommendcrypto_box
anyway because a) it doesn't have sender authentication since the public keys are not included in the key derivation, b) it uses XSalsa20-Poly1305 instead of the more widely used, slightly better (X)ChaCha20-Poly1305, and c) it may be removed in the future. $\endgroup$crypto_box
would you recommendcrypto_box_seal
instead? $\endgroup$crypto_box
. $\endgroup$