[HN Gopher] PQConnect: Automated Post-Quantum End-to-End Tunnels
___________________________________________________________________
PQConnect: Automated Post-Quantum End-to-End Tunnels
Author : nabla9
Score : 70 points
Date : 2024-12-27 13:30 UTC (1 days ago)
(HTM) web link (www.pqconnect.net)
(TXT) w3m dump (www.pqconnect.net)
| arj wrote:
| Does not seem like the source code is available?
| nemoniac wrote:
| Click through to "For users".
|
| Python source code available at
|
| www.pqconnect.net/pqconnect-1.2.1.tar.gz
| ktm5j wrote:
| https://github.com/jedisct1/pqconnect
| cpach wrote:
| https://www.pqconnect.net/user.html
| orlp wrote:
| 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 wrote:
| 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.
| tptacek wrote:
| You're not supposed to do that in links on HN.
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu.
| ..
| layer8 wrote:
| It wasn't clear to me that DJB and Lange in the title were
| names of persons.
| tptacek wrote:
| 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 wrote:
| Doesn't sound a lot different than Tailscale co-option
| (commercially) of Wireguard?
| fulafel wrote:
| Does Tailscale support opportunistic use so that other people
| running Tailscale will transparently use it when they connect
| to you?
|
| Also, "Today, Tailscale's WireGuard implementation is not
| post-quantum secure" (from
| https://tailscale.com/kb/1460/post-quantum-cryptography)
| layer8 wrote:
| From the Compatibility page:
|
| "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.
| ur-whale wrote:
| 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.
| coppsilgold wrote:
| 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>
|
| [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...>
| philsnow wrote:
| > 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.
|
| [0]
| https://github.com/jedisct1/pqconnect/blob/6d093005ed164ff31...
| fulafel wrote:
| From the paper:
|
| "Our threat model includes attackers controlling network
| routers near the legitimate DNS servers. It also includes
| attackers using NSA's QUANTUMINSERT man-on-the-side attack
| technique (no relation to quantum computing), which injects
| fake responses to DNS queries before the real responses arrive
| (see, e.g., [32]); the real responses are then ignored."
|
| Their proposed ways to tackle these (following the above, see
| the paper) seem decidedly imperfect though.
| fulafel wrote:
| The team sounds impressive:
|
| "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."
___________________________________________________________________
(page generated 2024-12-28 23:02 UTC)