-
Notifications
You must be signed in to change notification settings - Fork 855
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Management of Harvest Now, Decrypt Later
("HNDL") and Post-Quantum Safety
("PQS")
#1536
Comments
SOPS basically works as follows:
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 :) |
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:
Harvest Now, Decrypt Later
strategy and Post Quantum Safe Cryptography FiloSottile/age#578The text was updated successfully, but these errors were encountered: