Re: [EXT] Re: How to generate ML-KEM key-pair?

["Blumenthal, Uri - 0553 - MITLL" <uri@xxxxxxxxxx>]

On Sun, Dec 29, 2024 at 04:29:32AM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> $ openssl pkeyutl -encap -pubin -inkey pubkey-kem.pem -secret ss1.dat -out ctext.dat
> $ openssl pkeyutl -decap -inkey prkey-kem.pem -out ss2.dat < ctext.dat

The encap/decap interface isn't quite right.  I'm changing it in:

    https://github.com/openssl/openssl/pull/26281

The "-decap" option will also write the shared-secret to the file
specified with "-secret", rather than "-out", and the "-secret" file
permissions will be owner-only for both encap and decap.  The '-pubin'
option for '-encap' will become implicit.

 

Excellent, thanks – it would make much more sense that way.

For backwards compatibility, the "-decap" option will default to using
the "-out" file (which then may not have the right permissions). I am
not inclined to encourage the use of the fallback interface by
documenting its use. 

 

😉

> Question: could you help me, using the two key-pairs above, create
> (a) a self-signed certificate for the ML-DSA-87 pubkey with ML-DSA-87
>     as signature algorithm, and SHA384 as hash, and

Presumably, (a) just works with in the usual way:

    openssl req -x509 -new \
        -key somekey.pem \
        -out somecert.pem \
        -subj "/CN=somehost" -days 60 \
        -extfile <(printf '...extensions...\n')

 

Thanks! Indeed, the above works. Is there a good (“convenient” 😉) example of a text file that contains extensions (a) suitable for a CA (that would be for the ML-DSA “keyholder”), and (b) suitable for a TLS or IPsec peer (that would for the ML-KEM cert holder)? Something in a format “ready-for-OpenSSL-consumption”?

> (b) a certificate for the above ML-KEM-1024 public key signed by the
>     above ML-DSA-87 key?  (Getting CSR and all the arguments seems to be a
>     problem for me.)

It isn't possible to create a CSR for ML-KEM, because CSR's needs to be
signed by the subject key, but ML-KEM keys can't sign.

 

Yes…

While you can create a certificate with an ML-KEM public key in it, you
probably don't want to. 

 

Respectfully disagree. I absolutely do want to create a certificate with an ML-KEM public key in in, among other reasons – because I intend to use it in an Authenticated Key Exchange (currently working on an RFC that defines this protocol, spoiler alert – it’s named “PQuAKE”). It’s designed in the spirit of MQV/HMQV, KEMTLS, and such.

 

Since the key can't do any of the things that one expects a public key in a certificate to do.

 

What might those things be? For me the only value/benefit I expect from this certificate is the “attestation” to the “belonging” and the validity period of the ML-KEM public key it contains (probably a few other details – but, e.g., one thing I do not need it to do is signing anything).

 

    $ openssl x509 -new -key /tmp/ed.pem -force_pubkey /tmp/ml-512-pub.pem \
        -out /tmp/ml-cert.pem -subj / -days 30 -extfile <(
                printf "keyUsage = keyEncipherment\n'
                printf "subjectKeyIdentifier = none\n"
            )
    Warning: Signature key and public key of cert do not match

 

Thank you!! Yes, this works!

Perhaps you're looking to implement KEMTLS "delegated credentials"?

 

Well, not exactly, not really – but I can see the similarity. 😉

For these the ML-DSA key signs a TLS "delegated credential" blob,
which is then only useful with KEMTLS, since again, the subject key
can't do signing.

 

Since my use case is similar to KEMTLS, I’m perfectly happy with being unable to sign with the subject key. Implicit authentication is all I need here.

What exactly is your use-case for an ML-KEM SPKI in an an X.509
certificate?

 

Not to bore the audience with nitty-gritty details – it’s similar to PQ variant of MQV. Avoid explicit dynamic signatures as much as possible, rely upon implicit authentication and static certificates, prefer the cost of two extra KEM operations to the cost of two signatures.

 

Thanks!

--
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe@xxxxxxxxxxx.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/BN0P110MB1419433BE45049D823A2AFCA9008A%40BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM.

Attachment: smime.p7s
Description: S/MIME cryptographic signature