Rename spk -> proof

draft-bbs-signatures.md

@@ -75,7 +75,7 @@ Below is a basic diagram describing the main entities involved in using the sche
 
 !---
 ~~~ ascii-art
- (1) sign (3) spkGen (5) spkVerify
+ (1) sign (3) ProofGen (5) ProofVerify
  +----- +----- +-----
  | | | | | |
  | | | | | |
@@ -136,10 +136,7 @@ nonce
 : A cryptographic nonce
 
 presentation\_message (pm)
-: A message generated and bound to the context of a specific spk.
-
-spk
-: Zero-Knowledge Signature Proof of Knowledge.
+: A message generated and bound to the context of a specific proof.
 
 nizk
 : A non-interactive zero-knowledge proof from fiat-shamir heuristic.
@@ -459,14 +456,14 @@ Procedure:
 8. return C1 == C2
 ```
 
-### SpkGen
+### ProofGen
 
 A signature proof of knowledge generating algorithm that creates a zero-knowledge proof of knowledge of a signature while selectively disclosing messages from a signature given a vector of messages, a vector of indices of the revealed messages, the signer's public key, and a presentation message.
 
 If an application chooses to pass the indexes of the generators instead, then it will also need to pass the indexes of the generators corresponding to the revealed messages.
 
 ```
-spk = SpkGen(PK, (msg_1,..., msg_L), (H_1,..., H_L), RevealedIndexes, signature, pm)
+proof = ProofGen(PK, (msg_1,..., msg_L), (H_1,..., H_L), RevealedIndexes, signature, pm)
 
 Inputs:
 
@@ -479,7 +476,7 @@ Inputs:
 
 Outputs:
 
-- spk, octet string
+- proof, octet string
 
 Procedure:
 
@@ -527,23 +524,23 @@ Procedure:
 
 22. for j in (j1, j2,..., jU): m^_j = m~_j + c * msg_j
 
