Scalar group order about curve25519-dalek HOT 3 CLOSED

Thanks for pointing this out.

I'm assuming when you say "curve25519 typically uses scalars ... and makes the key creator responsible", you're referring to X25519, which is not (currently) a part of dalek — different meanings should have different types, so I think an X25519 implementation would have a different type, like X25519Secret or something. At the moment we've been busy with some other issues, so X25519 issues are on a back burner.

I think a Scalar should be an element of ℤ/lℤ, as the documentation suggests — I'll check into this.

from curve25519-dalek.

Yes, I said curve25519 meaning X25519 but Ed25519 clears the low bits to multiply by the cofactor too. If one did not do so, then conversion between Ed25519 and X25519 might require an annoying shift operation.

These schemes have related base points which likely all have order l anyways, so that part is almost surely right, and perhaps important for Ed25519 somehow. Also, a Scalar in ℤ/8lℤ does "represent" its quotient "scalar" in ℤ/lℤ, and an element chosen uniformly at random in ℤ/8lℤ yields a uniformly random element of ℤ/lℤ.

I doubt anything is wrong here, but it confused me when reading. :)

from curve25519-dalek.

I'm wrong. Adding this test shows your Scalar is actually in ℤ/lℤ, not ℤ/8lℤ.

    #[test]
    fn test_highbits() {
        let mut rng = ::rand::os::OsRng::new().unwrap();
        let mut x = 0u8;
        for i in 0..256 {
            let s = Scalar::random(&mut rng);
            x |= s[31];
        }
        assert!(x & 0xF0 != 0);
    }

It's clear agl's Ed25519 has three bits more in the private scalar's high byte, so your private keys differ by a three bit shift, which costs nothing.

There might however be places where scalar multiplication alone is believed to sanitize the input but does not do so, and the point must first be multiplied by 8.

from curve25519-dalek.