Comments (4)
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 :)
from hpke-js.
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.
from hpke-js.
@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 :-)
from hpke-js.
@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: #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!
from hpke-js.
Related Issues (20)
- Add fastly/js-compute to supported JavaScript runtimes.
- Add JWK support to importKey. HOT 3
- Support public key encoding and decoding at the suite HOT 6
- Strange interaction with vercel/ncc HOT 1
- Publish a new npm hpke-js pkg version
- Drop support for egg.
- Add package.json.
- Replace chacha20poly1305 with noble/ciphers
- Add support for X25519Kyber768
- Question about the JS module size HOT 2
- Fix docs for deno.land. HOT 1
- suite.kemContext is not a function HOT 2
- We are using bidirectional encryption support and cannot find way to re-implement it in v1.2.3 HOT 3
- Suggestions for Browser Extension Manifest V3 HOT 3
- Expose HKDFs as utilities HOT 1
- Cannot find module './src/cipherSuite.js' HOT 5
- Consider adding ML-KEM HOT 1
- [email protected] does not work.
- How to import public keys? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hpke-js.