-23. spk = ( A', Abar, D, c, e^, r2^, r3^, s^, (m^_j1, ..., m^_jU))
+23. proof = ( A', Abar, D, c, e^, r2^, r3^, s^, (m^_j1, ..., m^_jU))
 
-24. return spk
+24. return proof
 ```
 
-### SpkVerify
+### ProofVerify
 
-SpkVerify checks if a signature proof of knowledge is valid given the proof, the signer's public key, a vector of revealed messages, a vector with the indices of these revealed messages, and the presentation message used in SpkGen.
+ProofVerify checks if a signature proof of knowledge is valid given the proof, the signer's public key, a vector of revealed messages, a vector with the indices of these revealed messages, and the presentation message used in ProofGen.
 
 ```
-result = SpkVerify(spk, PK, (msg_i1,..., msg_iR), (H_1,..., H_L), RevealedIndexes, pm)
+result = ProofVerify(proof, PK, (msg_i1,..., msg_iR), (H_1,..., H_L), RevealedIndexes, pm)
 
 Inputs:
 
-- spk, octet string.
+- proof, octet string.
 - PK, octet string in output form from SkToPk.
-- msg_i1,..., msg_iR, octet strings. The revealed messages in input to spkGen.
+- msg_i1,..., msg_iR, octet strings. The revealed messages in input to ProofGen.
 - H_1,..., H_L, points of G1. The generators in input to Sign.
 - RevealedIndexes, vector of unsigned integers. Indexes of revealed messages.
 - pm, octet string
@@ -560,7 +557,7 @@ Procedure:
 
 3. (j1, j2, ..., jU) = [L]\RevealedIndexes
 
-4. (A', Abar, D, c, e^, r2^, r3^, s^, (m^_j1,...,m^_jU)) = spk
+4. (A', Abar, D, c, e^, r2^, r3^, s^, (m^_j1,...,m^_jU)) = proof
 
 5. C1 = (Abar - D) * c + A' * e^ + H0 * r2^
 
@@ -581,7 +578,7 @@ Procedure:
 
 ### CreateGenerators
 
-The CreateGenerators operation defines how to create a set of generators that form a part of the public parameters used by the BBS Signature scheme to accomplish operations such as sign, verify, spkgen and spkverify.
+The CreateGenerators operation defines how to create a set of generators that form a part of the public parameters used by the BBS Signature scheme to accomplish operations such as sign, verify, ProofGen and ProofVerify.
 
 *Note* The scope in which the seed used below is determined, is still an active conversation in the working group see (#ciphersuites) for the current method being used.
 
@@ -617,7 +614,7 @@ Procedure:
 
 ### MapMessageToScalar
 
-There are multiple ways in which messages can be mapped to their respective scalar values, which is their required form to be used with the sign, verify, spkGen and spkVerify operations.
+There are multiple ways in which messages can be mapped to their respective scalar values, which is their required form to be used with the sign, verify, ProofGen and ProofVerify operations.
 
 #### MapMessageToScalarAsHash
 
@@ -666,7 +663,7 @@ The IKM input to KeyGen MUST be infeasible to guess and MUST be kept secret. One
 
 Secret keys MAY be generated using other methods; in this case they MUST be infeasible to guess and MUST be indistinguishable from uniformly random modulo q.
 
-BBS proofs (SPK's) are nondeterministic, meaning care must be taken against attacks arising from using bad randomness, for example, the nonce reuse attack on ECDSA [@HDWH12]. It is RECOMMENDED that the presentation messages used in this specification contain a nonce chosen at random from a trusted source of randomness, see the (#presentation-message-selection) for additional considerations.
+BBS proofs are nondeterministic, meaning care must be taken against attacks arising from using bad randomness, for example, the nonce reuse attack on ECDSA [@HDWH12]. It is RECOMMENDED that the presentation messages used in this specification contain a nonce chosen at random from a trusted source of randomness, see the (#presentation-message-selection) for additional considerations.
 
 BlindSign as discussed in 2.10 uses randomness from two parties so care MUST be taken that both sources of randomness are trusted. If one party uses weak randomness, it could compromise the signature.
 
@@ -686,9 +683,9 @@ In addition, ciphersuites MUST specify unique domain separation tags for hash\_t
 
 BBS signatures can be implemented on any pairing-friendly curve. However care MUST be taken when selecting one that is appropriate, this specification defines a ciphersuite for using the BLS12-381 curve in (#ciphersuites) which as a curve achieves around 117 bits of security according to a recent NCC ZCash cryptography review [@ZCASH-REVIEW].
 
-## Security of spkGen
+## Security of Proofs generated by ProofGen
 
-The BBS proof, as returned by spkGen, is a zero-knowledge proof-of-knowledge [@CDL16]. This guarantees that no information will be revealed about the signature itself or the undisclosed messages, from the output of spkGen. Note that the security proofs in [@CDL16] work on type 3 pairing setting. This means that G1 should be different from G2 and with no efficient isomorphism between them.
+The proof, as returned by ProofGen, is a zero-knowledge proof-of-knowledge [@CDL16]. This guarantees that no information will be revealed about the signature itself or the undisclosed messages, from the output of ProofGen. Note that the security proofs in [@CDL16] work on type 3 pairing setting. This means that G1 should be different from G2 and with no efficient isomorphism between them.
 
 # Ciphersuites
 
@@ -1114,9 +1111,9 @@ And the following signature
 
 Along with the PK value as defined in (#key-pair) as inputs into the Verify operation should fail signature validation due to public key used to verify is in-correct
 
-## Signature Proof of Knowledge Algorithmic Explanation
+## Proof Generation and Verification Algorithmic Explanation
 
-The following section provides an explanation of how the Signature Proof Of Knowledge Generation (SpkGen) works.
+The following section provides an explanation of how the ProofGen and ProofVerify operations work.
 
 Let the prover be in possession of a BBS signature `(A, e, s)` with `A = B * (1/(e + Sk))` where `Sk` the signer's secret key and,
 
@@ -1135,7 +1132,7 @@ Let the prover be in possession of a BBS signature `(A, e, s)` with `A = B * (1/
  4. r3 = r1 ^ -1 mod q
  5. s' = s + r2 * r3.
 
- The values `(A', Abar, d)` will be part of the spk and are used to prove possession of a BBS signature, without revealing the signature itself. Note that; `e(A', Pk) = e(Abar, P2)` where `Pk` the signer's public key and P2 the base element in G2 (used to create the signer’s `Pk`, see [SkToPk](#sktopk)). This also serves to bind the spk to the signer's `Pk`.
+ The values `(A', Abar, d)` will be part of the proof and are used to prove possession of a BBS signature, without revealing the signature itself. Note that; `e(A', Pk) = e(Abar, P2)` where `Pk` the signer's public key and P2 the base element in G2 (used to create the signer’s `Pk`, see [SkToPk](#sktopk)). This also serves to bind the proof to the signer's `Pk`.
 
 - Set the following,
 
@@ -1147,7 +1144,7 @@ Let the prover be in possession of a BBS signature `(A, e, s)` with `A = B * (1/
  EQ1. C1 = A' * (-e) - H0 * r2
  EQ2. C2 = D * (-r3) + H0 * s' + H_j1 * msg_j1 + ... + H_jU * msg_jU.
 
- If both EQ1 and EQ2 hold, and `e(A', Pk) = e(Abar, P2)`, an extractor can return a valid BBS signature from the signers `Sk`, on the disclosed messages. The spk returned is `(A', Abar, d, nizk)`. To validate the spk, a verifier checks that `e(A', Pk) = e(Abar, P2)` and verifies `nizk`.
+ If both EQ1 and EQ2 hold, and `e(A', Pk) = e(Abar, P2)`, an extractor can return a valid BBS signature from the signers `Sk`, on the disclosed messages. The proof returned is `(A', Abar, d, nizk)`. To validate the proof, a verifier checks that `e(A', Pk) = e(Abar, P2)` and verifies `nizk`.
 
 <reference anchor="SHA3" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf">
  <front>