# Zencash uses your passphrase to identify AND unlock a wallet - how is this secure?

When looking into Zencash I stumbled into myzenwallet.io (by the Zencash creators), which gives you the option to enter a passphrase to generate a wallet (seems normal), but then after creating your wallet you can come back later and open your wallet by simply re-entering your passphrase again... this was unexpected and had me not only wondering about how it worked, but also wondering whether whatever means were used to achieve this would remain secure in the future.

Given that I don't need to identify the resource I'm unlocking, but rather just hand over the passphrase, I'm left to assume that their system generates a token by hashing my passphrase a number of times to generate my "master address" or "account ID" (I just made those terms up, because Zencash gives you many addresses, so I also assume you have some sort of master address / account ID), and then also using that same passphrase to lock / authenticate (not to encrypt though, right?) the wallet.

• Well, if you have a deterministic procedure to generate a private key(s) from a master secret, then you can create the wallet and subsequently re-create the wallet whenever you log back in,. just with the difference that the server has the blockchain for your transactions... – SEJPM Apr 20 '18 at 10:18
• What research have you done? I’m asking, because there are ample explanations out there that dive into what a “mnemonic phrase” aka “mnemonic recovery phrase” aka “mnemonic seed” is, how it works, and why it’s used… like (for example) https://en.bitcoin.it/wiki/Mnemonic_phrase and BIP-0039 – e-sushi Apr 20 '18 at 12:56

I don't know how Zencash works. For all I know they store all the data in cleartext. But I'm going to explain how this can be done securely to some extent, but with fundamental flaws nonetheless.

The fundamental tool here is a key derivation function. A key derivation $F(P,L)$ calculates a value from a secret key $P$ and a public label $L$ such that:

• It is unfeasible to calculate any part of $P$ even if you happen to know the value of $F(P,L)$ for many values $L$.
• It is unfeasible to calculate any part of $F(P,L)$ without knowing $P$, even if you happen to know the value of $F(P,L')$ for many $L' \ne L$.

The following protocol allows a site to store some data without being able to decrypt it, using your passphrase as the sole input.

• You enter your passphrase $P$ on the web page. The browser does not send the passphrase to the server.
• The browser calculates both $A = F(P, \mathtt{"address"})$ and $K = F(P, \mathtt{"encryption"})$.
• The browser sends $A$ to the server. The server uses $A$ to retrieve an encrypted blob of data and sends this encrypted blob to the browser.
• The browser uses $K$ to decrypt the data.

The server is not able to decrypt the data in this scenario. Note that you need to trust that the Javascript code sent by the server is doing the right thing. If the server is compromised, it could start sending new Javsscript code that does send the passphrase to the server.

The fundamental flaw with this approach is that someone can easily steal money by guessing someone's passphrase. This is inherent in using a passphrase as the sole identification method: it permits a mass untargeted attack. If you can guess anybody's passphrase, you can retrieve their data. You don't need to know who they are: just keep guessing potential passphrases until you find one with a non-empty wallet.

Reasonable systems that use a passphrase to secure something always include a salt in the label for the key derivation. The salt is unique per passphrase. It does not need to be secret, but when you come back to the site, you'd need to re-use the same salt. With a salt, it is not possible to carry out mass untargeted attacks. If the attacker guesses that squeamish ossifrage is a likely passphrase, they still need to try it out with every possible salt value.

For completeness, note that when deriving a key from a passphrase, in addition to using a salt, it is necessary to apply a stretching mechanism to make the computation slower. This is the same problem as password hashing. In fact, password hashing and password-based key derivation are very close cryptographic problems.

If, instead of a human-chosen passphrase, the derivation was based on a sufficiently long randomly generated string, then the protocol above would be secure. The problem with human-chosen passphrases is that they have very little entropy: it's relatively easy to enumerate all likely passphrases. This is compounded by the fact that in this scenario, the attacker only cares about the weakest passphrases, they're generally not trying to attack a particular user who may have been extra careful to pick a strong passphrase. But even a user who chooses, say, a passphrase made of 4 random words from a dictionary of 100,000 (which includes some pretty obscure words) has only reached 66 bits of entropy, whereas the standard minimum size for a random string used as a secret is 128 bits and for a financial application 256 bits would be preferred. And if the passphrase which is a grammatical sentence, the amount of entropy is vastly reduced.

• @orokusaki According to BIP-00039, a typical mnemonic code/phrase for generating deterministic keys will have 24 words – which equals a 256 bit seed. Even 12 word mnemonic seeds will equal 128 bit seed, which makes the guessing Gilles talks about as hard as guessing inputs of a 128 or 256 bit KDF outputs. The fact that the binary seed is produced via PBKDF2 (or alike) doesn’t allow for (let’s just call it) “quick brute-force attacks” either. The only thing we can’t verify is if myzenwallet.io correctly implememented BIP-00039. – e-sushi Apr 20 '18 at 13:04
• @e-sushi I doubt that most people who use this service follow BIP-00039. My uninformed bet is that short English sentences are a very common choice. – Gilles 'SO- stop being evil' Apr 21 '18 at 8:41

It's not a security hole, just a different approach to security.

If you're going for anonymity, you don't want accounts. You want free-floating bits of currency that are only identified by being able to unlock them. A master account is a major privacy compromise; for a private currency, you just need to lock your multiple cash addresses with the same key.

The principle isn't a crypto invention; CDMA - a common communications multiplexing protocol - works by assigning each user a code (not secure, but that's not the point) to filter out only the messages meant for them.

The cryptosystems used for coins are far more complex than that and I'll admit to only quite understanding the most basic ones. A dedicated forum might well be a better place to get step-by-step descriptions of the protocol.

Security holes in cryptocurrency are attacked with particular vigor, since the reward is straight up money. There sure are some, but generally nothing glaring.