feat: ipfs key sign|verify

[hacdias]

Closes #10230 by adding key sign|verify commands that facilitate offline key ownership proofs.

Notes:

• Output response is a bit different than the suggested in ipfs key sign|verify #10230 in order to match the remaining key/* endpoints. Similarly, Err field is not included as there's already a common way for the API to error, and that is not by adding a field to the output.
• In key/verify, the signature URL param is base64url encoded. None of the other things have to be encoded. The rest of the binary data goes in the body, so it does not relate to the issues in Pubsub subscription data encoding #7939.
• self is used as a default key. Happy to change this.
• Paid some debt by changing the current key tests to require. and assert.
• ⚠️ Helia test failures tracked on Slack.

[lidel]

Quick feedback on the code, will take it for a spin later today.

[Jorropo]

Could we devise a human readable combined scheme ?
$PEERID-$SIG ?
Can't use PEERID for RSA but else should be fine.

---

Else for ECC you can omit the public key entirely and do public key recovery (so we would print the signer's PeerID instead of saying correct or incorrect).

[hacdias]

Do you mean the signature to include the peer ID such that we do not need to provide the key?

[Jorropo]

Yes, forget the ECC thing it's not what we are trying to do right now.

Instead of -key Qmfoo -sig zMM... Qmfoo-zMM ?

[hacdias]

@Jorropo I see how that could be nice: a single signature that already includes the key, a single value to pass around. However, I think whoever is trying to verify the signature always knows which Peer ID they want to verify it against.

It would also make it harder to choose your own key by name to verify, no?

Just trying to see what would be best.

[Jorropo]

I don't understand what you mean, if it already contains the key, why do I need to specify the peer id ?

[lidel]

We want this API to accept key as a pet name (ipfs key list) or the actual libp2p-key (peerid).

Combining key and sig into a single arg makes the meaning of mfoo-mbar-mbuz ambiguous because we allow - in pet names AND mbase64url:

• is the key name mfoo or mfoo-mbar?
• is the signature mbar-mbuz or mbuz? (mind that - is part of base64url alphabet)

Someone would have to invent additional syntax or parsing rules for this.
My suggestion is to avoid sinking unnecessary time into answering these questions and writing tests for all edge cases – keep it simple, use separate params.

[lidel]

Lgtm, we marked these new commands as experimental so it should be good enough to ship in Kubo 0.25.0-rc1, allowing Brave to start designing/prototyping with this.

Demo of HTTP RPC wire format

$ ipfs key sign --enc=json CHANGELOG.md | jq
{
  "Key": {
    "Name": "self",
    "Id": "k51qzi5uqu5dggn4h373qmumq7le1gq3c72pdqd1weqagz4i19xfmvuuvyj2rt"
  },
  "Signature": "u6TLv2lQr-O168Xcu9mC1QoXswb64mdVwz9wsqA9ttW0BI2W5_AAOJglm444xpHGTfwBhrew8BQdovX30-Br7Bw"
}

$ ipfs key verify --enc=json --signature u6TLv2lQr-O168Xcu9mC1QoXswb64mdVwz9wsqA9ttW0BI2W5_AAOJglm444xpHGTfwBhrew8BQdovX30-Br7Bw CHANGELOG.md | jq
{
  "Key": {
    "Name": "self",
    "Id": "k51qzi5uqu5dggn4h373qmumq7le1gq3c72pdqd1weqagz4i19xfmvuuvyj2rt"
  },
  "SignatureValid": true
}