1. Introduction
Monero stands out from other cryptocurrencies in its ability to hide the signer, conceal the transaction amount, and protect the identity of the recepient. Parts 1, 2, 3, 4, 5, and 6 helped us build the foundation to better understand and appreciate the security properties of ring signatures (albeit in the RO model). This part (introduction to MLSAG), as well as part 8 and part 9 will focus on Monero’s privacy in so far as the signer’s identity and the transaction amount are concerned. Part 10 will introduce stealth addresses as a mechanism to protect the identity of the fund’s recipient.
In order to describe how a Monero transaction hides both the signer’s identity and the amount of the transaction, we introduce 2 additional concepts:
- A generalization of the LSAG signature (introduced in part 6) to allow each member of the ring to have a key-pair vector instead of only one pair
- A particular map known as the Pedersen Commitment that will be used to hide transaction amounts while allowing the network to check that input and output amounts always balance out.
Recall that by proving that a digital signature scheme was unforgeable, one gets the assurance that only the signing algorithm associated with a given ring member can produce a valid signature (i.e., verified by ). Any other procedure that bypasses will result in a failed attempt of forgery with overwhelming probability. We note the following about the verification process of :
- In a “non-ring” setting, the verification is done using a particular public key . The validation of a given signature proves that the signer of the message (in this case user ) knows the secret key associated with . Assuming that secret keys are safe-guarded and non-compromised, this actually proves that the user with key-pair () signed the message.
- In a ring setting, the verification is conducted using a public key vector known as a ring. This vector is used to conceal the identity of the signer. The validation of a given signature proves that the the signer of the message (in this case user ) knows the secret key associated with one of the public keys in . Assuming that secret keys are safe-guarded and non-compromised, this actually proves that the user with key-pair () signed the message, for some index that no one other then the actual signer knows.
-
The ring setting can be generalized further by allowing each ring member to have a key-pair vector of length , given by , as opposed to a unique key pair . In this setting, the verification is conducted using a public key matrix
The validation of the signature proves that the signer knows the secret key associated with each one of its public keys. In other terms, there exists a column in (say column ) such that the signer knows the secret key associated with each public key appearing in that column. Assuming that secret keys are safe-guarded and non-compromised, this actually proves that the user with key-pair vector signed the message, for some index (that no one other then the actual signer knows).
2. The MLSAG scheme
The MLSAG signature scheme is a generalization of the LSAG scheme encountered earlier in part 6. It was introduced by Shen Noether in his 2016 paper entitled “Ring Confidential Transactions” [2]. MLSAG security analysis closely mirrors that of the LSAG scheme. Although the security proofs are similar, we will go over them again in detail to highlight the nuances pertaining to the generalization.
Similar to the LSAG version, MLSAG is built on a group of prime order and uses 2 statistically independent ROs:
We carry forward all the notation used in the Cryptonote scheme and the LSAG scheme. In particular, we conduct arithmetic in the subgroup of the elliptic curve group introduced in part 5 (refer to the post entitled Elliptic Curve Groups for an introduction to this topic).
With a slight divergence from [2], we first introduce a hash function before we define . The reason is the same as the one we previously articulated in part 5 and part 6 and will be highlighted in section 4 when we build the signing simulator to prove MLSAG’s resilience against EFACM.
takes an and outputs a tuple . Here is a random element chosen according to a uniform distribution over . We then let . So , takes an element and returns an element where is randomly chosen in
Note that [2] defines as a map from to . Here we restricted the domain and the range to instead. This is because in our exposition, is strictly applied to public keys as opposed to any element of . Public keys are elements of that are scalar multiples of the base point . Moreover, the scalar is never equal to order() (we impose this constraint when we introduce the key generation algorithm ). We are then justified in restricting the domain to . The range is arbitrarily defined to be , which is permissible since it preserves the injective nature of the map.
The MLSAG scheme is defined by a set of 4 algorithms:
- The key generation algorithm }. On input , the MLSAG generation algorithm produces a key-pair vector
of matching secret and public keys. is randomly chosen in , and is calculated as . (Note that and are both elements of while is an element of ( is the security parameter that by design we request to satisfy
In addition to the key-pair vector, computes
is known as the key image vector (or tag vector). It is signer-specific since it depends only on the signer’s private and public keys. It allows the ring linkability algorithm to test for independence between different MLSAG signatures. is modeled as a PPT Turing machine.
Suppose we have a ring of members, each with keys as described above. The objective of the MLSAG scheme is two-fold:
- To demonstrate that one of the signers knows all the secret keys associated with her key-pair vector.
- To ensure that if the signer uses at least one of their secret keys in a different MLSAG signature, then the 2 MLSAG signatures will be flagged as linked and proper measures taken.
-
The ring signing algorithm . Suppose a user decides to sign a message on behalf of the ring . has key-pair vector and key-image vector respectively given by:
Moreover, the public key matrix associated with the ring of users is given by:
MLSAG’s does the following:
- , choose random . Assign:
- :
- , choose random . Assign:
- , where
- , choose random . Assign:
- , set Here denotes regular scalar multiplication in modulo arithmetic. outputs a signature
is a PPT algorithm. We note that one drawback of the MLSAG scheme is the size of the signature. An increase of the ring size by one unit corresponds to an increase of units in the size of the signature. This constraint limits the usage of large ring sizes in practice.
- , choose random . Assign:
- The ring verification algorithm . Given a message , a pubic key matrix of the ring members given by:
and a signature given by
- Let
- :
- , compute:
- , compute:
- The MLSAG verification algorithm checks if where
If equality holds, the signature is valid and outputs True. Otherwise, it outputs False. is a deterministic algorithm.
- The ring linkability algorithm . It takes a -verified valid signature . It checks if any component of the key-image vector was used in the past by comparing it to previous key-image vector components stored in a set . If a match is found, then with overwhelming probability the 2 signatures were produced by the same key-pair vector (as will be justified when we prove the exculpability of the MLSAG scheme in section 5 below), and outputs Linked. Otherwise, its key-image vector is added to and outputs Independent.
3. Security analysis – Correctness
Let be an MLSAG -generated signature. Without loss of generality, assume . Then , we have the following implication:
If then:
-
and :
-
-
Recall that (by design of ) and so and . We therefore conclude by induction on that , . In particular, . This implies that :
We can then invoke a similar induction argument on as the one stated earlier, but this time for . We therefore conclude that:
(by design of )
(by induction proof showing that and )
Subsequently, any MLSAG -generated signature will satisfy ‘s verification test.
4. Security analysis – Unforgeability vis-a-vis EFACM
To demonstrate that the MLSAG scheme is unforgeable, we follow the 5-step approach outlined earlier in part 1. (Recall that for ring signatures, we prove resilience against EFACM with respect to a fixed ring attack as described in part 3 of this series. The nuance here is that we have a fixed public key matrix , as opposed to a fixed public key vector ).
Step 1: To prove that this scheme is secure against EFACM in the RO model, we proceed by contradiction and assume that there exists a PPT adversary such that:
for non-negligible in
Step 2: Next, we build a simulator such that it:
- Does not have access to any component of the private key vector of any signer.
- Has the same range as the original signing algorithm (i.e., they output MLSAG signatures taken from the same pool of potential MLSAG signatures over all possible choices of RO functions and random tapes and ).
- Has indistinguishable probability distribution from that of over this range.
The reason we introduced as opposed to introducing only is that the simulator makes use of the random elements in order to set to the desired value. In other words, in the absence of knowledge about , the simulator needs to have access to the random element that is used in the calculation of in order to ensure that equates to
By construction, the output of will satisfy the verification equation. Moreover, it does its own random assignments to what otherwise would be calls to RO (i.e., bypasses RO ). Next, note the following:
- does not use any private key.
- and both have a range
such that and where and are calculated as follows:
- Let
- :
- compute:
- compute:
- and have the same probability distribution over . Indeed, , we have:
- For
The first factor is the probability of choosing the exact value in the set that is equal to . The second factor is the probability of choosing the exact values given by and the ‘s
- For :
Note that the range of is equal to by construction of . And so the first factor is the probability of choosing the exact value in the set that is equal to . The second factor is the probability of choosing the exact values given by and the ‘s
- For
With adequately built, we conclude that (as justified in section 6 of part 1):
for non-negligible in .
Step 3: We now show that for the MLSAG scheme, the probability of faulty collisions is negligible (refer to section 6 of part 1 for an overview). The 2 tyes of collisions are:
- : such that a tuple that encounters — recall that makes its own random assignment to and bypasses RO — also appears in the list of queries that sends to RO . A conflict in the 2 values will happen with overwhelming probability and the execution will halt.
- : such that a tuple that encounters — makes its own random assignment to — is similar to that encountered earlier — here too, randomly assigns . Since
the assignments must also match, i.e.,
However, the likelihood that the 2 are equal is negligible. Hence they will be different with overwhelming probability and the execution will halt.
The aforementioned collisions must be avoided. In order to do so, we first calculate the probability of their occurrence in an MLSAG scheme. We assume that during an EFACM attack, can make a maximum of queries to RO , a maximum of queries to RO , and a maximum of queries to . , , and are all assumed to be polynomial in the security parameter , since the adversary is modeled as a PPT Turing machine.
(since by design).
Recalling that and are polynomial in , we conclude that is negligible in
Next, we compute
(since by design).
Recalling that is polynomial in , we conclude that is negligible in
Putting it altogether, we find that the below quantity is negligible in :
This allows us to conclude that the below quantity is non-negligible in (refer to section 6 of part 1 for a justification):
Step 4: In this step, our objective is to show that if is a successful tuple that generated a first MLSAG EFACM forgery, then the following quantity is non-negligible in
Here is an appropriate index that we will define in the proof. To further simplify the notation, we let and for all . ( and denote respectively the query to and to ).
Let’s take a closer look at
Any successful MLSAG forgery must satisfy the verification equation where we let , and
- , compute:
We distinguish between 3 scenarios (without loss of generality, we assume that all -queries sent to RO are distinct from each-other. Similarly, all -queries sent to RO are distinct from each-other. This is because we can assume that keeps a local copy of previous query results and avoid redundant calls):
- Scenario 1: was successful in its forgery, and
- No collisions occured, and
- such that it never queried RO on input .
- Scenario 2: was successful in its forgery, and
- No collisions occured, and
- it queried RO on input during execution, and
- such that it queried RO on input after it had queried RO on input .
- Scenario 3: was successful in its forgery, and
- No collisions occured, and
- it queried RO on input during execution, and
- , it queried RO on input before it queried RO on input
The probability of scenario 1 is upper-bounded by the probability that picks such that it matches the value of . If the 2 values don’t match, then will be different than (by the verification algorithm ). It is upper-bounded because at the very least, this constraint must be observed to pass the verification test. is the value that RO returns to (the verification algorithm) when verifying the validity of the forged signature. And since can be any value in the range of (which was defined to be ) we get:
, which is negligible in
In scenario 2, let and be 2 indices such that queried RO on input after it had queried RO on input . Note that during the verification process, will calculate and hence will make a call to on input (remember that is derived from ). The probability that the resulting matches the argument previously fed to is upper-bounded by (since the range of ). Moreover, can be any index in and any index in . We get:
, which is negligible in
So we assume that a successful MLSAG forgery will likely be of the Scenario 3 type.
which is non-negligible in
The rest of the proof for Step 4 is exactly the same as the one outlined for the LSAG scheme. We will not reproduce it here (the reader can refer to the details in section 4 of part 5).
Step 5: The final step uses the 2 forgeries obtained earlier to solve an instance of the Discrete Logarithm (DL) problem. Here is a recap of Step 4 results:
- With non-negligible probability of at least we get a successful tuple , s.t. for some vector of indices (note that in this context, refers to a specific set of indices and not to the key-image vector. Review section 4 of part 5 for a definition of and ). By running a number of times polynomial in , we can find such a tuple.
- Once we find such a tuple, we’ve also shown that with non-negligible probability of at least , we can find another successful tuple s.t. and
Let correspond to forgery
and correspond to forgery
Recall that is the index of the last query of the form
that sends to RO (). Since the 2 experiments corresponding to the 2 successful tuples have:
- The same random tapes and
- The same RO
- ROs and behave the same way on the first queries,
we can be confident that the first queries sent to the 2 ROs and are identical. In other words, we have
Without loss of generality, let , (where ), correspond to the last query of this type sent to RO . That means that is the query sent to RO . We have:
(where ( whenever )
(by writing
Moreover, we have
(by definition of in )
(by design of the forgery tuples)
(by definition of in )
And so , we can solve for in polynomial time, contradicting the intractability of DL on elliptic curve groups. We conclude that MLSAG is secure against EFACM in the RO model.
5. Security analysis – Exculpability
This section is concerned with the notion of exculpability from an unforgeability standpoint as described in [1]. A detailed discussion can be found in part 5 of this series. The setting is similar to the one previously described in part 5 and part 6, with a small nuance. Suppose all private keys of each member of an subset of ring members have been compromised in an -ring setting. Let denote the index of the only non-compromised user with key-vector , and let denote the key-image vector associated with it. We investigate whether it is likely to produce a valid forgery with key-image vector that includes at least one component equal to for some . In what follows, we show that this can only happen with negligible probability. In essence, this means that a non-compromised honest ring member (by honest we mean a ring member that signs at most once using his private key-vector) does not run the risk of encountering a forged signature that carries any component of his key-image vector. In the context of Monero, this implies that a non-compromised honest ring member cannot be accused of signing twice using the same key-image vector, and hence is exculpable.
Note that since the adversary has access to all the compromised private keys of members, it can easily calculate their corresponding public key vectors. Doing so will allow it to identify the public key vector of the non-compromised ring member and hence determine the index . In order to prove the exculpability of the MLSAG scheme, we follow an almost identical proof to that of the previous section (i.e., unforgeability vis-a-vis EFACM) and apply the same 5-step approach. The objective is to show that this particular type of forgery would imply the ability to solve the DL of at least one component of . The nuance resides in the specific index for which the DL will be solved, as opposed to any other index. This is because we assume that all the other members are compromised and hence their DLs (i.e., private keys) are common-knowledge.
Step 1: We proceed by contradiction and assume that there exists a PPT adversary such that:
, for non-negligible in
We refer to “succeeds in creating a forgery as . We re-write the above equation as:
, for non-negligible in
The notation used makes it explicit that can access the set of compromised key vectors with excluded. Success is defined as issuing a forged signature with a key image vector that shares at least one component with the key image vector of the non-compromised user . We let this component be for some . (Recall that is derived from
Step 2: The next step consists in building a simulator such that it:
- Does not have access to any component of the private key vector of any signer.
- Has the same range as the original signing algorithm (i.e., they output MLSAG signatures taken from the same pool of potential MLSAG signatures over all possible choices of RO functions and respective random tapes and ).
- Has indistinguishable probability distribution from that of over this range.
The simulator is the same as the one we built in the previous section. The only difference is that does not choose a random index , since already knows the index of the non-compromised ring member.
Step 3: The logical reasoning and procedure are identical to those of the previous section. We conclude that
Step 4: Here too, the logical reasoning and procedure are identical to those of the previous section. In particular, we define the following sets in a similar way:
and conclude that:
, which is non-negligible in
Here , as before, is an appropriately defined index, for all and denotes the query sent to RO.
Step 5: The final step uses the 2 forgeries obtained earlier to solve an instance of the Discrete Logarithm (DL) problem. Here is a recap of Step 4 results:
- With non-negligible probability of at least we get a successful tuple , s.t. for some vector of indices (note that in this context, refers to a specific set of indices and not to the key-image vector. Review section 4 of part 5 for a definition of and ). By running a number of times polynomial in , we can find such a tuple.
- Once we find such a tuple, we’ve also shown that with non-negligible probability of at least , we can find another successful tuple s.t. and
Let correspond to forgery
and correspond to forgery
Recall that is the component of ‘s key image vector that appears in the forgery. is the index of the last query that sends to RO of the form Since the 2 experiments corresponding to the 2 successful tuples have:
- The same random tapes and
- The same RO
- ROs and behave the same way on the first queries,
we can be confident that the first queries sent to the 2 ROs and are identical. In other words, we have
, and
In particular, for the index that corresponds to the component that appears in the forgery, we let , and . For each , we get 2 identical systems of equations dictated by ‘s verification computation:
, the first system is a linear system of 2 equations in variables and . Similarly, the second system is a linear system of 2 equations in variables and . The 2 systems are identical with different variable names. Hence, if is a unique solution to the first system and a unique solution to the second, we can be confident that and . (Note that for any index other than , the 2 forged signatures do not necessarily share the same image-key component. In other terms is not necessarily equal and so the 2 systems of linear equations would be different from each other). For either system to admit a unique solution, the 2 equations must be linearly independent. We re-write the 2 systems as follows:
If we multiply the second equation by (multiplication refers to ), we see that a sufficient condition for the system to be linearly independent is to have . Next, we show that with overwhelming probability, the system is indeed independent :
- Recall that the range of is and that the order of
- Therefore, such that and
- We can then re-write the sufficient condition as
- Note that given , and , there is at most one value of that satisfies . Otherwise, we would have
, , and
This would imply that , a contradiction.
- Noting that each corresponds to a distinct , we conclude that given and there is at most one s.t.
- Since is a RO outputing random values, the probability of getting the right value of is (negligible in ).
, we therefore conclude that with overwhelming probability we have . We can then be confident that the linear system of 2 equations has a unique solution. Hence, , we have , and
Moreover, by design of the 2 forgeries, we know that there exists one and only one (corresponding to the query sent to RO ) that satisfies
(by definition of in )
(by design of the forgery tuples)
(by definition of in )
But , we showed that with overwhelming probability . Therefore, it must be that and so
Going back to the system of 2 equations associated with , we write:
That means that we can solve for in polynomial time, contradicting the intractability of DL on elliptic curve groups. We conclude that the MLSAG scheme is exculpable and secure against in the RO model.
6. Security analysis – Anonymity
In this section, we show that the MLSAG scheme satisfies the weaker anonymity definition #2 introduced in part 3 of this series. Note that as we previously observed in part 5, linkable signatures cannot satisfy anonymity definition #1.
More formally, let be a PPT adversary with random tape that takes 4 inputs:
- Any message
- A public key matrix that includes of the signer.
- A list of compromised private key vectors ( can be empty and may be different than for But
- A valid signature on message , public key matrix and actual signer private key vector
outputs an index in that it thinks is that of the actual signer. Definition # 2 mandates that for any polynomial in security parameter , we have:
if and
if or
In the RO model, can send a number of queries (polynomial in ) to RO and RO . The probability of ‘s success is computed over the distributions of and . Making explicit the dependence on the ROs, definition # 2’s condition becomes:
if and
if or
In order to prove that anonymity holds in the above sense, we proceed by contradiction and rely on the intractability of the Decisional Diffie Hellman problem or DDH for short (refer to part 5 for a discussion of DDH). We consider 3 separate cases:
Case 1: and
Suppose that in PPT() and non-negligible in such that
if and
Recall that since , one can automatically rule out all the compromised ring members as possible signers (the logic is similar to what was described in the anonymity section of part 5). One can then limit the guessing range of the identity of the signer to the uncompromised batch of remaining members.
We now build PPT() that colludes with to solve the DDH problem. The input to consists of 1) The tuple being tested for DDH, 2) A certain ring size (randomly chosen), 3) A number of compromised members (randomly chosen), and 4) A message (randomly chosen).
outputs a tuple consisting of 1) The message , 2) A randomly generated public key matrix , 3) A randomly chosen set of compromised secret key vectors, and 4) A not-necessarily valid signature assigned to ring member s.t. . We let do the following:
feeds its output to . In order for to use its advantage in guessing the signer’s identity, it must be given a valid signature (i.e., a signature that is an element of the range of acceptable MLSAG signatures over all RO . For to be a valid signature, must be a DDH instance. Indeed, let be partially defined as per the design of . We show that for such an , the signature obtained is an element of the range of acceptable MLSAG signatures. First note the following (all the primed quantities below are as defined in the verification algorithm :
If then:
-
- , if
- , if
Since is a DDH instance then we necessarily have
Moreover, recall that (by design of ). And so
and We therefore conclude by induction on that , . In particular, This in turn implies that is a valid signature.
On the other hand, if is not a DDH instance, then and with overwhelming probability is not a valid signature.
Recall that can send queries to and during execution. It is important to enforce consistency between and ‘s query results obtained from RO and RO on the same input. There are no risks of faulty collisions in so far as is concerned (by design of ). However, bypasses RO and conducts its own backpatching to . If such that queries on input , then with overwhelming probability, it will conflict with ‘s backpatched value causing the execution to halt. The aforementioned collision must be avoided. In order to do so, we first calculate the probability of its occurence. We assume that during execution, can make a maximum of queries to RO . is assumed to be polynomial in the security parameter , since the adversary is modeled as a PPT Turing machine.
and so we conclude that:
Here, non-negligibale in
After execution, returns to an integer . outputs 1 if or outputs 0/1 with equal probability otherwise:
Using the setting described above, one can now calculate the probability of guessing whether is DDH or not. The calculation is the same as the one previously conducted in section 6 of part 5 and part 6 and leads us to conclude:
Since is non-negligible in , the above probability outperforms random guessing. This contradicts the intractability of DDH. Similarly, we can show that
is also bounded from below. We finally conclude that for any polynomial :
Case 2: and
In this case, can check if the key-image vector appearing in matches the key-image vector of any of the compromised users (i.e., , for . With overwhelming probability, none of them will match since we proved that the scheme is exculpable and so no one can forge a signature with a tag of a non-compromised member. Proceeding by elimination, can then conclude that the signer is
Case 3:
In this case, can check which of the compromised key-image vectors (i.e., , for matches the key-image vector appearing in ). Only one of them will match (due to exculpability), subsequently revealing the identity of the signer
7. Security analysis – Linkability
The linkability property means that if a secret key of a given secret key vector is used in more than one signature, then the resulting signatures will be linked and flagged by (the linkability algorithm).
We proved in part 5 of this series that a signature scheme is linkable if and only if a ring of members, it is not possible to produce valid signatures with pairwise different key-images such that all of them get labeled independent by . This result can be easily adapted to the case of a public key matrix (where ) and secret key vectors
A signature scheme is linkable
a ring of members, it is not possible to produce valid signatures such that no 2 key image vectors share a component in common.
The proof of the above equivalence is identical to the one previously outlined in section 7 of part 5. To prove that the MLSAG scheme is linkable we follow a reductio ad absurdum approach, similar to the one described in part 5:
-
- Assume that the MLSAG signature scheme is not linkable.
- The equivalence above would imply that such that it can produce valid signatures such that no 2 key image vectors share a component in common. This means that
- This implies that there must exist a signature (from the set of valid signatures) with key-image vector for which such that
Denote this signature by
- When verifying the validity of first computes the following:
- Let
- :
- , compute:
- , compute:
- , and for as identified above, the system of 2 equations given by and can be equivalently written as:
For a given , , and , this constitutes a system of 2 equations in variables and
-
-
Since , the system of 2 equations corresponding to each is independent and admits a unique solution for any given and . In particular, that means that the value is well defined and equal to
-
By virtue of being a valid signature, must satisfy ‘s verification equation requiring that
But RO is random by definition. The probability that it outputs a specific value is eqal to (recall that the range of ). Since by design we have , we conclude that the probability that
is upper-bounded by and is hence negligible. In other terms, the probability that is a valid signature is negligible.
We hence conclude that the MLSAG scheme is linkable.
References
[1] E. Fujisaki and K. Suzuki. Traceable ring signatures. Public Key Cryptography, pages 181-200, 2007.
[2] S. Noether and A. Mackenzie. Ring condential transactions. Monero Research Lab, 2016.
Tags: LSAG, MLSAG, Monero, multilayered, ring signature, Security
No comments
Comments feed for this article
Trackback link: https://delfr.com/mlsag-signature-moneros-part-7/trackback/