Re: [bitcoin-dev] Proposal for an Informational BIP
Hi Chris, thanks for the clarification. It makes sense so far. About the "chicken - egg" problem: When you generate a BIP39 mnemonic "A" without password, you get a Seed "As" from which you derive your private key. Using the same mnemonic with a passphrase will give you a different seed "As*" with a different private and public key. Now your process must look like: - Generate mnemonic A without password (will never be used) - Generate mnemonic B* using words from A as password - Generate mnemonic A* using words from B* as password That's just an implementation detail but might have impact on the actual process, depending on the wallet you are using. Hope it's clear. Kind regards Tobias BitPLATES (Chris) schrieb am So., 9. Mai 2021, 10:29: > Hi Tobias, > > In answer to your questions... > > "Isn't your suggestion already covered by BIP39 since there is not > restriction in how you choose your passphrase?" > > - Correct, my idea is covered by BIP39, and therefore compatible with > BIP39... I see the 'quantum' passphrase as an optional 'soft fork' leading > towards a more restricted choice of characters, rather than the fuller, > less restrictive choice of characters. > > "It's up to any user to choose his password like you propose. I see your > proposal more like a way to choose my password rather than anything that > needs to be implemented somewhere." > > - Correct also, my proposal is for an Informational BIP to educate users > how to create a 'quantum' passphrase, which provides the same high degree > of protection (2048^23 combinations) as the original 1st layer mnemonic > seed words. Should their 24 seed words be compromised (or posted on the > internet), this extreme level of protection would make it impossible to > brute-force the wallet without the 'quantum' passphrase. > > "Don't I have plausible deniability already with any other password that I > keep in mind, since the seed without the password is already a valid > address?" > > - No, because an unrestricted passphrase may contain characters different > to those allowed by the 'quantum' passphrase. Memorisation of the 2nd layer > passphrase is very dangerous, whereby, an unfortunate accident could leave > your family without access to their inherence. The 'quantum' passphrase > encourages the use of multiple metal backup storage devices, but anything > more that A-Z (upper case only), would not be disguised as a 24 word seed. > Therefore, discovery of a backup device with the extra, unrestricted > characters that don't also open a (sacrificial) wallet, will be recognised > as a 2nd layer passphrase... This is when the $5 wrench is brought to the > table to extract the 1st layer seed words. > > "One issue might be, that the passphrase is part of the mnemonic. A > hardware wallet needs the passphrase to generate the complete mnemonic > (changing the password does change the resulting seed). Thus you get a > chicken-egg problem, at least for some implementations. Probably you could > use the restore feature to work around this - but it's one step more that > should be mentioned." > > - I'm not sure that I fully understand this last paragraph of your email, > but just to be clear, the 'quantum' passphrase is made from the 24 seed > words of a separate wallet. This is essentially the 2nd layer (or 2nd > signing key) to add to the 1st layer (or 1st signing key) required to > complete the full mnemonic, which then provides access to the > passphrase-protected wallet. > > eg. The 1st Bitcoin wallet is protected by a 'quantum' passphrase, > containing the seed words of the 2nd Bitcoin wallet; inversely, the 2nd > Bitcoin wallet is protected by a 'quantum' passphrase, containing the seed > words of the 1st Bitcoin wallet. > > Thank you for your thoughts. > > Regards, > > Chris > > > On Sun, 9 May 2021, 08:24 Tobias Kaupat, wrote: > >> Hello Chris, >> Isn't your suggestion already covered by BIP39 since there is not >> restriction in how you choose your passphrase? >> >> It's up to any user to choose his password like you propose. I see your >> proposal more like a way to choose my password rather than anything that >> needs to be implemented somewhere. >> >> Don't I have plausible deniability already with any other password that I >> keep in mind, since the seed without the password is already a valid >> address? >> >> One issue might be, that the passphrase is part of the mnemonic. A >> hardware wallet needs the passphrase to generate the complete mnemonic >> (changing the password does change the resulting seed). Thus you get a >> chicken-egg problem, at least for some implementations. Probably you could >> use the restore feature to work around this - but it's one step more that >> should be mentioned. >> >> >> Kind regards >> Tobias >> >> >> >> >> BitPLATES® (Chris) via bitcoin-dev >> schrieb am Sa., 8. Mai 2021, 17:21: >> >>> Hi, >>> >>> I'd like to submit an idea for review, as a potential informational BIP >>> (Bitcoin Improvement Propos
Re: [bitcoin-dev] Proposal for an Informational BIP
Hello Chris, Isn't your suggestion already covered by BIP39 since there is not restriction in how you choose your passphrase? It's up to any user to choose his password like you propose. I see your proposal more like a way to choose my password rather than anything that needs to be implemented somewhere. Don't I have plausible deniability already with any other password that I keep in mind, since the seed without the password is already a valid address? One issue might be, that the passphrase is part of the mnemonic. A hardware wallet needs the passphrase to generate the complete mnemonic (changing the password does change the resulting seed). Thus you get a chicken-egg problem, at least for some implementations. Probably you could use the restore feature to work around this - but it's one step more that should be mentioned. Kind regards Tobias BitPLATES® (Chris) via bitcoin-dev schrieb am Sa., 8. Mai 2021, 17:21: > Hi, > > I'd like to submit an idea for review, as a potential informational BIP > (Bitcoin Improvement Proposal), describing an optional method of producing > a BIP39 passphrase, using only BIP39 'mnemonic' seed words. > > The idea specifically refers to a method of introducing two-factor > authentication, to protect a Bitcoin wallet using only 24 seed words, and > therefore, providing plausible deniability about the existence of this > separate 2nd layer passphrase. > > I've suggested the name 'quantum' passphrase to be used casually as a > unique identifier. > > The data stored within a 'quantum' passphrase, is simultaneously the > minimum required data for reproducing a BIP39-compatible 24-word seed > mnemonic... hence, the name 'quantum' seems fitting, to reflect the > multiple simultaneous states of data. > > Abstract... > > This improvement proposal describes the use of twenty four, newly > generated BIP39 seed words, to produce a '25th-word' BIP39-compatible > 'quantum' passphrase. > > Two-factor authentication (2FA) or (2 of 2 multi-signature) can be > implemented with a two-wallet setup: > > The 1st Bitcoin wallet is protected by the seed words of the 2nd Bitcoin > wallet; inversely, the 2nd Bitcoin wallet is protected by the seed words of > the 1st Bitcoin wallet. > > The 'quantum' passphrase offers an exponential increase in the level of > protection, as that offered by the original BIP39 mnemonic seed words > (≈2048^23 possible combinations). > > ie. A Bitcoin wallet with a 2nd layer 'quantum'passphrase is protected by > 2048^23 to the power of 2048^23 possible combinations. > > With existing computer capabilities, this level of protection is far > greater than required; however, this does provide a sufficient level of > protection for each separate layer of a two-factor Bitcoin wallet, should > any one layer be accidentally exposed. > > This method of passphrase generation, consists of two parts: > > 1st - generating the BIP39 mnemonic seed words, using a BIP39-compatible > hardware wallet. > > 2nd - Converting these seed words into the 'quantum' passphrase, following > four simple rules, which most importantly, do not destroy the integrity of > the initial data. > > Motivation... > > The well established practice of preserving up to 24 seed words for the > purpose of reproduction of a Bitcoin wallet, suffers from a major flaw... > Exposure of these mnemonic seed words can cause catastrophic loss of funds > without adequate multi-factor protection. > > Whilst it is recognised that a number of multi-factor solutions are > available (including the standard BIP39 passphrase, and hardware wallet > multi-signature functionality), this proposal aims to provide an extremely > safe and secure 'low-tech' option, that requires minimal (non-destructive) > adjustments to the seed words. > > Furthermore, the 'quantum' passphrase offers a number advantages over the > existing methods of multi-factor protection: > > Firstly, this method of creating a passphrase leaves no evidence of its > existence on any backup devices, providing plausible deniability in case of > coercion. > > This is because the passphrase is easily created from a genuine 24 seed > word mnemonic; therefore, the physical backup of the passphrase can be > disguised as a simple Bitcoin wallet on a metal backup plate. > > It presents a way of discouraging user-created words or sentences (also > known as 'brain-wallets'), which often provide a drastically reduced level > of passphrase security, unbeknown to many users. > > The large amount of data required to produce a 'quantum' passphrase (up to > 96 characters long), encourages the physical backup of the passphrase. > > Furthermore, the use of BIP39-only words provides a higher degree of > standardization, which can help to avoid potential mistakes made by > creating unnecessarily complicated combinations of letters, numbers and > symbols. Increased complication (disorderly, and non-human-friendly), does > not always equal increased complexity (orderly, and more human-
Re: [bitcoin-dev] Encryption of an existing BIP39 mnemonic without changing the seed
Hello Erik, Thanks for your reply. After a little research I came to the same conclusion. PDKDF2 makes sense, since it is already used in BIP39. I will update my code. Regarding SeedXOR: That's at least a similar solution, but than I have to store 2 phrases, I really like to keep one part in my head, which is only possible with a password. Plus for anyone who want to use two seeds my proposal also works - it just needs software to be applied. Kind regards Tobias Kaupat Erik Aronesty schrieb am Do., 6. Mai 2021, 15:19: > i would stretch the password, with pbkdf2 or argon2 with like 30k > rounds or something first, rather than "just hashing it". remember, > it's pretty easy to validate these seeds - not like you lock someone > out after 9 guesses! > > On Wed, May 5, 2021 at 3:38 PM Tobias Kaupat via bitcoin-dev > wrote: > > > > 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 > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Encryption of an existing BIP39 mnemonic without changing the seed
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
