This page explains PQConnect's top three cryptographic goals, and various aspects of how PQConnect aims to achieve those goals. There is a separate page looking more broadly at security.

Priority 1: post-quantum encryption

Attackers are carrying out mass surveillance of Internet traffic. They are saving encrypted data to break later. They are years ahead of the public in investing in quantum computers. The ciphertexts we send are irrevocably shown to any attackers monitoring the network; we cannot retroactively improve the encryption of that data.

The top priority for PQConnect is to switch as much Internet traffic as possible, as quickly as possible, to high-security end-to-end post-quantum encryption.

To the extent that some applications have already been rolling out post-quantum encryption, great! PQConnect adds another layer of defense in case that fails, a layer systematically designed for high security. But the more obvious benefit of PQConnect is for applications that are still using pre-quantum encryption or no encryption at all. PQConnect provides a fast application-independent path to post-quantum cryptography.

Priority 2: post-quantum authentication

Another important goal of PQConnect is to switch as much Internet traffic as possible, as quickly as possible, to high-security end-to-end post-quantum authentication.

The urgency of post-quantum authentication is not as obvious as the urgency of post-quantum encryption. Consider, for example, an application relying on pre-quantum signatures for authentication. Assume that the application is upgraded so that all verifiers accept post-quantum signatures, and then upgraded to replace all generated pre-quantum signatures with post-quantum signatures, and then upgraded so that verifiers stop accepting pre-quantum signatures, with all of these upgrades deployed by all signers and verifiers before the attacker has a quantum computer. There will then be no verifiers accepting the attacker's forged pre-quantum signatures.

However, the timeline for upgrades is variable and often extremely slow. For example, within web pages loaded by Firefox, the percentage using HTTPS was around 30% in 2014, around 80% in 2020, and still around 80% in 2024. There are clear risks that, when the first public demonstrations of quantum attacks appear, many applications will still be using pre-quantum cryptography, while real quantum attacks will already have been carried out in secret. Starting earlier on upgrades will reduce the damage.

Priority 3: fast post-quantum key erasure

Sometimes a user's device is stolen or otherwise compromised by an attacker. Perhaps this allows attackers to find decryption keys inside the device, and to use those keys to decrypt ciphertexts that the attacker previously recorded.

Of course, the big problem here is that secrets stored on a user device were exposed in the first place. What one wants is better protection for all data stored on the device. However, in case that protection fails, the damage may be reduced if keys are preemptively erased.

PQConnect sets a goal of having each ciphertext no longer decryptable 2 minutes later, even if the client and server devices are subsequently compromised by an attacker also having a quantum computer. Concretely, PQConnect encrypts each ciphertext using a post-quantum key that is erased by the client and by the server within 2 minutes. This erasure happens within each PQConnect tunnel, no matter how long the tunnel lasts.

For comparison, the "ephemeral" options in TLS are often claimed to provide "Perfect Forward Secrecy", but these options still allow ciphertexts to be decryptable for as long as a TLS session lasts. A 2016 study found that "connections to 38% of Top Million HTTPS sites are vulnerable to decryption if the server is compromised up to 24 hours later, and 10% up to 30 days later". Current security guides that ask TLS applications to disable session resumption do not prevent sessions from lasting for hours or longer.

Full-packet encryption

PQConnect encrypts the complete packets sent by applications, including protocol headers and port numbers. Attackers may be able to deduce the same information by analyzing metadata such as the timings and lengths of packets, but this is not a reason to simply give the data away.

VPNs and BPNs

VPNs typically share PQConnect's features of being application-independent and encrypting full packets. However, VPNs generally do not provide end-to-end security. A client sets up a VPN to encrypt traffic to a VPN proxy, but then traffic is exposed at the VPN proxy, and at every point between the VPN proxy and the ultimate server.

It is possible to manually configure typical VPN software so that a connection to www.your.server goes through a VPN tunnel to www.your.server, a connection to www.alices.server goes through a VPN tunnel to www.alices.server, etc., when this is supported by the servers. PQConnect automates the processes of announcing server support and of creating these tunnels.

In English, "boring a tunnel" means creating a tunnel by digging, typically with a tool. PQConnect is a "BPN": a "Boring Private Network".

The PQConnect mascot is a Taiwanese pangolin. Pangolins dig tunnels and are protected by their armor. The Mandarin name for pangolins is 穿山甲, literally "pierce mountain armor". Legend says that pangolins travel the world through their tunnels.

There is another use of the word "boring" in cryptography: "boring cryptography" is cryptography that simply works, solidly resists attacks, and never needs any upgrades. PQConnect also aims to be boring in this sense.

Double public-key encryption: ECC+PQ

To the extent that applications have upgraded to post-quantum public-key encryption, they are normally using it as a second layer on top of pre-quantum public-key encryption (typically X25519), rather than as a replacement for pre-quantum public-key encryption. This reduces the damage in case of a security failure in the post-quantum software: the impact is delayed until the attacker has a quantum computer.

PQConnect follows this approach. One difference in details is that PQConnect replaces typical concatenated encryption with nested encryption to reduce attack surface.

Conservative public-key encryption: McEliece

