Support secp256k1/k256 Koblitz curve

[iameli]

Cross-posting trussed-dev/trussed#172

The NitroKey 3A NFC shop advertises support for Koblitz curves:

Elliptic curves: NIST P-256, P-384, P-521 (secp256r1/prime256v1, secp384r1/prime384v1, secp521r1/prime521v1), Ed25519/Curve25519, Koblitz (192-256 bit), brainpoolP256r1, brainpoolP384r1, brainpoolP512r1

But I bought one and it doesn't work.

pkcs15-init \
  --delete-objects privkey,pubkey \
    --id 01 \
    --store-private-key secp256k1.p12 \
    --format pkcs12 \
    --auth-id 3 \
    --verify-pin \
    --pin 12345678

Using reader with a card: Nitrokey Nitrokey 3 [CCID/ICCD Interface] 00 00
NOTE: couldn't find privkey 01 to delete
NOTE: couldn't find pubkey 01 to delete
Deleted 0 objects
Importing 1 certificates:
  0: /C=US/ST=CA/L=Somewhere/O=Aquareum/CN=Cert Testing
Failed to store private key: Key length/algorithm not supported by card

My understanding is that such support would have to be implemented in this repo, is that right? Could we get support so I don't have to return mine? <3

[iameli]

Oh interesting, that's not actually on the shop anymore. How about that 😂

[daringer]

yes, that's correct - thanks for pointing this out, this was an accidental copying error which survived quite long - there are various new crypto algorithms available in the test release right now, but this doesn't include Koblitz (yet?). I will keep this open to crosscheck how many people would be interested.

Please +1 this comment to vote for Koblitz curves in NK3

[daringer]

hey @iameli - could you share with us which actual use-cases you are aiming for? Is there some tooling around crypto to support OpenPGPCards or did you maybe just wanted this as a hardware-key backup?

[iameli-streams]

@daringer I've got two!

1. I work a lot with the Livepeer Network, which is a decentralized video transcoding network built on the Ethereum blockchain. Long story short this involves getting useful video processing work -- say, turning 4k video into 1080p video -- by untrusted actors ("orchestrators") somewhere out there in the world. (More info here.) How can you trust work done by random people, you ask? How do you know the work is reliable? There are a few answers to that question, but one of them is that all of the work is signed by an Ethereum key provided by the orchestrator. If an orchestrator cheats -- for example, ingesting 4k video and returning empty black 1080p frames -- you could construct a proof that they did a bad job and get some of their money taken away.

To make that happen, orchestrators need to be constantly signing video segments with their Ethereum keys, sometimes one per second when livestreaming. Most crypto wallets, like Ledger and Trezor, are designed for human interaction and don't allow for automated signing without a user manually approving on the hardware wallet. So right now those private keys are just sitting on the hard drive on the orchestrators' servers, which isn't ideal. For that reason, I'm looking at implementing PKCS#11 signing support in the Livepeer node, and I've been shopping around for security keys that support secp256k. The Nitrokey HSM 2 works well, as does the YubiHSM 2. But getting Nitrokey 3 support would make it by far the best option.

2. These days I'm working on building Aquareum, which is decentralized livestreaming software built using a lot of the same technologies. One of the things we're attempting to build is livestreaming for Farcaster and Bluesky's AT Protocol; both of these require secp256k support. For the livestreaming use case that means signing every one-second video segment with an Ethereum key. Once again we're currently storing keys on the streaming device themselves but I'd love to recommend to our users that they use hardware security. Again, if it were supported, Nitrokey 3 would be by far the best available option.

Let me know if you have any other questions!

[daringer]

Uh thanks for the details, that sounds interesting - will check. In the meantime we've also checked how far away secp256k is and good news: not too far. Don't want to promise an ETA, but but expect it to be available sooner than later...