234

So, I want to start using pass, but I need a GPG key for this. This application will store all of my passwords, which means it's very important that I don't lose my private key, once generated.

Hard disks break, cloud providers are generally not trusted. Not that I don't trust them to not mess with my key, but their security can be compromised, and all my passwords could be found.

So, where can I safely store my GPG private key?

boleslaw.smialy
  • 1,627
  • 2
  • 15
  • 25
Florian Margaine
  • 2,465
  • 3
  • 13
  • 10
  • Mine is simply stored in the OpenPGP application. –  Feb 19 '14 at 08:38
  • 2
    I keep my private key store on the cloud and on a thumbdrive that I usually have with me. Of course it has a _good_ passphrase. It's really about balancing risk and accessibility. I could easily imagine a situation in which I'd handle my keys very differently. – Dominykas Mostauskis Feb 21 '14 at 10:24
  • 1
    Um, you *do* have good backups of your hard disk, right? – Bob Brown Nov 13 '14 at 12:13
  • On a smartcard. –  Dec 30 '14 at 07:52
  • Secret sharing? – CMCDragonkai Apr 21 '15 at 23:38
  • 5
    *pass* can leak account information via its filenames and directory structure. This may or may not matter to you, but it's something to be aware of. – Todd A. Jacobs Sep 26 '15 at 07:32
  • Could you please expand on this: "Worth noting you can protect your private key with a passphrase, so even if it's hosted with a cloud provider they can't see your private key, but then all your password security is reduced to that passphrase ". I'm confused here. Is it not yet more secure if you keep your key printed somewhere? When you scan it or whatever at the point of decryption isn't that password any added level? – RichieHH Nov 30 '20 at 08:20

15 Answers15

181

I like to store mine on paper.

Using a JavaScript (read: offline) QR code generator, I create an image of my private key in ASCII armoured form, then print this off. Note alongside it the key ID and store it in a physically secure location.

Here's some that should work for you no matter what operating system you use, as long as you have a browser that supports JavaScript.

For Windows users:

Click here to download the JavaScript QR code generator: https://github.com/davidshimjs/qrcodejs/archive/04f46c6a0708418cb7b96fc563eacae0fbf77674.zip

Extract the files somewhere, then proceed edit index.html per the instructions below.

For MacOS or Unix users:

$ # This specific version is to avoid the risk that if someone hijacks `davidshimjs`'s 
$ # repository (or he goes rogue), you will still be using the version that I vetted.
$ # For the truly paranoid you don't trust GitHub either, and you will want to verify the code you download yourself.
$ wget https://github.com/davidshimjs/qrcodejs/archive/04f46c6a0708418cb7b96fc563eacae0fbf77674.zip
$ unzip qrcodejs-04f46c6a0708418cb7b96fc563eacae0fbf77674.zip
$ cd qrcodejs-04f46c6a0708418cb7b96fc563eacae0fbf77674/
$ # We need to edit index.html so that it supports pasting your PGP key
$ # Open the file in a text editor like Notepad, vi, or nano
$ vi index.html

Change line 11 from:

<input id="text" type="text" value="http://jindo.dev.naver.com/collie" style="width:80%" /><br />

to:

<textarea id="text" type="text" value="http://jindo.dev.naver.com/collie" style="width:80%" /></textarea><br />

Now navigate to the directory you get here with Explorer, Finder, or Nautilus, etc.

For example:

$ pwd
/Users/george/Documents/Code/qrcodejs/qrcodejs-04f46c6a0708418cb7b96fc563eacae0fbf77674
$ open .

Viewing the directory in Finder

Now, double click on the index.html file you just edited and saved.

QR code being generated

You will most likely need to break up your PGP key into quarters or even smaller to create nice big QR codes that you can easily scan later. After pasting in the text area, click away from the text box and your QR code should appear. Save each one as you go and name them appropriately so that you know their order!

After you've created all the codes, scan them with, for example, a mobile phone QR code scanner app. For the paranoid, keep this device offline once you've installed a barcode reader and then perform a full wipe and factory reset of the device before putting it back online. This will prevent the QR scanner app from leaking your PGP key.

