New entry: store-now-decrypt-later-isnt-taken-seriously-enough

1 files changed, 17 insertions, 0 deletions

diff --git a/content/entry/store-now-decrypt-later-isnt-taken-seriously-enough.md b/content/entry/store-now-decrypt-later-isnt-taken-seriously-enough.md
new file mode 100644
index 0000000..f0d11b5
--- /dev/null
+++ b/content/entry/store-now-decrypt-later-isnt-taken-seriously-enough.md
@@ -0,0 +1,17 @@
+---
+title: "Store Now Decrypt Later Isn't Taken Seriously Enough"
+date: 2025-11-23T00:00:00Z
+tags: ['computing']
+draft: false
+---
+There is always the possibility that some new mathematical technique breaks existing encryption algorithms. We should not therefore say that all encryption is insecure. Rather, we should change our conception to reflect that **encryption has an expiration date**. A lock is the most common analogy for encryption, and it's fine for helping beginners grasp the concept, but a [countdown timer](/2022/03/23/encryption-is-a-timer-not-a-lock/ "Journal Entry: Encryption is a Timer, Not a Lock") is more apt in this context.
+
+The countdown timer represents how long encrypted data will stay secret for. It has no markings on it for us to know how long until its dial reaches zero (representing the data becoming decryptable), so we can only estimate. Following that analogy, using classical encryption instead of hybrid encryption (classical + quantum-resistant) is like winding back the dial halfway when you could wind it back all the way.
+
+There's software out there whose users' data is vulnerable to [store now, decrypt later](https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later "Wikipedia: Harvest now, decrypt later") attacks in the near term not as a result of the aforementioned inevitable mathematical advances, but rather due to the software developers just not winding back the dial all the way (using quantum-secure libraries).
+
+We don't know how soon practical [Shor-capable](https://en.wikipedia.org/wiki/Shor%27s_algorithm "Wikipedia: Shor's algorithm") quantum computers will hit the scene, but there are good reasons to suspect that they're not far off. So developers should anticipate that any data sent today using classical encryption algorithms might be intercepted and retroactively decrypted in the near future.
+
+If you're a developer, it is irresponsible to subject users to this risk when it can be avoided. There are quantum-secure cryptographic libraries available for mitigating it. Too many software projects that don't need backwards compatibility still lack quantum-resistant encryption and still market their software as private and secure. I think some gatekeeping is in order...
+
+**If you're writing software that transmits sensitive data over the internet in current year and it has no compatibility requirements and isn't quantum-resistant, then it's not private or secure and marketing it as such is false advertising.**