Support of curve secp256k1

[lightsing]

I'd like to bring HPKE to web3 ecosystem. The curve secp256k1 is native on ethereum.

There's some existing js implementation of curve secp256k1 like secp256k1. I believe that this curve is capable of KEM in HPKE.

I'm asking for your opinion of adding support of secp256k1. Then I can start to work and submit a pr to this repo.

[dajiaji]

@lightsing thanks for considering using my library.

I believe that this curve is capable of KEM in HPKE.

I agree with you but all of the HPKE KEM algorithms must be standardized in IETF and registered to the HPKE IANA registry because the 2-byte HPKE KEM id space does not have any user-defined space.

I'm asking for your opinion of adding support of secp256k1. Then I can start to work and submit a pr to this repo.

At first, I'd like to know whether you or your team have plan to propose the new HPKE KEM using secp256k1 to IETF (such as DHKEM(secp256k1, HKDF-SHA256)). If you have it, your PR would be welcome. I will also be happy to help.

If you don't have the plan, I'd like to know the reason why you want to use not secp256r1 but secp256k1 in a bit more details. I know secp256k1 is used widely in blockchain domain but it's not for e2e encryption but for signing. I think you can use secp256r1 on the web3 world too.

Anyway, if the reason is clear to me, I think it is feasible for secp256k1 to be standardized in IETF and I can consider accepting your PR.

[lightsing]

Thanks for your clarification.

HPKE KEM algorithms must be standardized in IETF and registered to the HPKE IANA registry

I don't know this before. Thanks for the information.

In the previous design draft we choose ECIES. However, after doing more background investigation, we found HPKE is better. In our design, the public key is retrived by using ec recover of a on chain signature. Cuz the signature needs to be verified by other smart contracts, using different curve like secp256r1 means the contract needs to implement the verify algorithms which would cause increasing in gas cost comparing to calling precompiled contract of ecRecover.

We want to reuse the ethereum cryptography infrastructure. There might be some workaround to use standard HPKE. It would be best solution if HPKE supports secp256k1 natively.

[dajiaji]

Thanks for explaining the background of your request.

Okay.

If we add the note "experimental" to the secp256k1 KEM, it should be no problem to add it to the library. So please feel free to send me the PR. I will review it.

In addition, note that this library has been developed for various JS runtimes as many as possible using Deno development tools.

For making a PR, all you have to do is 1) install Deno and 2) make sure all tests pass with the following commands (See hpke-js/deno.json for details):

# tests for deno
deno task test
# tests for node.js
deno task dnt

Tests on web browsers are executed as the github action triggered by a pull request.

Sorry for the lack of documentation. If you have any questions, please do not hesitate to ask.

[lightsing]

May I ask more backgrounds question?

1. Would the 2-byte HPKE KEM id encoded in the "sealed" message? If not, it's possible to construct a CipherSuite using a KdfInterface implemenation?
2. Why all dependencies are bundled into bundles? Won't it be hard to manage and get security updates?

[dajiaji]

1. Would the 2-byte HPKE KEM id encoded in the "sealed" message?

No. But the kem_id is used both in the KEM process and the KDF process to derive a key.

2. Why all dependencies are bundled into bundles? Won't it be hard to manage and get security updates?

I've been thinking it's a problem too and I have to remove the bundles as soon as possible. This was the only way to deploy the hpke-js package that runs on node.js, deno, and web browsers. If the stablelib components in the bundles become pure ESM modules, I can remove the bundles.

[lightsing]

I purpose a refactor to :

• decouple KdfContext to seperated class like HkdfSha256Kdf & HkdfSha384Kdf & HkdfSha512Kdf
• decouple KemContext to a free combination of KemPrimitives and KdfInterface
• provide a freely way to construct CipherSuite from external implementation of KemContext and KdfInterface

[dajiaji]

KEM, KDF, and AEAD are not as loosely coupled as you might think; KdfContext contains information on KEM and AEAD for the internal process, and the KDF contained in KEM is determined by the KEM ID.

I will consider your suggestion, but please give me some time. I can at least understand your request to pass KemContext from the outside. I will consider it.

[dajiaji]

FYI: Remove bundles on #111.

[dajiaji]

@lightsing I've implemented DHKEM(secp256k1, HKDF-SHA256) experimentally and released it as v0.17.0. Could you try to use it and give me some feedback?

[lightsing]

it works as expected, thanks!