Ignacio Berrozpe [ARCHIVE] on Nostr: 📅 Original date posted:2018-09-24 📝 Original message:Hi Andrew Please allow me ...
📅 Original date posted:2018-09-24
📝 Original message:Hi Andrew
Please allow me to comment on your work, as I happened to publish an
article 5 months ago proposing SSS to split bitcoins private keys into
shares that could be encoded directly using BIP-0039 mnemonic words. While
cryptographically much simpler than your proposal, the proposal had the
characteristic that it could be applied directly to existing private keys
backups, by splitting the keys into SSS shares that could benefit from the
existing BIP-0039 mnemonic to encode directly the shares. I thought it
would be a simple path for hardware wallets providers such as Trezor into
providing a better/more secure alternative the existing BIP-0039 privatekey
backups of 24 words.
The article can be found here, and I've enclosed a simplified version
https://privatekeys.org/2018/04/24/k-of-m-private-key-generation-and-backup-in-bitcoin-wallets/
Mind two questions? Your proposed work provides a way to split the
pre-secret into SSS shares, a format of encoding the shares, and finally
several methods to derive the master secret from the pre-secret. Would you
envision standarizing these different topics under the same proposal? Also,
have you thought of a way to deal with the existing legacy privatekeys
already encoded into BIP-0039, or stored in other formats, and how to
migrate them securely into a schema of encoded SSS shares?
Best regards
Ignacio Berrozpe
On Fri, Sep 21, 2018 at 8:18 PM Andrew Kozlik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello everyone,
>
> We are currently writing a new specification for splitting BIP-32 master
> seeds into multiple mnemonics using Shamir's secret sharing scheme. We
> would be interested in getting your feedback with regard to the
> high-level design of the new spec:
> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
> Please focus your attention on the section entitled "Master secret
> derivation functions", which proposes several different solutions. Note
> that there is a Design Rationale section at the very end of the
> document, which should answer some of the questions you may have. The
> document is a work in progress and we are aware that some technical
> details have not been fully specified. These will be completed once the
> high level design has been settled.
>
> Thanks,
>
> Andrew Kozlik
> TREZOR Team
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180924/9bc30814/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KofM Private Key Generation and Backup in Bitcoin Wallets _ Submit.rtf
Type: application/msword
Size: 1074372 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180924/9bc30814/attachment-0001.doc>;
📝 Original message:Hi Andrew
Please allow me to comment on your work, as I happened to publish an
article 5 months ago proposing SSS to split bitcoins private keys into
shares that could be encoded directly using BIP-0039 mnemonic words. While
cryptographically much simpler than your proposal, the proposal had the
characteristic that it could be applied directly to existing private keys
backups, by splitting the keys into SSS shares that could benefit from the
existing BIP-0039 mnemonic to encode directly the shares. I thought it
would be a simple path for hardware wallets providers such as Trezor into
providing a better/more secure alternative the existing BIP-0039 privatekey
backups of 24 words.
The article can be found here, and I've enclosed a simplified version
https://privatekeys.org/2018/04/24/k-of-m-private-key-generation-and-backup-in-bitcoin-wallets/
Mind two questions? Your proposed work provides a way to split the
pre-secret into SSS shares, a format of encoding the shares, and finally
several methods to derive the master secret from the pre-secret. Would you
envision standarizing these different topics under the same proposal? Also,
have you thought of a way to deal with the existing legacy privatekeys
already encoded into BIP-0039, or stored in other formats, and how to
migrate them securely into a schema of encoded SSS shares?
Best regards
Ignacio Berrozpe
On Fri, Sep 21, 2018 at 8:18 PM Andrew Kozlik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello everyone,
>
> We are currently writing a new specification for splitting BIP-32 master
> seeds into multiple mnemonics using Shamir's secret sharing scheme. We
> would be interested in getting your feedback with regard to the
> high-level design of the new spec:
> https://github.com/satoshilabs/slips/blob/master/slip-0039.md
> Please focus your attention on the section entitled "Master secret
> derivation functions", which proposes several different solutions. Note
> that there is a Design Rationale section at the very end of the
> document, which should answer some of the questions you may have. The
> document is a work in progress and we are aware that some technical
> details have not been fully specified. These will be completed once the
> high level design has been settled.
>
> Thanks,
>
> Andrew Kozlik
> TREZOR Team
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180924/9bc30814/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KofM Private Key Generation and Backup in Bitcoin Wallets _ Submit.rtf
Type: application/msword
Size: 1074372 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180924/9bc30814/attachment-0001.doc>;