From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B1B7CC0177 for ; 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 ; 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 ; 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 ; 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 ; Wed, 26 Feb 2020 14:56:21 -0500 Received: by mail-io1-f47.google.com with SMTP id z16so461441iod.11 for ; 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: In-Reply-To: From: Jeremy Date: Wed, 26 Feb 2020 11:56:09 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Contact Team , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
As a replacement for pape= r, something like this makes sense v.s. what you do with a ledger presently= .

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

Non-interactive mul= tisig has the benefit of being able to sign transactions without having key= s in the same room/place/device ever.


On Wed, Feb 26, 2020 at 9:14 AM Contact T= eam 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 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= .

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 cypherock.com. 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.

Thanks<= /div>
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000934a39059f7fff02--