No section for "Public Master Keys" or BIP32/39 wallets

[olalonde]

Some wallets such as Electrum allow the user to export a "read only seed" from which only public keys can be generated. I think there should be a section in the guidelines regarding this. For example, a little known "gotcha" is that a single private key from a wallet is needed to generate all possible private keys given the "read only seed". I'm not sure however where this would fit in the criteria.

[kristovatlas]

@olalonde what's the privacy impact to a wallet user?

[evoskuil]

@kristovatlas - the privacy impact is that someone with a master public key effectively knows every public key in the wallet. In other words all of the wallet's keys are tainted by relationship to each other.

There is also an integrity impact. With the compromise of any private key and a master public key, one can recover all private keys in the wallet. Limiting this problem is the purpose of hardened keys in BIP32.

[ghost]

Absolutely nobody should ever be spreading a Master Public Key, despite it's name it needs to remain private. For this reason Electrum doesn't give the remote server the MPK but only keys derived from it. Based on their comments Blockchain.info's BIP32 wallet will be passing the MPK to the remote server, which is devastating from a privacy and security viewpoint.

[evoskuil]

It would not be as bad if it was a user choice (ie opt out of privacy), as there are scenarios that it facilitates. But never as default behavior. In terms of privacy it's comparable to using a public address, which is of course common.

In the case of Electrum, uploading a set of addresses from the same IP address (or the same Tor channel) still exposes the set of addresses to correlation. And over time any overlap in those address queries from differing IP address or channels results in the same exposure.

[olalonde]

Absolutely nobody should ever be spreading a Master Public Key

I absolutely disagree. First, it's a big step up from sharing private keys or using a hosted wallet (e.g. Coinbase) which a lot of Bitcoin users don't seem to care too much about sadly. Second, there's a bunch of use cases for sharing a MPK (the immediate one that comes to mind right now is financial audit of exchanges or non profits who want to be transparent about finances).

[ghost]

@evoskuil You've completely missed the point. A monitoring Electrum server gains insight into the current wallet addresses, a fictional one with access to the MPK can monitor it forever. The privacy considerations are vastly different, and you're opening people up to phishing attacks "export an empty private key for me, there's no harm in that right?".

@olalonde Most people don't concern themselves with the dangers of spear guns until there's one skewering their foot to the floor. It's the duty of the software's author to care for the user in places they might not even know are a problem, like this. Even worse, the perception of privacy "well it's not Coinbase" is probably completely false. Sure, one private company doesn't get to know about your identity and transactions, but how many unknown parties are getting that information?

[evoskuil]

Phishing attacks from someone who already has your MPK are not privacy questions, they deal with integrity. Ideally it's best not to give up private keys. But this is a red herring. The question is regarding privacy. A bad privacy model doesn't improve because it's not as bad as another from an integrity standpoint.

Compromise of a MPK compromises future addresses as long as it continues to be used.

Use of address search compromises addresses as long as the same IP address (or Tor channel) is used, or longer as far as there is an intersection in independent searches of payment addresses that can join IP addresses.

Both scenarios are potentially unlimited in time. However, in the case of MPK exposure, the problem can be terminated by generation of a new MPK. Mitigating search correlation requires a new identity (IP address) and some assurance that old bitcoin addresses will no longer be searched from that new identity. Which do you think is harder to achieve?

It is true that MPK compromise is trivial to exploit once you have the key. But consider how easy it is to attack the Electrum model, without any exposure of keys. All you need to do is control a sufficient number of servers. That number may be as low as 1.

I'm tempted to set up my own Electrum server to prove the point.

[ghost]

There's a big difference between having a cryptographic proof (a MPK) linking addresses and hearsay.

Given the ineptitude of Blockchain.info and Electrum it would be pretty foolish to assume that they aren't going to leak nonces again in the future as well. Spreading your MPK is just unnecessary exposure.

[evoskuil]

Different yes, but how exactly is it less significant? I'd call it a distinction without a difference. In fact identity-based correlation is arguably much more significant.

Whether it's unnecessary or even problematic is scenario dependent.

Web wallets are problematic on multiple levels, but clearly any existing wallet that is not full chain has search-related privacy issues. This includes those that use bloom filters, unless they only use them, which is not sufficient for common scenarios.

Apart from search, spending, from even full chain wallets, is also problematic. Independent Tor/I2P channels per tx become necessary. And then there's the issue of a trustworthy hardware and software platform.

