path: root/64/40f557b519544be3b2e523d551ebd0ef05cf08

Return-Path: <Tobias@kaupat-hh.de>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1FF99C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 May 2021 07:24:51 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 0F7014011F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 May 2021 07:24:51 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 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]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id QtGlXd8w6AOn
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 May 2021 07:24:49 +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 smtp2.osuosl.org (Postfix) with ESMTPS id DE98D4011D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 May 2021 07:24:48 +0000 (UTC)
Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com
 [209.85.219.43]) (Authenticated sender: tobias@kaupat-hh.de)
 by mail.worldserver.net (Postfix) with ESMTPSA id 0DA5326B26
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  9 May 2021 09:24:41 +0200 (CEST)
Received: by mail-qv1-f43.google.com with SMTP id jm10so6930574qvb.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 09 May 2021 00:24:41 -0700 (PDT)
X-Gm-Message-State: AOAM533oZbDJB4oAP7T4dpJVpvutfPQsTUyeJAl4u2iKRAMfutoLbbef
 u4PTlYGQYhoIQg80vl4kipkg0xHcktz9M0FfNWQ=
X-Google-Smtp-Source: ABdhPJynyfs72jhNidEKKQuKEdxq2MXpExVTTXEvDIBu14QOU68kCnuEleHg51wnpyiORTn4vPNWlK5Gq/IDqFwMldM=
X-Received: by 2002:a0c:ec0f:: with SMTP id y15mr17836939qvo.9.1620545080424; 
 Sun, 09 May 2021 00:24:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAAvTZ6546k0Rx2ODQ7EHJWV=F-DU-kQEg=Qh6yK6WNH-dmgv8w@mail.gmail.com>
In-Reply-To: <CAAvTZ6546k0Rx2ODQ7EHJWV=F-DU-kQEg=Qh6yK6WNH-dmgv8w@mail.gmail.com>
From: Tobias Kaupat <Tobias@kaupat-hh.de>
Date: Sun, 9 May 2021 09:24:28 +0200
X-Gmail-Original-Message-ID: <CAPyCnfsRhF-X792cFUAcWj2DK=3WE_LYMX-eFO2A-U7aA81btQ@mail.gmail.com>
Message-ID: <CAPyCnfsRhF-X792cFUAcWj2DK=3WE_LYMX-eFO2A-U7aA81btQ@mail.gmail.com>
To: =?UTF-8?Q?BitPLATES=C2=AE_=28Chris=29?= <bitplates@marketnetworks.co.uk>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000dc7e8c05c1e08d7c"
X-Mailman-Approved-At: Sun, 09 May 2021 08:40:58 +0000
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 09 May 2021 07:24:51 -0000