PQConnect does not use the presence of an ECC backup as an excuse for risky PQ choices. A devastating PQ failure would mean that goal #1 is not achieved.

The foundation of security in PQConnect is the Classic McEliece encryption system at a very high security level, specifically mceliece6960119; the software uses libmceliece. Among proposals for post-quantum public-key encryption, the McEliece cryptosystem is unique in how strong its security track record is: more than 50 papers attacking the system since 1978 have produced only tiny changes in the McEliece security level. Classic McEliece is also used in the Mullvad and Rosenpass VPNs, and in various other applications.

Each PQConnect server has a long-term 1MB Classic McEliece key that it sends out upon request. To prevent amplification, PQConnect pads the request to 1MB. This cost is only per-client, not per-tunnel or per-connection. The PQConnect client software generates and saves many Classic McEliece ciphertexts so that it can immediately generate fresh tunnels to the server without re-requesting the key; an alternative would be to save the full key.

Of course, if your smartphone's mobile-data plan has a 10GB-per-month data cap, and this month your phone wants to contact 5000 PQConnect servers that it has never talked to before, then you'll have to get on Wi-Fi.

Public-key encryption for authentication

PQConnect uses Classic McEliece not just to protect the confidentiality of user data but also to protect the user data against forgeries. The client sends a ciphertext to the server's public key to establish a secret session key known to the client and server. The session key is the key for an authenticated cipher that protects each packet of user data.

Reusing encryption for authentication avoids the need for a separate signature system. Some references: 1998, 2009, 2016, 2018, 2020.

Authenticating public keys

TLS relies on DNS to be secure. An attacker that controls the DNS records for www.your.server (for example, an attacker that compromises the root DNS servers, that exploits continuing holes in the deployment of cryptography for DNS, or that uses a quantum computer to break pre-quantum cryptography used for DNS) can obtain www.your.server certificates from Let's Encrypt and can then freely impersonate www.your.server, even if applications stop trusting all CAs other than Let's Encrypt. "Certificate transparency" sees the new certificate but does not stop the attack.

Similarly, an attacker controlling the DNS records for www.your.server can turn off PQConnect for www.your.server, or replace the legitimate PQConnect public key for www.your.server with the attacker's public key.

The PQConnect protocol supports three approaches to stopping this attack. First, the PQConnect protocol is capable of protecting DNS itself. We are planning more documentation and software for this; stay tuned!

Second, to the extent that other security mechanisms are deployed successfully for DNS, they also protect PQConnect's server announcements.

Third, the PQConnect protocol lets you use a high-security name that includes your server's public key. For example, instead of linking to https://www.pqconnect.net, you can link to a high-security PQConnect name for the same server, as long as the application does not impose severe length limits (in, e.g., certificates). Some client-side software steps are necessary to make sure that all paths for attackers to substitute other names are closed off (e.g., the key extracted from the PQConnect name has to override any keys provided by CNAMEs, and DNS responses sent directly to applications have to be blocked), but this is conceptually straightforward.

Public-key encryption for fast key erasure: NTRU Prime

Beyond encrypting data to the server's long-term McEliece public key, a PQConnect client applies another layer of encryption to a short-term public key provided by the server, to enable fast key erasure.

This short-term public key uses a small-key lattice-based cryptosystem. This choice has the advantage of reducing per-tunnel costs, although this does not matter when there is a large amount of data per tunnel. The disadvantage is that lattice-based cryptography has higher security risks than the McEliece cryptosystem, and a break of the lattice-based cryptosystem would mean that keys are not erased, although this does not matter unless the attacker also steals secrets from the device.

Trigger warning: If you find patents traumatic, or if your company has a policy to not learn about patents, please stop reading at this point.

Unfortunately, lattice-based cryptography is a patent minefield. NIST has published edited excerpts of a license that appears to cover two older patents (9094189 and 9246675), but the license is only for Kyber; meanwhile another patent holder, Yunlei Zhao, has written that "Kyber is covered by our patents".

Fortunately, there is one lattice-based cryptosystem old enough for its patent to have expired, namely NTRU. Various security problems were discovered the original version of NTRU, but all of the known issues (and some other issues that make audits unnecessarily difficult) are addressed by tweaks in Streamlined NTRU Prime (sntrup), which was published in May 2016. There were not many post-quantum patents at that point. The current version of sntrup differs only in some small tweaks to serialization and hashing published in April 2019, and patent searches have found no issues here.

Streamlined NTRU Prime was added to TinySSH and OpenSSH in 2019, and was made default in OpenSSH in 2022, with no reports of any problems. PQConnect also uses Streamlined NTRU Prime, specifically sntrup761. The software uses libntruprime.

Formal verification

Most of the PQConnect security analysis so far is manual, but symbolic security analysis of one component of PQConnect, namely the handshake, is within reach of existing automated tools and has been carried out using an existing prover, namely Tamarin. Running

scripts/install-tamarin
scripts/run-tamarin

inside the PQConnect software package will install Tamarin and verify the handshake. See Section V of the NDSS 2025 paper for more information.

---

Version: This is version 2024.12.27 of the "Cryptography" web page.