posted: may 17, 2026

Post-quantum Cryptography for Homelabs and SysAdmins

Are your favorite tools and systems already secure?

Chase Berry

brief intro

just a few terms to touch on

There are plenty of posts online about this topic, so I am going to skim the background info here:
Quantum-day (Q-day): A theoretical “day” where quantum computing becomes powerful enough to easily crack today’s public-key cryptography [1].

Post-quantum Cryptography (PQC): Cryptographic algorithms designed to be secure against an attack by a quantum computer [2].

Harvest Now, Decrypt Later (HNDL): The concept of collecting cryptographic keys and storing them until having the required compute power to crack them [1].

Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM): A type of NIST-approved cryptographic scheme that is used to establish a shared secret key between two communicating parties. This shared secret key can then be used for symmetric-key cryptography [3, Sec. 3.1].

Module-Lattice-Based Digital Signature (ML-DSA): A type of NIST-approved cryptographic scheme which generates a unique public key from a party’s private key. This digital signature can be used to detect unauthorized modifications to data, authenticate the identity of the signatory, or demonstrate a signature was generated by a signatory [4, Sec. 3.1-3.5].

Stateless Hash-Based Digital Signature (SLH-DSA): A type of NIST-approved cryptographic scheme which generates a unique public key from a party’s private key. This is a bit less “general-purpose” than ML-DSA [5].

what’s the point?

As computing power grows, it becomes increasingly likely that the cryptography we use today can be cracked in the near future. Any key or password that is stored today can be harvested by threat actors, which they can keep until we reach Q-day. I can already hear you saying “My systems are locked down” and “I change my passwords” but do you really?

Especially with critical vulnerabilities becoming more common; for example, in the past month, there were four critical zero-day vulnerabilities: Copy Fail (CVE-2026-31431) [6], Dirty Frag (CVE-2026-43284 / CVE-2026-43500) [7, 8], and Fragnesia (CVE-2026-46300) [9] and each of those vulnerabilities affects every version of the Linux Kernel for the past decade.

implementing pqc locally

password managers

We all assume our password managers are safe… why else would we use them? It doesn’t matter what password manager you use, whether it’s locally-hosted or cloud-hosted, you believe yours is the best. If someone got their hands on the database that stores your passwords, would those passwords be safe from a HNDL-style attack?

lastpass

LastPass uses the PBKDF2-SHA256 with 600,000 iterations [10] to store passwords securely. If your password was a randomly-generated 12-character password with uppercase letters, lowercase letters, and numbers, that gives us 62 possible characters. A modern computer would need to check $O(N)$ operations, which is $3.2*10^{21}$ attempts to brute-force. Grover’s Algorithm is able to do it in $O(\sqrt{N})$ operations [11], reducing the worst-case scenario to $5.6*10^{10}$ operations. That means the password vaults are quantum-resistant.

When you share a password from your vault or an “emergency access key” with another user, LastPass uses PKI for sharing that data with the other user [12]. LastPass will use a user’s public key to encrypt your password, then the user receiving the data can use their private key to decrypt it, using RSA-2048 [12]. In other words: if you give someone an emergency access key to your vault, your entire vault’s decryption key is encrypted with RSA-2048 and sent to the other user, since that uses a public key to encrypt the data and that is stored on LastPass’ servers, so if a threat actor intercepts the traffic with a MitM attack or gains access to the servers, they are able to get the public key AND the encrypted data… A quantum computer with 100,000 qubits can crack RSA-2048 encryption in about a week or two [13, 14] and 500,000 qubits could do it in “just a few minutes” [15]

Also, the LastPass breach from 2022 [16] contained those RSA-2048 encrypted keys.

bitwarden / vaultwarden

Bitwarden uses the same PBKDF2 algorithm with 600,000 iterations as LastPass for vault data and the same RSA-2048 PKI for shared passwords, vaults, and emergency access [17].

1password

1Password is using TLS1.3 and if your browser supports it, all of your data is transferred using X25519MLKEM768, which is a hybrid encryption that uses ECC AND the NIST recommended ML-KEM algorithms. [18]
They also have a roadmap outlining all of the PQC efforts they have started working on in 2026-04-01 which you can review in [19].

