IANA codepoint for DHKEM-over-secp256k1

[kwantam]

Hi folks! Thanks for a really useful implementation.

I recently wrote a brief specification for HPKE using DHKEM over secp256k1, for which IANA has allocated the codepoint 0x0016. (I am sorry to report that the code point 0x0013 used in this project's experimental implementation was already allocated to a different DHKEM variant, as you can see from the link above.)

It would be great if this project could update its experimental DHKEM-over-secp256k1 implementation to use this codepoint! I'm happy to submit a pull request---please let me know if/how I can be helpful.

[dajiaji]

@kwantam Thank you too for writing the DHKEM-secp256k1 draft! In fact, I thought I'd had to write and submit the same draft for over half a year, so I'm very happy to see this.

See the Issue: https://github.com/dajiaji/hpke-js/issues/108

My @hpke/dhkem-secp256k1 was implemented before I saw your draft, so the codepoint was tentative and it also has another problem.

The problem was that my implementation adopted the compact key representation. Specifically, the secret/key lengths are defined as follows:

• Nsecret: 32
• Nenc: 33
• Npk: 33
• Nsk: 32

My suggestion is:

• First, add the compact version of the "DHKEM(secp256k1, HKDF-SHA256)"(0x0016), named "DHKEM(C-secp256k1, HKDF-SHA256)"(0x0017) to your draft proposal.
• Then, update hpke-js to support both of them.

What do you think?

In fact, I was considering creating issues on the github repo for your draft to (1) add support for the compact key representation and (2) update the KEM identifier to resolve the conflict with Deterministic Nonce-less Hybrid Public Key Encryption.

I'm happy to submit a pull request---please let me know if/how I can be helpful.

Your contributions are very welcome!

[kwantam]

Ah! I did not notice the compact vs non-compact issue. Thanks for pointing it out! (and sorry for the trouble...)

Completely happy to update the draft with the compact suite and to request another codepoint.

But I think I am probably missing something with regard the compact suites: what's the reason for them? Even if the suite specifies the use of an uncompressed code point, any public key can be sent over the wire in compressed form, then decompressed on the other side before being used for HPKE. Or is the idea that one uses an X-only ladder for ECDH, thereby saving both communication and the cost of point decompression?

Anyhow, I'll get back to you after I have updated the draft and requested another codepoint :)

[dajiaji]

But I think I am probably missing something with regard the compact suites: what's the reason for them? Even if the suite specifies the use of an uncompressed code point, any public key can be sent over the wire in compressed form, then decompressed on the other side before being used for HPKE.

I think the point is only in the enc (encapsulated key). In general, the protocol/application specs using HPKE use the enc as is (e.g., OHTTP, ODOH, ECH, MLS, COSE-HPKE). There are some cases for the protocols/apps to want the size of the enc keep small. In particular, it is very important for the COSE-HPKE (I'm one of the contributors to the spec) to keep the size of the enc small.

On the other hand, the non-compact version is still needed because there are some cases that a secp256k1 implementation does not support the compressed mode.

But it's just my opinion. Experts around CFRG/HPKE might have other opinions.

Anyway, I'm ready to follow the CFRG/HPKE decision.

[dajiaji]

@kwantam if you (and CFRG/HPKE community) decide to add the compact version of DHKEM-secp256k1, I'm willing to assist in making test vectors, so please feel free to ask me. I'd be happy to contribute to your draft :-)