Shared / Multisig / Sharded IPNS Keys

[lidel]

This is a placeholder issue for tracking this topic.

Why

Publishing updates is important.
Being able to do it without dependency on censorable DNS, or paying for Gas to some blockchain grows the pie of use cases IPNS could serve.

Would be beneficial to the IPFS ecosystem if

• https://specs.ipfs.tech/ipns/ includes a golden path spec that is known to work, and has been reviewed by more than one dev
• devs had built-in support and examples in some reference libraries that work with boxo/ipns (go) or js-ipns
  • this allows for people to build things that resolve fine in regular clients, without waiting for implementations like Kubo

How (Feature Set)

TBD, topics to discuss:

• could it work with existing spec and legacy clients? (do not require custom signature)
• is the goal to have N sub-keys (shards) and only M required for publishing (M<=N, both >=1), or something else?
  • details tbd, the most common ask has been to require min. 2 sigs to ensure peer review before publishing IPNS Record update
• is there a way to replace shards with new ones?

TODO

• gather prior art from community 👈 we are here
  • please comment on this issue, ideally with working code or spec draft
  • an ideal MVP is to have a solution for the default key type (currently ED25519) what works with legacy IPNS clients (only publisher needs to support multisig)
  • If you feel confident in your solution, and want to discuss technical details, proposing IPIP in a PR is appreciated
• decide on feature set
• find a champion to open a PR with IPIP
• wait for IPNS: allow lean V2-only records #376 as it needs to happen before anything else

Prior Art

• threshold-ipns by @TheFrozenFire (ed25519 with threshold shards)

[TheFrozenFire]

Here are some materials worth reading:

Shamir's Secret Sharing: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
FROST: https://eprint.iacr.org/2020/852.pdf
A Go implementation of FROST: https://github.com/taurusgroup/frost-ed25519

In my proof of concept, I used an older implementation of threshold ed25519 signatures that uses two rounds with coordination. FROST is a better target, as it supports one-round threshold signatures as long as all parties behave correctly, or two-round if there are misbehaving parties.

If you're unfamiliar with Schnorr threshold signatures, the basic concept is that Shamir's Secret Sharing is used to split a private key into a specified number of shares, which are then distributed to different parties. You can think of these shares as each being a percentage of the bits of the whole private key, which can be used separately to produce a signature, and then those separate signature "shares" can be combined to form a signature that is indistinguishable from one produced directly with the whole private key.

The big advantage with this approach is that it's transparent during signature verification. You don't need special code to check threshold signatures, you can use the standard signature verification process. This is particularly useful for threshold IPNS, as it doesn't require peers to upgrade or be aware of the use of this scheme.

More key advantages of this approach are that additional shares of the private key can be generated, to add additional signers, and producing a signature only requires a "threshold" of shares - so if some people lose their shares, or are offline, or misbehave, a valid signature can still be produced so long as a quorum of signers cooperate. Schnorr threshold signatures are also very widely supported across curves, so if another signature scheme is added to IPFS, there's a good chance that a generic FROST implementation would be supported for that new scheme.

As disadvantages go for this approach, the major ones are complexity and newness. Schnorr threshold ed25519 has some proof of concept implementations out there, but they aren't battle-tested or audited, so far as I'm aware. Additionally, distributed key generation requires either a trusted coordinator who knows the whole private key and produces shares of it, or an MPC solution which decentralizes this role, but which doesn't currently exist to my knowledge.

[TheFrozenFire]

Answers in the context of Schnorr threshold signatures:

could it work with existing spec and legacy clients? (do not require custom signature)

Yes. Schnorr threshold signatures are transparent. They don't require special verifier behaviour

is the goal to have N sub-keys (shards) and only M required for publishing (M<=N, both >=1), or something else?

The terminology here is "shares" and "threshold". Arbitrarily large numbers of shares are supported.