Hello, I'm currently using this in a no_std environment and after adding my own getrandom implementation I enabled the getrandom feature of your crate but alas I got a compile error in your rand_hack when rand is not enabled.

Compiling schnorrkel v0.9.2
error[E0425]: cannot find value `OsRng` in crate `rand_core`
   --> /home/becominginsane/.cargo/registry/src/github.com-1ecc6299db9ec823/schnorrkel-0.9.2/src/lib.rs:233:18
    |
233 |     ::rand_core::OsRng
    |                  ^^^^^ not found in `rand_core`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0425`.
error: could not compile `schnorrkel`

I believe schnorrkel should enable rand_core/getrandom when the feature is enabled, as this scheme currently requires the user to add the feature manually

Seems like dh could be easily added [0] and there seems to be precedent for using the same keys for both signing and encryption [1].

• [0] https://github.com/ZcashFoundation/ristretto255-dh
• [1] https://signal.org/docs/specifications/xeddsa/

The latest version has been published back in March 2020, around 10 months ago. The diff is starting to be quite substantial: https://github.com/w3f/schnorrkel/compare/156b84d6b49c43b49d38869a355a472ce9f30ef3...master

While skimming through this repo, I've noticed a few things that a .travis.yml exists but still seems to contain arteefacts from dalek-cryptography? https://github.com/w3f/schnorrkel/blob/eaf66334f251984a9a9dd545a1c3bb043da62e12/.travis.yml#L30 I think re-enabling travis, and at least adding rust fmt, clippy, cargo audit (and maybe other lints), would help to keep the code quality high.

When attempting to using vrf sign in #[no_std] context, no rand features, and with a custom rng attached to my transcript (via attach_rng) I got a panic, since schnorrkel was attempting to use os-provided rng.

I think it might be due to the "extra" transcript being generated anew without basing it on the existing's transcript rng...

test tests::verify_vrf_sign ... thread 'main' panicked at 'Attempted to use functionality that requires system randomness!!', /home/karrq/.cargo/registry/src/github.com-1ecc6299db9ec823/schnorrkel-0.10.1/src/lib.rs:250:55
stack backtrace:
  0: rust_begin_unwind
            at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/std/src/panicking.rs:493:5
  1: core::panicking::panic_fmt
            at /rustc/07e0e2ec268c140e607e1ac7f49f145612d0f597/library/core/src/panicking.rs:92:14
  2: core::panicking::panic_str
            at /home/karrq/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panicking.rs:57:5
  3: <schnorrkel::rand_hack::PanicRng as rand_core::RngCore>::fill_bytes
            at /home/karrq/.cargo/registry/src/github.com-1ecc6299db9ec823/schnorrkel-0.10.1/src/lib.rs:250:55
  4: merlin::transcript::TranscriptRngBuilder::finalize
            at /home/karrq/.cargo/registry/src/github.com-1ecc6299db9ec823/merlin-3.0.0/src/transcript.rs:329:13
  5: <merlin::transcript::Transcript as schnorrkel::context::SigningTranscript>::witness_bytes_rng
            at /home/karrq/.cargo/registry/src/github.com-1ecc6299db9ec823/schnorrkel-0.10.1/src/context.rs:160:21
  6: schnorrkel::context::SigningTranscript::witness_bytes
            at /home/karrq/.cargo/registry/src/github.com-1ecc6299db9ec823/schnorrkel-0.10.1/src/context.rs:97:9
  7: schnorrkel::context::SigningTranscript::witness_scalar
            at /home/karrq/.cargo/registry/src/github.com-1ecc6299db9ec823/schnorrkel-0.10.1/src/context.rs:90:9
  8: schnorrkel::vrf::<impl schnorrkel::keys::Keypair>::dleq_proove
            at /home/karrq/.cargo/registry/src/github.com-1ecc6299db9ec823/schnorrkel-0.10.1/src/vrf.rs:637:21
  9: schnorrkel::vrf::<impl schnorrkel::keys::Keypair>::vrf_sign_extra
            at /home/karrq/.cargo/registry/src/github.com-1ecc6299db9ec823/schnorrkel-0.10.1/src/vrf.rs:678:40
 10: schnorrkel::vrf::<impl schnorrkel::keys::Keypair>::vrf_sign
            at /home/karrq/.cargo/registry/src/github.com-1ecc6299db9ec823/schnorrkel-0.10.1/src/vrf.rs:667:9

related https://github.com/paritytech/substrate/issues/8208

semver breakage in 0.9.2

it seems 0.9.2 is breaking semver because of merlin major update (from 2.0 to 3.0)

It is because merlin is publicly used: SigningTranscript is implemented on merlin::Transcript

sidenote about rng_hack failing in std or with u64_backend and getrandom but no std.

schnorrkel with features "std" fails with:

error[E0425]: cannot find function `thread_rng` in crate `rand`
   --> src/lib.rs:228:13
    |
228 |     ::rand::thread_rng()
    |             ^^^^^^^^^^ not found in `rand`

for this we need to set the feature rand/std_rng.

And schnrrkel with features "u64_backend" and "getrandom" (and no default features) fails with:

error[E0425]: cannot find value `OsRng` in crate `rand_core`
   --> src/lib.rs:233:18
    |
233 |     ::rand_core::OsRng
    |                  ^^^^^ not found in `rand_core`

I think to fix it we should add specific features to set the rng:

rand_std_rng = ["rand/std_rng"]
getrandom_rng = ["rand_core/getrandom"]
std = ["rand_std_rng", ...]

Hi,

I'd like to make Starsig and Schnorrkel compatible and maybe bikeshed the labels a little. Have you deployed Schnorrkel already, is it hard to update the labels? Would love to hear your thoughts on this: https://github.com/stellar/slingshot/issues/382

Thanks!

This PR addresses the issue outlined in #66.

2 new dependencies were added: serde_bytes to actually use when serializing and deserializing, and cfg_if, so deserialization can use Bytes when in no alloc context and BytesBuf otherwise, since the latter allows to deserialize from more data types where the size is not known or it is not borrowable, such as sequences.

serde has also been renamed in the manifest as serde_crate, similar to curve25519-dalek's manifest, to allow bundling serde_bytes and serde in a single feature flag.

Tests were added to check compatibility with serde_json

Closes #66

During testing I encountered an error when trying to deserialize a PublicKey from a serde_json::Value

Error:

thread 'main' panicked at 'unable to deserialize PublicKey: Error("invalid type: sequence, expected A Ristretto Schnorr public key represented as a 32-byte Ristretto compressed point", line: 0, column: 0)', src/main.rs:11:40

example code can be found here.

I think this can be fixed in multiple ways, either by implementing visit_seq or by making use of serde_bytes (even tho it will probably mean that it'll be necessary to wrap with Bytes during serialization / deserialization manually instead of using the attributes offered)

Adding some test vectors may be helpful to ensure internal consistency.

• few vectors for expanding Secrets into Keypairs, and comparing a known result
• few vectors for signing a payload and comparing to a known result
• few vectors for verifying a result we know should correctly verify

Hello,

I am trying to use schnorr signatures and know that to sign you need a nonce. I know you cannot use the same nonce twice.

My question is that with schnorr signatures, is the signing context made into the nonce. In other words, how do I sign a message by using the signing context if I do not want anything in the signing context? Can I use a static value for the signing context and safely make more signatures with the same signing context?

Sorry if this is a naive question or confusing.

Thank you

We should replace the loose public key interface we inherited from ed25519-dalek:

• https://docs.rs/schnorrkel/latest/schnorrkel/keys/struct.Keypair.html
• https://docs.rs/schnorrkel/latest/schnorrkel/keys/struct.SecretKey.html#method.sign

We'll basically make SecretKey be a keypair that contains the PublicKey. I'm already doing the ring VRF this way, so then we can backport stuff. It's kind an overhaul of the whole crate interface, but once someone asked me how to use schnorrkel with the randomness in merlin disabled, so likely worth doing.

Description

Hello! I'm trying to use the repository https://github.com/w3f/schnorrkel, more specifically the function verify_simple to verify signatures generated by polkadot-js using thesignRaw function and unforunately it's not working. However the function signatureVerify from @polkadot/util-crypto verify correctly the same signature.

Steps to reproduce

1. I've used the polkadot extension and the polkadot-js to generate the signature

https://user-images.githubusercontent.com/17255488/147632039-8dad0b7a-2584-4a3c-9e16-08654d153720.mov

output at console.log 

Public Key (hex) 0xf84d048da2ddae2d9d8fd6763f469566e8817a26114f39408de15547f6d47805
Message => message to sign
Signature (hex) 0x48ce2c90e08651adfc8ecef84e916f6d1bb51ebebd16150ee12df247841a5437951ea0f9d632ca165e6ab391532e75e701be6a1caa88c8a6bcca3511f55b4183

2. With the https://github.com/w3f/schnorrkel cloned at my machine I created the following test case (which fails) at src/sign.rs file:

#[test]
fn verify_polkadot_js_signature() {
      use hex_literal::hex;
      const CTX : &'static [u8] = b"substrate";
        
      let message = b"message to sign";
      let public = hex!("f84d048da2ddae2d9d8fd6763f469566e8817a26114f39408de15547f6d47805");
      let public = PublicKey::from_bytes(&public[..]).unwrap();
        
      let signature = hex!("48ce2c90e08651adfc8ecef84e916f6d1bb51ebebd16150ee12df247841a5437951ea0f9d632ca165e6ab391532e75e701be6a1caa88c8a6bcca3511f55b4183");
      let signature = Signature::from_bytes(&signature).unwrap();
        
      let ok = public.verify_simple(CTX, message, &signature).is_ok();
      assert!(ok)
}

Debugging the polkadot-js signatureVerify function I noticed that this function calls the rust function ext_sr_verify under the hoods by a WASM biding (very interestingly 😄 ) and the rust function uses the same w3f/schnorrkel repository, then I assumed the function ext_sr_sign is used to generate the signature so I decided to create the following test case that uses these 2 functions to generate and verify a signature:

    #[test]
fn sign_and_verify() {
        const CTX : &'static [u8] = b"substrate";
        let sec = SecretKey::generate();
        let pub_bytes = sec.to_public().to_bytes();
        
        // ext_sr_sign function
        let sig = match (SecretKey::from_ed25519_bytes(&sec.to_bytes()), PublicKey::from_bytes(&pub_bytes)) {
            (Ok(s), Ok(k)) => s
                .sign_simple(CTX, message, &k)
                .to_bytes()
                .to_vec(),
            _ => panic!("Invalid secret or pubkey provided.")
        };

        // ext_sr_verify function
        let res =   match (Signature::from_bytes(&sig), PublicKey::from_bytes(&pub_bytes)) {
            (Ok(s), Ok(k)) => k
                .verify_simple(CTX, message, &s)
                .is_ok(),
            _ => false
        };

        assert!(res)
}

And unfortunately, this test case fails. The same thing happens with the https://github.com/ChainSafe/go-schnorrkel package, the original issue was reported into Gossamer discord channel.

Thanks in advance!

Is serde too dangerous for key format stability? Should we remove the serde feature?

It's likely fine if someone uses bincode, etc. but if someone use something with unicode or utf-8 then maybe they'd output ligatures or something similarly messed up

Any thoughts @ordian or @becominginsane ?

Related:

• https://github.com/paritytech/substrate/issues/9072
• https://github.com/w3f/schnorrkel/commits/master/src/serdey.rs

I discovered a trick that avoids the separate individual and batchable VRFProof types, which we'll adopt in the ring VRF crate, so maybe the correct solution would be adopting that here via some VRF2 proof/signature type that requires a PoK. We'd maybe remove VRFProofBatchable from the older VRF design.

I believe VRF2 simplifies doing https://github.com/w3f/schnorrkel/issues/5 with some pre-signing abstraction for witness creation, so we'd eventually generalize the multi-signatures to cover VRF2 after doing https://github.com/w3f/schnorrkel/issues/6 and https://github.com/w3f/schnorrkel/issues/11

I've closed #26 in favor of this. It's different functionality but if you go too far that direction you need bulletproofs really, and the little step never materialized.

The output of the raw diffie-hellman is used as the aead key after compression. Afaik standard practice is to use a hkdf over diffie-hellman to get symmetric keys. Is there a reason why this isn't needed/recommended here?

We could add some analog of the bitfield signed message stuff from the BLS crate: https://github.com/w3f/bls/blob/master/src/bit.rs

Right now, you must implement it yourself using AggregatePublicKey::public_key, but you also cannot really screw it up since you cannot merge signatures like in BLS, so I'm not sure it's really critical here.