What is Nostr?
Tamas Blummer [ARCHIVE] /
npub1cce…x8m8
2023-06-07 15:16:35
in reply to nevent1q…n0xv

Tamas Blummer [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-29 📝 Original message:I had Matt's answer ...

📅 Original date posted:2014-03-29
📝 Original message:I had Matt's answer already, see below, but then I recognized that the group was not cc:-d, so I repeat:

It would help on the user interface to include into individual shares:

1. Number of shares needed
2. A few bytes fingerprint of the secret so shares that likely belong together can be identified.

I wonder how others weight security vs. usability in these questions.

Regards,

Tamas Blummer
http://bitsofproof.com

On Saturday, 29 March 2014, at 6:22 pm, Tamas Blummer wrote:
> It might make sense to store the number of shares needed. I know it is not needed by math, but could help on user interface to say,
> you need x more shares..

I intentionally omitted that information because it's a security risk. If an adversary gains control of one share and can see exactly how many more shares he needs, he may be able to plan a better attack. If he is clueless about how many shares he needs, then he may not be able to execute an attack at all because he may not know whether his information about what shares exist and where is complete.

On 29.03.2014, at 17:54, Matt Whitlock <bip at mattwhitlock.name> wrote:

> On Saturday, 29 March 2014, at 9:44 am, Tamas Blummer wrote:
>> I used Shamir's Secret Sharing to decompose a seed for a BIP32 master key, that is I think more future relevant than a single key.
>> Therefore suggest to adapt the BIP for a length used there typically 16 or 32 bytes and have a magic code to indicate its use as key vs. seed.
>
> I have expanded the BIP so that it additionally applies to BIP32 master seeds of sizes 128, 256, and 512 bits.
>
> https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
> The most significant change versus the previous version is how the coefficients of the polynomials are constructed. Previously they were SHA-256 digests. Now they are SHA-512 digests, modulo a prime number that is selected depending on the size of the secret.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/7d985b90/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/7d985b90/attachment.sig>;
Author Public Key
npub1ccegg9n9lnx6huppxg43m95488yur7pfemkn3pz0agjws5ffvtts0ex8m8