path: root/f1/2f8a98bd339ad61772d173813ebd49712ca5f3

Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1FD4149B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Dec 2018 12:16:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com
	[209.85.128.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB79914D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  4 Dec 2018 12:16:40 +0000 (UTC)
Received: by mail-wm1-f50.google.com with SMTP id z18so9365911wmc.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 04 Dec 2018 04:16:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=aw1OSKoNyqUKWX0V1RAl+cA8YfHNW8ZUCkSbsaq/wNw=;
	b=ipdLWycBbr1ZnyvPfoRWgWZhkLsEg4nXiDtlwSYrNijOOdzvZtR6/rRlKHYvQM/vdy
	/jhYl9mC6/mr8x5b/4mj7BwCfpKl9EZMDPK+TAWtXEkO88rL549x5wRRUzaki1kQn3nS
	DIfnRy9Zr/UgSkeyP8zRD3KlBLcmjpqQQwRCbs5TvhRTgdVmM26QmaYty4n1Y61f1fi2
	9YXEyLuoDisX9n1PJ+GeBlu5+2NnvKBbiTYvNJiz0fu2JbV0fL9BpwETNp57JQJDw49c
	c789e5Dz6MF2udHhlmA576JNFnMlCthaZIx8nuP9rPxptlKQbus8wiUSEXpCJuvhIW6y
	dVlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=aw1OSKoNyqUKWX0V1RAl+cA8YfHNW8ZUCkSbsaq/wNw=;
	b=VbDjkCYX4PDYw0HMj1ZFUXNBRzxyB/6hGf025BkkAisyTlzmrrSXTW26h1QTggBu+Z
	uEckSnZsKiDRIFWpme8yBvrJDA45tkgIz0clQ0w6uPVAARTDHsj8tFD0ri3bYZv9eFwG
	ma5rOlnKbgLfD+bnqq0pfMGXEwocakXwyKg5+ZLODEUUy290swTDoJSgcGShE0YeB9IJ
	aCmmb+dOz7gjsQXRp6ET4KuXg0RhEz+xYRGmP5UzV2c7Yw+gRncDJArkcQoIMqZlu5zG
	Q/fKUJAidyuI8l3bgteCUqRSC9C5Tey7hVXvIOATLcB2jJobzMFR3hO0R4EzW42f56JY
	hw1A==
X-Gm-Message-State: AA+aEWan2FCrvgXrrSD96WRq8mBOG1PgHxfnRNt278cd1DHURIs6mFdg
	73IRH8AyNEcMTxe2Tfy88HuzpeF+b+m3tvwWZJg=
X-Google-Smtp-Source: AFSGD/Wngejx/eyLc9fwx2Jkn1zB+ZRI/eP1FCynEndIwJ7uouzdAGmD1QHZVf3/VSPTv3wCndIeQQHU4pGsC9jLmC8=
X-Received: by 2002:a1c:e58c:: with SMTP id
	c134mr11709841wmh.124.1543925799348; 
	Tue, 04 Dec 2018 04:16:39 -0800 (PST)
MIME-Version: 1.0
References: <CABsxsG234DhY8Lxn0UMgXG0YnPdyJ5__U9P-aweV9L=xw7hxyw@mail.gmail.com>
	<CA+ASnrGEbksc-YeKR7bKpAv5=rcWcg8BeR6XDVUzvJ9C76bGpA@mail.gmail.com>
In-Reply-To: <CA+ASnrGEbksc-YeKR7bKpAv5=rcWcg8BeR6XDVUzvJ9C76bGpA@mail.gmail.com>
From: James MacWhyte <macwhyte@gmail.com>
Date: Tue, 4 Dec 2018 04:16:12 -0800
Message-ID: <CAH+Axy4=8SyRL5W9Av_6dDOp43Qd+Cdkf2XZnpf1i6zCT4Pemg@mail.gmail.com>
To: fireduck@gmail.com, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000d46e38057c313cf0"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 04 Dec 2018 13:08:52 +0000
Cc: shatzakis@gmail.com
Subject: Re: [bitcoin-dev] Proposal for Palindromic (Reversible) Mnemonics
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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, 04 Dec 2018 12:16:42 -0000

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

I agree with Joseph. If you want plausible deniability, it would be better
to simply hide the funds somewhere in the HD chain. Same if you want a
second vault tied to the same phrase.

You are reducing security by eliminating all entropy that doesn't fit the
reversible criteria, although in practice it doesn't make a difference
because the numbers are so big. However, it doesn't seem like a very useful
feature to have.

Thanks for doing all that work though, it was fun to read about your idea
and what you found out through experimenting!

James


On Mon, Dec 3, 2018 at 1:00 PM Joseph Gleason =E2=91=88 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I have a suggestion.  If you are concerned about plausible deniability,
> then it might make sense to just have the single mnemonic seed lead to a
> single xprv key (as usual) and then do a private key derivation from that
> based on a password string.  The password can be simple, as it is based o=
n
> the security of the seed, just as long as the user feels they need for
> deniability.
>
> A simple reverse scheme like you describe would just be another thing a
> person would know to check if given some seed so I don't see it as
> providing much value, but I could be missing something.
>
> On Mon, Dec 3, 2018 at 10:45 AM Steven Hatzakis via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi All,
>>
>> I've developed a method to check if a mnemonic is also valid when the
>> words are put into reverse order (not the entropy), where a given 12 or
>> 24-word mnemonic could be valid both in little endian and big endian
>> format. I've coined these "Palindromic Mnemonics", but perhaps more
>> user-friendly is "reversible mnemonics."
>>
>> Purpose:
>> A checksum-valid reversible mnemonic allows two separate vaults to be
>> connected to the same mnemonic string of words, where all a users must d=
o
>> is enter the words in reverse order (the last word becomes first, second=
 to
>> last becomes second, and so on) to access the secondary (reversed words)
>> vault. This utility could provide multiple use-cases, including related =
to
>> combinations with passphrases and plausible deniability, as well as
>> conveniences for those wishing to use a separate vault tied to the same
>> string of words.
>>
>> Security:
>> For any randomly generated 12-word mnemonic (128-bits of security) the
>> chances of it also being reversible are 1/16 (I believe), as a total of =
4
>> bit positions must be identical (4 bits from the normal mnemonic and
>> another 4 bits from the reversed string must match). For a 24-word
>> mnemonic, those values increase to 8 bits which need to match 8 bits fro=
m
>> the reversed string, leading to about 1 in every 256 mnemonics also bein=
g
>> reversible. While the message space of valid reversible mnemonics should=
 be
>> 2^124 for 12 words, that search must still be conducted over a field of =
2
>> ^128, as the hash-derived checksum values otherwise prevent a way to
>> deterministically find valid reversible mnemonics without first going
>> through invalid reversible ones to check. I think others should chime in=
 on
>> whether they believe there is any security loss, in terms of entropy bit=
s
>> (assuming the initial 128 bits were generated securely). I estimate at m=
ost
>> it would be 4-bits of loss for a 12-word mnemonic, but only if an attack=
er
>> had a way to search only the space of valid reversible mnemonics (2**124=
)
>> which I don't think is feasible (could be wrong?). There could also be
>> errors in my above assumptions, this is a work in progress and sharing i=
t
>> here to solicit initial feedback/interest.
>>
>> I've already written the code that can be used for testing (on GitHub
>> user @hatgit), and when run from terminal/command prompt it is pretty fa=
st
>> to find a valid reversible mnemonics, whereas on IDLE in Python on a 32-=
bit
>> and 64-bit machine it could take a few seconds for 12 words and sometime=
s
>> 10 minutes to find a valid 24-word reversible mnemonic.
>> Example 12 words reversible (with valid checksum each way):
>>
>> limit exact seven clarify utility road image fresh leg cabbage hint cano=
e
>>
>> And Reversed:
>>
>> canoe hint cabbage leg fresh image road utility clarify seven exact limi=
t
>>
>>
>> Example 24 reversible:
>>
>> favorite uncover sugar wealth army shift goose fury market toe message
>> remain direct arrow duck afraid enroll salt knife school duck sunny grun=
t
>> argue
>>
>> And reversed:
>>
>> argue grunt sunny duck school knife salt enroll afraid duck arrow direct
>> remain message toe market fury goose shift army wealth sugar uncover
>> favorite
>>
>>
>> My two questions 1) are how useful could this be for
>> you/users/devs/service providers etc.. and 2) is any security loss
>> occurring and whether it is negligible or not?
>>
>> Best regards,
>>
>> Steven Hatzakis
>> _______________________________________________
>> 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
>

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

<div dir=3D"ltr">I agree with Joseph. If you want plausible deniability, it=
 would be better to simply hide the funds somewhere in the HD chain. Same i=
f you want a second vault tied to the same phrase.<div><br></div><div>You a=
re reducing security by eliminating all entropy that doesn&#39;t fit the re=
versible criteria, although in practice it doesn&#39;t make a difference be=
cause the numbers are so big. However, it doesn&#39;t seem like a very usef=
ul feature to have.<div><br></div><div>Thanks for doing all that work thoug=
h, it was fun to read about your idea and what you found out through experi=
menting!</div><div><br clear=3D"all"><div><div dir=3D"ltr" class=3D"gmail_s=
ignature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>James<br=
></div></div></div></div><br></div></div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr">On Mon, Dec 3, 2018 at 1:00 PM Joseph Gleason =E2=91=88=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr">I have a suggestion.=C2=A0 If you are=
 concerned about plausible deniability, then it might make sense to just ha=
ve the single mnemonic seed lead to a single xprv key (as usual) and then d=
o a private key derivation from that based on a password string.=C2=A0 The =
password can be simple, as it is based on the security of the seed, just as=
 long as the user feels they need for deniability.<div><br></div><div>A sim=
ple reverse scheme like you describe would just be another thing a person w=
ould know to check if given some seed so I don&#39;t see it as providing mu=
ch value, but I could be missing something.</div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr">On Mon, Dec 3, 2018 at 10:45 AM Steven Hatzakis=
 via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><d=
iv dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default"><p style=3D"fo=
nt-family:-apple-system,system-ui,&quot;Segoe UI&quot;,Helvetica,Arial,sans=
-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe=
 UI Symbol&quot;;box-sizing:border-box;margin-bottom:16px;color:rgb(36,41,4=
6);font-size:14px;margin-top:0px">Hi All,=C2=A0</p><p style=3D"font-family:=
-apple-system,system-ui,&quot;Segoe UI&quot;,Helvetica,Arial,sans-serif,&qu=
ot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol=
&quot;;box-sizing:border-box;margin-bottom:16px;color:rgb(36,41,46);font-si=
ze:14px;margin-top:0px">I&#39;ve developed a method to check if a mnemonic =
is also valid when the words are put into reverse order (not the entropy), =
where a given 12 or 24-word mnemonic could be valid both in little endian a=
nd big endian format. I&#39;ve coined these &quot;Palindromic Mnemonics&quo=
t;, but perhaps more user-friendly is &quot;reversible mnemonics.&quot;</p>=
<p style=3D"font-family:-apple-system,system-ui,&quot;Segoe UI&quot;,Helvet=
ica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quo=
t;,&quot;Segoe UI Symbol&quot;;box-sizing:border-box;margin-bottom:16px;mar=
gin-top:0px;color:rgb(36,41,46);font-size:14px"><span style=3D"box-sizing:b=
order-box;font-weight:600">Purpose:</span><br style=3D"box-sizing:border-bo=
x">A checksum-valid reversible mnemonic allows two separate vaults to be co=
nnected to the same mnemonic string of words, where all a users must do is =
enter the words in reverse order (the last word becomes first, second to la=
st becomes second, and so on) to access the secondary (reversed words) vaul=
t. This utility could provide multiple use-cases, including related to comb=
inations with passphrases and plausible deniability, as well as convenience=
s for those wishing to use a separate vault tied to the same string of word=
s.</p><p style=3D"font-family:-apple-system,system-ui,&quot;Segoe UI&quot;,=
Helvetica,Arial,sans-serif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emo=
ji&quot;,&quot;Segoe UI Symbol&quot;;box-sizing:border-box;margin-bottom:16=
px;margin-top:0px;color:rgb(36,41,46);font-size:14px"><span style=3D"box-si=
zing:border-box;font-weight:600">Security:</span><br style=3D"box-sizing:bo=
rder-box">For any randomly generated 12-word mnemonic (128-bits of security=
) the chances of it also being reversible are 1/16 (I believe), as a total =
of 4 bit positions must be identical (4 bits from the normal mnemonic and a=
nother 4 bits from the reversed string must match). For a 24-word mnemonic,=
=C2=A0those values increase to 8 bits which need to match 8 bits from the r=
eversed string, leading to about 1 in every 256 mnemonics also being revers=
ible. While the message space of valid reversible mnemonics should be 2^<sp=
an style=3D"box-sizing:border-box">124 for 12 words, that search must still=
 be conducted over a field of 2</span><span style=3D"box-sizing:border-box;=
font-weight:600">^</span>128, as the hash-derived checksum values otherwise=
 prevent a way to deterministically find valid reversible mnemonics without=
 first going through invalid reversible ones to check. I think others shoul=
d chime in on whether they believe there is any security loss, in terms of =
entropy bits (assuming the initial 128 bits were generated securely). I est=
imate at most it would be 4-bits of loss for a 12-word mnemonic, but only i=
f an attacker had a way to search only the space of valid reversible mnemon=
ics (2**124) which I don&#39;t think is feasible (could be wrong?). There c=
ould also be errors in my above assumptions, this is a work in progress and=
 sharing it here to solicit initial feedback/interest.</p><p style=3D"font-=
family:-apple-system,system-ui,&quot;Segoe UI&quot;,Helvetica,Arial,sans-se=
rif,&quot;Apple Color Emoji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI=
 Symbol&quot;;box-sizing:border-box;margin-bottom:16px;margin-top:0px;color=
:rgb(36,41,46);font-size:14px">I&#39;ve already written the code that can b=
e used for testing (on GitHub user @hatgit), and when run from terminal/com=
mand prompt it is pretty fast to find a valid reversible mnemonics, whereas=
 on IDLE in Python on a 32-bit and 64-bit machine it could take a few secon=
ds for 12 words and sometimes 10 minutes to find a valid 24-word reversible=
 mnemonic.=C2=A0</p>Example 12 words reversible (with valid checksum each w=
ay): <br><br>limit exact seven clarify utility road image fresh leg cabbage=
 hint canoe<br><br>And Reversed:<br><br>canoe hint cabbage leg fresh image =
road utility clarify seven exact limit<br><br><br>Example 24 reversible:<br=
><br>favorite uncover sugar wealth army shift goose fury market toe message=
 remain direct arrow duck afraid enroll salt knife school duck sunny grunt =
argue</div><div class=3D"gmail_default"><br>And reversed:</div><div class=
=3D"gmail_default"><br>argue grunt sunny duck school knife salt enroll afra=
id duck arrow direct remain message toe market fury goose shift army wealth=
 sugar uncover favorite<p class=3D"m_-575678971359378551m_67113220125865167=
52gmail-p1" style=3D"margin:0px;font-variant-numeric:normal;font-variant-ea=
st-asian:normal;font-stretch:normal;font-size:11px;line-height:normal;font-=
family:Menlo;color:rgb(0,0,0)"><span class=3D"m_-575678971359378551m_671132=
2012586516752gmail-s1" style=3D"font-variant-ligatures:no-common-ligatures"=
><br></span></p><p style=3D"box-sizing:border-box;margin-bottom:16px;margin=
-top:0px"><span style=3D"color:rgb(36,41,46);font-family:-apple-system,syst=
em-ui,&quot;Segoe UI&quot;,Helvetica,Arial,sans-serif,&quot;Apple Color Emo=
ji&quot;,&quot;Segoe UI Emoji&quot;,&quot;Segoe UI Symbol&quot;;font-size:1=
4px">My two questions 1) are how useful could this be for you/users/devs/se=
rvice providers etc.. and 2) is any security loss occurring and whether it =
is negligible or not?</span><br></p><p style=3D"box-sizing:border-box;margi=
n-bottom:16px;margin-top:0px"><span style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:12.8px">Best regards,</span></p></div><div><div dir=3D"l=
tr" class=3D"m_-575678971359378551m_6711322012586516752gmail_signature"><di=
v dir=3D"ltr"><div dir=3D"ltr"><div style=3D"font-size:12.8px;font-family:a=
rial,helvetica,sans-serif"><span><br>Steven</span>=C2=A0<span>Hatzakis</spa=
n>=C2=A0</div><div style=3D"font-size:12.8px;font-family:arial,helvetica,sa=
ns-serif"><span class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif"> </span></div></div></div></div></div></div></div></div></div=
>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000d46e38057c313cf0--