-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The privateKey encoding for pure ml-dsa differs from the privateKey encoding for the ml-dsa part in composite ml-dsa-xxxx #466
Comments
Tagging @feventura fyi |
Based on the sample private key I found here: https://github.com/lamps-wg/draft-composite-sigs/blob/main/examples/MLDSA44-ECDSA-P256-SHA256.pvt I'd assume that the composite code is emitting the intended ASN.1 and the pure ML-DSA privateKey double octet string is "wrong"? |
Thanks very much for the thorough analysis and clear problem description, @pdb0102 ! As you have this tooling at hand, may I ask (just for confirmation/my own peace of mind) whether you can confirm that hybrid keys (both for KEM and sig algs) are formatted as you expect them? |
Thanks for the comment @pdb0102 , as you said the private key encode description on the MLDSA draft is vague. In the composite WG we already discussed about this topic and we think it should not contain the extra octet string layer. |
@baentsch I verified the following algorithms all issue a single octet string with the key: When trying to create a KEM key pair, OpenSSL gave me the finger:
This could be due to my configuration/compilation options/openssl.cfg, or due to my own ignorance doing something wrong, though. I've been focused on DSA and haven't played with KEM before. I did verify that openssl list -kem-algorithms does report all the OQS provided KEM algorithms. |
Thanks for thoroughly checking all composite sigs. I'd be primarily interested in how the hybrid sigs (classic alg name before PQ alg name) do as per
If you'd also want to check KEM encoding, then this first needs to be enabled when building |
I don't think so: As far as I know it's simply a concatenation of classic and PQ data that has its origins in a proof-of-concept implementation in the original OQS-OpenSSL111 fork that got moved to the oqsprovider in a way ensuring interoperability with the original code -- but no one ever bothered to do a spec for this, right @dstebila @christianpaquin ? |
Not a formal spec, AFAIK. It used to be documented on the 1.0.2/1.1.1 project wiki, but the latest description can be found in this paper. |
I've found a related problem, not sure if it should be a new issue or is related my original report. An EdDsa25519 key's private key is represented as OctetString inside OctetString (see https://www.rfc-editor.org/rfc/rfc8410#page-7) :
However, when the private key is part of a composite key, it is missing the CurvePrivateKey part, and the private key bytes are the data of the PrivateKey node. See the following screenshot that shows the end of the dump of a composite PQ key (visible is the end of the PQ key, and the full Ed key. The second half shows the dump of a regular Ed key PKCS#8 structure) Notice the missing second octet string in the first dump. ![]() This seems to be a bug in the composite code, since the ML spec ("Each element is a OneAsymmetricKey` [RFC5958] object for a component private key.") says the OneAsymmetricKey syntax is to be used. |
@feventura OK in your mind to close this? @pdb0102, did you get a chance to validate your problems are gone with #549 landed so we can close for good? |
I'm fine with this being closed, but I haven't had a chance to validate the changes. Once the IETF switched to storing seeds instead of generated keys and supporting pre-hash signing, and the upstream libs didn't support that yet, I figured I'd wait until things settle a bit and everyone in the chain has caught up. (I'm using oqsprovider to as interop test with my own code that creates and consumes PKIX data) |
Describe the bug
The privateKey encoding for pure ml-dsa differs from the privateKey encoding for composite ml-dsa-xxxx
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I would expect that, despite the ambiguity, the key is encoded the same way in both cases, either as a single octet string with raw key data, or a "constructed" octet string with another octet string and raw key data attached to that one. As it stands, it makes it hard to parse with the same method when parsing a composite key vs. pure key
Screenshots
If applicable, add screenshots to help explain your problem.
Environment (please complete the following information):
5.4.0-187-generic Build a module instead of a shared library. #207-Ubuntu SMP Mon Jun 10 08:16:10 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
OpenSSL 3.3.1 4 Jun 2024 (Library: OpenSSL 3.3.1 4 Jun 2024)
oqsprovider
name: OpenSSL OQS Provider
version: 0.6.2-dev
status: active
The text was updated successfully, but these errors were encountered: