search

w3f / schnorrkel

Schnorr VRFs and signatures on the Ristretto group
BSD 3-Clause "New" or "Revised" License
310 stars 93 forks source link

Should we rip out Ed25519 private key compatibility? #9

Closed burdges closed 5 years ago

burdges commented 5 years ago

As discussed in https://github.com/w3f/schnorrkel/issues/7 we needed to dump the Ed25519 public key compatibility, so we should probably rip out the private key compatibility too for simplicity. We should probably consider the issues further before doing this however, like if anyone wants a migration crate then maybe we should not do this. I suppose the right answer might be: Keep the code for private key compatibility but do not make it the default.

burdges commented 5 years ago

If we keep the Ed25519 keypairs then we should hardcode sha2 as in d81d43e3ae957e4c707560d7aaf9f7326a96eaaa https://github.com/dalek-cryptography/ed25519-dalek/issues/64

Now done in https://github.com/w3f/schnorrkel/commit/be13a05e6cbca2fe3722a97d6611c9343ab7e811

burdges commented 5 years ago

We'll keep minisecretkey being an ed25519 secret key for now. There is only one cost: If you wanted to use these keys in some tricks that expose the non-uniformity then you must make the secretkey directly.

As a poor example, imagine we permit an account public key to be either a public key or a public key hashed to the curve, with the real public key provided. If keys are uniform then an adversary with a quantum computer might attempt to steal funds by breaking an account key. If they did not check if the key had never been used before then they might break one that is hashed to the curve. In that case, they would steal the funds but they're also give the legitimate funds holder the ability to prove a person with a working quantum computer stole their funds. This is all pretty far fetched.

As a better example, someone might use these keys for key exchanges in a mixnet, in which case an adversary with a quantum computer can get one bit of information about their route.

We could fix any worried with more scary warnings on using minisecretkey, but ideally we might just have two mini secret key types, one called Ed25519SecretKey that works like now, and one called something else that uses wide generation for the scalar, so no clamping.

burdges commented 5 years ago

I've ripped out the ed25519-style minisecretkey to secretkey mapping because I expect protocols that want uniformity for secret scalars exist.

I've switched the secret key serialization to canonical bytes instead of the ed25519 compatible bit shifting because that gives a very limited amount of compatibility with more dalek ecosystem crates like slingshot. see https://github.com/w3f/schnorrkel/issues/34

burdges commented 5 years ago

I put back ed25519 private key compatibility because we never updated subkey before asking user to use it. This is fine. It adds a sha2 dependency, and might annoy someone someday, but if anyone ever wants a map from ristretto to ed25519 then they can exploit it, so maybe that's good.