Tests use invalid Curve25519 private keys

[mmdriley]

See also: signalapp/libsignal-protocol-c#15.

RatchetingSessionTest and RootKeyTest each include an invalid Curve25519 private key where the first byte isn't divisible by 8 (here and here).

The Curve25519 functions have code to sanitize private keys before they're used, but that code has been commented out in curve25519-java.

[mmdriley]

Perhaps it's more accurate to say: these tests have "golden values" that rely on the X25519 implementation in this codebase, which doesn't appropriately decode keys before using them. Other X25519 implementations won't produce the same output values.

The input values can stay the same, but the code to normalize those keys should be restored and the expected output value should be updated.

[Arthur111]

Thank you mmdriley to pointed out this issue.
I just learned Open Whisper Systems use a doctored, proprietary, obscure version of Curve25519.
Their keys are not compatible with Curve25519.

[mmdriley]

That's probably a bit extreme. This codebase (and others by WhisperSystems) normalize keys on creation rather than on use. In practice, this only causes difficulty when importing keys created by other software.

These tests are annoying because they use nonnormal keys that curve25519-java would never actually produce, and which produce different outputs depending on whether the X25519 implementation decodes the keys. But it's still fine to swap in vanillla X25519 implementations when using the library.

[Arthur111]

They have to fork the project curve25519-donna and modify it.
What they do imply they use the original curve25519 which is not the case.
And they add confusion by referencing to their java version.
Its just about clearness.