uppose you had some documents that your competitors must never see.
What documents? Oh, I don't know, maybe the one where you confess to
poaching their CFO, or where you document your idea for cheaply producing
large quantities of antimatter. Whatever they are, if they went out on the
Internet, they'd cause problems. So you encrypt them and forget
about them.
Ten years later, suddenly realizing how cool it would be to ask your friend to hold your beer while you refit your pickup truck to run on antimatter, you try to decrypt your document. But you discover that the software you used is now Functionality Unknown, Computer Kaput due to Evaporating Dependencies.
This is SOP in Linux. Remember that time they changed the executable file
format from a.out to elf, making all existing
software un-executable? Or that time when some killer programmer created
a killer filesystem that had the unique property of wiping your hard drive
when we upgraded the kernel? Remember Motif, OpenGL, and 32-bit libraries?
About ten years ago I encrypted a file with an app called des.
Thanks to the ubiquitous use of shared libraries, des now
only runs if I install 32-bit libraries. Debian has them . . . for now.
And of course DES is obsolete, no doubt soon to be dropped.
Then there's the problem of remembering which type of encryption you used.
Openssl still supports 15 different types of DES and 18
different types of AES: aes128, aes192, and aes256 in plain, cbc, cfb,
ctr, ecb, and ofb. Actually 36 if you count 'salted' vs 'unsalted.'
But it doesn't detect the encryption type automatically: if you forget
which one you used, you have to run through all 18.
Just for fun, and because I have no life, I compared the output of
three popular command-line password-based encryption programs in Linux:
Openssl, aescrypt, and ccrypt.
The outputs were completely different: each one could only decrypt files
produced by itself. Usually, but not always, they refused to produce any
decrypted output if the 'magic number' wasn't present. Some encode the
data in base64, some delete the original, and some don't. Some salt the
password by default and some don't. Yet the encrypted parts never matched.
I haven't yet looked at the source code to see why they're incompatible,
but it scarcely matters. After hours of testing with different parameters,
I had zero success getting one to decrypt the output of the other.
Conclusion: if the original app disappears, there's a good chance that whatever you encrypted is gone forever.
I suppose the general idea is to give as little information as possible to a potential attacker. But this needs to be weighed against the risk of losing the information altogether. If that risk is higher than the risk of exposure, people will simply not use encryption. Or they'll write their own. The only way to prevent that would be for programmers to agree on a standardized header that allows for compatibility among different software.
Conclusion: If you want to encrypt something, you jolly well better keep a copy of the source around and hope it still compiles fifteen years from now. On the other hand, if the CIA comes after you and demands that you decrypt those plans to conquer the universe, you now have an excuse. And then you get to experience being waterboarded. Win-win!
jul 01 2023, 6:55 am
