Little write-up on Monero's "ring signature" construction; enjoy!
Below is a graphic showing what a "normal" transaction looks like (Bitcoin), for comparison:
As we can see in the chart above, transactions can be finitely tied to addresses on blockchain (without a doubt). While it is true we may not always know the name of the identity behind a given address, there is zero doubt about where a given transaction came from. In fact, Bitcoin does just the opposite by enshrining quasi-permanent evidence on the blockchain akin to a living archive that one refer to as as proof that a certain address sent some form of payment on the blockchain.
Specifically, when we mention proof - we're referring to the fact that virtually all transactions include a signature, which is cryptographically linked to the associated public key for the wallet address, removing virtually all doubt about the address of the sender.
Below is a closer look at some of the granular information included within each transaction:
How Ring Signatures Work
Ring signatures are expressly different in that the sender of the transaction includes addresses of several other potential senders of the transaction.
Out of all the addresses in a given ring signature construction, only one of them is the actual sender of the transaction. Transaction amounts are also not included with transactions as a means of further removing information that observers could use to 'decode' the transaction and figure out the true sender.
Despite there being several proposed candidates for the transaction (including the "real" one), only one signature is produced and verified by the blockchain as proof that the transaction is legitimate. This signature can be verified & validated as legitimate without knowing the identity of the "true" sender in the group.
All of these characteristics are able to exist within this "ring signature" structure due to cryptographic principles premised on certain empirical mathematical proofs. For the sake of brevity, those cryptographic principles will not be elaborated upon in this write-up.
Below is a visualized representation of a transaction constructedf rom a 'ring signature' setup:
Take a mental snapshot of that photo above its going to be used in the next section where we uncover how 'MyMonero' rips this privacy model to shreds.
Understanding How Decoys are Selected on Monero
Few are familiar with how Monero works on a fundamental level (if you read the description), its clear in MyMonero's construction that there is zero privacy afforded to the end user.
Reasons for this are:
Use of WebRTC: This exposes the user's IP address to the server that they are connecting to. Also, this deviates from the JSON-RPC that is normally for RPC connections. Since there is one endpoint that is receiving the information, polling the blockchain and 'bookmarking' various points in the blockchain where transactions are stored, 'MyMonero' stands as one major central point of failure for anyone relying on their services.
Deceptive Marketing Surrounding the Use of the View Key: According to MyMonero's website, "only your view key" is shared with the server. Yet, in the very next sentence the service claims that they "keep no log". If that is the case, then there is no reason for any portion of any user's keys to be kept on the server.
OpenAlias is Not Secure: This goes down to the construction of OpenAlias itself as a protocol. While Monero claims that DNSSEC validation is provided for any and all URIs linked with OpenAlias, there is no documentation outlining exactly how this is done. Additionally, it is not clear in the codebase where (if anywhere) such validation takes place. That point aside, the DNS system was never designed to afford anonymity or privacy to those that use it (hence why 'TLS', 'dnscrypt', 'VPNs' etc., are so popular today). Thus, by taking a private protocol like Monero and tying one's address with a finite entity, the opsec risk incurred is enormous (potentially eroding privacy flat out for all users of the protocol).
False Claims Made on the Site
On the site, there is a brief paragraph at the bottom of the page that makes the following claim:
"Your app data is saved locally under strong encryption and only your "view key" is shared with the server. We keep no logs. You can also connect to your own server under Preferences."
However, this statement is wholly inconsistent with one made at the top of the webpage where it states:
"There's no Monero blockchain node to run. The MyMonero server does the heavy lifting for free. Forget spending days syncing the blockchain from your phone while waiting in line to pay for coffee. Get your entire transfer history instantly on any device with only your seed words."
Breaking Down Transaction Sending on the Monero Protocol
The key to understanding the contradiction in the two quotes requires some understanding of how transactions are sent to users on the Monero protocol.
When a user generates a Monero address they receive 5 different addresses in return:
The formatting of the webpage chomped up one of the inputs (use your imagination), but what a user will typically receive is their:
private spend key
public spend key
private view key
public view key
concatenated Monero address
Breaking Down the Spending Process
Whenever someone wishes to send funds to another using Monero, they will send over their 96-byte Monero address.
This address is a concatenation (combination) of both the public spend and view keys.
The sender splits this 96-byte key into its two constituent parts, then derives a sub-address from the public spend key (first). This address is considered the stealth key.
Once the stealth key has been created, a transaction is crafted by the sender that makes the payment to the stealth key, then that transaction is encrypted to the public spend key of the recipient.
From that point, the recipient must scan each and every single transaction on the blockchain, attempting to decrypt each, until they find the correct one (i.ehttps://dev.to/librehash/rust-ephemeral-encrypted-containersfs-maybe-4jlk., the transaction that they are able to successfully decrypt). At that point the recipient can log the transaction in their wallet address as one that they've positively received (without finding this information, the payment is effectively "lost" [to everyone except the sender of the transaction]).
This process requires the recipient to use their private view key. Once the transaction has been retrieved, the recipient must use their private spend key to actually spend it to someone else (spending the transaction requires the same process).
Below is an illustration that captures this process succinctly:
Tying This into the Research Paper's Findings
Let's go back to how someone sends a transaction on Monero.
First they receive the 96-byte address (or copy it from whatever website its hosted at). The address is the result of the concatenated public view & spend keys of the intended recipient.
Once these two keys are extracted from the 96-byte address, a subkey is derived from the public view key.
Once that subkey is generated / derived from the public view key (using scalar multiplication ; leveraging commutative property), the subkey (public) is then encrypted to the recipient's public view key.
The sender does not usually reveal where they sent the transaction to. However, the sender does possess knowledge that will allow them to know when the transaction has been sent - the key image.
Key Image in Monero
Every single transaction is accompanied with a 'key image' of some sort. That key image is necessary for funds to be spent by the recipient of (whatever) transactions that they have received.
The key image is unique for each and every single transaction on the blockchain. The key image is generated with each output, but the key image from that output is not seen in the actual chain until that output is spent (at some point).
Thus, the sender is in a position where they're able to at least tell when/whether a recipient has spent the funds that they received by (a) retaining the derived public key that they generated & (b) also remembering the key image that was generated with the transaction itself (if given directly to the recipient, the 'key image' can be used as a means of bypassing the extensive process of scanning the entire blockchain & attempting to decrypt each output until one's key successfully does so).
Exemplified in Documentation + Monero Construction
By virtue of the cryptography that Monero uses, there exists a way for spenders to prove that they spent funds from their wallet (w/o needing to enter the derived recipient address into the equation).
Documentation (in laymen's terms), can be found here - https://www.getmonero.org/resources/user-guides/prove-payment.html (not entirely sure about the veracity of this source, but from what I can see, it appears that the information on *this page was at least accurate; mentioning this because there are a substantial # of pages where the information was not accurate for some reason).
More information about 'proving' that one has made a payment can be found here as well - https://www.monero.how/tutorial-how-to-prove-payment
Out of both links that were sent, however, this latest one provides the best 'proof' that a sender can tell when a transaction has been spent (by the recipient; assuming the sender kept all of the technical details of the send).
Here is the link - https://monerodocs.org/cryptography/asymmetric/key-image/ (these are great docs)
Specifically, this documentation notes that:
Key images prevent double spend attempts
Funds are always spent to a one-time public key (derived from public spend key as sub-address / subkey)
Each key image can only be spent once, since it is related to the derived subaddress that was generated by the sender
Therefore if the sender sees that key image on the blockchain, then they can be assured that the transaction they sent is being spent at whatever block height where they've spotted the transaction. As an added bonus, once this deduction has been made, the observer (sender here), will also be able to rule out the subaddress they sent funds to if they see it in rings subsequent to identifying the spent generated key image. Thus, if and when they do (if they're observing), they will retain the added benefit of striking off another mixin from the ring when they spot a re-use of the generated pubkey subaddress.
How Monero's Model Yields Way for Abuse
If we go back to that pdf (have to upload it now since the Linode servers are suspended), we can see that the researchers publishing about the 'flood attack' came to what should be a fairly obvious consensus based on what we know - and that's that ring signatures on Monero can be decoded (to some extent) if someone is able to rule out some % of the mixins (accurately).
Unfortunately for Monero users, validating / removing certain outputs via process of elimination is something that can be cross-referenced empirically (since this is all based on cryptography and mathematical proofs).
Undertanding the Mixin Process for Monero
At the time of writing, Monero mandates 11 mixins per transaction (giving an observer a 1/12 chance in 'guessing' the true input).
Below is an illustration that provides a bit more clarity on how these mixins are slotted into future transactions.
The researchers that we're covering that published information about the transaction flooding deduced that if they could send enough transactions on Monero (in a short enough timeframe), then inevitably, some of the future blocks would contain public keys generated from them (via those sends), that they can later recognize & rule out.
Since Monero has no provision that to combat this, this simple method of analysis is essentially 'checkmate' for the project until they change its construction entirely.
Why This is Checkmate
Some may be tempted to argue that Monero could simply add more 'mixins' to the equation to increase the difficulty of deciphering the "real" input.
However, those individuals should keep in mind that additional mixins means additional selections must be made from the blockchain. Thus, if we're in a situation where there are 10 mixins (hypothetically) and the flood attacker is responsible for creating 5/10 of those mixins, it must be considered that tacking on an additional mixin (as a requirement), could result in another attacker mixin being added (resulting in 6/11 vs. 5/10).
Assuming there is an attacker using this technique (which evidence that we'll review later suggests there is), then the benefit of mandating any additional mixins could be negligible at best. In a worst case scenario where the attacker is able to maintain a TX flooding output that makes them responsible for 60%+ or more of transactions outputs, its quite possible that adding more mixins as a requirement could deteriorate the protections provided by the ring signature even further.
Top comments (0)