nordpass

Nord wants to be different and they decided to rely on the XChaCha20 encryption algorithm [20, 21]. XChaCha is a symmetric algorithm and is weakened by Grover’s Algorithm, but the keys are large enough to make them to be highly quantum-resistant [22], similar to PBKDF2.

ssh

OpenSSH 9.0 supports PQC algorithms and OpenSSH 10.0 enables and prefers them by default [23].

client

You can verify if your installation has those PQC algorithms by querying the KEX options:

$ ssh -Q kex | grep -E "sntrup761|mlkem768"
sntrup761x25519-sha512
sntrup761x25519-sha512@openssh.com
mlkem768x25519-sha256

If your client isn’t using those algorithms, you can edit ~/.ssh/config or /etc/ssh/ssh_config to add:

Host *
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512

server

You can verify if your SSH Server has PQC support by checking the daemon’s effective configuration:

$ sudo sshd -T | grep "^kexalgorithms"
kexalgorithms sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256

If your server doesn’t show the “sntrup761” or “mlkem768” keys OR if those keys aren’t the first ones in the list, you can add KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,curve25519-sha256 to /etc/ssh/sshd_config.

connections

To verify if you’re using a PQC-compliant algorithm when connecting to an SSH server, you can use the -v flag to see the debug data:

$ ssh -v [user]@[host]
debug1: OpenSSH_10.3p1, OpenSSL 3.6.2 7 Apr 2026
[truncated]
debug1: kex: algorithm: sntrup761x25519-sha512
[truncated]
Enter passphrase for key [redacted]:

keygen

When you generate a key with ssh-keygen, the current recommended option is still Ed25519. OpenSSH supports PQC-compliant connections, but they do not have a PQC-compliant identity private key yet.

vpn

expressvpn

ExpressVPN upgraded Lightway to use ML-KEM in 2025 [24]. They also have a blog post that outlines more PQC changes they are making in [25].

nordvpn

NordVPN launched PQC-compliant algorithms across its entire ecosystem [26]. It started in 2024 and finished a few months ago, and they offer instructions for turning on post-quantum encryption in [27].

mullvadvpn

Mullvad made quantum-resistant tunnels the default in early 2025 [28].

wireguard

WireGuard currently is not post-quantum secure because of how handshakes are performed [29]. Although, WireGuard supports pre-shared keys, which allows users to configure WireGuard to be quantum-resistant [30].

local accounts

linux

Linux stores all local passwords in the /etc/shadow file, which makes it very tempting for a threat actor to get their hands on. The good news is since Linux only stores the password hashes, they fall under Grover’s Algorithm, so as long as you configure your system to use a strong hashing algorithm, it’ll be quantum-resistant.

The modern default encryption algorithm used by most distributions is Yescrypt [31], the last default was SHA-512 and then SHA-256 before that. You can tell what algorithm was used for a specific password because there will be a prefix applied to it. The prefixes for the algorithms mentioned above are $y$ , $6$ , and $5$ , respectively.

windows

Windows has been making changes to be quantum-resistant [32] and changes are still coming with the road map stating the PQC early-access window ends in 2029 [33]. There is more information on transitioning to the new Cryptography APIs, Server Certificates, and TLS protocols in [34].

For local accounts, Microsoft recommends disabling NTLM and using IAKerb and Local KDC for user authentication - which will be default in the next version of Windows Server [35].

macos

Apple has taken great steps to maintaining their reputation of security, pretty much everything is already quantum-resistant [36]. Every system is using PQC-compliant or quantum-resistant algorithms and they’ve already enforced them across all of their modern devices.

outro

action items

Some of the immediate action items for everyone are:

Regularly rotate passwords AND keys, sometimes keys might be hidden, like in password managers that has the ability to share passwords or access with other users with an RSA-2048 key usually has an extra step to rotate those keys.
Ensure your remote access tools and applications use TLS1.3 or another PQC algorithm to communicate.
Verify your stored passwords are secure, especially the Root account in Linux and disable NTLM in Windows.
Keep up-to-date on critical vulnerabilities and regularly update your systems.