summaryrefslogtreecommitdiff
path: root/e9/d5a2c70f3f72d8d2692ba7bad2290394e59c78
blob: 8437ada9217d65e19a0f6c5bb5796759e9a06a9f (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
Return-Path: <bitplates@marketnetworks.co.uk>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id ACFFBC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 17:45:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 8F5E54011A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 17:45:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 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_PASS=-0.001, T_SPF_PERMERROR=0.01]
 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 LGMsoK9FAkHJ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 17:45:28 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 75595400C2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 17:45:28 +0000 (UTC)
Received: from mail-lj1-f181.google.com ([209.85.208.181])
 by smtp.hosts.co.uk with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256)
 (Exim) (envelope-from <bitplates@marketnetworks.co.uk>)
 id 1lgWRg-0000OD-65
 for bitcoin-dev@lists.linuxfoundation.org; Tue, 11 May 2021 18:45:26 +0100
Received: by mail-lj1-f181.google.com with SMTP id p20so2204871ljj.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 11 May 2021 10:45:24 -0700 (PDT)
X-Gm-Message-State: AOAM532tiyHyiHjYA4R4Mk67hMPjA2G48GRvXjNZ3Mke/d6lpnHCa9mZ
 63KLFvqichfJAvxgtx54X8++kqtVI6ZwNhMS9Ro=
X-Google-Smtp-Source: ABdhPJy4oGETbmYcvg0CbzR+Ae5m0BSlvNVUIHrJeILQvI5hOW95JoA9NXJZLEpHruJHSA5nQfdAeGIjlTrplAvE14U=
X-Received: by 2002:a2e:2c01:: with SMTP id s1mr25593921ljs.17.1620755123786; 
 Tue, 11 May 2021 10:45:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAAvTZ6546k0Rx2ODQ7EHJWV=F-DU-kQEg=Qh6yK6WNH-dmgv8w@mail.gmail.com>
 <CAC0TF=m+Cg_LKz0vSuTb-xg6qY1GbeGMjaXa0bgoiLqtCbMikQ@mail.gmail.com>
 <CAAvTZ64H3jQJ9F-Hxbc1=0+pN8p=wGEEcMokpoJCFJSVDjqzKA@mail.gmail.com>
 <CAC0TF=meoUhRUMWmto8fxksse6G=66XJdxH8bvFfHENvVnS_+A@mail.gmail.com>
In-Reply-To: <CAC0TF=meoUhRUMWmto8fxksse6G=66XJdxH8bvFfHENvVnS_+A@mail.gmail.com>
From: "BitPLATES (Chris)" <bitplates@marketnetworks.co.uk>
Date: Tue, 11 May 2021 18:45:13 +0100
X-Gmail-Original-Message-ID: <CAAvTZ67kGBeqKd_mTdMU-S_Q1K92R5qq=vwTe12TrTnUAxUpfA@mail.gmail.com>
Message-ID: <CAAvTZ67kGBeqKd_mTdMU-S_Q1K92R5qq=vwTe12TrTnUAxUpfA@mail.gmail.com>
To: "Chris D'Costa" <chrisjdcosta@gmail.com>,
 bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="0000000000006bdbe005c21175f6"
X-Mailman-Approved-At: Tue, 11 May 2021 18:25:37 +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: Tue, 11 May 2021 17:45:30 -0000

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

Hi Chris,

I apologise if I did not make it clear enough, but the 24 seed words used
to make the quantum passphrase are separate, newly generated 24 seed words,
and not the same as those for the main wallet.

With both layers (seed words + quantum passphrase) the security provided is
(2048^23)^(2048^23).

ie. 2048 to the power of 23, to the power of 2048 to the power of 23
possible combinations of words.

The BIP39 passphrase is designed to prevent catastrophic loss of funds in
the case of accidental seed word exposure.

If both, seed words and quantum passphrase, are stored on two separate
metal backup storage plates, in two separate locations, then the accidental
disclosure of either one provides 2048^23 (or 10^76) possible combinations
of words to decrypt.

ie. The quantum passphrase provides the same degree of security, as the
original 24 seed words.

I hope this helps.

Best regards,

Chris


On Tue, 11 May 2021, 17:54 Chris D'Costa, <chrisjdcosta@gmail.com> wrote:

