zkcrypto / curve25519-dalek-ng Goto Github PK

I am importing these crates
curve25519-dalek-ng = "4.1.1"
x25519-dalek = "1.1.0"

And I am generating a Curve25519 private key from a Ed25519 private key with the following code:
// Obtain the secret point from the Private Key Ed25519 of 64 bytes
let secret_key_point: EdwardsPoint = &secret_key_scalar * &ED25519_BASEPOINT_POINT;

// Generate the X25519 key pair from the Private Key Ed25519
let curve25519_private_key_montgomery = secret_key_point.to_montgomery();

But now I have an issue, when I create a StaticSecret, for example as:

let curve25519_private_key_ss = StaticSecret::from(curve25519_private_key_array);

I get a different result depending on how many times I run it

private_key = x25519::StaticSecret::from(self.config.cgrodt_private_key);

self.config.cgrodt_private_key and curve25519_private_key_array having the same value, produce different private keys.

Now, this obviously should not happen but on top, to give you an example, these two private keys are generated:

0HloxiLX/gYf2s3WLlkPibiU4NuSK1C6otJsoNNfo3o=
1XloxiLX/gYf2s3WLlkPibiU4NuSK1C6otJsoNNfozo=

If you convert this to Hex and then to ASCII you get

olxEyeMlittle-alpha-word

and

myellite-alpha-word

Neither look very random to me.

I am under the impression either the code is compromised or the crate is compromised.

Any ideas?

curve25519-dalek exports the rand_core API as part of its API, so changes to the rand_core (or digest) version require version bumps. In the past, this has been an automatic major version bump as soon as there was a new release, to prevent getting out of sync with the rest of the ecosystem, and that should probably continue to create curve25519-dalek-ng 4.0.0.

Before implementing the hash to curve functionality, I would like to know if it'd be something that would be considered for a merge. The implementation would follow the standard.

Thanks!

I have in mind an application that uses GF(2^255-19) for secret sharing rather than elliptic curves: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-vdaf-03. We picked this field because of its large size (~256 bits) and to take advantage of high-quality implementations already available.

This crate seems to have the best implementation for rust. Would you consider adding the module to the public API? Do you foresee any technical difficulties with doing so?

Failed to compile subtle-ng 2.4.1. See zkcrypto/subtle-ng#3.

The previous repository used Travis CI, which is de-facto deprecated now.

Using the current crate with the 0.10 version of sha2 turns out to be a little messy:

error[E0277]: the trait bound `CoreWrapper<CtVariableCoreWrapper<Sha512VarCore, UInt<UInt<UInt<UInt<UInt<UInt<UInt<UTerm, B1>, B0>, B0>, B0>, B0>, B0>, B0>>>: digest::Update` is not satisfied
   --> src/user.rs:84:9
    |
84  |         RistrettoPoint::hash_from_bytes::<Sha512>(&input)
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `digest::Update` is not implemented for `CoreWrapper<CtVariableCoreWrapper<Sha512VarCore, UInt<UInt<UInt<UInt<UInt<UInt<UInt<UTerm, B1>, B0>, B0>, B0>, B0>, B0>, B0>>>`
    |
    = note: required because of the requirements on the impl of `digest::digest::Digest` for `CoreWrapper<CtVariableCoreWrapper<Sha512VarCore, UInt<UInt<UInt<UInt<UInt<UInt<UInt<UTerm, B1>, B0>, B0>, B0>, B0>, B0>, B0>>>`
note: required by a bound in `RistrettoPoint::hash_from_bytes`
   --> .../curve25519-dalek-ng-4.1.1/src/ristretto.rs:689:18
    |
689 |         where D: Digest<OutputSize = U64> + Default
    |                  ^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `RistrettoPoint::hash_from_bytes`

It seems like the requirements from this crate are modest, but the change would be quite disruptive (for the same reason) and it might need a version bump. I'd have said a minor release is in order, but you seem to be using major versions for similar changes.

Hello! When I try to do the following in the new version it gives me an error. Can you tell me why, please? Thanks!

let mut h = Sha512::new()
        .chain("Tstring");
    
let s = Scalar::from_hash(h);

The GH Actions added in #3 don't actually check the simd backend, because they're compiled without awareness of the CPU flags that would support AVX2, and the implementation doesn't do dynamic dispatch. Two ways to address this:

1. Set the target_cpu to native and hope that actions runs on something with AVX2 (likely, since AVX2 is not that new);
2. Use qemu or something to run the avx2 or ifma implementations in an emulator;

Due to the rift that seems to have formed on the dalek-cryptography organization, what is the overall plan for the other crates that were in that org? I'm specifically interested in ed25519, but wondering if there are plans for more than just curve25519.

As a user this is all quite confusing, so I'm just trying to do my best to navigate the waters of this delicate situation.