š
Original date posted:2023-02-19
šļø Summary of this message: Codex32 is a new seed phrase scheme that offers a longer, stronger checksum and more compact encoding, designed to be readable and computable by hand. It uses the bech32 alphabet and does not support passphrases or hardening. It also allows for periodic recollection verification and versioning metadata for wallets.
š Original message:On 2023-02-16 03:49, Andrew Poelstra via bitcoin-dev wrote:
> the draft lists several benefits over SLIP-0039.
The only benefit over SLIP39 that I see explicitly mentioned in the
draft BIP is "simple enough for hand computation". In the FAQ[1] on the
project's website, I see some additional reasons:
| This scheme is essentially the same as SLIP39, with the following
differences:
|
| - The checksum is longer, slightly stronger, and designed to be
| computable by hand.
|
| - Our encoding is more compact, giving us room for a bit of more
| metadata, which is also designed to be readable by hand.
|
| - Unlike SLIP39, we do not support passphrases or hardening of any
| form.
|
| - Unlike SLIP39, we have no hardware wallet support. But we hope that
| will change!
From having perused the extended documentation myself, I think I would
personally note the following differences.
- Alphabet: Codex32 uses the bech32 alphabet rather than SLIP39's
alphabet consisting of English words. The benefit to human-language
words is easier memorization for those proficient in the particular
language (in this case, SLIP39 only allows the use of English). A
disadvantage, IMO, is that it encourages the practice of memorization
(which does have a few advantages but also a lot of drawbacks).
Interestingly, Codex32 addresses what I think is the main problems of
memorization: difficult-to-prove successful recollection. Someone who
wants to reliably keep seed-related material only in their head
needs to practice recalling it on a regular basis, but for BIP39,
SLIP39, Aezeed, etc... there's no way for them to confirm they
successfully recalled it short of going through the entire recovery
process; they probably just judge how confident they feel about the
recollection and assume that feeling like they recalled it correctly
is the same thing as recalling it correctly.
Codex32 allows the individual to periodically perform their
recollection on paper in a private room without electronics and use
nothing but a pen and some loookup tables (or a paper device) to
verify that they recalled the string correctly (and its checksum can
help with correcting up to several errors, although you might need a
computer for error location and correction assistance).
- Hierarchy: Codex32 does not natively provide support for nested SSSS
whereas SLIP39 does. E.g., in SLIP39, you can require 2-of-3 for
{me, family, friends} where me is 2-of-3 {fire_safe, bank_safe,
buried_in_woods}, family is 1-of-3 {alice, bob, carol}, and friends
are 2-of-5 {d, e, f, g, h}. I assume you can do the same with Codex32
by using the share for one level as the secret for the next level,
although this is not described in the protocol.
- Versioning: Codex32's metadata can store version information for
wallets that use implicit BIP32 paths (e.g. BIP44/49/84/86), although
this would cut into the space available for users to set their own
metadata and it is not specified in the draft BIP. SLIP39 also
doesn't specify anything about implicit path versioning and, AFAICT,
doesn't have any room to store such metadata without reducing seed
entropy.
- Plausible deniability dummy wallets: Codex32 doesn't support this;
SLIP39 does. Much has been written by other people about whether
dummy wallets are a good idea or not, with strong opinions on both
sides, so maybe we can just leave it at that.
---
When I first saw the post about this, it was unclear to me that it was a
serious project, but I've become increasingly interested as I researched
it. I'm not personally that interested in generating entropy from dice
or encoding shares by hand---it's already imperative that I acquire a
trustworthy computer and load it with trustworthy software in order to
use my seed securely, so I might as well have it generate my seeds and
my
recovery codes for me.
What really did catch my attention, but which was kind of buried in the
project documentation, is the ability to verify the integrity of each
share independently without using a computer. For example, if I store a
share with some relative who lives thousands of kilometers away, I'll be
able to take that share out of its tamper-evident bag on my annual
holiday visit, verify that I can still read it accurately by validating
its checksum, and put it into a new bag for another year. For this
procedure, I don't need to bring copies of any of my other shares,
allowing them (and my seed) to stay safe.
---
I do have one question after watching an excellent video[2] about the
motivation for this system. In the video, one of the threat models
described is a disarrangement of the words in a metal backup system.
The implication seems to be that this would be an accidental
disarrangement, which obviously the Codex32 checksum would catch during
periodic offline verification. But what about deliberate modification
of a recovery code? For example, Bob doesn't keep his seed loaded on
any computer; it only exists in Codex32 shares which Bob plans to
combine together in 20 years when he retires, although he makes regular
deposits to the pubkeys derived from the seed's master xpub. Mallory is
able to obtain access to Bob's shares, allowing her to immediately steal
his current funds---but also allowing her to replace them with
similar-looking
shares with the same metadata and valid checksums so that Bob
continues making deposits to the wallet.
I'm curious about whether there's a way to prevent this attack without
otherwise compromising the properties of the code? For example, some
extra data that Bob can carry around (or memorize) for verifying the
shares haven't changed, but which is not otherwise needed for recovery
(so there's no problem if it's lost).
Thanks,
-Dave
[1] https://secretcodex32.com/faq/index.html
[2]
https://www.youtube.com/watch?v=kf48oPoiHX0&list=PLyOGyBytgcuQLi9DC5g88DOEGnqBDPmq1&index=2
David A. Harding [ARCHIVE] /
npub16dā¦x4wrd
2023-06-07 23:19:42
in reply to nevent1qā¦6ypj
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-07 23:19:42Event JSON
{
"id": "b1919fadfc4d5dad4dccee9fe82d5a20a9e25f612799a94924a83f1d4b33a5a6",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686179982,
"kind": 1,
"tags": [
[
"e",
"a3a3f4bb7a4f76a4dd4ffb9bad737c4cf2aefb0496fa4b312d6d5bf1fd8cde22",
"",
"root"
],
[
"e",
"2fb630e8cc04e0b51ae2f1327e7d95b85843b57e869e341c13251d1de44732a8",
"",
"reply"
],
[
"p",
"ee55eb03423bd4db01d5c92ad434d52c602d9da1de37ed37cc5bf7d2a13a4cab"
]
],
"content": "š
Original date posted:2023-02-19\nšļø Summary of this message: Codex32 is a new seed phrase scheme that offers a longer, stronger checksum and more compact encoding, designed to be readable and computable by hand. It uses the bech32 alphabet and does not support passphrases or hardening. It also allows for periodic recollection verification and versioning metadata for wallets.\nš Original message:On 2023-02-16 03:49, Andrew Poelstra via bitcoin-dev wrote:\n\u003e the draft lists several benefits over SLIP-0039.\n\nThe only benefit over SLIP39 that I see explicitly mentioned in the\ndraft BIP is \"simple enough for hand computation\". In the FAQ[1] on the\nproject's website, I see some additional reasons:\n\n| This scheme is essentially the same as SLIP39, with the following \ndifferences:\n|\n| - The checksum is longer, slightly stronger, and designed to be\n| computable by hand.\n|\n| - Our encoding is more compact, giving us room for a bit of more\n| metadata, which is also designed to be readable by hand.\n|\n| - Unlike SLIP39, we do not support passphrases or hardening of any\n| form.\n|\n| - Unlike SLIP39, we have no hardware wallet support. But we hope that\n| will change!\n\n From having perused the extended documentation myself, I think I would\npersonally note the following differences.\n\n- Alphabet: Codex32 uses the bech32 alphabet rather than SLIP39's\n alphabet consisting of English words. The benefit to human-language\n words is easier memorization for those proficient in the particular\n language (in this case, SLIP39 only allows the use of English). A\n disadvantage, IMO, is that it encourages the practice of memorization\n (which does have a few advantages but also a lot of drawbacks).\n\n Interestingly, Codex32 addresses what I think is the main problems of\n memorization: difficult-to-prove successful recollection. Someone who\n wants to reliably keep seed-related material only in their head\n needs to practice recalling it on a regular basis, but for BIP39,\n SLIP39, Aezeed, etc... there's no way for them to confirm they\n successfully recalled it short of going through the entire recovery\n process; they probably just judge how confident they feel about the\n recollection and assume that feeling like they recalled it correctly\n is the same thing as recalling it correctly.\n\n Codex32 allows the individual to periodically perform their\n recollection on paper in a private room without electronics and use\n nothing but a pen and some loookup tables (or a paper device) to\n verify that they recalled the string correctly (and its checksum can\n help with correcting up to several errors, although you might need a\n computer for error location and correction assistance).\n\n- Hierarchy: Codex32 does not natively provide support for nested SSSS\n whereas SLIP39 does. E.g., in SLIP39, you can require 2-of-3 for\n {me, family, friends} where me is 2-of-3 {fire_safe, bank_safe,\n buried_in_woods}, family is 1-of-3 {alice, bob, carol}, and friends\n are 2-of-5 {d, e, f, g, h}. I assume you can do the same with Codex32\n by using the share for one level as the secret for the next level,\n although this is not described in the protocol.\n\n- Versioning: Codex32's metadata can store version information for\n wallets that use implicit BIP32 paths (e.g. BIP44/49/84/86), although\n this would cut into the space available for users to set their own\n metadata and it is not specified in the draft BIP. SLIP39 also\n doesn't specify anything about implicit path versioning and, AFAICT,\n doesn't have any room to store such metadata without reducing seed\n entropy.\n\n- Plausible deniability dummy wallets: Codex32 doesn't support this;\n SLIP39 does. Much has been written by other people about whether\n dummy wallets are a good idea or not, with strong opinions on both\n sides, so maybe we can just leave it at that.\n\n---\n\nWhen I first saw the post about this, it was unclear to me that it was a\nserious project, but I've become increasingly interested as I researched\nit. I'm not personally that interested in generating entropy from dice\nor encoding shares by hand---it's already imperative that I acquire a\ntrustworthy computer and load it with trustworthy software in order to\nuse my seed securely, so I might as well have it generate my seeds and \nmy\nrecovery codes for me.\n\nWhat really did catch my attention, but which was kind of buried in the\nproject documentation, is the ability to verify the integrity of each\nshare independently without using a computer. For example, if I store a\nshare with some relative who lives thousands of kilometers away, I'll be\nable to take that share out of its tamper-evident bag on my annual\nholiday visit, verify that I can still read it accurately by validating\nits checksum, and put it into a new bag for another year. For this\nprocedure, I don't need to bring copies of any of my other shares,\nallowing them (and my seed) to stay safe.\n\n---\n\nI do have one question after watching an excellent video[2] about the\nmotivation for this system. In the video, one of the threat models\ndescribed is a disarrangement of the words in a metal backup system.\nThe implication seems to be that this would be an accidental\ndisarrangement, which obviously the Codex32 checksum would catch during\nperiodic offline verification. But what about deliberate modification\nof a recovery code? For example, Bob doesn't keep his seed loaded on\nany computer; it only exists in Codex32 shares which Bob plans to\ncombine together in 20 years when he retires, although he makes regular\ndeposits to the pubkeys derived from the seed's master xpub. Mallory is\nable to obtain access to Bob's shares, allowing her to immediately steal\nhis current funds---but also allowing her to replace them with \nsimilar-looking\nshares with the same metadata and valid checksums so that Bob\ncontinues making deposits to the wallet.\n\nI'm curious about whether there's a way to prevent this attack without\notherwise compromising the properties of the code? For example, some\nextra data that Bob can carry around (or memorize) for verifying the\nshares haven't changed, but which is not otherwise needed for recovery\n(so there's no problem if it's lost).\n\nThanks,\n\n-Dave\n\n[1] https://secretcodex32.com/faq/index.html\n[2] \nhttps://www.youtube.com/watch?v=kf48oPoiHX0\u0026list=PLyOGyBytgcuQLi9DC5g88DOEGnqBDPmq1\u0026index=2",
"sig": "d0a97c8d1a9ba6126cdae7a2818e8914ad31caaeedd09dbaeda091028b690a540668f10d7b5869ad978a32757ab151c550e421f214d6f22eb8158c2b01aea2b6"
}