Slashdot Mirror


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?

4 of 167 comments (clear)

  1. QR Code? by Anonymous Coward · · Score: 5, Informative

    How big are these keyfiles? QR codes can encode up to 4,296 characters, and have alignment-assisting and error-correcting features built in.

    https://en.wikipedia.org/wiki/QR_code

    1. Re:QR Code? by Junta · · Score: 5, Interesting

      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.
  2. There should be a federal registry by Anonymous Coward · · Score: 5, Funny

    There should be a federal registry for keyfiles. That way, in the event of having a warrant and needing to conduct a search, law enforcement readily has access to the keyfile. You benefit from this because there's a secure backup maintained by the government rather than a business that can change the services they provide, be sold, or cease to operate. A federal registry is a great solution to these problems.

  3. Re:printed/scanned versions are fine by arglebargle_xiv · · Score: 5, Funny

    I have another approach, I simply never have an original or interesting thought, ever. Because of that there's nothing to keep secret, so I don't need any encryption keys.

    Oh, I'm head of programming for a major US network, in case you were curious.