There is now a codex32-enabled wallet

[BenWestgate]

Hello, the website mentions that there are no codex32-enabled wallets at this time.

I have taken it upon myself to change that and made the first since I like this format of seed backups best.

Right now, it only works on Tails, but I will turn my codex32 GUI into a stand-alone project so any system with python3 running Bitcoin Core can create and restore codex32 seeds.

https://twitter.com/epic_curious/status/1681316791107346436?s=20

[apoelstra]

Cool!! Thank you.

I don't know anything about Tails or what was involved in this, but I'm in favor of using codex32 seeds with Core.

[BenWestgate]

Tails is a debian-based linux distribution that forces all traffic to go thru Tor and runs from a LiveUSB.

It's safer to Not run desktop wallets like Core from a daily driver OS.
A bootable USB makes a portable system they can use for Bitcoin.

[BenWestgate]

@apoelstra: the Bails alpha last summer had a non-canonical feature I'm trying to decide whether to discard or keep for the Beta.

It seemed useful, my testers understood it correctly and (perhaps naively?) liked it:

It was a passphrase derived KDF share. So during recovery, after entering threshold - 1 codex32 share(s), they had an option to type a "seed backup passphrase" OR a final share to recover the seed. (Question prompt, then different entry dialogs for passphrase vs share)

Using scrypt with the codex32 header as salt, the passphrase hash was set as the payload for share index p and recovery attempted. The bip32 fingerprint share ID could detect typos in passphrase entry.

Creating a sort of hybrid brainwallet where a memorized string plus randomly generated share(s) are required to recover but which also tolerates forgetting said passphrase by recovering canonically with codex32 shares, curing all major drawbacks of brainwallets.

Pros:

• Re-using the full-disk encryption (FDE) passphrase Bails requires memorizing seems convenient.
• Stealing a memory can be harder than a physical backup.
• Less locations needed for equivalent redundancy, or improved redundancy or security in same number of locations.
• Less travel and disturbing backups to recover.

Cons:

• FDE Passphrases can be keylogged or shoulder surfed, reuse threatens the seed.
• Increased torture risk at T - 1 compromised shares.
• Less travel to recover.
• Low entropy passphrases can slip past policy banning them, reducing effective threshold.
• Max 23 bits salt makes low entropy passphrases more vulnerable to rainbow tables.
• KDF share not directly compatible with other Codex32 wallets, written shares are.
• Custom share IDs can't give typo feedback without a known fingerprint, address or a share digest.
• 21x21 CodexQRs will only have 1-bit (threshold flag) to salt with...
• Likely easier to forget than physical shares are to lose.
• 1 GB system requirement for Fixed scrypt hashing parameters.

I recall you prefer, if a user were hell bent on memorizing a codex32 string, they directly encode it with the SLIP39 wordlist. That eliminates 7 cons above, but I don't find it realistic for most users to memorize 14 - 24 random words. The suggested FDE passphrase Bails users must memorize is only 5-7 diceware words.

The UX is meant to be manageable, especially if poor or Bitcoin is illegal in their jurisdiction. Codex32 is used more to conceal transaction history than theft and loss resistance.

What would you suggest doing with this KDF share feature?
Do the pros seem worth the cons?

[apoelstra]

Yeah, this seems like a reasonable feature for implementations to (optionally) support. Regarding the list of cons:

• FDE Passphrases can be keylogged or shoulder surfed, reuse threatens the seed.
• Increased torture risk at T - 1 compromised shares.
• Less travel to recover.

These are all decisions that users can reasonably make for themselves.

• Low entropy passphrases can slip past policy banning them, reducing effective threshold.

That's true, but I'm skeptical of any password policy scheme (including this one which at least attempts not to piss off cryptographers).

• Max 23 bits salt makes low entropy passphrases more vulnerable to rainbow tables.

Similarly to above; users should (hopefully) understand that if they are making up their own passphrases then these passphrases need to be secure. With the caveat that leaking a single share is usually not a crisis. Probably the system should disallow passphrase-generating more than one share and disallow even this in "just a seed, no splitting" mode.

• KDF share not directly compatible with other Codex32 wallets, written shares are.

I suppose we could try to standardize this, though this falls into the category of things I'd personally never use and don't care to specify...

• Custom share IDs can't give typo feedback without a known fingerprint, address or a share digest.
• 21x21 CodexQRs will only have 1-bit (threshold flag) to salt with...

...as is everything related to the seed QRs, which I'd have to go back and reread our discussions about :).

• Likely easier to forget than physical shares are to lose.

User can make this choice. (Though yes, personally I think it's always better to have a physical token than to try to use a human brain.)

• 1 GB system requirement for Fixed scrypt hashing parameters.

This is a tough call. Maybe it should be parameterizable somehow, but fundamentally there's a tension here between the ability to run your KDF on a hardware wallet (where it's presumably more secure from sidechannels or fault injection attacks) and the requirement to use a lot of RAM (which will slow offline cracking). I don't have a good opinion.

[BenWestgate]

Yeah, this seems like a reasonable feature for implementations to (optionally) support.

Okay, great. I knew at least a few people would have missed the feature. I'll leave an option to not use a "passphrase derived share" when generating backups for flexibility.

the system should disallow passphrase-generating more than one share and disallow even this in "just a seed, no splitting" mode.

Correct on both, for simplicity (and security) a backup passphrase can only generate one share and never a seed.

I suppose we could try to standardize this...

Let's use the same algorithm and parameters as when user entropy + bitcoin core entropy is stretched when deterministically generating codex32 backups.

I use the openSSL Scrypt defaults everywhere I use Scrypt KDF in my codex32 library:

When N, r or p are not specified, they default to 1048576, 8, and 1, respectively. The default amount of RAM that may be used by scrypt defaults to 1025 MiB.

From OWASP Password Storage Cheat Sheet:

While Argon2id should be the best choice for password hashing, scrypt should be used when the former is not available.

For Argon2id, I'd copy the cryptsetup and luks2 defaults: 1GiB memory cost, 4 rounds time cost, parallelism 4. Or for compatibility reduce parallelism to 2. Even the cheapest laptops Best Buy sells have 2 cores: AMD A4 and Celeron N4000.

I haven't used Argon2 in my library since it's not in Python's hashlib but Scrypt is.

as is everything related to the seed QRs

Already figured it out.

...between the ability to run your KDF on a hardware wallet...

Because they have 50,000 times less RAM and 10,000 times slower CPUs, passphrases get 29-bits less stretching, nearly 3 words.

At the point of needing an 8 - 10 word passphrase for equal brute-force protection they may as well do 12 and memorize an entire seed or share directly.

HWW compatibility defeats the convenience benefit for Bails users of reusing their luks2 disk encryption passphrase, which is stretched with Argon2id as above. Otherwise offline cracking t-1 shares is 500 million times cheaper than attacking the USB stick image. Which ironically, may not even store private keys sometimes, like in a stateless signer setup.

[apoelstra]

At the point of needing an 8 - 10 word passphrase for equal brute-force protection they may as well do 12 and memorize an entire seed or share directly.

This is a great point. Ok, we can forget about HWW support as a design goal.

[BenWestgate]

we can forget about HWW support as a design goal

We didn't forget, that's what un-checking the "passphrase derived share" option during creation does, or not losing so many shares you HAVE to use your passphrase to recover.

Another recovery option is use an offline PC to convert your codex32 header and backup passphrase into a codex32 share and enter that on your hardware wallet.