diff options
author | Gregory Maxwell <greg@xiph.org> | 2018-01-08 04:22:43 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-01-08 04:22:45 +0000 |
commit | afa64edec109f174bb685407dda7e29a5508ca84 (patch) | |
tree | f5b000d442a2cb9e805e280cecb8d3f0a4c7474e | |
parent | 0114653e0475a98d5919dd6c8c21b9bc1b1b21f5 (diff) | |
download | pi-bitcoindev-afa64edec109f174bb685407dda7e29a5508ca84.tar.gz pi-bitcoindev-afa64edec109f174bb685407dda7e29a5508ca84.zip |
[bitcoin-dev] Satoshilabs secret shared private key scheme
-rw-r--r-- | 4a/e8120cc712a4bc72ea796a7b0975e5b9af7f0e | 121 |
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! + |