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

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

I’m getting a very confusing problem: when I invoke “openssl” from the Makefile by “make”, it fails. But when I copy exactly the same command line into a Terminal (aka, shell), it works perfectly fine:

 

$ make

openssl genpkey -algorithm mlkem1024 -outform PEM -out prkey-kem.pem -outpubkey pubkey-kem.pem

Error initializing mlkem1024 context

C0642D48F87F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:355:Global default library context, Algorithm (mlkem1024 : 0), Properties (<null>)

make: *** [gen_kem_keys] Error 1

$ openssl genpkey -algorithm mlkem1024 -outform PEM -out prkey-kem.pem -outpubkey pubkey-kem.pem

$ ll prkey-kem.pem 

-rw-------  1 ur20980  staff  6506 Dec 29 15:10 prkey-kem.pem

$ 

 

What’s wrong???

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

 

I was a shepherd to fools

Causelessly bold or afraid.

They would not abide by my rules.

Yet they escaped. For I stayed.

                                                  R. Kipling “Epitaphs of the War. Convoy Escort”

 

 

 

From: openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> on behalf of Blumenthal, Uri - 0553 - MITLL <uri@xxxxxxxxxx>
Date: Sunday, December 29, 2024 at 14:40
To: openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx>
Subject: Re: [EXT] Re: How to generate ML-KEM key-pair?

> 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"?

Perhaps the below will help?

    https://docs.google.com/presentation/d/1xU2-U_6uUW4gB3j_v7EQC81t1RZ_slHyY_91MLlMDEg/edit#slide=id.g2b4be0ee06d_0_0
    https://www.youtube.com/watch?v=OuH4vwmzP_o

 

Oh, it absolutely does – thank you!

 

$ openssl x509 -new -key prkey-dsa.pem -out dsa-ca.pem -force_pubkey pubkey-dsa.pem -set_issuer "/CN=Experimental_PQ_CA" -set_subject "/CN=Experimental_PQ_CA" -days 360 -extfile <(printf "basicConstraints=critical,CA:true,pathlen:1\n")

$ 

$ openssl x509 -new -key prkey-dsa.pem -force_pubkey pubkey-kem.pem -out kem-cert.pem -subj "/CN=PQ_KEM_Entity" -set_issuer "/CN=Experimental_PQ_CA" -days 360 -extfile <(printf "keyUsage=keyEncipherment\n")

Warning: Signature key and public key of cert do not match

$ 

$ openssl verify -show_chain -CAfile dsa-ca.pem kem-cert.pem 

kem-cert.pem: OK

Chain:

depth=0: CN=PQ_KEM_Entity (untrusted)

depth=1: CN=Experimental_PQ_CA

$ 

$ 

$ openssl verify -show_chain -trusted dsa-ca.pem kem-cert.pem 

kem-cert.pem: OK

Chain:

depth=0: CN=PQ_KEM_Entity (untrusted)

depth=1: CN=Experimental_PQ_CA

$

 

The above – worked, thanks!

 

Perhaps you could clue me in regarding “(untrusted)” in the above?

 

Also, am I correct to assume that if I choose to prepare extension templates, those files would look like:

For CA template (ca-template.txt):

basicConstraints = critical, CA:TRUE, pathlen:1

keyUsage = critical, digitalSignature, nonRepudiation, keyCertSign

 

For KEM cert template (kem-template.txt):

basicConstraints = critical, CA:FALSE

keyUsage = critical, keyEncipherment

 

and I’d be able to refer to them in the “openssl x509 …..” command above as “-extfile kem-template.txt”?

 

If the format of the above files should be more elaborate – I’d appreciate being “clued in”!

 

> 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.

Then, assuming it still makes sense for the payload to be an X.509
certificate, and not something much simpler (like a delegated
credential), you should be all set.

 

Unless I’m mistaken, delegated credentials are supposed to have very short lifetime, and be “renewed” (re-“retrieved”) quite often. My use case suggests (reasonably) long-term certificates, whose main difference from the traditional PKI for TLS or IPsec is that they’re used in implicit authentication, rather than for generating dynamic signatures during the handshake.

 

Perhaps, I need to understand “delegated credentials” better. Though there’d be a question of whether my infrastructure is ready and willing to embrace that concept, and the workflows it would require…

 

Thank you!!

--
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/BN0P110MB141960C4C230AF2B6D3D47C69008A%40BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM.

--
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/BN0P110MB1419C2019074C706506781BA9008A%40BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM.

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