MIME-Version: 1.0
References: <CAEcfjBRCA1sKcFC5M++WECsgYD-jDBYGuwxLfh0PSzRkCehEDA@mail.gmail.com>
In-Reply-To: <CAEcfjBRCA1sKcFC5M++WECsgYD-jDBYGuwxLfh0PSzRkCehEDA@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Wed, 26 Feb 2020 11:56:09 -0800
Message-ID: <CAD5xwhgP=9-AvMOVO+-b9c3DZ_vYd-bPLYM26Qvawmcj28UOZw@mail.gmail.com>
To: Contact Team <contact@cypherock.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000934a39059f7fff02"
Subject: Re: [bitcoin-dev] Removing Single Point of Failure with Seed Phrase
	Storage
Precedence: list

--000000000000934a39059f7fff02
Content-Type: text/plain; charset="UTF-8"

As a replacement for paper, something like this makes sense v.s. what you
do with a ledger presently.

However, shamir's shares notoriously have the issue that the key does exist
plaintext on a device at some point.

Non-interactive multisig has the benefit of being able to sign transactions
without having keys in the same room/place/device ever.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Wed, Feb 26, 2020 at 9:14 AM Contact Team via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Everyone,
> Seed phrase security has been a subject of discussion for a long time now.
> Though there are varying opinions on the subject but the conflict usually
> arises due to different security models used by different individuals. The
> general practice in the space has been to use paper or metal engraving
> options to secure seed phrase but those too act as a single point of
> failure when secure storage is concerned. The hardware wallets, no matter
> whether use a secure element or not can be hacked either through basic
> glitching or through bigger schemes state enforced backdoors in the closed
> soured SE used.
>
> The option that Cypherock (Cypherock X1 Wallet)  is working on removes a
> single point of failure when it comes to storage of seed phrases. It uses 2
> of 4 (with the option of setting up custom threshold limit) Shamir Secret
> Sharing to  split the seed phrase into 4 different shares. Each share gets
> stored in a PIN ( hardware enforced ) Card with an EAL 6+ secure element.
> The user would need any 2 of these 4 cyCards to recover the seed or make a
> transaction. Ideally they should all be stored at different locations and
> this added security through distribution makes losing seed phrase highly
> improbable. We have decoupled storage and computation aspect of a hardware
> wallet. More information can be obtained from cypherock.com. The purpose
> of this mail is to get feedback from the community. Let us know if there is
> any feedback, we would love it.
>
> Thanks
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">As a replacement for pape=
r, something like this makes sense v.s. what you do with a ledger presently=
.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:#000000"><br></div><div class=3D"gmail_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#=
000000">However, shamir&#39;s shares notoriously have the issue that the ke=
y does exist plaintext on a device at some point.</div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:#000000">Non-interactive mul=
tisig has the benefit of being able to sign transactions without having key=
s in the same room/place/device ever.<br clear=3D"all"></div><div><div dir=
=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_bl=
ank">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"=
_blank"></a></div></div></div><br></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Wed, Feb 26, 2020 at 9:14 AM Contact T=
eam via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Everyone,<di=
v>Seed phrase security has been a subject of discussion for a long time now=
. Though there are varying opinions on the subject but the conflict usually=
 arises due to different security models used by different individuals. The=
 general practice in the space has been to use paper or metal engraving opt=
ions to secure seed phrase but those too act as a single point of failure w=
hen secure storage is concerned. The hardware wallets, no matter whether us=
e a secure element or not can be hacked either through basic glitching or t=
hrough bigger schemes state enforced backdoors in the closed soured SE used=
.</div><div><br></div><div>The option that Cypherock (Cypherock X1 Wallet)=
=C2=A0 is working on removes a single point of failure when it comes to sto=
rage of seed phrases. It uses 2 of 4 (with the option of setting up custom =
threshold limit) Shamir Secret Sharing to=C2=A0 split the seed phrase into =
4 different shares. Each share gets stored in a PIN ( hardware enforced ) C=
ard with an EAL 6+ secure element. The user would need any 2 of these 4 cyC=
ards to recover the seed or make a transaction. Ideally they should all be =
stored at different locations and this added security through distribution =
makes losing seed phrase highly improbable. We have decoupled storage and c=
omputation aspect of a hardware wallet. More information can be obtained fr=
om <a href=3D"http://cypherock.com" target=3D"_blank">cypherock.com</a>. Th=
e purpose of this mail is to get feedback from the community. Let us know i=
f there is any feedback, we would love it.</div><div><br></div><div>Thanks<=
/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>

--000000000000934a39059f7fff02--