From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BE424FE6 for ; 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 ; Mon, 8 Jan 2018 04:22:44 +0000 (UTC) Received: by mail-vk0-f51.google.com with SMTP id o16so6591331vke.12 for ; 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 Date: Mon, 8 Jan 2018 04:22:43 +0000 X-Google-Sender-Auth: uKnInfNbPuRfV2MoxYMaz6XRbxE Message-ID: To: Pavol Rusnak , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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!