path: root/80/040d5e5d32f915c5b89ddda17873e70b641cba

Return-Path: <jlrubin@mit.edu>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B1B7CC0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Feb 2020 19:56:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id A01F986BA6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Feb 2020 19:56:24 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wohzDvkwjF5p
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Feb 2020 19:56:23 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 40DAB86BA4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Feb 2020 19:56:23 +0000 (UTC)
Received: from mail-io1-f47.google.com (mail-io1-f47.google.com
 [209.85.166.47]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01QJuLqZ029583
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 26 Feb 2020 14:56:21 -0500
Received: by mail-io1-f47.google.com with SMTP id z16so461441iod.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 26 Feb 2020 11:56:21 -0800 (PST)
X-Gm-Message-State: APjAAAWrFKHRrUwb4PI14P4Kw5OvuWlv2wm6DzRU2js8DrDh6cwS8NpQ
 RDd5iW15Il9y/VWcmg7VSLi/Trr8ELdVmORbyLs=
X-Google-Smtp-Source: APXvYqxMD5Wl/cvmhp563IX6KkxNoVriWyccdrvmHyidDZhLtBG+KQREu0O9I7cMCAhFDv/1I24XLiQZJuj3LgOjw/Q=
X-Received: by 2002:a02:ad0a:: with SMTP id s10mr1156450jan.73.1582746981056; 
 Wed, 26 Feb 2020 11:56:21 -0800 (PST)
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
X-Gmail-Original-Message-ID: <CAD5xwhgP=9-AvMOVO+-b9c3DZ_vYd-bPLYM26Qvawmcj28UOZw@mail.gmail.com>
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
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: Wed, 26 Feb 2020 19:56:24 -0000

--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--