public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tobias Kaupat <Tobias@kaupat-hh.de>
To: "BitPLATES (Chris)" <bitplates@marketnetworks.co.uk>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal for an Informational BIP
Date: Mon, 10 May 2021 00:53:51 +0200	[thread overview]
Message-ID: <CAPyCnfu32KKmrmDEmx5QNNnzifNE_J5Sfi2uWoPZo0NA4ruqgg@mail.gmail.com> (raw)
In-Reply-To: <CAAvTZ658FN2++znPjWim+cf=Xfgq7ycWqyZLbjKyizorkxv0ww@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 11147 bytes --]

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) <bitplates@marketnetworks.co.uk> 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, <Tobias@kaupat-hh.de> 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 <bitcoin-dev@lists.linuxfoundation.org>
>> 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-friendly),
>>> or increased security.
>>>
>>> As previously mentioned, a two-wallet configuration provides the user an
>>> opportunity to safely split the two factors of protection (equivalent to a
>>> 2 of 2 'multi-sig' setup).
>>>
>>> If a BIP39-compatible passphrase is created using a new set of 24 seed
>>> words, it provides 76 degrees of extra complexity (ie. 1 with 76 zeros, or
>>> 10⁷⁶ possible combinations of words).
>>>
>>> The strength of this 2nd factor solution, provides adequate
>>> risk-management, when considering the production of multiple backup
>>> devices, strategically stored in multiple geographical locations.
>>>
>>> Generating the 'quantum' passphrase...
>>>
>>> Following just four (non-destructive) BIP39-compatible rules, the 24
>>> seed words can also function as a 'quantum' passphrase:
>>>
>>> 1 . Only BIP39 words
>>> (Standard list of 2048 English words - other languages should be
>>> compatible)
>>>
>>> 2 . Only the first four letters of each word
>>> (BIP39 words require only this data for reproduction)
>>>
>>> 3 . Only upper case letters
>>> (All alphabet references use this standard format)
>>>
>>> 4 . No spaces between words
>>> (Spaces represent an additional unit of data, that is not recorded)
>>>
>>> In essence, the 'quantum' passphrase is simply a single string of all 24
>>> seed words, set out using the above rules.
>>>
>>> I welcome a productive technical discussion.
>>>
>>> Thanks,
>>>
>>> Chris Johnston
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>

[-- Attachment #2: Type: text/html, Size: 14933 bytes --]

  reply	other threads:[~2021-05-09 22:54 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08 15:21 [bitcoin-dev] Proposal for an Informational BIP BitPLATES® (Chris)
2021-05-09  7:24 ` Tobias Kaupat
2021-05-09  8:29   ` BitPLATES (Chris)
2021-05-09 22:53     ` Tobias Kaupat [this message]
2021-05-10  6:30       ` BitPLATES (Chris)
     [not found] ` <CAC0TF=m+Cg_LKz0vSuTb-xg6qY1GbeGMjaXa0bgoiLqtCbMikQ@mail.gmail.com>
2021-05-11  8:48   ` BitPLATES (Chris)
     [not found]     ` <CAC0TF=meoUhRUMWmto8fxksse6G=66XJdxH8bvFfHENvVnS_+A@mail.gmail.com>
2021-05-11 17:45       ` BitPLATES (Chris)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPyCnfu32KKmrmDEmx5QNNnzifNE_J5Sfi2uWoPZo0NA4ruqgg@mail.gmail.com \
    --to=tobias@kaupat-hh.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=bitplates@marketnetworks.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox