> 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.
I mainly take issue with this claim of "automatically" detecting servers and magically doing post-quantum magic to your connections, magically.
It seems to do so by noticing that DNS records for names are CNAMEs that match a format ("pq1" and then a 52-char b32-encoded hash), which it does by creating a netfilter rule for "udp sport 53" [0].
So, I guess if you don't have adversaries racing your DNS response packets, and you're not using dns-over-tls or dns-over-https, then the magic can work.
One glaring problem with this kind of automatic, magic setup is that if you do have attackers, or if your system does dns in some newfangled way that wasn't thought up in the 1980s, then it doesn't secure your connection, but it also doesn't tell you that it failed to do so.
So many clients (imap, ldap, anything) that use StartTLS don't default to "fail if TLS doesn't work" and don't tell the user anything about it, and it makes me hate StartTLS even though the fault isn't directly with StartTLS.
“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. [The installation also requires root access.]
“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. […]”
I would have expected information about OS support, and on which application/OS layer PQConnect operates, on the Intro page.
coppsilgold 10 hours ago [-]
There are a number (or just one? Mullvad) of commercial VPN providers that provide an optional PQC layer, and that fact is referenced on this project's page.
There is also VPN software that incorporates PQC (also referenced): <https://rosenpass.eu>
What this project attempts to do is to establish a transparent PQC stream between client and server.
I'm not sure I like the way they are doing this, with a lot of magic (PQConnect inserts itself into the network stack to inspect incoming DNS responses) and with Python of all things.[1][2][3]
I think the best way to do this is to graft it on top of QUIC and not mess with linux network plumbing. Perhaps integrate it with something like <https://github.com/n0-computer/iroh>
It's rather unclear how this integrates with the OS you run on top of.
I think a short explanation of how this actually works (not the post-quantum crypto part, but rather the plumbing into the networking stack of your box) would be very helpful.
[EDIT]: an a very quick first glance at the python source code and the install scripts reveals that a PQconnect install performs rather intrusive changes to your system:
- installs lots of packages
- installs a daemon running under systemd
- creates a new user
- creates a new tunnel network device
I'm going to take a wild initial guess and assume that there's some dynamic manipulation of low-level networking state (routing tables, iptables, etc...), which makes me rather queasy to install this on a production and/or work system because I have no idea if it is going to wreck my existing setup.
Also, the server is written in python ... I most certainly hope the python code is not in any way processing / redirecting network traffic itself in userland, or performance is going to be awful.
All of this points to the fact that an overview of how pqconnect grafts itself into your Linux system would be most welcome.
10 hours ago [-]
orlp 14 hours ago [-]
Seems a bit disrespectful to only list the big name professors in the title and shove the PhD student who seemingly actually wrote the pqconnect software (Jonathan D. Levin) into the ohters [sic] category.
nabla9 13 hours ago [-]
The purpose of the title is not to distribute credit.
It's to provide information about the link. People in HN don't know Levin (yet). The nave conveys no information. . Everybody knows DJB and Lange.
It wasn’t clear to me that DJB and Lange in the title were names of persons.
tptacek 13 hours ago [-]
The title of this post should be "PQConnect", or "PQConnect:
Automated Post-Quantum End-to-End Tunnels" (from the paper). The editorialized title here now stiffs the guy who actually wrote the software.
This looks like basically a McEliece/SNTRUP version of Colin Percival's spiped.
jmspring 13 hours ago [-]
Doesn't sound a lot different than Tailscale co-option (commercially) of Wireguard?
Rendered at 08:16:50 GMT+0000 (UTC) with Wasmer Edge.
I mainly take issue with this claim of "automatically" detecting servers and magically doing post-quantum magic to your connections, magically.
It seems to do so by noticing that DNS records for names are CNAMEs that match a format ("pq1" and then a 52-char b32-encoded hash), which it does by creating a netfilter rule for "udp sport 53" [0].
So, I guess if you don't have adversaries racing your DNS response packets, and you're not using dns-over-tls or dns-over-https, then the magic can work.
One glaring problem with this kind of automatic, magic setup is that if you do have attackers, or if your system does dns in some newfangled way that wasn't thought up in the 1980s, then it doesn't secure your connection, but it also doesn't tell you that it failed to do so.
So many clients (imap, ldap, anything) that use StartTLS don't default to "fail if TLS doesn't work" and don't tell the user anything about it, and it makes me hate StartTLS even though the fault isn't directly with StartTLS.
[0] https://github.com/jedisct1/pqconnect/blob/6d093005ed164ff31...
“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. [The installation also requires root access.]
“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. […]”
I would have expected information about OS support, and on which application/OS layer PQConnect operates, on the Intro page.
There is also VPN software that incorporates PQC (also referenced): <https://rosenpass.eu>
What this project attempts to do is to establish a transparent PQC stream between client and server.
I'm not sure I like the way they are doing this, with a lot of magic (PQConnect inserts itself into the network stack to inspect incoming DNS responses) and with Python of all things.[1][2][3]
I think the best way to do this is to graft it on top of QUIC and not mess with linux network plumbing. Perhaps integrate it with something like <https://github.com/n0-computer/iroh>
[1] <https://www.pqconnect.net/pqconnect-20241206.pdf>
[2] <https://www.pqconnect.net/20241227.pdf>
[3] <https://github.com/jedisct1/pqconnect/tree/main/src/pqconnec...>
Python source code available at
www.pqconnect.net/pqconnect-1.2.1.tar.gz
I think a short explanation of how this actually works (not the post-quantum crypto part, but rather the plumbing into the networking stack of your box) would be very helpful.
[EDIT]: an a very quick first glance at the python source code and the install scripts reveals that a PQconnect install performs rather intrusive changes to your system:
I'm going to take a wild initial guess and assume that there's some dynamic manipulation of low-level networking state (routing tables, iptables, etc...), which makes me rather queasy to install this on a production and/or work system because I have no idea if it is going to wreck my existing setup.Also, the server is written in python ... I most certainly hope the python code is not in any way processing / redirecting network traffic itself in userland, or performance is going to be awful.
All of this points to the fact that an overview of how pqconnect grafts itself into your Linux system would be most welcome.
It's to provide information about the link. People in HN don't know Levin (yet). The nave conveys no information. . Everybody knows DJB and Lange.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
This looks like basically a McEliece/SNTRUP version of Colin Percival's spiped.