Seed encryption and plausible deniability

[tevador]

The seed encryption feature currently sets a bit flag in the mnemonic phrase that marks the phrase as being encrypted. This is done for UX reasons so users don't accidentally try to restore the encrypted polyseed without a password, which does happen with the 25-word mnemonic phrase and causes confusion when users find an empty wallet.

However, when decrypting a polyseed, there is no way to check if the password that was entered is correct. Polyseed will simply XOR the secret seed with whatever bit mask is generated from the password. This allows users to create a second "duress wallet" by decrypting the polyseed with a different password than the one that was used to encrypt it.

However, some people have expressed concern that the presence of the "encrypted" bit-flag is bad for plausible deniability because an attacker might suspect trickery from the mere fact that the mnemonic seed is encrypted.

I think the current functionality provides sufficient plausible deniability even if it does not hide the fact that the seed is encrypted. However, I'm opening this discussion to hear more opinions.

[chaserene]

I can't really think of an in-between here, and if it comes down to that (better UX vs better personal security), I'm in favor of removing the "encrypted" bit flag to allow for perfect plausible deniability.

for reference, BIP-39 works along the same trade-off. some wallets that rely on this passphrase functionality ask for the passphrase by default, check if the wallet is without any past activity, and if so, ask you to confirm the passphrase. this could be used as a UX crutch.

it could be even improved with specific suggestions (remind you of the passphrase option if you didn't enter any, or if you did, remind you that maybe you didn't set a passphrase initially). I'm not sure about this, but it wouldn't appear for anyone who has prepared a "duress wallet".

[tevador]

With the current functionality, the most paranoid users can have an unencrypted phrase and 2 passwords that will transform the phrase into the actual wallet (first encrypt with the first password, then decrypt with the second one).

I'm in favor of removing the "encrypted" bit flag

It's not that simple. There are already Polyseed integrations in the wild, so we would need a backwards compatible solution.

check if the wallet is without any past activity, and if so, ask you to confirm the passphrase

Why can't the attacker do the same? Essentially, everyone using an encrypted seed would need to put some funds into the "decoy wallet", which would negate this UX crutch.

remind you that maybe you didn't set a passphrase initially

IMO, this would only cause more confusion.

it wouldn't appear for anyone who has prepared a "duress wallet"

How would the software know? And if the software knows, why can't the attacker find out the same way that you have a decoy wallet?

[chaserene]

the most paranoid users can have an unencrypted phrase and 2 passwords

did you mean encrypted here? if yes, let me illustrate the situation: if an attacker that can access the mnemonic can tell whether it's encrypted or not, they can be more efficient and take less risks. this is because they can focus on victims with encrypted mnemonics and expend more energy on pressing them. if crypto wrench attacks become part of the public's understanding (which they will), unencrypted mnemonics will become a Schelling point, and the encrypted minority will be in even greater danger.

contrast this with a standard that where attackers can't tell if it's encrypted or not. the average expected value and thus the risk-adjusted return of pressing a victim becomes lower because they have to engage with more of them. if they still decide to do it, it will be harder to correctly call bluffs because non-technical (=less likely to have a "duress wallet") and technical (=more likely) victims will form a single "victim pool".

I heavily oppose the labeling of the preference for personal security as "paranoia". just like privacy, security is for everyone.

It's not that simple. There are already Polyseed integrations in the wild, so we would need a backwards compatible solution.

isn't that an unavoidable burden if we change anything in this aspect? each new major version carries the risk of additional obsoleted standards and required compatibility features.

Why can't the attacker do the same?

this crutch targets the case you outlined first, when a user tries to restore a wallet with past activity but forgot about the password (or made a typo), and is surprised to find an untouched wallet. as you said, for duress situations, you ideally have a "duress wallet" that has activity (which doesn't trigger the crutch).

How would the software know?

again, this presumes you already have a "duress wallet" prepared. my arguments here are for enabling perfect plausible deniability. most people who want to take advantage of that will do the required preparations.

---

another con: with the unencrypted/encrypted distinction, IIUC, once you create a non-encrypted mnemonic, you can't generate new password-derived wallets, nor for/in duress situations, neither for other reasons. you have to create a new mnemonic, recreate backups, adjust everything else that relies on that wallet, and move funds (which most people will do with one huge multi-input transaction, which is horrible for privacy). I consider this a major setback.

[tevador]

did you mean encrypted here?

I meant what I wrote. You can have a technically encrypted Polyseed that looks unencrypted if you use 2 passwords.

isn't that an unavoidable burden if we change anything in this aspect?

It's avoidable if we don't make the breaking change you are proposing.

Let's wait for more feedback.