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 <markh...@markhack.com> 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 >>
smime.p7s
Description: S/MIME cryptographic signature
