Looking for Part One? Click Here
Now that we have the introductions out of the way, let's go ahead and check out the 'MyMonero' website.
Below is a screenshot showing the webpage in live time (as this is being written):
Their slogan mentions that the app hits the "sweet spot between security, convenience, and features", which is interesting when considering that Monero's biggest value-add is the fact that its supposed to be more secure and private than Bitcoin (while doing the same thing).
Where Things Begin Sliding Off a Cliff
Scrolling a bit further down the page, one can see the following:
This is where the problems begin to crop up in the design of this project.
By stating that, "There's no Monero blockchain node to run" and that the "MyMonero server does the heavy lifting for free", the developers are implicitly stating that they will be the ones taking on the responsibility of handling all of your transactions on the blockchain.
This is made especially clear where it states, "Get your entire transfer history instantly on your device with only your seed words." For that to be true, we'd have to assume that MyMonero not only accesses the blockchain for its users - it also remembers and associates specific transactions with said users as well.
"Spend Key" Semantics and Issues
Moving further down the page, the site states that, "MyMonero is safe and secure. The server can't withdraw funds on your behalf because your spend key never leaves your computer."
While this statement may be true, it doesn't address the complete reality of what this setup entails.
Brief Dive into Ring Signatures
This part may suck for a few people, but it is a necessary evil if we are to gain a true understanding of why 'MyMonero' destroys any semblance of privacy users thought they had with Monero.
Without being too verbose, it should be known that Monero uses something called "ring signatures".
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 for Web Wallet: 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 How Transactions are Sent on Monero
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.e., 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: