Re: Q: creating CSR for encryption-only cert?

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

Thank you - and it’s great to see that 100% PQ Key Exchange is working with the existing code (I assume - based on liboqs?). 

But generating signature is not acceptable in my use case, which is why we settled on a KEMTLS-like approach. Or, conceptually, like MQV/HMQV. Authenticating the peer implicitly by having its long-term (certified) public key participating in the Key Exchange. 

I fully realize that the current TLS-1.3 does not support this kind of Key Exchange. Which is fine, because we’re not using TLS. :-)

Thanks

Regards,

Uri

On Oct 3, 2022, at 17:02, Mark Hack <markhack@xxxxxxxxxxxx> wrote:



In this case you need to look at certificate / signature generation separately from the key exchange.  In classical terms, I can have anRSA key with a RSA-SHA256 signature and use DHE elliptic curves to exchange a secret without knowing the elliptic curve public private key pair.

For example to use Dilthium public/private keys and a Dilithium signature , you can use the following to generate a csr ( or self sign):

openssl req -new -newkey dilithium2  -keyout qsc.key -config openssl.cnf -nodes 

After you have the signed certificate, TLS uses that certificate but specifies Kyber for the key exchanges.

I self signed a dilithium certificate and started a server using:

openssl s_server -cert  dilithium.crt -key dilithium.key -groups kyber768 

Then connected with a client using:

openssl s_client -connect 127.0.0.1:4433  -groups kyber768

This return a good connection:

No client certificate CA names sent

Peer signature type: Dilithium2

Server Temp Key: kyber768

---

SSL handshake has read 7911 bytes and written 1589 bytes

Verification error: self signed certificate

---

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

Server public key is 10496 bit

Regards

Mark Hack

On Mon, 2022-10-03 at 15:11 +0000, Blumenthal, Uri - 0553 - MITLL wrote:

TLDR;

Need to create a CSR for a key pair whose algorithm does not allow signing (either because it’s something like Kyber, or because restriction enforced by HSM). How to do it?

 

There are several use cases that require certifying long-term asymmetric keys that are only capable of encryption/decryption – but not signing/verification. That could be either because the algorithm itself does not do signing, or because the private key is generated and kept in a secure hardware that enforces usage restriction.

 

CSR is supposed to be signed by the corresponding private key to prove possession. Obviously, it cannot be done with a key such as described above. How is this problem addressed in the real world?  With AuthKEM and KEMTLS, how would these protocols get their certificates?

 

Thanks!

--

V/R,

Uri Blumenthal                              Voice: (781) 981-1638 

Secure Resilient Systems and Technologies   Cell:  (339) 223-5363

MIT Lincoln Laboratory                     

244 Wood Street, Lexington, MA  02420-9108      

 

Web:     https://www.ll.mit.edu/biographies/uri-blumenthal

Root CA: https://www.ll.mit.edu/llrca2.pem

 

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

 

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