Add Post-Quantum Cryptography (PQC) Algorithms for TLS 1.3 Key Exchange

[yuhh0328]

Description: Hi, I've made some changes to the key exchange mechanism in TLS 1.3 by incorporating Post-Quantum Cryptography (PQC) algorithms.

Changes:

• Add kyber algorithms to the NamedGroup.
• Add TlsAgreement for PQC algorithms. (BcTlsKyber, JceTlsKyber)
• Add TlsPQCKemMode to distinguish Client / Server, and move receivePeerValue() forward than generateEphemeral().
• We do not add PQC namedGroups to CANDIDATES_DEFAULT. So in order to use PQC namedGroups, you must set the "jdk.tls.namedGroups". (java -Djdk.tls.namedGroups=kyber1024,x25519,x448 ClientExample)

Questions:

• NamedGroupInfo.hanAnyECDSA() was temporarily modified to use PQC namedGroups with ECDSA certificate. Where is a better location than here?
• We've added TlsPQCKemMode to distinguish Client / Server, is there any good way to distinguish without this?

I'd be happy to address any feedback or questions you may have. Thank you for your time and consideration! Best regards, hunhee

[yuhh0328]

Hello, Is the review still in progress? code for ec-kyber-hybrid, edec-kyber-hybrid are also prepared.

• ec-kyber-hybrid : https://github.com/samsungsds-research-papers/bc-java/tree/tls-ec-kyber-hybrid
• edec-kyber-kybrid : https://github.com/samsungsds-research-papers/bc-java/tree/tls-edec-kyber-hybrid @roy-basmacier @peterdettman @lee-changhoon

[roy-basmacier]

@yuhh0328

• NamedGroupInfo.hanAnyECDSA() was temporarily modified to use PQC namedGroups with ECDSA certificate. Where is a better location than here?

Modifiying the NamedGroupInfo changes are wrong and presumably unnecessary. Proir to TLS 1.3, signature schemes based on ECDSA could function without specifying a particular curve. The "hasAnyECDSA" determined whether a NamedGroup supported such schemes. I might be mistakened, is it applicable to the PQC Groups?

• We've added TlsPQCKemMode to distinguish Client / Server, is there any good way to distinguish without this?

TlsPQCKemMode isn't needed. The TlsCryptoParameters interface would be a better way of distinguishing between Client/Server. It would be better to pass a TlsCryptoParameters implementation inside of TlsPQCDomain.createPQC()

Can you clean up these two things? Then we can take over the rest.

Another note that things shouldn't be named for their "PQC"-ness, but instead for the type of algorithm/functionality, presumably "KEM" in many cases here.

[yuhh0328]

@roy-basmacier @lee-changhoon

1. It has been changed to use "TlsCryptoParameters" to distinguish client/server. (TlsPQCKemMode has been deleted)
2. "PQC" has been changed to "KEM".
3. "hasAnyECDSA" is back to its original code. ※ To use the KEM namedGroups with ECDSA certificate, the EC namedGroup must be included in the "jdk.tls.namedGroups". (jdk.tls.namedGroups=kyber512,kyber768,kyber1024,secp384r1)

[hwupathum]

Currently, BC only look at the priority of NamedGroups in Djdk.tls.namedGroups if X25519 or secp256r1 is not in the list as mentioned in https://github.com/bcgit/bc-java/blob/main/tls/src/main/java/org/bouncycastle/tls/AbstractTlsClient.java#L409.

If I create a BC client with the list of Namedgroups [kyber768,X25519], it will only send X25519 shared keys only while a client with liboqs provider will send the both pairs of keys. IMO it is preferred if we can support sending a standard NameGroup alongside the PQC ones as a fallback option, since most of the other clients and the servers still does not support PQC NamedGroups.