--000000000000dc7e8c05c1e08d7c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C2=AE (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 producin=
g
> 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
> (=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, 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, followin=
g
> four simple rules, which most importantly, do not destroy the integrity o=
f
> 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 fund=
s
> 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 extremel=
y
> 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 leve=
l
> of passphrase security, unbeknown to many users.
>
> The large amount of data required to produce a 'quantum' passphrase (up t=
o
> 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), doe=
s
> 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, o=
r
> 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 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
>

--000000000000dc7e8c05c1e08d7c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hello Chris,<div dir=3D"auto">Isn&#39;t your suggestion a=
lready covered by BIP39 since there is not restriction in how you choose yo=
ur passphrase?</div><div dir=3D"auto"><br></div><div dir=3D"auto">It&#39;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 b=
e implemented somewhere.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
><span style=3D"font-family:sans-serif">Don&#39;t I have plausible deniabil=
ity already with any other password that I keep in mind, since the seed wit=
hout the password is already a valid address?</span><br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">One issue might be, that the passphrase is=
 part of the mnemonic. A hardware wallet needs the passphrase to generate t=
he complete mnemonic (changing the password does change the resulting seed)=
. Thus you get a chicken-egg problem, at least for some implementations. Pr=
obably you could use the restore feature to work around this - but it&#39;s=
 one step more that should be mentioned.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Kind regards</div><div dir=3D"=
auto">Tobias</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><=
br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gm=
ail_attr">BitPLATES=C2=AE (Chris) via bitcoin-dev &lt;<a href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</=
a>&gt; schrieb am Sa., 8. Mai 2021, 17:21:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"auto">Hi,<div dir=3D"auto"><br></div><div dir=3D"auto">=
I&#39;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 &#39;mnemonic&#39; seed words.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">The idea specifically refers t=
o a method of introducing two-factor authentication, to protect a Bitcoin w=
allet using only 24 seed words, and therefore, providing plausible deniabil=
ity about the existence of this separate 2nd layer passphrase.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto">I&#39;ve suggested the name &#39;qua=
ntum&#39; passphrase to be used casually as a unique identifier.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">The data stored within a &#39;quan=
tum&#39; passphrase, is simultaneously the minimum required data for reprod=
ucing a BIP39-compatible 24-word seed mnemonic... hence, the name &#39;quan=
tum&#39; seems fitting, to reflect the multiple simultaneous states of data=
.</div><div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">Abst=
ract...</div><div dir=3D"auto"><br></div><div dir=3D"auto">This improvement=
 proposal describes the use of twenty four, newly generated BIP39 seed word=
s, to produce a &#39;25th-word&#39; BIP39-compatible &#39;quantum&#39; pass=
phrase.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Two-factor authe=
ntication (2FA) or (2 of 2 multi-signature) can be implemented with a two-w=
allet setup:</div><div dir=3D"auto"><br></div><div dir=3D"auto">The 1st Bit=
coin wallet is protected by the seed words of the 2nd Bitcoin wallet; inver=
sely, the 2nd Bitcoin wallet is protected by the seed words of the 1st Bitc=
oin wallet.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The &#39;qua=
ntum&#39; passphrase offers an exponential increase in the level of protect=
ion, as that offered by the original BIP39 mnemonic seed words (=E2=89=8820=
48^23 possible combinations).</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">ie. A Bitcoin wallet with a 2nd layer &#39;quantum&#39;passphrase is =
protected by 2048^23 to the power of 2048^23 possible combinations.</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">With existing computer capabili=
ties, 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.</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">This method of passphrase =
generation, consists of two parts:</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">1st - generating the BIP39 mnemonic seed words, using a BIP39-co=
mpatible hardware wallet.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">2nd - Converting these seed words into the &#39;quantum&#39; passphrase, =
following four simple rules, which most importantly, do not destroy the int=
egrity of the initial data.</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Motivation...</div><div dir=3D"auto"><br></div><div dir=3D"auto">The we=
ll established practice of preserving up to 24 seed words for the purpose o=
f reproduction of a Bitcoin wallet, suffers from a major flaw... Exposure o=
f these mnemonic seed words can cause catastrophic loss of funds without ad=
equate multi-factor protection.</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Whilst it is recognised that a number of multi-factor solutions a=
re available (including the standard BIP39 passphrase, and hardware wallet =
multi-signature functionality), this proposal aims to provide an extremely =
safe and secure &#39;low-tech&#39; option, that requires minimal (non-destr=
uctive) adjustments to the seed words.</div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Furthermore, the &#39;quantum&#39; passphrase offers a numbe=
r advantages over the existing methods of multi-factor protection:</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Firstly, this method of creating=
 a passphrase leaves no evidence of its existence on any backup devices, pr=
oviding plausible deniability in case of coercion.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">This is because the passphrase is easily created=
 from a genuine 24 seed word mnemonic; therefore, the physical backup of th=
e passphrase can be disguised as a simple Bitcoin wallet on a metal backup =
plate.</div><div dir=3D"auto"><br></div><div dir=3D"auto">It presents a way=
 of discouraging user-created words or sentences (also known as &#39;brain-=
wallets&#39;), which often provide a drastically reduced level of passphras=
e security, unbeknown to many users.</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">The large amount of data required to produce a &#39;quantum&#3=
9; passphrase (up to 96 characters long), encourages the physical backup of=
 the passphrase.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Further=
more, the use of BIP39-only words provides a higher degree of standardizati=
on, which can help to avoid potential mistakes made by creating unnecessari=
ly complicated combinations of letters, numbers and symbols. Increased comp=
lication (disorderly, and non-human-friendly), does not always equal increa=
sed complexity (orderly, and more human-friendly), or increased security.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">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 &#39;multi-sig&#39; =
setup).</div><div dir=3D"auto"><br></div><div dir=3D"auto">If a BIP39-compa=
tible passphrase is created using a new set of 24 seed words, it provides 7=
6 degrees of extra complexity (ie. 1 with 76 zeros, or 10=E2=81=B7=E2=81=B6=
 possible combinations of words).</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">The strength of this 2nd factor solution, provides adequate risk-=
management, when considering the production of multiple backup devices, str=
ategically stored in multiple geographical locations.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Generating the &#39;quantum&#39; passphrase..=
.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Following just four (n=
on-destructive) BIP39-compatible rules, the 24 seed words can also function=
 as a &#39;quantum&#39; passphrase:</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">1 . Only BIP39 words</div><div dir=3D"auto">(Standard list of 2=
048 English words - other languages should be compatible)</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">2 . Only the first four letters of each w=
ord</div><div dir=3D"auto">(BIP39 words require only this data for reproduc=
tion)</div><div dir=3D"auto"><br></div><div dir=3D"auto">3 . Only upper cas=
e letters</div><div dir=3D"auto">(All alphabet references use this standard=
 format)</div><div dir=3D"auto"><br></div><div dir=3D"auto">4 . No spaces b=
etween words</div><div dir=3D"auto">(Spaces represent an additional unit of=
 data, that is not recorded)</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">In essence, the &#39;quantum&#39; passphrase is simply a single string=
 of all 24 seed words, set out using the above rules.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">I welcome a productive technical discussion.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">Thanks,</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Chris Johnston</div><div dir=3D"auto"><b=
r></div><div dir=3D"auto"><br></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000dc7e8c05c1e08d7c--