> "well established security of the existing BIP39 standard"
>
> You are basing your entire proposal on this basic misunderstanding.
>
> There is no inherent (or "existing") security in BIP39. All it does is
> provide a standardised and convenient way to record, and recover a
> private key from a readable seed phrase. In fact there are many language
> versions of BIP39 dictionary. But really the worst part of the idea from =
a
> security perspective is that it reveals the seed phrase. Even a simple
> password to encrypt (whilst possibly weak) would still never so this!
>
> C
>
>
> On Tue, 11 May 2021 at 10:48, BitPLATES (Chris) <
> bitplates@marketnetworks.co.uk> wrote:
>
>> Hi Chris,
>>
>> Thank you for your thoughts.
>>
>> Unfortunately, your analysis is incorrect.
>>
>> This is a non-destructive adaptation of the BIP39 standard, and is
>> certainly not "rolling your own security".
>>
>> The 'quantum' passphrase is relying on the well established security of
>> the existing BIP39 standard.
>>
>> There are 2048 possible words that can be chosen from the BIP39 word
>> list. Therefore, to derive a seed from a string of 24 BIP39 words, is
>> exactly the same as deriving a seed from the full 24 words:
>>
>> 2048 to the power of 23 combinations of security (not the power of 24
>> because of the checksum), or 10 to the power of 76 combinations.
>>
>> If you created your own combinations of words to make up a passphrase,
>> this same degree of security would require 15 random words from the Engl=
ish
>> dictionary (assuming 100,000 English words):
>>
>> 100,000 to the power of 15 =3D 10 to the power of 75 combinations.
>>
>> The other problem with this, is that you could not plausibly deny that i=
t
>> was a passphrase, whereas, using a 'quantum' passphrase allows you to
>> backup your passphrase disguised as a 24 seed mnemonic.
>>
>> I hope this alleviates your concerns.
>>
>> All the best,
>>
>> Chris
>>
>>
>> On Tue, 11 May 2021, 09:12 Chris D'Costa, <chrisjdcosta@gmail.com> wrote=
:
>>
>>> I think the biggest problem you have with this proposal is "rolling you=
r
>>> own security".
>>>
>>> Are you aware that the dictionary is designed such that the first four
>>> letters are unique to each word? Taking those four letters and
>>> concatenating them to a string basically means that I can derive your s=
eed
>>> from your supposedly secure "quantum" passphrase. It does not add to th=
e
>>> security - if anything it makes it worse. It would be orders of magnitu=
de
>>> worse than using a random password and encryption as most wallets have =
been
>>> using for years.
>>>
>>> C
>>>
>>> On Sat, 8 May 2021 at 17:21, BitPLATES=C2=AE (Chris) via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'd like to submit an idea for review, as a potential informational BI=
P
>>>> (Bitcoin Improvement Proposal), describing an optional method of produ=
cing
>>>> 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 o=
f
>>>> 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 o=
f
>>>> protection for each separate layer of a two-factor Bitcoin wallet, sho=
uld
>>>> 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 th=
e
>>>> integrity of the initial data.
>>>>
>>>> Motivation...
>>>>
>>>> The well established practice of preserving up to 24 seed words for th=
e
>>>> purpose of reproduction of a Bitcoin wallet, suffers from a major flaw=
...
>>>> Exposure of these mnemonic seed words can cause catastrophic loss of f=
unds
>>>> 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 walle=
t
>>>> multi-signature functionality), this proposal aims to provide an extre=
mely
>>>> safe and secure 'low-tech' option, that requires minimal (non-destruct=
ive)
>>>> 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 it=
s
>>>> existence on any backup devices, providing plausible deniability in ca=
se of
>>>> coercion.
>>>>
>>>> This is because the passphrase is easily created from a genuine 24 see=
d
>>>> 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 (als=
o
>>>> known as 'brain-wallets'), which often provide a drastically reduced l=
evel
>>>> of passphrase security, unbeknown to many users.
>>>>
>>>> The large amount of data required to produce a 'quantum' passphrase (u=
p
>>>> to 96 characters long), encourages the physical backup of the passphra=
se.
>>>>
>>>> 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 an=
d
>>>> symbols. Increased complication (disorderly, and non-human-friendly), =
does
>>>> not always equal increased complexity (orderly, and more human-friendl=
y),
>>>> or increased security.
>>>>
>>>> As previously mentioned, a two-wallet configuration provides the user
>>>> an opportunity to safely split the two factors of protection (equivale=
nt 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, 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
>>>>
>>>

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

<div dir=3D"auto"><div><div dir=3D"auto">Hi Chris,</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">I apologise if I did not make it clear enough, b=
ut the 24 seed words used to make the quantum passphrase are separate, newl=
y generated 24 seed words, and not the same as those for the main wallet.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">With both layers (seed wo=
rds + quantum passphrase) the security provided is (2048^23)^(2048^23).</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">ie. 2048 to the power of 23=
, to the power of 2048 to the power of 23 possible combinations of words.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">The BIP39 passphrase is d=
esigned to prevent catastrophic loss of funds in the case of accidental see=
d word exposure.</div><div dir=3D"auto"><br></div><div dir=3D"auto">If both=
, seed words and quantum passphrase, are stored on two separate metal backu=
p storage plates, in two separate locations, then the accidental disclosure=
 of either one provides 2048^23 (or 10^76) possible combinations of words t=
