Matt Whitlock [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-29 📝 Original message:On Saturday, 29 March ...
📅 Original date posted:2014-03-29
📝 Original message:On Saturday, 29 March 2014, at 4:51 am, Matt Whitlock 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.
>
> Master keys of 32 bytes would work as-is, as ordinary private keys are also 32 bytes. Secrets of other lengths could be supported if the function that generates a[i] from a[i-1] (which is presently SHA-256) were replaced with a function having parameterized output length, such as scrypt.
Actually, secrets with value greater than secp256k1_N cannot be supported because the modular arithmetic would destroy them. But any secret smaller than 256 bits would be fine.
📝 Original message:On Saturday, 29 March 2014, at 4:51 am, Matt Whitlock 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.
>
> Master keys of 32 bytes would work as-is, as ordinary private keys are also 32 bytes. Secrets of other lengths could be supported if the function that generates a[i] from a[i-1] (which is presently SHA-256) were replaced with a function having parameterized output length, such as scrypt.
Actually, secrets with value greater than secp256k1_N cannot be supported because the modular arithmetic would destroy them. But any secret smaller than 256 bits would be fine.