summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGregory Maxwell <greg@xiph.org>2018-01-08 04:22:43 +0000
committerbitcoindev <bitcoindev@gnusha.org>2018-01-08 04:22:45 +0000
commitafa64edec109f174bb685407dda7e29a5508ca84 (patch)
treef5b000d442a2cb9e805e280cecb8d3f0a4c7474e
parent0114653e0475a98d5919dd6c8c21b9bc1b1b21f5 (diff)
downloadpi-bitcoindev-afa64edec109f174bb685407dda7e29a5508ca84.tar.gz
pi-bitcoindev-afa64edec109f174bb685407dda7e29a5508ca84.zip
[bitcoin-dev] Satoshilabs secret shared private key scheme
-rw-r--r--4a/e8120cc712a4bc72ea796a7b0975e5b9af7f0e121
1 files changed, 121 insertions, 0 deletions
diff --git a/4a/e8120cc712a4bc72ea796a7b0975e5b9af7f0e b/4a/e8120cc712a4bc72ea796a7b0975e5b9af7f0e
new file mode 100644
index 000000000..fa7be02bc
--- /dev/null
+++ b/4a/e8120cc712a4bc72ea796a7b0975e5b9af7f0e
@@ -0,0 +1,121 @@
+Return-Path: <gmaxwell@gmail.com>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id BE424FE6
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 8 Jan 2018 04:22:45 +0000 (UTC)
+X-Greylist: whitelisted by SQLgrey-1.7.6
+Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com
+ [209.85.213.51])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 06F0418A
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Mon, 8 Jan 2018 04:22:44 +0000 (UTC)
+Received: by mail-vk0-f51.google.com with SMTP id o16so6591331vke.12
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Sun, 07 Jan 2018 20:22:44 -0800 (PST)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
+ h=mime-version:sender:from:date:message-id:subject:to;
+ bh=hI/tLQPXQ/gNHPIjvVSJnRxOkwsa7oJZXSDk4gSy1rI=;
+ b=TcVQVzytrerXs3IED+69KhdKuqS+uHV4JZrO+yPypOTE1BGTukuxPnk5V8EVwPC+bR
+ Uuv15roC5FCOcGhbNZY8kSj9dXP2P8PLu0XsD0CFcw9KpdaSIP/XloXVahoTOvEw3Lnx
+ ZDgaiVWsCYERMncdM91llmRPtznYc91FCHk9sWafmjLb8ekLshUenENzhmxZneOrnBTV
+ xgB0RVHA3uFVudZtGf9ng/C9eeC6C5uxf/vPLrJwgw/8AGzquc9wFJg7JTZEepbCYSms
+ efcCEUP7VK6nWEKI9Az8LUIMk/pfQrPqG6aLI1fZnG4xCuG5pQoEyt+BzYnd+kPN91aE
+ F6OA==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20161025;
+ h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
+ :to; bh=hI/tLQPXQ/gNHPIjvVSJnRxOkwsa7oJZXSDk4gSy1rI=;
+ b=NqzP9Daa2vIMBU7LyW5aPzpiN7ytTV9H+UJ7oEQd0r9JZ70abIE+jND1q9Fe+Rcear
+ r+/U/0Yu3JFfJsBdqSuHZG6JA6k40os4dIVFbVy97eAXlp1doCEVNASSMZm/rlZxDlwQ
+ oqQITNODbHx0hQSkcUNR3el+2vxlPs1mGh051ESKrRiK4GR4ay3a6Z6U7rjyTyT0CsO5
+ Da042d9otXVenTFDbvuF1ZkgDxgPw1c+SaX+gUERqGeiyv00m1uJKBQpX/gPMgBINlQR
+ 4HXI5VzBN3KTgyQRr52eyB9ELb/b1Hz3m6uKmTwjugEEq6vK60m7x+4ogdmtWDhA1Hle
+ Yh4w==
+X-Gm-Message-State: AKwxyte11X3fBNd7XvIXUKt6jtctcdLjEkvXZzyC4v/8dnyDeI2oPcbX
+ M147M2z8hLcCP9rqg4nKXXDRAWFVFNA/VGAovgM=
+X-Google-Smtp-Source: ACJfBosUrDNOwp235n+KIbafemO+NL5IggOghpdT06QXXrtLPnsY7QyyKLQZP4dapl8bz1z5E7gj790JX5JlneusZSw=
+X-Received: by 10.31.82.194 with SMTP id g185mr9453546vkb.15.1515385364053;
+ Sun, 07 Jan 2018 20:22:44 -0800 (PST)
+MIME-Version: 1.0
+Sender: gmaxwell@gmail.com
+Received: by 10.103.85.148 with HTTP; Sun, 7 Jan 2018 20:22:43 -0800 (PST)
+From: Gregory Maxwell <greg@xiph.org>
+Date: Mon, 8 Jan 2018 04:22:43 +0000
+X-Google-Sender-Auth: uKnInfNbPuRfV2MoxYMaz6XRbxE
+Message-ID: <CAAS2fgR-or=zksQ929Muvgr=sgzNSugGp669ZWYC6YkvEG=H5w@mail.gmail.com>
+To: Pavol Rusnak <stick@satoshilabs.com>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Content-Type: text/plain; charset="UTF-8"
+X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+ DKIM_VALID, FREEMAIL_FROM,
+ 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
+Subject: [bitcoin-dev] Satoshilabs secret shared private key scheme
+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: Mon, 08 Jan 2018 04:22:45 -0000
+
+On Sun, Jan 7, 2018 at 3:16 PM, Pavol Rusnak via bitcoin-dev
+<bitcoin-dev@lists.linuxfoundation.org> wrote:
+> On 05/01/18 14:58, nullius via bitcoin-dev wrote:
+> I am currently drafting a new standard[1] which will allow also Shamir
+> Secret Scheme Splitting and there we disallow usage of a custom wordlist
+> in order to eradicate this mess. Will try to push this as BIP too once
+> we get it to the point we are OK with the contents.
+>
+> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
+
+This specification forces the key being used through a one way
+function, -- so you cannot take a pre-existing key and encode it with
+this scheme. The KDF it specifies is unconfigurable and fairly weak
+(20000xhmac-sha2-- which can be cracked at about 0.7M passwords a
+second on a single motherboard GPU cracker). The construction also
+will silently result in the user getting a different private key if
+they enter the wrong passphrase-- which could lead to funds loss. It
+is again, unversioned-- so it kinda of seems like it is intentionally
+constructed in a way that will prevent interoperable use, since the
+lack of versioning was a primary complaint from other perspective
+users. Of course, it fine if you want to make a trezor only thing,
+but why bother BIPing something that was not intended for
+interoperability? Even for a single vendor spec the lack of
+versioning seems to make things harder to support new key-related
+features such as segwit.
+
+The 16-bit "checksum" based on sha2 seems pretty poor since basing
+small checksums on a cryptographic hash results in a fairly poor
+checksum that is surprisingly likely to accept an errored string. Your
+wordlist is 10 bits and you have much less than 1023*10 bits of input,
+so you could easily have a 20 bit code (two words) which guaranteed
+that up to two errored words would always be detected, and probably
+could choose one which catches three words much more often 1:2^20
+(sipa's crc tools can help find codes like this).
+
+The metadata seems to make fairly little affordance to help users
+avoid accidentally mixing shares from distinct sharings of the same
+key. Is it the idea that this is the only likely cause of a checksum
+error? (1:2^16 chance of silently returning the wrong key seems kinda
+bad). -- I'm not sure much could be done here, though, since
+additional payload is precious.
+
+As an aside, your specification might want to give some better advice
+about the SSS since my experience virtually everyone gets it wrong in
+ways that degrade or destroy its properties e.g. many fail to generate
+the additional coefficients of the polynominal randomly which results
+in insecurity (see armory for an example). Oh, also, I believe it is
+normally refereed to as "SSS" (three S)-- four S is the name of a
+linux program for secret sharing.
+
+I'm happy to see that there is no obvious way to abuse this one as a
+brainwallet scheme!
+