Obviously there's a positive ux reason, so what I'm asking is if there's a compelling argument that the loss of security by doing so is inconsequential.
Conversation
Replying to
Under duress, you can give the wrong passphrase resulting in deriving a different key. BIP39 seed phrases use this for an optional passphrase added to the end of the seed phrase. Trezor (who created BIP39) treat it as an advanced feature since it can result in harmful mistakes.
1
2
The only state that's stored is the seed phrase so if you enter the wrong passphrase, you get a completely different wallet:
wiki.trezor.io/Passphrase
They make sure you back up the seed phrase, so if the device dies or is lost you don't lose funds or other keys (SSH, GPG, etc.).
2
2
Replying to
Yeah, I'm aware there are situations where this property is an advantage. I'm asking about the other direction - whether there are situations where there's a compelling argument that it doesn't matter if the attacker can see if passphrase is right or wrong without testing it.
1
My particular need here is private key for backup restoration. Intent is that it be kept offline, airgapped, but I want to add passphrase in case users are less careful/paranoid.
1
Replying to
The only use I can think of is an example like twitter.com/DanielMicay/st. For example, law enforcement compromises a server used by something like Silk Road. They got assorted public keys and someone having the private key would be pretty strong evidence they're that person.
Quote Tweet
Replying to @DanielMicay and @RichFelker
So you can give the attacker one or more valid passphrases they can confirm are valid while still having ones you didn't tell them. Could be relevant to a use case like SSH. Could have some server not tied to you that they compromised so they have pubkey but can't prove it's you.
1
With the approach of seed phrase + passphrase added to it, you could use one passphrase to derive a key for assorted web sites, etc. and then another passphrase for this more sensitive use. You could turn over the passphrase for the non-sensitive use without turning over other.
1
It's only something that advanced users would benefit from when being extremely careful with opsec and they could easily cause harm to themselves by screwing it up and lying about not having secondary passphrase(s).
1
Replying to
This is all very interesting but doesn't really answer the original question (about compelling arguments that it doesn't matter in some cases, not about compelling arguments that it does matter in others).
1
Replying to
That's what I was trying to get at in twitter.com/DanielMicay/st. If the only actual uses of the key are plainly visible and easily confirmed, it doesn't help.
In fact, if you don't use hidden keys, you'd be better off if the feature wasn't supported so it can't be suspected.
Quote Tweet
Replying to @RichFelker
If the public key is stored right next to them, then they can easily check if it's correct. It might be a private key by itself where the attacker doesn't know the use case for sure. It could be beneficial if they can't confirm passphrase they were given is valid in that case.
If you give an attacker the valid passphrase(s) under duress and don't have a hidden one, then you're worse off if hidden ones are supported. They could suspect you used one and you can't prove you didn't so you might get beaten with a wrench or held prisoner indefinitely anyway.
1
That tends to be why I'm not always the biggest fan of this kind of feature: everyone using the software pays the price of being suspected of using the feature in those situations. Often, an attempt at actually using it will be ruined by not having perfect opsec about it anyway.
Replying to
This does potentially apply to my usage case: if you need to avoid disclosing backup contents, you can plausibly claim the seized encrypted key was the wrong one rather than your passphrase just being wrong.