Comment by withinboredom
4 years ago
I doubt that would work. You can’t decrypt things encrypted 20 years ago on modern API’s because those algorithms are known to be insecure. You’d have to probably rewrite it from scratch or install an old version of the browser. So it’s probably best to keep a windows version of the browser since that’s currently the only OS that can run software from 20 years ago, so hopefully they’ll still be able to do that 20 years from now.
The cryptography is insecure. The code often is secure – it's just doing an insecure thing. In this example, the encrypted data is (perhaps) insecure, because the cryptography algorithm has known exploits.
Consider a magic unpickable door lock that automatically unlocks itself at midnight. The lock has no security vulnerabilities (it's doing exactly what it's supposed to, and there's no way to subvert it), but your house probably does.
I’m not sure if anything you said makes any sense in the context of my comment, are you sure you’re replying to me?
I assumed you meant something slightly different to what you wrote, because you wrote:
> You can’t decrypt things encrypted 20 years ago on modern API’s because those algorithms are known to be insecure.
Python's standard library, C's standard library, and Win32's CryptoAPI all beg to differ. The specific algorithms used by Crypto.subtle (Rijndael, Rivest–Shamir–Adleman) are over 20 years old, already, so even that's a counterexample.
> So it’s probably best to keep a windows version of the browser since that’s currently the only OS that can run software from 20 years ago, so hopefully they’ll still be able to do that 20 years from now.
Most operating systems can run software from 20 years ago. I'm currently running a 35-year-old piece of software on the latest version of an OS that isn't Windows. (I'm not aware of modern Windows being able to do that, actually; not since NTVDM got removed.)
Does this address your comment better?
2 replies →