PQConnect: Compatibility
Preserving connectivity is critical.
After you install the PQConnect client software,
your machine will connect to PQConnect servers
and will continue to connect to non-PQConnect servers.
PQConnect is designed so that the PQConnect client software
detects PQConnect servers without sending extra queries to non-PQConnect servers.
(Such queries might trigger hyperactive firewalls to break connectivity.)
Similarly,
if you are a sysadmin installing the PQConnect server software,
your machine will continue to allow connections from non-PQConnect clients.
This compatibility works using CNAME records, a standard DNS feature
(for example, www.amazon.com relies on CNAME records).
To announce PQConnect support for www.your.server,
you will rename the existing DNS records for www.your.server
(typically just an A record showing the server's IP address)
under a new name determined by PQConnect,
and you will set up a DNS CNAME record
pointing from www.your.server to the new name.
For example,
www.pqconnect.net has a CNAME record pointing to
pq1u1hy1ujsuk258krx3ku6wd9rp96kfxm64mgct3s3j26udp57dbu1.pqconnect.net,
which in turn has an A record listing the server's IP address.
Non-PQConnect clients follow the CNAME record
and connect to the server.
PQConnect clients recognize the CNAME record as a PQConnect announcement
and make an encrypted connection to the server.
PQConnect announcements include a version number pq1.
This supports smooth future upgrades
in which clients are upgraded to allow a modified pq2 protocol,
and then servers can freely begin announcing pq2.
PQConnect is not limited to www.your.server.
You can also announce PQConnect support
for imap.your.server, zulip.your.server, or whatever other subdomains you want
within your DNS domains.
However,
you cannot set up a DNS CNAME record
specifically for the second-level name your.server
delegated from the top-level .server administrators.
DNS does not allow CNAME records to have exactly the same name as other records,
such as delegation records.
It would be possible for PQConnect to work around this restriction
by inserting PQConnect announcements into delegation records,
but currently PQConnect focuses on protecting subdomains.
Operating systems
The initial PQConnect software release is for Linux.
The software installation
relies on packages supplied by Linux distributions.
Package names are not synchronized across Linux distributions.
The installation currently understands the names for
Debian; Debian derivatives such as Ubuntu and Raspbian; Arch; and Gentoo.
Adding further distributions should be easy.
Support for non-Linux operating systems is planned,
handling the different mechanisms
that different operating systems provide
for reading and writing IP-layer packets.
The PQConnect system as a whole
is designed to be compatible with any operating system.
The PQConnect software is written in Python.
The underlying C libraries for cryptography have already been ported to MacOS.
Accessing the IP layer is not the only way to implement the PQConnect protocol.
Existing user-level applications access the kernel's network stack
via system calls, normally via libc.
It is possible to modify those network packets by modifying the kernel,
by modifying libc,
or by pre-loading a PQConnect dynamic library,
still without touching the individual applications.
Also, most applications
access DNS at the servers designated in /etc/resolv.conf,
usually via libc,
so it is possible to modify DNS packets by changing libc,
by modifying /etc/resolv.conf
to point to local DNS software that handles PQConnect,
or by modifying existing local DNS software to handle PQConnect
(via plugins where applicable, or by code modifications).
These software choices can also be of interest to apply PQConnect to
applications that manage to dodge the current PQConnect software.
Our experiments have found the PQConnect software
successfully wrapping post-quantum cryptography around a wide range of applications.
However,
there is no guarantee that PQConnect covers all applications.
For example,
an application might read a server address from a local file
without using DNS queries,
might use its own encrypted tunnel to a DNS proxy,
or might otherwise
deviate from the normal modular usage of DNS services
provided by the operating system.
These applications do not receive the benefits of PQConnect:
they will continue to make non-PQConnect-protected connections as usual.
A notable example is Firefox,
which automatically uses DNS over HTTPS in some cases
to send DNS queries to Cloudflare.
A DNS proxy (or DNS packet rewriting) can disable this by creating an IP address for use-application-dns.net;
this allows Firefox to benefit from PQConnect,
and is still compatible with passing DNS queries locally to a modular DNS-over-HTTPS client.
A user manually configuring Firefox to use DNS over HTTPS will prevent Firefox from using PQConnect.
SSH connections, TLS connections, etc. work smoothly over PQConnect.
The software managing those security mechanisms
doesn't notice that everything is protected inside a PQConnect tunnel.
The PQConnect software doesn't notice that the packets it's encrypting
already have another layer of encryption.
Conceptually,
running the PQConnect protocol
on top of a VPN protocol,
or vice versa,
is a simple matter of routing packets
in the desired order through PQConnect and the VPN.
So far we haven't written scripts to do this,
but if you have specific use cases then please share details in the
Compatibility channel on the PQConnect chat server.
PQConnect encrypts and authenticates complete IP packets,
including port numbers.
After decrypting a packet,
PQConnect forwards the packet to the local machine
on whichever port number is specified by the client.
One consequence of this encryption
is that you cannot rely on a firewall outside your machine to block ports:
any desired port blocking must be handled by a firewall inside your machine.
Note that an external firewall also does not block
attackers who have compromised a router or network card
between the firewall and your computer.
You may be behind a firewall that restricts which ports you can use:
for example, the firewall may block low ports, or may block high ports.
PQConnect is flexible in which ports it uses.
The -p option for the pqconnect program chooses a client port.
The -p and -k options for the pqconnect-server program choose a crypto-server port and a key-server port.
All of these are UDP ports.
Our PQConnect tests have been with IPv4,
but the protocol should also work with IPv6.
The PQConnect handshake packets are small enough
that even multiple levels of surrounding tunnels
should stay below the 1500-byte Ethernet limit on packet sizes.
The PQConnect server software
automatically replaces client IP addresses with local addresses such as 10.10.0.5
when it delivers packets to applications running on your server.
Hiding client addresses can help protect privacy
against applications that are careless in handling client data,
and can help comply with privacy regulations.
If you need applications to be able to check client locations
to route clients to nearby servers for efficiency,
one option is to provide different DNS responses
to clients in different locations
(using, e.g., the "client location" feature in tinydns),
already pointing those clients to nearby servers at DNS time
rather than having the application perform this routing.
If you need to check client information in logs
for abuse tracking,
one option is to collate PQConnect logs and application logs,
still without exposing client IP addresses to the application.
Version:
This is version 2024.12.26 of the "Compatibility" web page.
pqconnect-1.2.1/doc/html/crypto.html 0000444 0000000 0000000 00000045577 14733452565 016160 0 ustar root root
PQConnect: Cryptography
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
pqconnect-1.2.1/doc/html/index.html 0000644 0000000 0000000 00000016171 14733452565 015735 0 ustar root root
PQConnect: Intro
PQConnect is a new easy-to-install layer of Internet security.
PQConnect lets you take action right now on your computer
to address the threat of quantum attacks,
without waiting for upgrades in the applications that you are using.
PQConnect automatically applies post-quantum cryptography
from end to end between computers running PQConnect.
PQConnect adds cryptographic protection to unencrypted applications,
works in concert with existing pre-quantum applications to add post-quantum protection,
and adds a second application-independent layer of defense
to any applications that have begun to incorporate application-specific post-quantum protection.
VPNs similarly apply to unmodified applications,
and
some
VPNs
support post-quantum cryptography.
However, VPNs protect your traffic only between your computer
and the VPN proxies that you have configured your computer to contact:
VPN traffic is not encrypted end-to-end to other servers.
The
advantage of PQConnect
is that, once you have installed PQConnect on your computer,
PQConnect automatically detects servers that support PQConnect,
and transparently encrypts traffic to those servers.
If you are a system administrator installing PQConnect on the server side:
configuring a server name to announce PQConnect support is easy.
What to read next
The installation instructions for PQConnect are split between two scenarios.
If you are a system administrator
(for example, running a web server),
you should follow the
installation instructions for sysadmins.
This covers setting up the PQConnect server software to handle incoming PQConnect connections from clients.
If you are a normal user
(for example, using a web browser),
you should follow the
installation instructions for users.
This covers setting up the PQConnect client software to handle outgoing PQConnect connections to servers.
What about the combined scenario
that your computer is a client and a server
(for example, your computer is running an SMTP server
and is also making outgoing SMTP connections)?
Then you should follow the
installation instructions for sysadmins.
We have very recently set up https://zulip.pqconnect.net
using Zulip, a popular open-source web-based chat system.
Feel free to join and discuss PQConnect there—you can be one of the first users!
Just click on "Sign up" and enter your email address.
Reports of what worked well and what didn't work so well
are particularly encouraged.
Team
PQConnect team (alphabetical order):
-
Daniel J. Bernstein,
University of Illinois at Chicago, USA, and Academia Sinica, Taiwan
-
Tanja Lange,
Eindhoven University of Technology, The Netherlands, and Academia Sinica, Taiwan
-
Jonathan Levin,
Academia Sinica, Taiwan, and Eindhoven University of Technology, The Netherlands
-
Bo-Yin Yang,
Academia Sinica, Taiwan
The PQConnect software is from Jonathan Levin.
Funding
This work was funded in part
by the U.S. National Science Foundation under grant 2037867;
the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation)
under Germany's Excellence Strategy–EXC 2092 CASA–390781972 "Cyber Security in the Age of Large-Scale Adversaries";
the European Commision through the Horizon Europe program
under project number 101135475 (TALER);
the Dutch Ministry of Education, Culture, and
Science through Gravitation project "Challenges in Cyber Security - 024.006.037";
the Taiwan's Executive Yuan Data Safety and Talent
Cultivation Project (AS-KPQ-109-DSTCP);
and by the Academia Sinica Grand Challenge Projects AS-GCS-113-M07 and AS-GCP-114-M01.
"Any opinions, findings, and conclusions or recommendations expressed in this material are those
of the author(s) and do not necessarily reflect the views of the National Science Foundation"
(or other funding agencies).
Version:
This is version 2024.12.27 of the "Intro" web page.
pqconnect-1.2.1/doc/html/mascot.png 0000644 0000000 0000000 00000027614 14733452565 015740 0 ustar root root PNG
IHDR _ R | IDATxռgteu&s9"gs#,JV-Y%DZxx<ϣ53Oֳgfyƣ,-%*آ l6;hth \ 7tr fS"` Ω:U v{FcpF*+4(6˛iV} 9la@ r
_O.,E:?;Lz@]8n7JմoDQ]M]{:&Ç@} |YWHIO/h+Wpq IXZD-Bфi26uɱ?t>设 `gf]`- %lvjBv>k6e2J2
ZR}l 77akOc>IG_ި?+VJ9[zf:}zZGerN5͟Spk!Sn3l1l9h@Ǒ-ο+fq}#ّ$׆of^ >LS*ԥ)mg $3D|z SMOK
Q NOyfrR$xSS/`S(3L }@>NοuSڑSlzgί ,'!#KWr .: v珮itgZ. ljr[A#Rs5stba* ŮH4kgy{_~x兓Vv7 YܧϟIUJ(zLN6X#ZVxaUDYÈ}vy#?&=搇R
Y5e"3n,VzBETY#L78 ^{ wTU}rX(/ddRvyooe"r nT6 \f4b'av"bk6p`#RUO&!,l|N$:2Sg" 럞 EQG.o2%YMV@5_͍Zmr̝)KQYgHo#)ӬHs
?W}rzΕduH:pS9ɟ]KzW-ztr";dG;rMcѦbv^zaۆd"v3|fOi).]$={.sc ZC͌Z<0(&qGu] JLƥ+dj\́#8F'$:٢cц^@47*ȱ& ~qz̙QU=rp{6,T=w:yn;TH USr*Vp mѰ%_nhgpd3R,V Pݸ3 !o-*bZhuWYZ@\Xji9) i>.b8M +j,e %vIUvt _x2