From 1e9548614ba139e3c0763741f3efcbf46e26588f Mon Sep 17 00:00:00 2001 From: Alexander Munch-Hansen Date: Fri, 7 Feb 2020 10:39:12 +0100 Subject: [PATCH] Added notes --- notes.org | 56 ++++++++++++++++++++++++++++++++++++++++++++++++ papers_notes.org | 15 +++++++++++++ 2 files changed, 71 insertions(+) create mode 100644 notes.org create mode 100644 papers_notes.org diff --git a/notes.org b/notes.org new file mode 100644 index 0000000..6ff2d59 --- /dev/null +++ b/notes.org @@ -0,0 +1,56 @@ +- 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. diff --git a/papers_notes.org b/papers_notes.org new file mode 100644 index 0000000..0a93b0c --- /dev/null +++ b/papers_notes.org @@ -0,0 +1,15 @@ +* Anonymous Identification in Ad Hoc Groups +- States they can accomplish constant sized signatures. This is not the case however, as they either need to send the group S as a part of the signature or assume that the group S is somewhat static and can thus be assumed to be known. This seems like quite the stretch and I do not consider their signatures to be constant sized as such. +- If this assumption holds, extending it to a threshold scheme is intuitive. +* Short Linkable Ring Signatures Revisited +- These guys use a CA (certificate or central authority?), as part of their key-gen algorithm. This is not a nice feature for complete ad-hoc schemes. +- Question, are we okay with having a central authority? This CA is only used within keygen to create a certificate, it is not used when signing. +* Short Linkable Ring Signatures for E-voting,E-cash and Attestation +- Also requires a CA.. +* The others mentioned in RingCT 2.0: A Compact Accumulator-Based (Linkable Ring Signature) Protocol for Blockchain Cryptocurrency Monero +- Are not public key based, but instead identity based and as such likely requires a PKG as well. +* Constant Size Ring Signature Without Random Oracle +- Uses something called Groth-Sahai commitments whick work in the CRS model.. + + I don't know if you can perhaps make this not be in the CRS model +- Extending this to a constant-sized blind ring signature is an open problem. + + What is a blind ring?