📅 Original date posted:2021-05-05
📝 Original message:Hi all,
I want to start a discussion about a use case I have and a possible
solution. I have not found any satisfying solution to this use case yet.
*Use case:*
An existing mnemonic (e.g. for a hardware wallet) should be saved on a
paper backup in a password encrypted form. The encrypted form should be a
mnemonic itself to keep all backup properties like error correction.
*Suggested solution:*
1) Take the existing mnemonic and extract the related entropy
2) Create a SHA526 hash (key) from a user defined password
3) Use the key as input for an AES CTR (empty IV) to encrypt the entropy
4) Derive a new mnemonic from the encrypted entropy to be stored on a paper
backup
We can add some hints to the paper backp that the mnemonic is encrypted, or
prefix it with "*" to make clear it's not usable without applying the
password via the algorithm above.
To restore the original mnemonic, one must know the password and need to
follow the process above again.
An example implementation in GoLang can be found here:
https://github.com/Niondir/go-bip39/blob/master/encyrption_test.go
*Why not use the existing BIP-39 Passphrase?*
When generating a mnemonic with passphrase, the entropy is derived from the
passphrase. When you have an existing mnemonic without a passphrase, any
attempt to add a passphrase will end up in a different seed and thus a
different private key. What we actually need is to encrypt the entropy.
I'm open for your feedback. All encryption parameters are up to discussion
and the whole proposal needs a security review. It's just the first draft.
*Existing solutions*
One solution I found is "Seedshift" which can be found here:
https://github.com/mifunetoshiro/Seedshift
But I consider it less secure and I would like to suggest a solution based
on provably secure algorithms rather than a "rot23 derivation". Also using
a date as password seems not very clever to me.
Kind regards
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210505/3e25a360/attachment.html>;
Tobias Kaupat [ARCHIVE] /
npub1l0…9yst7
2023-06-07 22:52:28
in reply to nevent1q…hsug
Author Public Key
npub1l0qdcz02mgzllfd9vjecejejwds3y0rea0qzmdnvypq2fp7ds9qsn9yst7Published at
2023-06-07 22:52:28Event JSON
{
"id": "6fbe96f00cc7f3911250e507c1a5dad847e2adc07c7f1489cb88a76fc21aee21",
"pubkey": "fbc0dc09eada05ffa5a564b38ccb327361123c79ebc02db66c2040a487cd8141",
"created_at": 1686178348,
"kind": 1,
"tags": [
[
"e",
"e11519c341ac153b44c66b1b04fa38247862a9f7c423be70a3fb8c9280689f6f",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2021-05-05\n📝 Original message:Hi all,\nI want to start a discussion about a use case I have and a possible\nsolution. I have not found any satisfying solution to this use case yet.\n\n*Use case:*\nAn existing mnemonic (e.g. for a hardware wallet) should be saved on a\npaper backup in a password encrypted form. The encrypted form should be a\nmnemonic itself to keep all backup properties like error correction.\n\n*Suggested solution:*\n1) Take the existing mnemonic and extract the related entropy\n2) Create a SHA526 hash (key) from a user defined password\n3) Use the key as input for an AES CTR (empty IV) to encrypt the entropy\n4) Derive a new mnemonic from the encrypted entropy to be stored on a paper\nbackup\n\nWe can add some hints to the paper backp that the mnemonic is encrypted, or\nprefix it with \"*\" to make clear it's not usable without applying the\npassword via the algorithm above.\n\nTo restore the original mnemonic, one must know the password and need to\nfollow the process above again.\n\nAn example implementation in GoLang can be found here:\nhttps://github.com/Niondir/go-bip39/blob/master/encyrption_test.go\n\n*Why not use the existing BIP-39 Passphrase?*\nWhen generating a mnemonic with passphrase, the entropy is derived from the\npassphrase. When you have an existing mnemonic without a passphrase, any\nattempt to add a passphrase will end up in a different seed and thus a\ndifferent private key. What we actually need is to encrypt the entropy.\n\nI'm open for your feedback. All encryption parameters are up to discussion\nand the whole proposal needs a security review. It's just the first draft.\n\n*Existing solutions*\nOne solution I found is \"Seedshift\" which can be found here:\nhttps://github.com/mifunetoshiro/Seedshift\n\nBut I consider it less secure and I would like to suggest a solution based\non provably secure algorithms rather than a \"rot23 derivation\". Also using\na date as password seems not very clever to me.\n\nKind regards\nTobias\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210505/3e25a360/attachment.html\u003e",
"sig": "35a61a6396b3ef7236b53c0b0f43a724fc5ab7d7a924fb146fd712baf8a39457747b1af4a13c620fad98e25797eff664a7600f36636603194cf5fe3bbcec8bde"
}