open-quantum-safe / openssl

UNSUPPORTED Fork of OpenSSL 1.1.1 that includes prototype quantum-resistant algorithms and ciphersuites based on liboqs PLEASE SWITCH TO OQS-Provider for OpenSSL 3
https://openquantumsafe.org/
Other
286 stars 124 forks source link

Trying to use hybrid X.509 certificate for CMS encrypt operations. errors ensue. #455

Closed igorbarshteyn closed 1 year ago

igorbarshteyn commented 1 year ago

Using OQS OpenSSL 1.1.1 Stable cloned and built 2 days ago.

I successfully generated a p521_dilithium5 certificate and private key with the command:

./oqs-openssl/apps/openssl req -x509 -outform PEM -new -newkey p521_dilithium5 -keyout p521_dilithium5.key -out p521_dilithium5.pem -nodes -subj "/CN=IgorBarshteyn" -days 365 -config ./oqs-openssl/apps/openssl.cnf Generating a p521_dilithium5 private key writing new private key to 'p521_dilithium5.key'

Now, when trying to use this X.509 certificate to encrypt a file (with the public key in the cert), so that I can decrypt with the private key later, I receive the below errors:

./oqs-openssl/apps/openssl cms -encrypt -aes256 -in testfile.txt -binary -outform DER -out testfile.enc p521_dilithium5.pem 140248692602688:error:1012F040:elliptic curve routines:pkey_oqs_ctrl:fatal:crypto/ec/oqs_meth.c:1124: 140248692602688:error:1012F040:elliptic curve routines:pkey_oqs_ctrl:fatal:crypto/ec/oqs_meth.c:1124: 140248692602688:error:2E0AB06F:CMS routines:cms_env_asn1_ctrl:ctrl failure:crypto/cms/cms_env.c:75:

Is using CMS encrypt functionality using hybrid keys not supported, or am I issuing the command incorrectly?

Please advise. Thank you!

--Igor

baentsch commented 1 year ago

Thanks for this report. As I may be wrong in my understanding of CMS, please pardon the following question: Isn't this operation meant to do encrypt/decrypt operations using the PQ key (part)? So shouldn't this failure already appear with a plain PQ key and not only with a hybrid key/cert?

PQ encrypt/decrypt is not supported by the PQ APIs: They only support sign/verify and KEM encaps/decaps. See e.g., https://openquantumsafe.org/post-quantum-crypto.html. @dstebila : Didn't we want to mention this (limitation/difference to classic crypto) explicitly somewhere (or didn't I find this)? Edit/Add: Similar discussion at https://github.com/orgs/open-quantum-safe/discussions/1464

igorbarshteyn commented 1 year ago

Hi @baentsch! I suspected there may be no support, but I wanted to give it a try anyway. CMS has an envelope mode where it encrypts an input file with a symmetric cipher (e.g. aes256), then encrypts the resulting symmetric key with the public key from the recipient's certificate and builds an encrypted message file from both outputs. That's the mode I was trying. I'll give the plain PQ key a try too, just to test it out, but I suspect the result would be the same.

It'd be nice to have PQ public-private key encryption capabilities for messages as an alternative to, say, GPG with RSA or ECC, so that messages could be exchanged securely in a threat environment where quantum computers are common.

I appreciate your prompt response!

igorbarshteyn commented 1 year ago

Also, I realize that a signature algorithm may not be the best route here - using Kyber is probably better because it's designed for encryption of symmetric keys. There's an IETF document on Kyber in X.509 certificates (https://www.ietf.org/id/draft-ietf-lamps-kyber-certificates-01.html) from end of March of this year...

baentsch commented 1 year ago

Yup, KEMs in general seem a better approach. And here's the probably most relevant spec proposal for this: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-kyber. AFAIK far from standardization let alone implementation (in openssl). So I'm afraid we need to close this here -- but possibly move to oqs-provider (as and when CMS-KEM gets implemented in OpenSSL3 -- it surely never will in OpenSSL111).

FWIW, as per https://github.com/IETF-Hackathon/pqc-certificates/issues/26#issuecomment-1381237376 BouncyCastle should have support for this.

baentsch commented 1 year ago

Closing due to inactivity. Reopen with new information (or move to oqs-provider if topic becomes "hot").