o decrypt.</div><div dir=3D"auto"><br></div><div dir=3D"auto">ie. The quant=
um passphrase provides the same degree of security, as the original 24 seed=
 words.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I hope this help=
s.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Best regards,</div><d=
iv dir=3D"auto"><br></div><div dir=3D"auto">Chris</div><div dir=3D"auto"><b=
r></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Tue, 11 May 2021, 17:54 Chris D&#39;Costa, &lt;<a href=3D"mailto:chris=
jdcosta@gmail.com">chrisjdcosta@gmail.com</a>&gt; wrote:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr">&quot;well established security of t=
he existing BIP39 standard&quot;<div><br></div><div>You are basing your ent=
ire proposal on this basic misunderstanding.=C2=A0</div><div><br></div><div=
>There is no inherent (or &quot;existing&quot;) security in BIP39. All it d=
oes is provide a standardised and convenient way to record, and recover a p=
rivate=C2=A0key from a readable seed phrase. In fact there are many languag=
e versions of BIP39 dictionary. But really the worst part of the idea from =
a security perspective is that it reveals the seed phrase. Even a simple pa=
ssword to encrypt (whilst possibly weak) would still never so this!=C2=A0</=
div><div><br></div><div>C</div><div><br></div></div><br><div class=3D"gmail=
_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 11 May 2021 at 10:48,=
 BitPLATES (Chris) &lt;<a href=3D"mailto:bitplates@marketnetworks.co.uk" ta=
rget=3D"_blank" rel=3D"noreferrer">bitplates@marketnetworks.co.uk</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"auto"><div>Hi Chris,</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Thank you for your thoughts.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">Unfortunately, your analysis is incorrect.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">This is a non-destructive adaptation of the BIP39 =
standard, and is certainly not &quot;rolling your own security&quot;.</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">The &#39;quantum&#39; passphr=
ase is relying on the well established security of the existing BIP39 stand=
ard.</div><div dir=3D"auto"><br></div><div dir=3D"auto">There are 2048 poss=
ible words that can be chosen from the BIP39 word list. Therefore, to deriv=
e a seed from a string of 24 BIP39 words, is exactly the same as deriving a=
 seed from the full 24 words:</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">2048 to the power of 23 combinations of security (not the power of 24=
 because of the checksum), or 10 to the power of 76 combinations.</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">If you created your own combinati=
ons of words to make up a passphrase, this same degree of security would re=
quire 15 random words from the English dictionary (assuming 100,000 English=
 words):</div><div dir=3D"auto"><br></div><div dir=3D"auto">100,000 to the =
power of 15 =3D 10 to the power of 75 combinations.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">The other problem with this, is that you could =
not plausibly deny that it was a passphrase, whereas, using a &#39;quantum&=
#39; passphrase allows you to backup your passphrase disguised as a 24 seed=
 mnemonic.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I hope this a=
lleviates your concerns.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>All the best,</div><div dir=3D"auto"><br></div><div dir=3D"auto">Chris</di=
v><div dir=3D"auto"><br></div><div dir=3D"auto"><br><div class=3D"gmail_quo=
te" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, 11 May 2021,=
 09:12 Chris D&#39;Costa, &lt;<a href=3D"mailto:chrisjdcosta@gmail.com" tar=
get=3D"_blank" rel=3D"noreferrer">chrisjdcosta@gmail.com</a>&gt; wrote:<br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><d=
iv dir=3D"ltr">I think the biggest problem you have with this proposal is &=
quot;rolling your own security&quot;.<br></div><div dir=3D"ltr"><br>Are you=
 aware that the dictionary is designed such that the first four letters are=
 unique to each word? Taking those four letters and concatenating them to a=
 string basically means that I can derive your seed from your supposedly se=
cure &quot;quantum&quot; passphrase. It does not add to the security - if a=
nything it makes it worse. It would be orders of magnitude worse than using=
 a random password and encryption as most wallets have been using for years=
.</div><div><br></div><div>C</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sat, 8 May 2021 at 17:21, BitPLATES=C2=AE =
(Chris) via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div dir=3D"auto">Hi,<div dir=3D"auto"><br></div><div d=
ir=3D"auto">I&#39;d like to submit an idea for review, as a potential infor=
mational BIP (Bitcoin Improvement Proposal), describing an optional method =
of producing a BIP39 passphrase, using only BIP39 &#39;mnemonic&#39; seed w=
ords.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The idea specifica=
lly refers to a method of introducing two-factor authentication, to protect=
 a Bitcoin wallet using only 24 seed words, and therefore, providing plausi=
ble deniability about the existence of this separate 2nd layer passphrase.<=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;ve suggested the n=
ame &#39;quantum&#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;quantum&#39; passphrase, is simultaneously the minimum required dat=
a for reproducing a BIP39-compatible 24-word seed mnemonic... hence, the na=
me &#39;quantum&#39; seems fitting, to reflect the multiple simultaneous st=
ates of data.</div><div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=
=3D"auto">Abstract...</div><div dir=3D"auto"><br></div><div dir=3D"auto">Th=
is improvement proposal describes the use of twenty four, newly generated B=
IP39 seed words, to produce a &#39;25th-word&#39; BIP39-compatible &#39;qua=
ntum&#39; passphrase.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Tw=
o-factor authentication (2FA) or (2 of 2 multi-signature) can be implemente=
d with a two-wallet setup:</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">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 o=
f the 1st Bitcoin wallet.</div><div dir=3D"auto"><br></div><div dir=3D"auto=
">The &#39;quantum&#39; passphrase offers an exponential increase in the le=
vel of protection, as that offered by the original BIP39 mnemonic seed word=
s (=E2=89=882048^23 possible combinations).</div><div dir=3D"auto"><br></di=
v><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 combina=
tions.</div><div dir=3D"auto"><br></div><div dir=3D"auto">With existing com=
puter capabilities, this level of protection is far greater than required; =
however, this does provide a sufficient level of protection for each separa=
te layer of a two-factor Bitcoin wallet, should any one layer be accidental=
ly exposed.</div><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 dir=3D"auto">1st - generating the BIP39 mnemonic seed words, us=
ing a BIP39-compatible hardware wallet.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">2nd - Converting these seed words into the &#39;quantum&#39=
; passphrase, following four simple rules, which most importantly, do not d=
estroy the integrity of the initial data.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Motivation...</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">The well established practice of preserving up to 24 seed words f=
or the purpose of reproduction of a Bitcoin wallet, suffers from a major fl=
aw... Exposure of these mnemonic seed words can cause catastrophic loss of =
funds without adequate multi-factor protection.</div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Whilst it is recognised that a number of multi-fact=
or solutions are available (including the standard BIP39 passphrase, and ha=
rdware wallet multi-signature functionality), this proposal aims to provide=
 an extremely safe and secure &#39;low-tech&#39; option, that requires mini=
mal (non-destructive) adjustments to the seed words.</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">Furthermore, the &#39;quantum&#39; passphrase =
offers a number advantages over the existing methods of multi-factor protec=
tion:</div><div dir=3D"auto"><br></div><div dir=3D"auto">Firstly, this meth=
od of creating a passphrase leaves no evidence of its existence on any back=
up devices, providing 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 physica=
l backup of the 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 leve=
l of passphrase 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&#39; passphrase (up to 96 characters long), encourages the phys=
ical backup of the passphrase.</div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Furthermore, the use of BIP39-only words provides a higher degree of=
 standardization, which can help to avoid potential mistakes made by creati=
ng unnecessarily complicated combinations of letters, numbers and symbols. =
Increased complication (disorderly, and non-human-friendly), does not alway=
s equal increased complexity (orderly, and more human-friendly), or increas=
ed security.</div><div dir=3D"auto"><br></div><div dir=3D"auto">As previous=
ly mentioned, a two-wallet configuration provides the user an opportunity t=
o safely split the two factors of protection (equivalent to a 2 of 2 &#39;m=
ulti-sig&#39; setup).</div><div dir=3D"auto"><br></div><div dir=3D"auto">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).</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 back=
up devices, strategically stored in multiple geographical locations.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Generating the &#39;quantum&#3=
9; passphrase...</div><div dir=3D"auto"><br></div><div dir=3D"auto">Followi=
ng just four (non-destructive) BIP39-compatible rules, the 24 seed words ca=
n also function as a &#39;quantum&#39; passphrase:</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">1 . Only BIP39 words</div><div dir=3D"auto">(Sta=
ndard list of 2048 English words - other languages should be compatible)</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">2 . Only the first four le=
tters of each word</div><div dir=3D"auto">(BIP39 words require only this da=
ta for reproduction)</div><div dir=3D"auto"><br></div><div dir=3D"auto">3 .=
 Only upper case letters</div><div dir=3D"auto">(All alphabet references us=
e this standard format)</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
4 . No spaces between words</div><div dir=3D"auto">(Spaces represent an add=
itional unit of data, that is not recorded)</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">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 technic=
al 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"><br></div><div dir=3D"auto"><br></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
</blockquote></div></div></div>
</blockquote></div>
</blockquote></div></div></div>

--0000000000006bdbe005c21175f6--