[ghost]

• "I observed these two requests, therefor I believe a and b are related"
• "Here is cryptographic proof by way of an MPK proof that a and b are related"

There's a massive difference.

This includes those that use bloom filters,

Traditional bloom filters are in no way private, made especially so by the lack of junk retention. The privacy model described in BIP37 is broken as well as the software which implements it.

http://eprint.iacr.org/2014/763.pdf

[olalonde]

(didn't read other comments yet) @PrivacyDestroyer agree with your point but there's also a balance to be reached between convenience and privacy/security. One danger of setting too high standards for security/privacy is that users may end up completely ignoring them. I could be wrong but I think the idea of this wallet rating project comes from the realisation that not all users will use 100% private/secure wallets but at least we can help them make more informed decisions without telling them "those wallets are 100% good, those ones are 100% bad". Anyways, I'm not really sure myself how MPK would fit in this project to be honest.

[evoskuil]

Yes, bloom filters are poorly implemented. I was referring to the fact that the stateful protocol doesn't allow for recovery of missed updates or restore, but you are correct that the core implementation suffers from other issues.

WRT what constitutes proof, correlation is sufficient for most anything that matters to anyone. See Silk Road.

[ghost]

Perhaps it would be best to start off with defining what privacy in Bitcoin should afford you and in what situations. At least from my vantage point, there's zero transactional privacy beyond the simple fact that usually nobody is bothering to look.

[evoskuil]

It's a good question, maybe we take for granted that we all have a common understanding.

I personally consider three aspects of financial privacy, and a fourth pertaining specifically to Bitcoin. I've never formalized it, so please pardon the ad-hoc taxonomy.

• Public Trade
• Private Trade
• Anonymous Trade
• Bitcoin User

The first is the idea that parties to a trade expect others to be aware of the fact that the trade has occurred. For example, a man buys a cup of coffee in a crowded coffee shop.

The second is the idea that the parties to a trade expect to be known as such only to each other, and to those who either may intentionally notify. For example, a woman pays for an abortion.

The third is the idea that the existence of a trade is knowable to only one of the parties. For example, a family donates money to Wikileaks.

The fourth is the idea that a person expects to not be exposed to any other as a user of Bitcoin. For example, a North Korean may risk the gulags for the appearance of possibly evading currency controls.

Note that these all share a common characteristic - a person. There is no loss of privacy until a trade (or in the fourth case the use of Bitcoin) is associated with a person. After that point graph traversal using mathematics can greatly expand the damage.

It follows that there is never cryptographically strong proof associating a person in any of these cases. Such strength only exists between numbers (i.e. addresses/transactions). Until people are (however weakly) associated to those numbers there is no loss of privacy.

The question of the provability of a weak connection is tied to risk tolerance. Privacy scenarios include everything from state-level attacks against dissidents to the discovery of the price paid for a birthday gift. All we can do is asses the difficulty of various attacks.

[ghost]

I think a lot of this is somewhere between hard and impossible.

• Hiding that you purchased a coffee is more difficult than it sounds.
  • It's easy to poison the coffee shop's wallet and from there on out you know every single transaction made to them. Without totally altering how Bitcoin works you're not going to prevent merges from happening on any sort of scale.
  • Observing a person walking up to the counter you can guess or sniff their transaction broadcast and look for one with a suitable output size. Even with a 5 minute window finding the coffee shop and the client's wallet would be trivial.
• Fourth is not going to happen.
  • Bitcoin P2P isn't ever going to be encrypted in a way that can hide the fact that you are connected to a public Bitcoin node. All it takes is the observer connecting to the same remote socket as you and confirming what it is.
  • It's very easy to find Bitcoin users even if they are using some sort of encrypted tunnel just by observing the very unique traffic pattern, large bandwidth spikes and artificial traffic on the network can be made to create a unique signature on the target tunnel.

There is no loss of privacy until a trade (or in the fourth case the use of Bitcoin) is associated with a person.

I beg to differ, there's a lot of information that can be inferred with a cluster of addresses even without any connection to a real world identity. You know what client they use, possibly what operating system they use, you know what services they use, you know how much money goes in and out of their wallet.

[evoskuil]

• The coffee shop scenario is listed and described as "public".
• The fourth does not require that one connect to a Bitcoin node.
• Blockchain or traffic analysis to discover "information" is interesting but not a loss of privacy unless it connects to a person. Of course this is my definition, but I think it would be very hard to argue otherwise.

[ghost]

Right, sorry I misinterpreted your list items slightly.

[LaurentMT]

This typology raises some interesting points related to cryptocurrencies and blockchain analysis.

When you buy a coffee at Starbucks, you expect others to be aware of the trade but you don't expect the barista to know your financial incomes or your wealth.

With cash or credit card, there is little risks. With cryptocurrencies, this is a possible threat (b/o bad privacy practices like address reuse, blockchain analysis...).

People are used to a minimum of financial privacy provided by banks (banks and governments know everything about your transactions, shops only know transactions made with them). IMHO, bitcoin wallets should, as a minimum, provide a level of privacy equal to this one, without requiring tremendous efforts from the user.

Obviously, means to reach this goal may be very different according to the type of wallet (this is free lunch for online shared wallets but it may require more work for personal wallets (coinjoin txs + stealth addresses ?).

Note that a complementary typology might be obtained by classifying the attacker. A first attempt, to define this kind of typology, in this post on btctalk (https://bitcointalk.org/index.php?topic=279249.msg7170950#msg7170950)

[ghost]

People are used to a minimum of financial privacy provided by banks (banks and governments know everything about your transactions, shops only know transactions made with them). IMHO, bitcoin wallets should, as a minimum, provide a level of privacy equal to this one, without requiring tremendous efforts from the user.

..

When you buy a coffee at Starbucks, you expect others to be aware of the trade but you don't expect the barista to know your financial incomes or your wealth.

I think that's quite an important point too. People don't expect for other parties to know how much money they own, or know that the person buys alpaca socks, or that they normally buy coffee at the other shop down the street. Even without an identity attached these are all incredibly revealing pieces of information. A lot of users seem to be under the false impression that they are anonymous, or at least private to some degree, which is of course completely out of touch with reality.

Given the choice I would be using a shared wallet every time, as for the moment your privacy options are a choice between one company knowing and the entire world knowing. If you believe your adversary is a government then perhaps you should try to use a more convenient currency like Rai Stones.

[evoskuil]

Hi @LaurentMT,

I think it's important to be clear on the distinction between a taxonomy of privacy and what level of privacy people do or should expect.

For example, the discussion of the coffee scenario, in which a public trade may leak previous private trades (savings/income), should not conflate the two. The former is not intended to be private, the latter are. The fact that the public trade leaks private trades is a privacy bug (as it would be if private trades leaked other private trades), not a problem in the taxonomy.

Whether the bug is fixable or not is another question, but does not speak to its existence. Nor does the level of privacy that one or another person may desire in a private trade. That will vary by the number and type of bugs that someone is willing to sustain.

[LaurentMT]

@PrivacyDestroyer I fully agree. WRT privacy, online shared wallets are similar to the current banking model (as described in Satoshi's white paper). Personal wallets, as implementations of a different model, need to rebuild the "privacy stack" from the ground.

@evoskull You're 100% right. What I've described in previous post is a taxonomy of attackers, defining levels of privacy and this notion is orthogonal to your taxonomy. Levels of privacy may be seen as a general measurement of your "resistance" against blockchain analysis and others side channel attacks trying to gain insights about all your transactions.

On its side, your taxonomy acts at the finer level of a single transaction and defines the information about parties which should be available to whom.

May be we could use these two notions to build a matrix qualifying privacy provided by a wallet. Let's use the following axioms:

• bitcoin is the unique payment system,
• the wallet is the only one available to users,
• one wallet per user.

For a regulated online shared wallet, we may have something like this:

	Public	Private	Anon.	Bitcoin
Intl. agencies	O	X	X	X
Govt. agencies	O	X	X	X
Big data corps	O	O	O	O
Others	O	O	O	O

For a personal wallet with privacy leaks (address reuse allowed, bad merge inputs allowing address clustering, no coinjoin/stealth addresses...):

	Public	Private	Anon.	Bitcoin
Intl. agencies	O	X	X	X
Govt. agencies	O	X	X	X
Big data corps	O	X	X	X
Others	O	O	O	O

Notes:

• O means the wallet meets your criteria (with regards to the attacker)
• X means the wallet doesn't meet your criteria (with regards to the attacker)
• The same work can be done with different constraints (i.e. payer or payee can use several wallets)

BTW, I really like the concept of "privacy bugs". IMHO, that term should be used by OBPP ! :)

[evoskuil]

@LaurentMT I like the direction this is heading.

The primary concern I have with the project's approach is its focus on features. The inclusion of a feature or technique does not guarantee that an objective is achieved. For example, two factor authentication is often described as a security (integrity) benefit. But what is the specific objective? Presumably to ensure that two secrets must be concurrently under the control of a person in order for that person to gain control over some other private or secret information.

But the requirement of multiple secrets means nothing without a measurable understanding of the difficulty of obtaining each secret for use in combination. One hardware wallet advertises that, because it uses a second factor, it is “malware proof… even on a fully-compromised computer”. In its case the compromised computer can capture one factor on first use and execute a trivial MITM attack over a short number of uses against the other, obtaining both secrets and draining the wallet. The difficulty is only higher than one factor in terms of the number of lines of code that must be written to execute the attack.

An analysis of the privacy or integrity of any system cannot be allowed to rest on a list of features. The strength of all systems rest on assumptions. Any useful analysis must declare those assumptions and determine the cost of violating each of them. The end-user of the system can then be free to decide whether it’s reasonable to accept the risk of an attacker carrying out such an attack.

The concern I have with your categorization above is the differentiation between attackers. There is no strong basis for differentiating between governments, insiders, companies, etc. The user may or may not care about being attacked by one but not another, but it must be assumed that if one can execute the attack then so can the others.

WRT web wallets, there is no way to effectively measure the strength of a web wallet. Certain bugs can be analyzed, but there’s no way for the user to guard against others. The use of such a wallet is a decision by the user to accept inherent security and privacy bugs.

[LaurentMT]

@evoskuil

I understand your concern with the feature-oriented approach. I guess everybody at OBPP would agree to use clear quantitative metrics to rate privacy provided by wallets or services. The problem is that defining (and measuring) the right indicators may be a very long (or even a "never-ending") task.

Therefore, I'm really supportive of the choice made by Kristov & al. for a pragmatic first round. Despite its limitations, it should have a great educative value for the community. Moreover, delivering this first concrete support does not prevent us to work on more quantitative metrics for later and I'm quite motivated to push things further on this front (currently working on metrics to qualify the quality of coinjoin txs).

WRT my classification of attackers, the terms may be misleading about the intent. They're just generic terms (let's say personas) used to label different categories of attackers. Indeed, each category must be defined more precisely by a set of capabilities (no special capability, big data analysis, access to data owned by services providers thanks to legal requests, "shadow" operations like network eavesdropping, ...). You get the idea.

Indeed, mapping real world actors (govt agencies, corporations, hackers, ...) to these levels is another task.

[evoskuil]

It's very possible that the approach could do more harm than good. I see a lot of lies behind the advertising and discussion of products, and it's mostly enabled by feature focus. Really dangerous stuff. I would call it naïveté if the issues hadn't been surfaced in discussions.

Imagine if this wasn't some editorial process, but one with liability. Would you stand behind such a system? No chance in hell I would. But people are going to lose money because of these decisions nonetheless. It's not necessary to be perfect, especially initially, but the motto, "do no harm" should apply.

My recommendation would be to enumerate features and disclaim having reviewed ANY actual behavior of such features in implementation. And I would eliminate the scoring. Otherwise companies will advertise their results in this rating system, and that would be very bad.

[LaurentMT]

I agree that the scoring may be misused/misinterpreted. Applying a quantitative measure to a qualitative appreciation is always risky. How to prove your objectivity as the auditor if you can't rely on precise measurements ? Difficult task for sure. But, you know, our modern society likes short messages...like scores.

I think the document should have a clear statement that these features don't mean, in any way, that your privacy is ok because you're going to use this wallet and not this one. These features are a bare minimum to improve the current statu-quo but could become obsolete in a few years.

I fear there is a lot of education remaining to be made before people understand that privacy is not a present/absent "feature" offered by a system. What's done to measure security in crypto may serve as a source of inspiration.

[evoskuil]

It's quite straightforward to list features and to drop the rating system. That makes the process quantitative (in terms of features implemented) and with a disclaimer on implementation of the features, removes the implementation endorsement.

There are formalisms in security and privacy analysis, but they are complex and don't get much if any play in the Bitcoin space.

[evoskuil]

MITM phishing attack breaks so-called MFA: https://www.reddit.com/r/Bitcoin/comments/2ungby/fuck_i_just_got_scammed