[Short group signatures](https://crypto.stanford.edu/~xb/crypto04a/groupsigs.pdf) by Boneh, Boyen, and Shachum and later improved in [ASM](http://web.cs.iastate.edu/~wzhang/teach-552/ReadingList/552-14.pdf) as BBS+ and touched on again in section 4.3 in [CDL](https://eprint.iacr.org/2016/663.pdf). --- This crate implements the BBS+ signature scheme which allows for signing many committed messages. BBS+ signatures can be created in typical cryptographic fashion where the signer and signature holder are the same party or where they are two distinct parties. BBS+ signatures can also be used to generate signature proofs of knowledge and selective disclosure zero-knowledge proofs. To start, all that is needed is to add this to your `Cargo.toml`. ```toml [dependencies] aries_bbssignatures = "0.1" ``` Add in the main section of code to get all the traits, structs, and functions needed. ```rust use aries_bbssignatures::prelude::*; ``` ## Keygen BBS+ supports two types of public keys. One that is created as described in the paper where the message specific generators are randomly generated and a deterministic version that looks like a BLS public key and whose message specific generators are computed using IETF's [Hash to Curve](https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/?include_text=1) algorithm which is also constant time combined with known inputs. `generate(message_count: usize)` - returns a keypair used for creating BBS+ signatures `PublicKey` - _w ⟵ 𝔾2, h0, (h1, ... , hL) ⟵ 𝔾1L_ `DeterministicPublicKey` - _w ⟵ 𝔾2_. This can be converted to a public key by calling the `to_public_key` method. There is a convenience class `Issuer` that can be used for this as well. ```rust let (pk, sk) = Issuer::new_keys(5).unwrap(); ``` or ```rust let (dpk, sk) = Issuer::new_short_keys(None); let pk = dpk.to_public_key(5).unwrap(); ``` ## Signing Signing can be done where the signer knows all the messages or where the signature recipient commits to some messages beforehand and the signer completes the signature with the remaining messages. To create a signature: ```rust let (pk, sk) = Issuer::new_keys(5).unwrap(); let messages = vec![ SignatureMessage::hash(b"message 1"), SignatureMessage::hash(b"message 2"), SignatureMessage::hash(b"message 3"), SignatureMessage::hash(b"message 4"), SignatureMessage::hash(b"message 5"), ]; let signature = Signature::new(messages.as_slice(), &sk, &pk).unwrap(); assert!(signature.verify(messages.as_slice(), &pk).unwrap()); ``` or ```rust // Generated by the issuer let (pk, sk) = Issuer::new_keys(5).unwrap(); // Done by the signature recipient let message = SignatureMessage::hash(b"message_0"); let signature_blinding = Signature::generate_blinding(); let commitment = &pk.h[0] * &message + &pk.h0 * &signature_blinding; // Completed by the signer // `commitment` is received from the recipient let messages = sm_map![ 1 => b"message_1", 2 => b"message_2", 3 => b"message_3", 4 => b"message_4" ]; let blind_signature = BlindSignature::new(&commitment, &messages, &sk, &pk).unwrap(); // Completed by the recipient // receives `blind_signature` from signer // Recipient knows all `messages` that are signed let signature = blind_signature.to_unblinded(&signature_blinding); let mut msgs = messages .iter() .map(|(_, m)| m.clone()) .collect::>(); msgs.insert(0, message.clone()); let res = signature.verify(msgs.as_slice(), &pk); assert!(res.is_ok()); assert!(res.unwrap()); ``` This by itself is considered insecure without the signer completing a proof of knowledge of committed messages generated by the recipient and sent with the commitment. It is **IMPORTANT** that the signature issuer complete this step. For simplicity, the `Issuer` and `Prover` structs can be used as follows to handle this. ```rust let (pk, sk) = Issuer::new_keys(5).unwrap(); let signing_nonce = Issuer::generate_signing_nonce(); // Send `signing_nonce` to holder // Recipient wants to hide a message in each signature to be able to link // them together let link_secret = Prover::new_link_secret(); let mut messages = BTreeMap::new(); messages.insert(0, link_secret.clone()); let (ctx, signature_blinding) = Prover::new_blind_signature_context(&pk, &messages, &signing_nonce).unwrap(); // Send `ctx` to signer let messages = sm_map![ 1 => b"message_1", 2 => b"message_2", 3 => b"message_3", 4 => b"message_4" ]; // Will fail if `ctx` is invalid let blind_signature = Issuer::blind_sign(&ctx, &messages, &sk, &pk, &signing_nonce).unwrap(); // Send `blind_signature` to recipient // Recipient knows all `messages` that are signed let mut msgs = messages .iter() .map(|(_, m)| m.clone()) .collect::>(); msgs.insert(0, link_secret.clone()); let res = Prover::complete_signature(&pk, msgs.as_slice(), &blind_signature, &signature_blinding); assert!(res.is_ok()); ``` ## Proofs Verifiers ask a Prover to reveal some number of signed messages (from zero to all of them), while and the remaining messages are hidden. If the Prover agrees, she completes a signature proof of knowledge and proof of committed values. These messages could be combined in other zero-knowledge proofs like zkSNARKs or Bulletproofs like bound checks or set memberships. If this is the case, the hidden messages will need to linked to the other proofs using a common blinding factor. This crate provides three message classifications for proofs to accommodate this flexibility. - _ProofMessage::Revealed_: message will become known to the verifier. Caveat: cryptography operates on integers and not directly on strings. Usually the hash of the string is signed. The verifier will learn the revealed hash and not the message content. The prover must send the preimage so the verifier can check if the hashes are equal after verifying the signature. - _ProofMessage::Hidden_: message is not shown to the verifier. There are two kinds of hidden messages. - _HiddenMessage::ProofSpecificBlinding_: message is hidden and not used in any other proof, the blinding is specific to this signature only. - _HiddenMessage::ExternalBlinding_: message is hidden but is also used in another proof. For example, to show two messages are the same across two signature or 'linked', the same blinding factor must be used for both proofs. This kind groups the blinding factor and the message. To begin a zero-knowledge proof exchange, the verifier indicates which messages to be revealed and provides a nonce limit the prover's ability to cheat i.e. create a valid proof without knowing the actual messages or signature. The Verifier must trust the signer of the credential and know the message structure i.e. what message is at index 1, 2, 3, ... etc. ```rust let (pk, sk) = Issuer::new_keys(5).unwrap(); let messages = vec![ SignatureMessage::hash(b"message_1"), SignatureMessage::hash(b"message_2"), SignatureMessage::hash(b"message_3"), SignatureMessage::hash(b"message_4"), SignatureMessage::hash(b"message_5"), ]; let signature = Signature::new(messages.as_slice(), &sk, &pk).unwrap(); let nonce = Verifier::generate_proof_nonce(); let proof_request = Verifier::new_proof_request(&[1, 3], &pk).unwrap(); // Sends `proof_request` and `nonce` to the prover let proof_messages = vec![ pm_hidden!(b"message_1"), pm_revealed!(b"message_2"), pm_hidden!(b"message_3"), pm_revealed!(b"message_4"), pm_hidden!(b"message_5"), ]; let pok = Prover::commit_signature_pok(&proof_request, proof_messages.as_slice(), &signature) .unwrap(); // complete other zkps as desired and compute `challenge_hash` // add bytes from other proofs let mut challenge_bytes = Vec::new(); challenge_bytes.extend_from_slice(pok.to_bytes().as_slice()); challenge_bytes.extend_from_slice(nonce.to_bytes().as_slice()); let challenge = ProofNonce::hash(&challenge_bytes); let proof = Prover::generate_signature_pok(pok, &challenge).unwrap(); // Send `proof` and `challenge` to Verifier match Verifier::verify_signature_pok(&proof_request, &proof, &nonce) { Ok(_) => assert!(true), // check revealed messages Err(_) => assert!(false), // Why did the proof failed }; ```