Version:\n' output += 'This is version %s of the "%s" web page.\n' % (mtime,pagetitle) output += '\n' output += '
pqconnect-1.2.2/ 0000755 0000000 0000000 00000000000 14770633713 012217 5 ustar root root pqconnect-1.2.2/Dockerfile 0000644 0000000 0000000 00000001112 14770633713 014204 0 ustar root root FROM debian:bullseye AS build USER root RUN apt-get update && \ apt-get install -y build-essential \ clang wget python3 python3-pip \ python3-venv sudo libssl-dev \ libsodium-dev git valgrind RUN pip install build RUN useradd --create-home pqconnect RUN mkdir /home/pqconnect/python && \ mkdir /home/pqconnect/keys/ WORKDIR /home/pqconnect/python ADD Makefile . ADD scripts . ADD pyproject.toml . ADD README.md . ADD LICENSE . ADD server.patch . ADD src . RUN patch pyproject.toml server.patch RUN make install RUN ldconfig RUN pqconnect-keygen CMD ["pqconnect-server"] pqconnect-1.2.2/LICENSE 0000644 0000000 0000000 00000000532 14770633713 013224 0 ustar root root This package is hereby placed into the public domain. [SPDX-License-Identifier](https://spdx.dev/ids/): [LicenseRef-PD-hp](https://cr.yp.to/spdx.html) OR [CC0-1.0](https://spdx.org/licenses/CC0-1.0.html) OR [0BSD](https://spdx.org/licenses/0BSD.html) OR [MIT-0](https://spdx.org/licenses/MIT-0.html) OR [MIT](https://spdx.org/licenses/MIT.html) pqconnect-1.2.2/Makefile 0000644 0000000 0000000 00000004205 14770633713 013660 0 ustar root root USER:=pqconnect GROUP:=pqconnect VENV := venv PYTHON := $(VENV)/bin/python3 PIPFLAGS := $(shell python3 scripts/external.py) default: build .PHONY: test clean venv/bin/activate: pyproject.toml python3 -m venv --copies $(VENV) $(PYTHON) -m pip install .[dev] sudo setcap 'cap_sys_admin=ep cap_net_admin=ep cap_net_raw=ep' venv/bin/python sudo setcap 'cap_sys_admin=ep cap_net_admin=ep cap_net_raw=ep' venv/bin/python3 sudo setcap 'cap_sys_admin=ep cap_net_admin=ep cap_net_raw=ep' venv/bin/python3.12 setup: venv/bin/activate format: venv/bin/activate -$(PYTHON) -m isort src $(PYTHON) -m black src lint: venv/bin/activate -$(PYTHON) -m pyflakes src -$(PYTHON) -m pylint src -$(PYTHON) -m flake8 src -$(PYTHON) -m ruff src $(PYTHON) -m tryceratops src type: venv/bin/activate -$(PYTHON) -m mypy src -$(PYTHON) -m pyright src [ -e .pyre_configuration ] || echo "src" | $(VENV)/bin/pyre init $(VENV)/bin/pyre check coverage: venv/bin/activate sudo $(PYTHON) -m coverage report -m dead: venv/bin/activate -$(PYTHON) -m vulture src build-deps: scripts/download-build-install-deps test: venv/bin/activate build-deps sudo $(PYTHON) -m coverage run -m unittest discover -v test_%.py: venv/bin/activate build-deps sudo $(PYTHON) -m coverage run -m unittest test/$@ build: build-deps python3 -m build ls -alh dist/pqconnect* audit-and-build: venv/bin/activate format lint type dead test build install-user-and-group: -getent passwd ${USER} $2>/dev/null || sudo useradd -g ${GROUP} -r -m -s /bin/false ${USER} -getent group ${GROUP} $2>/dev/null || sudo groupadd -r ${GROUP} install: build install-user-and-group -sudo pip install $(PIPFLAGS) dist/pqconnect-0.0.1-py3-none-any.whl install-systemd-unitfiles: sudo cp misc/pqconnect-client.service /etc/systemd/system/ sudo chmod 644 /etc/systemd/system/pqconnect-client.service sudo systemctl daemon-reload clean: rm -rf dist downloads venv .pyre .pyre_configuration .coverage .ruff_cache .mypy_cache uninstall: clean -sudo pip uninstall $(PIPFLAGS) pqconnect test-run: @echo "Start pqconnect in another terminal and press [Enter]:" @bash -c read -n1 curl -L www.pqconnect.net/test.html pqconnect-1.2.2/README.md 0000644 0000000 0000000 00000000171 14770633713 013475 0 ustar root root Full documentation for PQConnect is located in the top-level `doc` directory. A good place to start is `doc/readme.md`. pqconnect-1.2.2/autogen/ 0000755 0000000 0000000 00000000000 14770633713 013661 5 ustar root root pqconnect-1.2.2/autogen/html 0000755 0000000 0000000 00000005436 14770633713 014563 0 ustar root root #!/usr/bin/env python3 import os import datetime import markdown def load(fn): with open(fn) as f: return f.read() style = load('autogen/html-style') sitetitle = load('autogen/html-title').strip() files = [] os.makedirs('doc/html',exist_ok=True) with open('autogen/html-files') as f: for line in f: line = line.strip() line = line.split(':') if len(line) != 3: continue files += [line] class superscripts(markdown.extensions.Extension): def extendMarkdown(self,md): md.inlinePatterns.register(markdown.inlinepatterns.SimpleTagInlineProcessor(r'()\^(.*?)\^','sup'),'sup',175) # this paragraph derived from python-markdown AUTOLINK_RE = r'<((?:[Ff]|[Hh][Tt])[Tt][Pp][Ss]?://[^<>]*)>' class ttautolinkprocessor(markdown.inlinepatterns.InlineProcessor): def handleMatch(self,m,data): tt = markdown.inlinepatterns.etree.Element('span') tt.set('class','url') tt.text = markdown.inlinepatterns.util.AtomicString(m.group(1)) e = markdown.inlinepatterns.etree.Element('a') e.set('href',self.unescape(m.group(1))) e.append(tt) return e,m.start(0),m.end(0) class ttautolink(markdown.extensions.Extension): def extendMarkdown(self,md): md.inlinePatterns.register(ttautolinkprocessor(AUTOLINK_RE,md),'autolink',119) for md,html,pagetitle in files: fnmd = 'doc/%s.md' % md fnhtml = 'doc/html/%s.html' % html output = '' x = load(fnmd) x = markdown.markdown(x,extensions=['markdown.extensions.extra','markdown.extensions.tables',superscripts(),ttautolink()]) mtime = datetime.datetime.utcfromtimestamp(os.path.getmtime(fnmd)).strftime('%Y.%m.%d') output += '\n
\n' output += style output += 'Add configuration checker (pqconnect-server-check
) for sysadmins to
diagnose configuration issues.
Fix unhandled connectivity-loss error.
Fix handling malformed static-key requests; thanks Jan Mojzis.
Port to Python 3.13,
by moving thread creation into run_server
.
Python dependencies: use the lib25519
wrapper
rather than the ondesmartenot/py25519
wrapper.
Handle miscellaneous installation issues on Debian and Alpine.
Many test improvements.
Small code cleanups.
Include ./autogen.do
for package preprocessing
(currently just rebuilding doc/html
).
Documentation improvements:
note dependency on wget
and sudo
;
use 203.0.113.113
as example IP address;
link to NDSS 2025 slides.
First public release.
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.
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.
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.
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.
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.
2025.01.12 news: The TU/e network is down because of an attack. We have restored https://www.pqconnect.net but we don't have the chat server back yet, sorry.
2025.01.30 news: The chat server is back!
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.
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).