Experimenting with Post Quantum Cryptography … The Greatest Change in the Internet Has Started…

Experimenting with Post Quantum Cryptography (PQC) … The Greatest Change in the Internet Has Started…

As you may know, we need to replace all our existing public key methods with methods that are quantum robust. One company at the forefront of pushing forward cryptographic methods is Cloudflare. In fact, their CIRCL library already contains Kyber, SIDH, and Frodo:

• Kyber Key Exchange. Kyber. In this case, we will implement Kyber512, Kyber738 and Kyber1024, in order to create a quantum-robust key exchange.
• Kyber, SIKE and Hybrid Key Exchange. Hybrid.
• SIDH using Cloudflare. SIDH. Post-quantum key exchange.
• SIKE Secret Shares with Go. SIKE. Post-quantum key exchange with key encapsulation.
• CSIDH Go. CSIDH. Post-quantum key exchange.
• SIKE Key Exchange. SIKE.
• Frodo. Frodo. Frodo KEM is based on the learning with errors (LWE) problem.

A core part of security on the Internet is the key exchange mechanism that happens every time we connect to a website. This is where an encryption key is negotiated between the client and the server. Unfortunately, most of the existing key exchanges on the Internet use ECDH (Elliptic Curve Diffie Hellman), and would could be cracked by quantum computers.

Overall, two core focus areas for Cloudflare are security and performance. Their core service aims to deliver content in a fast and efficient way, and where they will cache content and deliver it faster than if delivered from the target website. Thus, the move to PQC for key exchange is important in assessing the impact that it will have on their customer’s network connections.

While SIKE is struggling with a significant vulnerability, it is Kyber that leads the way on the likely method that will be used for PQC key exchange. This standard should be ready by 2024. The methods currently supported are this now include X25519Kyber512 and X25519Kyber768. You can try these here:

Cloudflare is now asking for companies to enrol their Websites for testing, and where it uses both Kyber and the classical X25519 key exchange method (in order to keep compatibility with existing systems).

Testing

Cloudflare has now run an experience for the hybrid key exchange method using the BoringSSL library and Go [here]. The script adds the curve name of Xyber521D00 and is run with [here]:

$ git clone https://github.com/cloudflare/boringssl-pq
[snip]
$ cd boringssl-pq && mkdir build && cd build && cmake .. -Gninja && ninja 
[snip]
$ ./tool/bssl client -connect pq.cloudflareresearch.com -server-name pq.cloudflareresearch.com -curves Xyber512D00
	Connecting to [2606:4700:7::a29f:8a55]:443
Connected.
  Version: TLSv1.3
  Resumed session: no
  Cipher: TLS_AES_128_GCM_SHA256
  ECDHE curve: X25519Kyber512Draft00
  Signature algorithm: ecdsa_secp256r1_sha256
  Secure renegotiation: yes
  Extended master secret: yes
  Next protocol negotiated: 
  ALPN protocol: 
  OCSP staple: no
  SCT list: no
  Early data: no
  Encrypted ClientHello: no
  Cert subject: CN = *.pq.cloudflareresearch.com
  Cert issuer: C = US, O = Let's Encrypt, CN = E1

And the Go code is [here]:

​​package main

import (
  "crypto/tls"
  "fmt"
  "net/http"
)

func main() {
  http.DefaultTransport.(*http.Transport).TLSClientConfig = &tls.Config{
    CurvePreferences: []tls.CurveID{tls.X25519Kyber512Draft00, tls.X25519},
    CFEventHandler: func(ev tls.CFEvent) {
      switch e := ev.(type) {
      case tls.CFEventTLS13HRR:
        fmt.Printf("HelloRetryRequest\n")
      case tls.CFEventTLS13NegotiatedKEX:
        switch e.KEX {
        case tls.X25519Kyber512Draft00:
          fmt.Printf("Used X25519Kyber512Draft00\n")
        default:
          fmt.Printf("Used %d\n", e.KEX)
        }
      }
    },
  }

  if _, err := http.Get("https://pq.cloudflareresearch.com"); err != nil {
    fmt.Println(err)
  }
}

For this, Cloudflare has forked the Go repository and updated the crypto part:

Results

With Wireshark, Cloudflare detects the TLS handshake (such as from the Client Hello and then onto the Server Hello) for X25519:

We can see that the key length is 32 bytes (256 bits). With Kyber, the Client Hello is sent with a single packet (but is larger than with X25519), but the Server Hello requires three packets (as opposed to two with X25519). This is because of the server has a larger key share:

As we can see, Kyber512 has a public key of 800 bytes and a cipher of 768 bytes. The derived shared key is 32 bytes, and which is then mapped to X25219 [here]:

Overall, Cloudflare found a small performance difference between X25519 and the Hybrid methods. It should be noted that the Hybrid method is NOT post-quantum robust but will allow us to slowly migrate our existing systems. Eventually, the X25519 part will be dropped, and it will be pure Kyber.

Conclusion

Moving away from RSA and ECC will be one of the most radical changes that we have ever seen on the Internet. Go ready for PQC …

https://asecuritysite.com/pqc