A little while ago we announced support for post-quantum KEM groups and then hybrid groups. We are now proud to announce support for the PQC NIST round 3 finalist signature scheme FALCON. With this announcement, customers can now experiment with fully quantum-safe TLS 1.3 handshakes.
From a high level perspective, for every TLS 1.3 connection, authentication and confidentiality are the two main goals that protect each connection. Authentication is maintained via signature schemes such as ECDSA. Confidentiality is maintained by key establishment algorithms such as ECDHE and then using the established key with symmetric encryption algorithms such AES to encrypt a communication stream. We can thus decompose the security of the TLS 1.3 protocol into 3 types of cryptographic algorithms:
– authentication algorithms
– key establishment algorithms
– symmetric cipher algorithms
When a cryptographically relevant quantum computer is finally developed, Shor’s algorithm completely breaks the security of modern authentication and key establishment algorithms while Grover’s algorithm reduces the security of modern symmetric cipher algorithms by half. So, we must replace our modern authentication and key establishment algorithms with quantum-safe ones and double the strength of our symmetric cipher algorithms to maintain the security of our communications.
Now that wolfSSL has integrated FALCON, we can use it for authentication. We can use any one of our new KEMs and just in case, we can hybridize it with NIST-approved ECDSA groups. And finally, since the strength of AES-128 is generally accepted to be sufficient, we can double our strength by using AES-256 by using the AES_256_GCM_SHA384 TLS 1.3 ciphersuite. To get a connection that has such a handshake, you would run the following commands:
$ examples/server/server -v 4 -l TLS_AES_256_GCM_SHA384 \ -A certs/falcon_level5_root_cert.pem \ -c certs/falcon_level5_server_cert.pem \ -k certs/falcon_level5_server_key.pem \ --oqs P521_KYBER_LEVEL5 $ examples/client/client -v 4 -l TLS_AES_256_GCM_SHA384 \ -A certs/falcon_level5_root_cert.pem \ -c certs/falcon_level5_cleint_cert.pem \ -k certs/falcon_level5_client_key.pem \ --oqs P521_KYBER_LEVEL5
You can then use a modified wireshark that recognizes our algorithms to monitor the connection and see what is really going over the wire:
The merge request for the wireshark modifications can be found here:
https://gitlab.com/wireshark/wireshark/-/merge_requests/4924/
The pull request for instructions for making a docker image with the wireshark modifications can be found here:
https://github.com/open-quantum-safe/oqs-demos/pull/104
The integration of FALCON has made it onto our wolfSSL master branch, and will be part of the next release of wolfSSL.
One last word on the threat model and why it is important to consider post-quantum authentication sooner rather than later. Due to your application parameters or use case, it might not be cost effective or even possible to update software components. In these cases, you must carefully evaluate the lifetime of your product. If you project that we will see a cryptographically relevant quantum computer within the lifetime of your product, but it can’t be updated, then perhaps you need to start thinking about a strategy for moving to post-quantum algorithms today.
Reach out to us at wolfSSL by sending a message to facts@wolfssl.com.