add secp256k1 key type

[inverted-capital]

In the docs we are promised the secp256k1 key type being available, but it is not. Is there some error with doing this ?

[welcome[bot]]

Thank you for submitting this PR! A maintainer will be here shortly to review it. We are super grateful, but we are also overloaded! Help us by making sure that:

• The context for this PR is clear, with relevant discussion, decisions and stakeholders linked/mentioned.

• Your contribution itself is clear (code comments, self-review for the rest) and in its best form. Follow the code contribution guidelines if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment. Next steps:

• A maintainer will triage and assign priority to this PR, commenting on any missing things and potentially assigning a reviewer for high priority items.

• The PR gets reviews, discussed and approvals as needed.

• The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution. We are very grateful for your contribution!

[lidel]

Triage notes:

It happens to be listed there because IPFS nodes reuse libp2p keystore, and libp2p's specs for peerid list these key types:

        RSA = 0;
    Ed25519 = 1;
    Secp256k1 = 2;
    ECDSA = 3;

afaik no IPFS implementation uses anything other than RSA and Ed25519, so allowing it here may open interoperability issues, especially in the context of IPNS specificiation which uses the same keystore, but does not explicitly list which key types should be supported by minimal IPNS implementation.

I'm marking this is blocked until we clarify the specs, at least IPNS one.

---

@inverted-capital mind elaborating why do you want to use secp256k1? is there a practical need (if so, it is useful for us to understand it, so we can adjust specs, if it is generic enough) or did you fill it only for completeness?

[inverted-capital]

Thanks for the review @lidel - we are using the private key to provide other forms of digital signing, and the scp256k1 key fills application specific needs for us. We would like to reuse the IPFS key management systems, and we would like only one secret key in our application, so it is convenient if they are the same. We think some of our preference for this algorithm overlap with what is useful to IPFS, namely:

1. audited and dependency free JS implementation in @noble/secp256k1
2. Very fast signing performance - less than 0.5ms in our benchmarks
3. Short key and signature lengths making it easier on the eye when reading data that is signed in this fashion, or when reading the public keys.

So this pull request is not based on some feature of IPFS that we need, but our more general preference and trust the algorithm and implementation.