Management of Harvest Now, Decrypt Later ("HNDL") and Post-Quantum Safety ("PQS")

[Kreyren]

The strategy of Harvest Now, Decrypt Later relies on the ability to collect and store encrypted secrets for later decryption through e.g. sufficiently efficient Quantum Computer or in case of major vulnerability found in the cryptographic implementation.

As explained in age this appears to be a major problem as the use of GitHub API makes it trivial to collect over 23.2K files while getting a reasonable idea about what these keys are storing through the meaningful filename, for sops through it's implementation in e.g. sops-nix amounts to potentially 22.4K affected files:

Which collection is a problem now as we can't retroactively remove them from the threat actor's machine and it's sane to assume that they will be decrypted once they get access to a sufficient quantum computer.

---

Please elaborate whether is sops vulnerable to HNDL to manage PQS, if it is then the users of sops should be made aware of the privacy and security implications e.g. Mic92, the author of sops-nix recommends rotate the keys so that they are useless in 5-10 years[2] and it's probably a good idea to not use sops for sensitive files that the user is not comfortable getting exposed in 5-10+ years and if they already done that to manage that situation for their threat model.

Relevants:

1. Management of Harvest Now, Decrypt Later strategy and Post Quantum Safe Cryptography FiloSottile/age#578
2. Quantum-resistant cryptography? Mic92/sops-nix#451 (comment)
3. Quantum-resistant crypto matrix-org/matrix-spec#975

[felixfontein]

SOPS basically works as follows:

1. To encrypt values and comments in a file, it uses a randomly generated 256 bit key and AES-256 with mode GCM to encrypt (and authenticate).
2. The secret key (or parts of it, if Shamir's secret sharing is used) is then encrypted with the various key sources.

AES-256 with the GCM ciphermode can be considered PQ safe. (Except potential specific quantum computer attacks against AES - currently there aren't any I know of - there's only Grover's search, which likely won't cause much practical problems for AES-256. See for example https://crypto.stackexchange.com/questions/6712/is-aes-256-a-post-quantum-secure-cipher-or-not.)

The key sources are another topic. Here it depends a lot on the key source. If you for example use age as a key source, you're as post-quantum safe as age itself is. (So not very much.) If age adopts another algorithm that is PQS and you stick to that one, it's fine.

If you're using GPG/PGP as a key source, it depends which algorithm you have configured there. If you're using elliptic curves or RSA, you have similar problems. (RSA with larger key sizes is likely more safe than ECC once quantum computers start to get interesting, but if they really start to scale ... who knows.) Once GPG/PGP supports PQS algorithms you can use them and you should be on the safe side.

If you're using other key sources, like AWS KMS, GCP KMS, Azure Key Vault etc., you depend on the algorithms used by them (and you have to trust the vendors that they store the keys safely). I have never looked into how exactly the cryptography works for these key stores, so I cannot say more about them.

So, summing up: if you use age or GPG/PGP as keysources, you're as vulnerable as these are. The crypto that SOPS itself adds on top is likely PQS. (SOPS' crypto is agile, so we can upgrade the algorithm used if needed. So far there is no indication that it's needed anytime soon.)

Also: storing encrypted private data in public places is something I would avoid in general. It's OK for secrets that can easily be rotated (like access tokens) or don't need to be kept safe for a long time, but I would really avoid it for data I want to keep safe over a long time - simply to avoid all HNDL attacks. That's my personal opinion, though, others will likely see this differently :)