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

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: [email protected] <[email protected]> on behalf of Blumenthal, Uri - 0553 - MITLL <[email protected]>
Date: Sunday, December 29, 2024 at 14:40
To: [email protected] <[email protected]>
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://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 <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-MCmKBN63+BlAfugRpC6u6w@public.gmane.org <mailto:openssl-users+unsubscribe-MCmKBN63+BlAfugRpC6u6w@public.gmane.org>.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/BN0P110MB141960C4C230AF2B6D3D47C69008A%40BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM <https://groups.google.com/a/openssl.org/d/msgid/openssl-users/BN0P110MB141960C4C230AF2B6D3D47C69008A%40BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM?utm_medium=email&amp;utm_source=footer>. 



-- 
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-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/BN0P110MB1419C2019074C706506781BA9008A%40BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM.