Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id BA535C0001 for ; Sun, 9 May 2021 22:54:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A1988605F7 for ; Sun, 9 May 2021 22:54:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ-yj7jf9iK5 for ; Sun, 9 May 2021 22:54:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.worldserver.net (mail.worldserver.net [217.13.200.37]) by smtp3.osuosl.org (Postfix) with ESMTPS id 3E715605D2 for ; Sun, 9 May 2021 22:54:10 +0000 (UTC) Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) (Authenticated sender: tobias@kaupat-hh.de) by mail.worldserver.net (Postfix) with ESMTPSA id B7CFF26A9A for ; Mon, 10 May 2021 00:54:05 +0200 (CEST) Received: by mail-qv1-f49.google.com with SMTP id u7so7475557qvv.12 for ; Sun, 09 May 2021 15:54:05 -0700 (PDT) X-Gm-Message-State: AOAM531W35m7J9A8CZSu1zhfLRrpEONm3uFxXng/IuOYMq8i8YSDHSDU pROQzo5feyqvg5KBnjNEBz7YIHiIZQYZa3beMlM= X-Google-Smtp-Source: ABdhPJz1KM3kIvUI2c65SVhzWEPMFy3wwpebBQLSVtL+gGsDetO1HtjC5gJFEvLMdcwtrJpT3IMZwOK24qSSmnSf5mI= X-Received: by 2002:a0c:eec7:: with SMTP id h7mr11657533qvs.45.1620600844067; Sun, 09 May 2021 15:54:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tobias Kaupat Date: Mon, 10 May 2021 00:53:51 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "BitPLATES (Chris)" Content-Type: multipart/alternative; boundary="000000000000a2275405c1ed895a" X-Mailman-Approved-At: Sun, 09 May 2021 23:01:19 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Proposal for an Informational BIP X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2021 22:54:13 -0000 --000000000000a2275405c1ed895a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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' leadin= g > 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 lay= er > passphrase is very dangerous, whereby, an unfortunate accident could leav= e > 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 recognise= d > 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 coul= d > 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 see= d > 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 cou= ld >> use the restore feature to work around this - but it's one step more tha= t >> should be mentioned. >> >> >> Kind regards >> Tobias >> >> >> >> >> BitPLATES=C2=AE (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 produc= ing >>> 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, a= nd >>> 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 Bitcoi= n >>> wallet; inversely, the 2nd Bitcoin wallet is protected by the seed word= s 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 >>> (=E2=89=882048^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, shou= ld >>> 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-compatibl= e >>> 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 fu= nds >>> 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 extrem= ely >>> safe and secure 'low-tech' option, that requires minimal (non-destructi= ve) >>> 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 cas= e 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 le= vel >>> 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 passphras= e. >>> >>> 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), d= oes >>> not always equal increased complexity (orderly, and more human-friendly= ), >>> or increased security. >>> >>> As previously mentioned, a two-wallet configuration provides the user a= n >>> opportunity to safely split the two factors of protection (equivalent t= o 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=E2=81=B7=E2=81=B6 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 2= 4 >>> 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 >>> >> --000000000000a2275405c1ed895a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chris,
thanks for the clarification. = It makes sense so far.

A= bout the "chicken - egg" problem:
When you= generate a BIP39 mnemonic "A" without password, you get a Seed &= quot;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 mne= monic A without password (will never be used)
- Gene= rate mnemonic B* using words from A as password
- Ge= nerate mnemonic A* using words from B* as password
<= br>
That's just an implementation detail but mig= ht have impact on the actual process, depending on the wallet you are using= .

Hope it's clear.

Kind regards
Tobias



BitPLATES (Ch= ris) <bitplates@market= networks.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 y= ou choose your passphrase?"

- Correct, my idea is covered by BIP39, and therefore compatible = with BIP39... I see the 'quantum' passphrase as an optional 'so= ft 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 hi= s 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.&qu= ot;

- Correct also, my p= roposal is for an Informational BIP to educate users how to create a 'q= uantum' 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 extre= me level of protection would make it impossible to brute-force the wallet w= ithout the 'quantum' passphrase.

<= div dir=3D"auto">"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. Memorisatio= n of the 2nd layer passphrase is very dangerous, whereby, an unfortunate ac= cident 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 disgui= sed as a 24 word seed. Therefore, discovery of a backup device with the ext= ra, unrestricted characters that don't also open a (sacrificial) wallet= , will be recognised as a 2nd layer passphrase... This is when the $5 wrenc= h is brought to the table to extract the 1st layer seed words.=C2=A0
<= div dir=3D"auto">
"One issue might be, that= the passphrase is part of the mnemonic. A hardware wallet needs the passph= rase to generate the complete mnemonic (changing the password does change t= he resulting seed). Thus you get a chicken-egg problem, at least for some i= mplementations. Probably you could use the restore feature to work around t= his - but it's one step more that should be mentioned."

- I'm not sure that I fully un= derstand 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 th= en 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&#= 39; passphrase, containing the seed words of the 1st Bitcoin wallet.
<= div dir=3D"auto">
Thank you for your thoughts.

Regards,

Chris

<= /div>
O= n Sun, 9 May 2021, 08:24 Tobias Kaupat, <Tobias@kaupat-hh.de> wr= ote:
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 m= y password rather than anything that needs to be implemented somewhere.

Don't I have plausible deniability already with any other p= assword 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 har= dware wallet needs the passphrase to generate the complete mnemonic (changi= ng the password does change the resulting seed). Thus you get a chicken-egg= problem, at least for some implementations. Probably you could use the res= tore feature to work around this - but it's one step more that should b= e mentioned.


<= div dir=3D"auto">Kind regards
Tobias




BitPLATES=C2=AE = (Chris) via bitcoin-dev <bitcoin-dev@lists= .linuxfoundation.org> schrieb am Sa., 8. Mai 2021, 17:21:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi,

I'd like to submit an idea for review, as a poten= tial informational BIP (Bitcoin Improvement Proposal), describing an option= al method of producing a BIP39 passphrase, using only BIP39 'mnemonic&#= 39; 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, provid= ing plausible deniability about the existence of this separate 2nd layer pa= ssphrase.

I've sugge= sted the name 'quantum' passphrase to be used casually as a unique = identifier.

The data sto= red within a 'quantum' passphrase, is simultaneously the minimum re= quired data for reproducing a BIP39-compatible 24-word seed mnemonic... hen= ce, the name 'quantum' seems fitting, to reflect the multiple simul= taneous states of data.

=
Abstract...

This improvement proposal describes the use of twenty four, newly gen= erated BIP39 seed words, to produce a '25th-word' BIP39-compatible = 'quantum' passphrase.

Two-factor authentication (2FA) or (2 of 2 multi-signature) can be im= plemented 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 i= n the level of protection, as that offered by the original BIP39 mnemonic s= eed words (=E2=89=882048^23 possible combinations).
=
ie. A Bitcoin wallet with a 2nd layer 'quan= tum'passphrase is protected by 2048^23 to the power of 2048^23 possible= combinations.

With exis= ting computer capabilities, this level of protection is far greater than re= quired; however, this does provide a sufficient level of protection for eac= h separate layer of a two-factor Bitcoin wallet, should any one layer be ac= cidentally exposed.

This= method of passphrase generation, consists of two parts:

1st - generating the BIP39 mnemonic seed w= ords, using a BIP39-compatible hardware wallet.

=
2nd - Converting these seed words into the 'qua= ntum' 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 w= ords for the purpose of reproduction of a Bitcoin wallet, suffers from a ma= jor flaw... Exposure of these mnemonic seed words can cause catastrophic lo= ss of funds without adequate multi-factor protection.

Whilst it is recognised that a number of mult= i-factor solutions are available (including the standard BIP39 passphrase, = and hardware wallet multi-signature functionality), this proposal aims to p= rovide an extremely safe and secure 'low-tech' option, that require= s minimal (non-destructive) adjustments to the seed words.

Furthermore, the 'quantum' passp= hrase offers a number advantages over the existing methods of multi-factor = protection:

Firstly, thi= s method of creating a passphrase leaves no evidence of its existence on an= y backup devices, providing plausible deniability in case of coercion.

This is because the passphra= se is easily created from a genuine 24 seed word mnemonic; therefore, the p= hysical backup of the passphrase can be disguised as a simple Bitcoin walle= t 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 reduce= d level of passphrase security, unbeknown to many users.

The large amount of data required to produ= ce a 'quantum' passphrase (up to 96 characters long), encourages th= e physical backup of the passphrase.

Furthermore, the use of BIP39-only words provides a higher deg= ree of standardization, which can help to avoid potential mistakes made by = creating unnecessarily complicated combinations of letters, numbers and sym= bols. Increased complication (disorderly, and non-human-friendly), does not= always equal increased complexity (orderly, and more human-friendly), or i= ncreased security.

As pr= eviously mentioned, a two-wallet configuration provides the user an opportu= nity 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=E2=81=B7=E2=81=B6 possible combinations of words).

The strength of this 2nd factor solution, pro= vides adequate risk-management, when considering the production of multiple= backup devices, strategically stored in multiple geographical locations.

Generating the 'quant= um' passphrase...

Fo= llowing just four (non-destructive) BIP39-compatible rules, the 24 seed wor= ds can also function as a 'quantum' passphrase:

1 . Only BIP39 words
(Standard list of 2048 English words - other languages should be compatibl= e)

2 . Only the first fo= ur letters of each word
(BIP39 words require only th= is data for reproduction)

3 . Only upper case letters
(All alphabet referenc= es use this standard format)

4 . No spaces between words
(Spaces represent a= n additional unit of data, that is not recorded)
In essence, the 'quantum' passphrase is si= mply a single string of all 24 seed words, set out using the above rules.

I welcome a productive te= chnical discussion.

Than= ks,

Chris Johnston
=


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.= org
https= ://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--000000000000a2275405c1ed895a--