thesis/notes.org

- Write flavors of ring signatures
- Study the short linkable ring signatures for next week
- We should keep in mind that Ring Signatures are per definition unlinkable and so should ours be, regardless of using a linkable scheme to achieve the threshold and proof part.

* Short Linkable Ring Signatures Revisited
** Introduction
- Ring signatures are characterised by anonymity, spontaneity and unlinkability
1) Anonymity
  - 1-out-of-n signer verifiability, enabling signer to keep anonymous in rings of diversion (diverse?) signers
2) Spontaneity
  - Makes distinction between ring signatures and group signatures. In group sigs there exists a TTP (a group manager handling joining). In ring sigs no such TTP exists and the rest of the n-1 members in the ring can be unaware of a new party. 
3) Unlinkability
  - Two ring sigs by the same signer are unlinkable in any way, except for the fast that this signer appears in the rings of both ring signatures.
- Linkable Ring Signatures throw away the notion of unlinkability though. 
  - They allow people to recognise if two signatures come from the same person, while still keeping the identity of this person hidden, yielding linkable-anonymity or pseudonymity.
** Review of scheme with poor security proof
- A linkable ring sig scheme consist of a tuple of algorithms (Init, KeyGen, Sign, Veirfy, Link), each poly-time.
1) Init
  - Generate sys param
2) KeyGen
  - Responsible for generating key pairs for all users in system. KeyGen is exec by a TTP
3) Sign
  - Run by a signer to generate a ring sig
4) Verify
  - Can be invoked by anybody to verify a signature
5) Link
  - Executed by anybody to test whether or not two signatures were generated by same signer
- This scheme uses accumulators
*** Specifically
**** Init
- On sec param \lambda, prepares a collision-resistant accumulator with one-way domain, together with its desc. Then picks uniformly at random a generator g \in QR(N) -- QR(N) explains the group of quadratic residues module the safe prime product N. N is defined by the description of the accumulator. The systems parameters are output as (\lambda, desc, g)
**** KeyGen 
- Executes for every user i in the scheme (So the TTP executes this A LOT), the sampling algo W of the accumulator to obtain (y_i, (p_i, q_i)), so each user's key pair (pk_i, sk_i) = (y_i, (p_i,q_i)), returning a vector of key pairs for all users.
**** Sign
- On input a public key set Y = (pk_1, pk_2, ..., pk_n) s.t. pk_i = y_i for all i, a message M \in \{0,1\}^* and a private key sk_{\pi} = (p_{\pi}, q_{\pi}) corresponding to pk_{\pi} \in Y, do the following:
1) Compute witness w_\pi for y_\pi as w_\pi <- f(u,\{y_i | i \neq \pi\}) (So they accumulate the value we are interested in, the u, with the public keys of all of the other peeps in the scheme!) and then the accumulated value v of all public keys as v <- f(w_\pi, y_\pi), where f is the accumulating function.
2) Compute a signature for: SPK{((w,y), (p,q)) : w^y = v mod N, y = 2pq+1 AND y \in S(2^l, 2^u) AND q \in S^(2^{l/2}, 2^y) AND y = g^{p+q} mod N}(M) -- What the fuck is S? - So, the Signature based on the PoK (so zero knowledge proof) of knowing this w,y,p,q s.t. all of the stuff holds. w is the witness maybe, v is still maybe the accumulated value of all public keys.
3) Denote by \sigma^' the output after the execution of the SPK above. The signature \sigma returned by the algorithm is given by \sigma = (v,y,\sigma^'). The tag y is uniquely determined by the private key sk_\pi.
**** Verify
- Input public key set Y = \{pk_1,...,pk_n\} with pk_i = y_i for all i, a message M \in \{0,1\}^* and a signature \sigma = (v,y,\sigma^') \in \Sigma where \Sigma is the signature space, verifies the statement v ?= f(u,\{y_i | i \in [1,n]\}) and the validity of \sigma^' w.r.t the SPK. Returns accept if both checks pass, rejects ow.
**** Link
- Given two valid sigs, extracts their respective linkability tags and returns linked if they are the same or unlinked otherwise.
**** Security Model
- As their CA has to generate the key pairs for each user as well, this introduces undesired attacks, as the CA is now capable of forging signatures, slandering honest users, revoking linkability-anonymity and undermine linkability.
** Their proposed model
- The old scheme is generating all key pairs for all users in the scheme in one shot, making the scheme non-spontaneous, conflicting a a requirement of ring signatures. As mentioned, one also has to trust this CA unreasonably much.
- Instead, these guys propose a keygen executed by each individual user.
- LINKABLE RING SIG SCHEMES MUST SATISFY:
  1) Verification Correctness -- Sigs signed according to specification are accepted during verification
  2) Linking Correctness -- Two sigs signed according to specification are linked with high prob if the two sigs share a common signed. Two are also unlinked with high prob if they are not.
** Their construction
- KeyGen no longer gens all key pairs, so it is not executed by a single entity.
- The CA is responsible for certifying user public keys, by signing on the public key and possibly along with some other identifying information. The CA must certify a public key only if its bearer can prove that the key pair was generated according to some specification. The CA is trusted to be honest.
- In original scheme, a user key pair (pk,sk) = (y,(p,q)) is generated s.t. y is a prime that equals 2pq+1 where p and q are primes of same size. Since primality can be checked by CA in poly time, we only have to prove that (y-1)/2 is a product of two primes of the same size. This is accomplished by protocol due to the paper: Separability and Efficiency for Generic Group Signature Schemes, and it is called "Prove". This protocol is an interactive 2P protocol between user and the CA. The input to the user is his/her private key. Common input to both parties is the corresponding user public key. In the end, Prove outputs 1 at the CA side only if user has knowledge of the private key, in which case the CA issues a certificate.
- The signing and verification algos should only work with certified user public keys.
- The sigma protocol explained above instantiates a O(1)-sized linkable ring signature scheme, provided the list of public keys is not a part of the signature.