ipfs key sign|verify

[lidel]

This is a placeholder issue for implementing commands that allow the end user to sign arbitrary bytes with one of the keys (over CLI and RPC).

Constraints

• Allow for signing of arbitrary bytes without worrying they will get mangled when sent over HTTP RPC At /api/v0/
  • We had this problem in ipfs pubsub and we ended up base-encoding the payload to avoid mangling in transit (fix: multibase in pubsub http rpc #8183)
  • Suggestion: do the same, and require binary blobs such as signature or <data> sent on the wire to be encoded in multibase64

Command design

    ipfs key sign <data>          - Generates a signature for the given data with a specified key
    ipfs key verify <data>        - Verify that the given data and signature match
    
    -k, --key       - string, key name to use for signing
    -s, --signature - string, multibase-encoded signature to verify
    -b              - string, multibase encoding of the output

To remove any ambiguity, we should use JSON output:

$ echo -n "text to sign" | ipfs key sign -k keyname
{ 
  "Key": "cidv1-libp2p-key",
  "Signature": "[multibase64url-encoded-signature]",
  "Err": "[null-or-string-error]"
}

for verify also allow passing third-party keys as cidv1 with libp2p-key codec:

$ echo -n "text to sign" | ipfs key verify -k keyname-or-cid -s signature-in-multibase
{
  "Key": "cidv1-libp2p-key",
  "SignatureValid": true|false,
  "Err": "[null-or-string-error]" // used when passed key does not exist or signature/key bytes could not be decoded
}
 

Use cases

• Creating cryptographic link between IPFS Node identity OR IPNS Name and third party systems
  • IPNS website owner being able to prove ownership
    • signature can be included in immutable snapshot, pointing at IPNS address with updates/latest version
    • unlocks participation in Brave Rewards (Add ability to prove IPNS content ownership with libp2p-key brave/brave-browser#14774)
    • allows experimentation in dapps without having to change IPNS spec (IPNS: support Ethereum wallet signing specs#323 (comment))

[Jorropo]

This is tricky, digital signatures are harder to use than it looks, for example some ethereum applications would sign arbitrary bytes and attackers could inject theses to be let's say an ethereum transaction.

Then there were the development of https://eips.ethereum.org/EIPS/eip-712 which adds enough salting that if you fuck it up this is limited to one dapp, not complete account take over.

Given here keys don't hold money this is less of concern but overall without knowing how the user is gonna use them this seems a bit reckless.
If anything, if we really need plain bytes signatures, I think it's better if users extract the private key and handle the signature themselves, this sounds dodgy, but that because signing arbitrary bytes is.

[lidel]

Before filling this issue, I did some threat modeling and RPC /api/v0/key/export does not work over HTTP, only works in offline mode where ipfs has direct access to the repo filesystem at IPFS_PATH.

• This means it is not possible for a dapp granted limited access to RPC (Sandboxing for MFS, Keys, IPNS #10229) to export a key over HTTP Kubo RPC and do signing. Key export requires physical access to the disk.

You have a fair point about user-friendly signing methods always being prefixed:

• Web API exposed by Metamask and others uses \x19Ethereum Signed Message:\n (IPNS: support Ethereum wallet signing specs#323 (comment))
• IPNS signatures prefix signed bytes with ipns-signature: (step 5 here)

If anything, if we really need plain bytes signatures

For real use cases like Brave and dapps/extensions with scoped RPC access (#10229), we don't:
What we need is a way to a link between IPNS key owner and some other system can be confirmed fast and offline, without publishing something and having to resolve the IPNS record first.

We could restrict ipfs key sign|verify commands to payloads prefixed with something unique like libp2p-key signed message:, making it portable between systems if required, but remove the signature-reuse problem.

Thoughts?

[Jorropo]

The prefix is good, it gets 80% of the safety here.
Ideally you also want a scope per usecase (and not bestow the application to do that, since some people just don't).

So something like this hash("libp2p-key signed message:"+hash(brave/ipns-proof-challenge)+hash(random_salt)+hash(domain)) looks good to me at first glance.