If you have a large key or lots of keys I recommend paperbak, although be sure to write down instructions on how to recover the data later. Just as important as how you back it up is how you restore it from a backup. I'd probably try this with dummy data just to be sure you know exactly how it works.

Worth noting you can protect your private key with a passphrase, so even if it's hosted with a cloud provider they can't see your private key, but then all your password security is reduced to that passphrase rather than the full private key, not to mention cloud providers can disappear overnight.

deed02392
  • 4,038
  • 1
  • 18
  • 20
  • 1
    Of all the answers, this seems the least risky to me. – zigg Feb 18 '14 at 13:48
  • 8
    +1. I've been using hard copies for backing my private keys since 1997, and have had to restore them twice. First time I used plain ASCII text in Courier and had to use OCR to restore them, which worked but did need manual error correction. The second time I used barcodes (actually a sequence of long 1D barcodes rather than a 2D barcode) and the restoration process was much easier. – Jules Feb 18 '14 at 15:31
  • 9
    I do the same. Go the extra mile and think about how paper can degrade, e.g. If an inkjet print gets wet -- put the paper in a ziplock bag, put a second copy in a safe or safety deposit box etc. – Chris Johnson Feb 18 '14 at 20:01
  • Here are some instructions for generating a QR code on the command line: [gist.github.com/fordhurley/9080024](https://gist.github.com/fordhurley/9080024) – ford Feb 18 '14 at 21:03
  • 3
    @ChrisJohnson Or print it on cardstock, preferably with a laser printer (plastic fused onto the page!) and laminate it. Pretty sure that'll last a good few decades, even if not stored properly. Dark place to protect against UV degradation. – Bob Feb 18 '14 at 23:00
  • 17
    Just as an option, paperkey also exists: http://www.jabberwocky.com/software/paperkey/ – Florian Margaine Feb 19 '14 at 09:03
  • @FlorianMargaine Nice Florian. The reason I went with QR codes is because of their wide use (by far the most used glyph by consumers), the ease of reading the code (if it fades I could feasibly regenerate it manually) and the built in error correction. I would just be concerned that I'd have to backup that software as well just in case it disappeared or became hard to retrieve. – deed02392 Feb 19 '14 at 13:32
  • Firefox has an add-on to prepare QR codes offline: https://addons.mozilla.org/pl/firefox/addon/OfflineQR/ – boleslaw.smialy Feb 19 '14 at 13:59
  • Finding a QRCode generator is actually harder than it seems. The FF addon or qrencode don't work on GPG keys. Any suggestion? – Florian Margaine Feb 20 '14 at 09:48
  • This one works well for large amounts of text http://www.princeton.edu/~stephenm/HTML5+QR/HTML5-QRCode-Generator.html. You may need to scan the QR and decode with an image decoder rather than with a smartphone. Something more reliable for huge keys would be http://ollydbg.de/Paperbak/. – deed02392 Feb 20 '14 at 10:40
  • 8
    @crdx This question was asked from a back-up point of view. For real time usage the most secure method would be an OpenPGP smart card with hardware pin entry. – deed02392 Feb 21 '14 at 09:13
  • 1
    @crdx no, the QRCode is for the absolute-last-solution. An USB stick with the private key next to the paper is probably a good solution for quick restores, but has a relatively-high chance of failure. – Florian Margaine Feb 21 '14 at 10:58
  • The only thing I don't like about that is I could have a malicious QR reader, unless the key is encrypted. – johannestaas Jun 29 '14 at 20:34
  • @johannestaas It's straightforward to encrypt the keys before backing them up although I'd prefer not to rely on remembering the pass-phrase. A backup in a physically secure location trumps encryption, IMO. You could use an open-source QR reader on an off-line device and then destroy all the data on it before putting it on-line again. – deed02392 Jul 01 '14 at 11:23
  • 1
    @deed02392 The QR code generator you linked to is no longer online, and the archive.org version (https://web.archive.org/web/20131019031808/http://www.princeton.edu/~stephenm/HTML5+QR/HTML5-QRCode-Generator.html) doesn't work. Any other suggestions for where to find this? – Jason Sep 25 '14 at 15:47
  • Has no one found a good QR generator for this? – Sauce McBoss Nov 02 '14 at 15:56
  • According to Wikipedia a QR-Code can take about 2950 bytes, where the private key part of my GnuPG key backup alone is already >> 3000 bytes. It would work with several offline tools if one splits the backup in several smaller chunks. – Marcus Bitzl Jan 04 '15 at 19:31
  • How does it take for paper or its ink to decay? – CMCDragonkai Apr 21 '15 at 23:35
  • 5
    Don't forget to wipe the printer's memory afterwards. – Matthew Dean May 18 '15 at 02:49
  • what does JavaScript supposed to mean here? if it's a joke I think this is the wrong time to make jokes... – n611x007 Oct 24 '15 at 08:05
  • 1
    @naxa the point is not transmitting your private key over the Internet. If it's encrypted then that's OK, but otherwise you want to use Javascript because that means only your computer sees the data. I will try to find a new solution and update my answer. – deed02392 Oct 24 '15 at 10:14
  • Does anyone recommend i store the keys in a file encrypted with my private key passphrase (40 random characters) on Google Drive? – user311982 Feb 22 '16 at 21:44
  • 4
    I just did this. Printed QR codes, scanned them, compared, yay it's working. It's hard to describe the crypto-anarchic-geeky feelings that I'm feeling right now. – Kit Johnson Jun 10 '16 at 06:47
  • 1
    @oldmankit Attaboy! I suggest you have a passphrase on the keyfile too, so that when it's scanned that your actual private key isn't for example stored in the scanner's memory. – deed02392 Jun 12 '16 at 13:42
  • 1
    Interesting conversation we have going here. IMO, for a related topic using keys, with DevOps, we do not have key management at all. Every build of the system generates new keys and if a server is having issues, then we architect them in a way that they are all ephemeral and can be rebuilt with a button click. The private keys are always thrown away during AMI baking. – Ligemer Aug 26 '16 at 20:44
  • Since this whole thread is a little light on details: [this answer on unix.se](https://unix.stackexchange.com/a/280791/288980) is pretty helpful. Using his `split` method with `qrencode` I managed to get it working. Please note my comment about byte size and QR code complexity/practicality. – mas Jan 01 '19 at 22:42
  • 1
    @malan For my keys that are too big to make QR codes from (e.g. RSA ones) I prefer to use paperbak – deed02392 Jan 02 '19 at 14:45
  • 1
    In order to solve this problem of needing to cut stuff by hand, copy paste on a single pdf etc, I am trying to write a small file to qr-codes on A4 pages script in bash: see qrdump here: https://github.com/jerabaul29/qrdump . Help welcome. Of course, possible uses go beyond this example, but this is the reason why I wrote this in the first place (and to be able to dump my pass tree after zipping). – Zorglub29 Mar 31 '20 at 16:09
  • (see more details in dedicated answer under). – Zorglub29 Mar 31 '20 at 16:43
  • _Any idea_ that uses QR codes is a bad one, no matter how smart they are, sorry. Also, unless you code something completely by yourself or at least read an open source offline implementation and _compile it yourself_, you are ultimately blindly trusting that the QR software is not going to steel your scanned content. And to add more paranoia to the game, it is proved that QR codes can be spied on very easily, even from long distances or using low resolution cameras/video, so make sure your windows (no pun intended) are closed. – Victor Schröder Jan 27 '21 at 09:53
  • @VictorSchröder your comment could be more useful if you stated your threat actor. It is not clearly discernible from your proposed scenario that indeed the software generating the key material is not also compromised in the same way you suggest the QR code generating software is – deed02392 Jan 27 '21 at 12:29
  • I agree @deed02392. Both ends need to share the same concerns and the OS as well. However it is well known that machines used to generate such keys have to be physically disconnected from all kinds of network and must not have any wireless capable hardware installed. This mitigates most of the problems one could have while generating the key. The same can't be said when the final result is an optical representation of the key, that can be captured without compromising the original machine. – Victor Schröder Jan 27 '21 at 13:03
  • @VictorSchröder I am not so sure that this fact is well known. I think that anyone who took such measures would probably also be capable of taking the necessary extra measures for the QR code generation, i.e. generating it on the same offline machine and rendering it in a way it cannot be spied upon. Again, I think you are not being specific enough with your concerns. Even your suggestion to use a machine that is _capable_ of wireless data transmission should be improved upon by using a dedicated crypto hardware device if your threat-actor is a nation state for example. – deed02392 Jan 28 '21 at 10:48
  • @deed02392, maybe you are right and these measures are not so well know and I'm definitely not even trying to cover the whole subject. Well... the comments section in a Q&A community is not exactly the best place to be fully comprehensive about these topics and maybe that's not convenient. In my opinion, this is a place to raise awareness about relevant topics, given the diverse audience we have here. Hopefully it will give people enough to look for more guidance and information. – Victor Schröder Jan 29 '21 at 08:40
73

On the days when my paranoia is like a ripe tomato, begging me to pick it, I split the private key (naturally it is already passphrase-protected) in half, then make a 3rd string by XOR-ing them together. Then I use simple password encryption (gpg --symmetric) on each string, and put each on a remote server on a different continent. Ideally, each remote server is with a different ISP or cloud provider.

But as the medicine was working -- at least until I realized how ambitious the NSA has been -- what I've actually done in the past is merely encrypted the (whole) private key (again using gpg --symmetric) and put it on my smartphone.

Now, having read the other answers, I'm finding the idea of three QR codes, embedded into three family photos, blindingly attractive. Time for stronger medicine?

Darren Cook
  • 871
  • 6
  • 6
39

This is not what I currently use, but I am thinking about it:

  1. Encrypt the private key with very long symmetric encryption key
  2. Use Shamir's Secret Sharing to split the symmetric encryption key to 7 pieces (like Voldemort), require at least 5 shares to merge successfully.
  3. Figure out where to put 7 secret backups, some ideas:
    • media card in a safe at home
    • printed paper in my wallet
    • in Dropbox
    • overseas safe deposit box
    • skin implants
    • buried in some random dude's grave
    • tattoed to poisonous pet snake

This way, I can lose access to a couple shares and still able to access the key; while an attacker would have to compromise 5 different individually secure places where it is easy for me to access but hard for evil dark lord's henchmen in that black car in front of the house <puts on tinfoil>.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
19

One option is to encrypt your key using a passphrase, and store the encrypted key on a cloud service.

I have the key on my laptop (hardware encrypted drive) and on a Truecrypt container on an external hard drive as backup. Ok, it's not zero risk of data loss, but it's down to a level that is acceptable to me.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • 9
    As mentioned in another answer, this is very convenient, but you reduce the security of all items protected by your key to the passphrase. You also run the very real risk that your cloud service is going to find itself with different business priorities someday (cf. http://ourincrediblejourney.tumblr.com/) which could leave you high and dry. – zigg Feb 18 '14 at 13:47
  • 1
    @zigg - if you use a decent passphrase then a cloud compromise is far from "high and dry" – paj28 Feb 18 '14 at 13:49
  • 3
    "High and dry" wasn't about compromise. There are two different points being made here, broken by "You also…" – zigg Feb 18 '14 at 16:26
  • 1
    Yes, this is only as secure as your passphrase... but you can use, say, a 40-character random passphrase, and print that on paper, which you keep someplace secure. This could be a lot easier than putting the entire key in a QR code, which may be hard to recover on a computer with no camera, or if the code is too damaged. (As for cloud services disappearing... so what? If Dropbox disappears tomorrow, all my dropboxed files are already synced to every one of my devices. I can sign up for a new cloud service the next day - no loss of data!) – Josh Oct 21 '16 at 18:46
  • @zigg "but you reduce the security of all items protected by your key to the passphrase" But isn't that always true no matter where you store keys? I would think the real weakness in the entire chain is how easy the physical/virtual location is to access from a malicious party, because the last step in any location option is always going to be cracking the passwords, so that should be assumed to be solid 70+ bit password or something and the real question really becomes where to put it. – brianclements Dec 05 '16 at 01:51
16

You can keep your private key in a flash drive and keep this drive in a locker. Also, ensure that you don't use this flash drive for activities which might cause infecting it with some malware.

Jor-el
  • 2,061
  • 17
  • 24
  • 13
    So, the day I need my key because I lost my computer, I go get the flash drive, and finds it's corrupted. What do I do? – Florian Margaine Feb 18 '14 at 09:52
  • 35
    I'm asking this question because I've stopped counting the number of USB keys I've seen corrupted. – Florian Margaine Feb 18 '14 at 09:58
  • 7
    @FlorianMargaine raises a great point. USB keys—and, for that matter, WORM (a.k.a. WORN—the N stands for "never") optical media—have bad track records. That said, I might consider using this *in addition to* another, less-convenient method of backup such as the paper methods presented in other answers. – zigg Feb 18 '14 at 13:45
  • 3
    Actually, considering malware, SD card might be safer. And the small ones (up to 2GB) are quite reliable. – yo' Feb 18 '14 at 20:12
  • 4
    What I do is to store the key on a flash drive *and* paper. If I'm lucky, the flash drive just works. If not, then the key recovery is just a bit more inconvenient. Also, like with any important data, consider having more than one backup. – Miikka Feb 19 '14 at 08:07
  • flash drive can't be considered as a secure data storage unit, you should never ever rely on a usb key to store important data.... – Kiwy Feb 19 '14 at 11:44
  • Would it help to write duplicates of the key to every writable address on the flash drive? – Magnus Nov 21 '19 at 07:46
7

I keep the key (and other sensitive data like a username / password list) encrypted in a truecrypt container. This container is protected by a massive passphrase. The container is also backed up on cloud storage so edits by any of my computers will be sync'd.

It's not perfect, but if the cloud provider dies, I still have it sync'd on my computers. If the file itself is compromised, they'd have to crack the truecyrpt phrase and the key passphrase.

Josh Vander Hook
  • 171
  • 3
  • 2
    [As mentioned in another answer, this is very convenient, but you reduce the security of all items protected by your key to the passphrase. You also...](https://security.stackexchange.com/questions/51771/where-do-you-store-your-personal-private-gpg-key#comment81600_51777) as zigg pointed out in a comment – n611x007 Oct 24 '15 at 08:11
  • How long is the passphrase? – user311982 Mar 02 '16 at 04:29
6

I would use steganography to place the encrypted key in a series of 100 photos that I upload on several cloud storage (box, dropbox and ovh) for example.
So first you need to know there is something on those picture, find out what and decrypt it.
It's a bit extreme but it resist fire better than paper.

Kiwy
  • 323
  • 1
  • 13
  • +1 for "it resist fire better than paper." I still think a clustered cloud service is better then paper. – EaterOfCode Feb 20 '14 at 10:42
  • 2
    If you've encrypted the secret key, you could just as well print it and store a PDF on a cloud service. Standardisation is a big problem with steganography - you may find the application you used has gone missing when you come to needing your key back. – deed02392 Feb 20 '14 at 10:44
  • @deed02392 Well the method I propose is definitely extreme but was more here to show that if your want to hide things you have to be really careful. Also a readable pdf could be decrypted easily with a bit of brutforce while steganography implies to first find the information. but yes tools are rare and you better code your own. – Kiwy Feb 20 '14 at 10:50
  • 9
    Whilst I love the principle behind steganography, I've lost count of the number of files that have gone missing because I couldn't remember what picture I stored it in. – deed02392 Feb 20 '14 at 10:52
  • @deed02392 you should give them filenames like "no_secrets_here.jpg". Or maybe just store a map somewhere on your computer. X marks the spot ;) – Wayne Werner Dec 29 '15 at 18:31
5

I have two keys, one less secure stored on the computer and another one in an OpenPGP Card. The latter is as safe as it possibly gets because the private key never leaves the chip on the card. (Though, years ago, for best security I had to slightly modify gpg to use my card reader's secure keypad instead of getting the card's PIN from the PC's keyboard which may be prone to keylogger attacks.)

JimmyB
  • 228
  • 1
  • 6
5

I store mine inside a KeePassX encrypted file, this file is saved inside a git repository which I clone on all machines I need to use the passwords. The added benefit is that I can keep passwords synchronized while if the server for some reason destroys the file I can always use any of the cloned repositories. If I am paranoid I can put a truecrypt volume containing the KeePassX encrypted file.

Git also gives me versioning so I can always get back to previous versions of my passwords file, that's preatty neet.

dendini
  • 680
  • 2
  • 8
  • 12
  • 3
    [Yo dawg](http://i0.kym-cdn.com/photos/images/original/000/001/122/xzibit-happy.jpg), I heard you like encrypted files, so I... – IQAndreas Sep 02 '14 at 11:36
4

I really like the idea of having a very-long-term last-resort backup on paper. (Alongside an encrypted archival CD in a secure location.) I just can't find a QR generator that supports the full length of a private key, and I don't trust paperbak until they fix the AES key generation (plus it appears to be Windows-only).

I did find optar which will encode any length of data into a machine-readable format, but for now you have to compile it from C manually. [Shouldn't be hard to put something in Homebrew for Mac people, and perhaps a samaritan can maintain a Windows build, if it proves to work well.]

paperkey should be good for printing off / using OCR to restore a private key, and creating minimal characters for a barcode / QR code generator.

Duke
  • 141
  • 3
2

Do the following:

  1. Choose two numbers you like: R and C.
  2. Go to your private key row R and column C and memorize the character X you find there.
  3. Change that character to any other random value.
  4. Safely store your altered private key on more than one cloud service (different geographic locations.

The key stored there is useless without R, C and X (given that you know the trick, of course). If one can afford the time to find R, C and X, well... good luck now guessing my password.

Also memorizing R, C and X should be very easy from the perspective of the one introducing the change.

Hint: don't do it at the very beginning or end of the string. There are patterns to be followed there, it would be very easy to guess the change.

Victor Schröder
  • 121
  • 3
0

disclaimer: pointing you to a piece of code I am writing / my own 'small' solution

For solving this kind of problems (and more generally 'archiving' important, moderate-size stuff on paper) I am working on qrdump, a way to automatically

  • 1) split your data into parts that are small enough to fit in qr-codes
  • 2) dump to a series of qr codes
  • 3) assemble the qr-codes with a predefined layout into a pdf.

Of course the inverse transformation is also implemented.

For example:

bash-4.4$ FOLDER_TESTS=$(mktemp -d)
bash-4.4$ cd $FOLDER_TESTS/
bash-4.4$ head -c 4096 </dev/urandom > dummy.dat # create a random file, 4096 bytes
bash-4.4$ sha256sum dummy.dat 
02f2c6dd472f43e9187043271257c1bf87a2f43b771d843e45b201892d9e7b84  dummy.dat
bash-4.4$ bash ~/Desktop/Git/qrdump/src/qrdump.sh --create-A4 --base64 --safe-mode --output ./pdf_dump.pdf --input dummy.dat # crete a printable qr-codes pdf of the file
SAFE to use: success restoring check
bash-4.4$ rm dummy.dat # the file is removed, so from now on only way to get it back is to restore from the pdf
bash-4.4$ bash ~/Desktop/Git/qrdump/src/qrdump.sh --base64 --read-A4 --input pdf_dump.pdf --output ./ # restore
bash-4.4$ sha256sum dummy.dat # the digest should be the same as the initial one to confirm good restore
02f2c6dd472f43e9187043271257c1bf87a2f43b771d843e45b201892d9e7b84  dummy.dat

If you are interested, more here:

https://github.com/jerabaul29/qrdump

Zorglub29
  • 255
  • 1
  • 11
0

You could try memorizing it...

It might be possible to use a gzip like algorithm for humans to compress and memorize. You could encode into a tune and memorize that,

0xcaff
  • 147
  • 5
0

The private key is already encrypted. Encrypting it symmetrically once more wouldn't hurt though. After that the worry should be about physical security. Media durability and safety off site should be the main considerations. A usb key is probably ok for at least ten years as long as usb ports are available. Put the key in a safe place. A Safety deposit box or good safe off site are good possibilities. This should allow for a recovery in the event that the system you are using now breaks in some unrecoverable way. label and date the usb stick. An encrypted copy of the key's revocation certificate should also be stored with it. make a couple of duplicates if you are worried about usb stick failure.

Rick
  • 1
-4

Encode with a strong password and use it as signature on every forum you use. maybe there are mailinglists for such keys too.

enjoy
  • 11