Ask Slashdot: How To Keep Keyfiles Secure, But Still Accessible?
New submitter castionsosa writes: With various utilities like borgbackup, NetBackup, zbackup, and others, one uses a keyfile on the client as the way to encrypt and decrypt data. Similar with PGP, GnuPG, and other OpenPGP utilities for the private keys. However, there is a balance between security (keeping the keyfile in as few places as possible) and recoverability (keeping many copies of it). Go too far one way, and one will be unable to restore after a disaster. Go far the other way, and the encryption can wind up compromised.
I have looked at a few methods. PaperBack (which allows one to print a binary file, then scan it) gives mixed results, and if there is any non-trivial misalignment, it won't retrieve. Printing a uuencoded version out is doable, but there would be issues for scanning, or worse retyping. There is obviously media storage (USB flash drive, CD-ROM), but flash isn't an archival grade medium, and optical drives are getting rarer as time goes on. Of course, stashing a keyfile in the cloud isn't a wise idea, because once one loses physical control of the medium the file is stored on, one can't be sure where it can end up, and encrypting it just means another key (be it a passphrase or another keyfile) is stored somewhere else. I settled upon having a physical folder in a few locations which contains a USB flash drive, CD-R, and a printed copy, but I'm sure there is a better way to do this.
Has anyone else run into this, either for personal recoverability of encrypted data, or for a company? Any suggestions for striking a balance between being able to access keyfiles after disasters of various sizes (ransomware, fire, tornado, hurricane) while keeping them out of the wrong hands?
I have looked at a few methods. PaperBack (which allows one to print a binary file, then scan it) gives mixed results, and if there is any non-trivial misalignment, it won't retrieve. Printing a uuencoded version out is doable, but there would be issues for scanning, or worse retyping. There is obviously media storage (USB flash drive, CD-ROM), but flash isn't an archival grade medium, and optical drives are getting rarer as time goes on. Of course, stashing a keyfile in the cloud isn't a wise idea, because once one loses physical control of the medium the file is stored on, one can't be sure where it can end up, and encrypting it just means another key (be it a passphrase or another keyfile) is stored somewhere else. I settled upon having a physical folder in a few locations which contains a USB flash drive, CD-R, and a printed copy, but I'm sure there is a better way to do this.
Has anyone else run into this, either for personal recoverability of encrypted data, or for a company? Any suggestions for striking a balance between being able to access keyfiles after disasters of various sizes (ransomware, fire, tornado, hurricane) while keeping them out of the wrong hands?
I don't know why you think that scanning things is going to be hard, OCR works very well these days, especially if you use a font like OCR-A which is intended for scanning. You can also print out a checksum of the key if you'd like as well. Or you could use some QR code variant to store the key too. Storing digital data on paper is mostly a solved problem these days.
Then again, it doesn't sound like you actually want any solutions, you just want to rule all of them out...
Why not print the encrypted key as a QR Code?
Similarly, you could use Shamir Secret Sharing with a theshold to break the key up into N shares which could be provided to people you trust. Then, your (or those you designate - include law enforcement) could recover the keys provided they have the threshold number of shares.
Maybe when burning such info into a crystal becomes cheaper and feasible for the common person, it could be burned into one for all posterity.
Yes, I've never seen a QR code have a problem scanning in from even pretty crappy photos.
However, I'd probably store the actual keys and encrypt them as usual, using the QR code to only store the key that decrypts the key (which can be 20 printable characters and still be damn near impossible to crack, requiring on average 20 billion millienia even if you could brute force a quadrillion guesses a second).
XML is like violence. If it doesn't solve the problem, use more.