


Ask Slashdot: How To Keep Keyfiles Secure, But Still Accessible? 167
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?
printed/scanned versions are fine (Score:3, Interesting)
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...
Re:printed/scanned versions are fine (Score:5, Informative)
As a keyfile - use a text that is present in many copies over the internet. Only you know the actual text and length of it to be used as a key. That way you will never actually lose your key.
Re: (Score:2)
Such text is unlikely to have high entropy.
Re:printed/scanned versions are fine (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.
QR Code? (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
Re: (Score:3)
The first thing to bear in mind is that the keyfile doesn't have to be stored on anything more durable than whatever the backup files are on.
Personally, if it's important, I back up to multiple media anyway on the assumption that a fire, flash flood and massive EMP/magnetic anomaly won't all be hitting me at the same time. I also copy the important stuff to fresh media occasionally. Which is why I still have files that started life on 8-inch floppy disks.
So for me, a thumb drive for key files isn't such a b
Re: (Score:2)
I back up to multiple media anyway on the assumption that a fire, flash flood and massive EMP/magnetic anomaly won't all be hitting me at the same time
You idiot, you just told everyone your weak spot! Now anyone with access to firefighter truck equipped with a mounted flamethrower [wikipedia.org] and an explosively pumped flux compression generator [wikipedia.org] can delete your backups!
Re: (Score:2)
Re: (Score:2)
Yes, and you can encrypt a large key (e.g. RSA keys are big) with a symmetric algorithm.
Re:QR Code? (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).
QR Codes w/wo Shamir Secret Sharing (Score:5, Interesting)
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.
Re: (Score:2)
QR codes would probalby work well for Curve25519 keys, but when I looked at generating QR-codes from the output of paperkey with a normal GNUPG RSA key they were way too large to be practical.
I recommend Shamir Secret Sharing, though. Pick N friends, preferably who don't know each other that well and keep good backups, pick some K N, and hand out your shares to your friends. Offer to keep a share of their keys, too, if they want. The upside is that you only have to prove to people who know you well that yo
Re: (Score:2)
You can take any key you like, and then encrypt *that* using a smaller symmetric key, which would work nicely. Symmetric algorithms can use tiny keys and still be more secure than asymmetric, and are suitable for use in the context of protecting a key.
Re:QR Codes w/wo Shamir Secret Sharing (Score:4, Interesting)
A variant of this would be to use shamir's secret sharing to back up shards of your key in places you trust. Back it up one share in each of ten places with 5 share threshold; 5 have to get compromised before your secrets are lost, and if you hear about one getting compromised you can rekey for the other 9.
Re: (Score:2)
That's the premise of a Threshold-Based Secret Sharing solution. There are multiple ways to provide a scheme where you need some X of Y shares to recover a value based on WHO is trying to recover the secret.
The simplest is to implement a scheme where N shares are generated and M (where M is less than/equal) to N shares are required to recover a secret.
The same secret can be split into different numbers of shares (or, even splitting a particular share into more shares that get distributed).
Assuming that
Re: (Score:2)
Back it up one share in each of ten places with 5 share threshold; 5 have to get compromised before your secrets are lost, and if you hear about one getting compromised you can rekey for the other 9.
Or do what Tolkien did: three for the elves, seven for the dwarves, nine for mortal men, and one for yourself.
And in the darkness, bind them.
Re: (Score:2, Informative)
With respect to the lifetime of USB flash drive and CD-ROM media for key backup, your key should change more often than those items fail. That is, a typical CD-R or flash device can provide reliable storage on a shelf for about 10 years with good storage conditions.
In six years, computing will be much more powerful and a dedicated hacker would be able to break the encryption in 3 years of brute force attack. So if you kept your key for 10 years, you may already be compromised anyway. Microsoft actually ran
There should be a federal registry (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.
Re:There should be a federal registry (Score:4, Funny)
"a secure backup maintained by the government"
It's mean of you to make coffee shoot out of my nose like that, you know.
Re: (Score:2)
It's mean of you to make coffee shoot out of my nose like that, you know.
What are you talking about, you've been snorting coffee most of your life. You should send him a tip.
Re: (Score:2)
Optical Disk (Score:3)
Is the way to go.
The fact that fewer and fewer people use them simply increases your security.
If and when you replace your PC with a device that doesn't have an optical drive, then the last thing you do with your old PC is to copy the data from the disks to something new.
Till then, the fading popularity of DVDs is just an added layer of security for you.
Re: (Score:2)
Security through obscurity is the best.
Re: (Score:2)
It's as valid a layer as any other, sure as hell worked for the code talkers. But it's a layer, not a panacea.
People often confuse "incomplete" with "worthless".
Re: (Score:3)
Optical disks have horrible shelf life. They degrade over time. They are not suitable for important backups. Magnetic tapes OTOH can be purchased in archival quality.
Plastics often take a long time to fully decompose, but their optical properties degrade rapidly.
That's leaving aside the "obscurity" flamebait. ;)
Re: (Score:2)
Re: (Score:2)
I've been making images of old CDs over and the majority read without any problems (dvdisaster), even ones I burned back in the late 90's!.
Gosh, me too! And yet, for archival use, "the majority" is just too small a value.
I would switch to archival tape long, long before I would start making multiple copies with different brands of disk. What an absurdity, what a time sink.
Re: (Score:2)
Assuming the plastic doesn't melt ... :-)
M-Disc (Re:Optical Disk) (Score:2)
Source: Wikipedia.
But even ordinary CDs last (mostly) for 10-20 years in my experience, s
Use a passphrase (Score:4, Informative)
Simple: require a passphrase to access the private keys, then back then up like any other file. PGP utilities allow this, and it should suffice for anything interactive.
For anything non-interactive, it may be still be possible to use a passphrase if there is a way to load the passphrase from disk (rather then keyboard); keep the files containing passphrases as private as they keys themselves, but just recreate them if they're lost. *Something* along the line has to be committed to human memory, otherwise you fall foul to the cryptographic equivalent of the "analogue hole" (I.e. if everything needed to decrypt the data is available without human intervention, an attacker just needs that data, they don't need you).
Re: (Score:2)
Re: (Score:2)
True, though if you let your machine pick the passhprase, in python:
base64.b64encode(os.urandom(15))
You now have a 'passphrase' that would withstand billions of millenia of guessing by a system unbelievably beyond the fastest thing we can imagine today. Maybe you have to print that out to a few qr codes to remember, but oh well.
Re: (Score:2)
How long would it withstand a quantum computer cracking it?
Hint: Fast-forward 10 years for all of your assumptions.
Re: (Score:2)
No, because quantum computing has only a doubling of effectiveness against common symmetric algorithms. Quantum computing would be a bad day for RSA encryption and elliptic curve, but the symmetric ciphers are largely apathetic.
Re: (Score:2)
Re: (Score:2)
As opposed to the zero attempts required to unlock a private key file which is not protected. OP is concerned about both loss and theft of their keys; if theft is a serious possibility, I fail to see how setting a passphrase will make things less secure. Also, a passphrase is not necessarily a single word; it is - as the name implies - an entire phrase, of arbitrary length, punctuation included.
Re: (Score:2)
A passphrase is inadequate. It's like you said, "I have a treasure chest filled with soled gold in my front yard; I should put a $2 padlock for a girl's diary on it to protect it." Yeah, I'll just pull harder on the latch; that lock will pop with just the force of my bare hands, no tools needed.
"Better than nothing" is not a strong vote of confidence. A seat belt is apparently better than nothing in a land speed record attempt, but you're still going to disintegrate into a cloud of red dust if you hit
Re: (Score:2)
This is my method.
I think it is a good compromise. I use a 20+ character pass phrase which I keep stored in a password manager. I keep the password manager's files (I use roboform) in a separate location so they are not sync'd to the same cloud drive.
Both the pw manager and the cloud sync use 2FA.
It is not bulletproof but that is the nature of security tradeoffs. I am sure a government level actor could figure something out if they really wanted my data.
Just FYI (Score:2)
Keeping physical copies of keys or keyfiles makes them subject to being seized by LE upon the serving of a subpoena, at least in the U.S.
Re: (Score:3)
In a police-state, that is everybody.
Re: (Score:2)
I'm so glad that I don't live in North Korea than.
Despite everything you read, the US isn't a police state.
Re: (Score:2)
The US already is a police-state at the low-intensity end. North Korea is full-blown fascism.
Re: (Score:2)
Setting aside the point of what constitutes a police state, "isn't" != "never will be" and it's the latter that matters.
Re: (Score:2)
Despite everything you read, the US isn't a police state.
....Yet. Give them a little more time. These things take time.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
A locked door (Score:2)
I find putting my data in a room with a locked door is pretty effective.
Re: (Score:2)
I find putting my data in a room with a locked door is pretty effective.
So did one of my clients whose manager was embezzling all their money. Initially. Later, we added cameras and electronic locks, and moved all the paper ledgers to spreadsheets on a VPN.
Also, thieves planning to steal an encryption key from a physical location might be able to open a door lock pretty easily. They might in fact have a copy of the key. I'm not convinced that is actually more secure than just having it in a desk drawer.
For personal use, yeah. Absolutely. Nobody is going to steal my embarrassing
Two ways (Score:2)
Easy solution: Use a good passphrase, and a secure computer. Have a dedicated computer that is well protected and that you don't install random crap on. Back the key up properly.
Harder solution: Use a smartcard, for instance a Yubikey. They allow keeping the key safely on a small USB device that fits on a keychain. The key never leaves the smartcard, and in the very worst case, a compromise still doesn't retrieve your key, it can only succeed in signing stuff while the key is physically in the computer.
The
Re: (Score:2)
Newer Yubikeys (Yubikey 4) allows up to 4k RSA keys, as well as some elliptic-curve keys. Mind you, smartcard-based 2048-bit RSA encryption is wildly better encryption than 99.9% of the world. Especially if you're not really thwarting the NSA, 2k is FINE.
But in general you're absolutely right. Carrying around an easily copied keyfile is really no spectacular increase in security. Smartcards (where the decryption step happens on a completely separate micro-micro-processor, right there inside the same phy
Re: (Score:2)
A problem with 2048 bit keys is standards. Debian for instance wants 4096 bit keys (though they do allow 2048 bit ones), so if you start just working with the command line, making a 4096 bit key is the logical choice. If then you get a device that can't handle it you have the problem of having to deal with creating a new, weaker key just for that.
Not a fatal problem, but it's an undesirable inconvenience.
Re: (Score:2)
Harder solution: Use a smartcard, for instance a Yubikey.
Or a PivKey [pivkey.com]. If I recall correctly, the T800s have about 20 programmable keyslots, so there is a way to program multiple keys onto the unit.
I suggest having at least two offsite backup units, and check each unit at least once a year.
The harder part is having the discipline to securely update all 3 units, whenever you generate or change a key. (Never having more than 1 of the units at the same place at the same time)
Re: (Score:2)
Yubikey 4 supports 4096 bit keys.
It won't solve the entire problem.. (Score:2)
But chmod 600 is a start.
Re: (Score:2)
'chmod' is not recognized as an internal or external command, operable program or batch file.
Torrent (Score:2)
Upload it to torrent sites with the title "Paris Hilton Sex Tape.mpg"
It will look like non-working garbage to most people, and no one will know it's your encryption key. Then when you need to decrypt your stuff just download it again.
Paper and a bank vault (Score:2)
That is really your only option, unless you want to invest seriously in archival-grade tape. There used to be MOD, but nobody cared enough about their data to keep the technology alive and DVD-RAM was a poor substitute. Nothing else has good endurance.
As to paper, print QR-codes, either with a good laser or pigmented ink. Then keep several redundant copies in a bank-vault. For convenience, you can, of course keep several different good-quality memory sticks in that vault as well, but do not depend on them a
Some best practices (Score:3)
Keep one copy in a safe in a tamper evident container. Either hardcopy or something like a read-only SD card or USB thumb drive will work. Routinely open the safe and verify that the key container hasn't been compromised.
Distribute copies to trusted parties in tamper evident containers. You can also split the key up into multiple pieces and distribute different pieces to different people. Don't let anyone know who else has copies. You will also need to routinely visit these trusted parties and confirm that they have not tampered with the key container.
Be sure to protect your private key with a wrapping passphrase if supported, otherwise use encrypted media. You should also specify a reasonable expiration date for your key and use the appropriate revocation mechanism, e.g. CRLs for x509 certs and revocation certificates for PGP. You shouldn't be too worried about the longevity of your storage media since you should be periodically updating your keys. I would recommend against media with photosensitive dyes and go with the more robust M-Disc based discs.
If at all possible, do not ever let your private key touch a networked/unsecure device. Use a hardware based key manager if possible, e.g. Yubikey. Keep a separate machine booted from read-only media for the sole purpose of key creation in a secured location. You can also use this machine for encryption/decryption, but you need to transfer data via sneakernet. Definitely don't keep a WiFi card or even an audio output device in the machine. Do all of your work inside a Faraday Cage if possible.
Read up on guidance from the various organizations. E.G. NIST's Computer Security Resource Center [nist.gov]
Stuff (Score:3)
Get a safety deposit box from a bank, put the key there as an ASCII armored plaintext paper and as a QR code printed on paper. And remember to use quality paper and a laser printer. The only ones who could get access to the key would be robbers and government officials with warrants.
Re: (Score:2)
OP said he doesn't want the key to be encrypted because "encrypting it just means another key". This considered the aforementioned solution fits OP's requirements. I personally would encrypt my keys (even the backups), but if it's corporate data we're talking about there's no need for encryption of the backup key.
First Encrypt (Score:2)
Clearly step one. Encrypt them, and I assume you can store a good key somehow in a way that you have no worry of ever losing control of it.
Then simply file for some government program where all applications are public record and attach the encrypted file to the document.
Presto, free storage and easy retrieval. It worked for leaking Scientology Documents, it can work for you too!
For my own personal use (Score:2)
I use hints for my passwords and then keep the ID plus hint in a list on my smartphone's notes. The master list of hints to passwords is kept on my main PC at home with a printout kept in a safe in the bedroom.
I tend to have 3 "classes" of passwords, stuff for common access which I don't care if it gets hacked, stuff for midlevel access (where I do care but I wouldn't have any actual loss if I did) and banking level type stuff.
common stuff I had about 2 passwords I would regularly use, mid-level stuff had
Key Files (Score:5, Insightful)
Key files, certs, etc. are all convoluted versions of the same thing - a secret.
Your question is really: "How do I keep my secrets secure?"
The answer is, as always: "Memorize them."
If your secrets are too complex or too numerous to memorize, you will need to write them down.
Because you're not an idiot, you write them down encrypted, and memorize that key so you can decrypt it later. This key is your secret.
If you're doing it correctly, you won't care where you store the encrypted secrets, because the security requirement is effectively binary. If you have security set to "on" because you used strong encryption, then you can turn accessibility to over 9000.
Throw your password database on a public FTP and let the world have it. You'll be long dead before the encryption is cracked.
If you're paranoid and you think usable quantum computers are really 5-10 years away, or that every encryption algorithm is flawed and backdoored, then you need to rely on hiding as well to turn security on. Put your shit on a micro SD card and hide it. Or, hide your shit by embedding it into innocuous data (digital or physical) steganographically. Or both. Or you could roll your own crypto on top of an established crypto.
Re: (Score:3)
The problem is death. :)
I keep a mnemonic around in my phone because I've got nearly 100 accounts online for various things - but I know what the password is from that and, even then, I can usually cycle through any variations to get to the one it was.
But how do you pass that info along to family members... especially ones like mine who are not tech savvy!!!
Paper in a lockbox!
Re: (Score:2)
The problem is death. :)
I keep a mnemonic around in my phone because I've got nearly 100 accounts online for various things - but I know what the password is from that and, even then, I can usually cycle through any variations to get to the one it was.
But how do you pass that info along to family members... especially ones like mine who are not tech savvy!!!
Paper in a lockbox!
Each of your heirs has to memorize and regularly recite their own personal secret passphrase in order to remain in your will. Your lawyer has a large envelope with a instructions and a set of smaller envelopes containing SD cards, one for each heir. The lawyer doesn't know what's in the outer envelope until you die, and it's no use to her without the passphrases. She can't be forced to cough it up while you live (solicitor-client priviledge). It isn't that tough, nor novel. Count on greed and the tools used
Re: (Score:3)
Memorizing a key is a pretty bad solution. I'm way more afraid of brain damage than I am of fire/flood/tornado. A large part of my old documents are stuff I should remember and not need anyway--unless I need to get my life back in order after brain damage, dementia, Alzheimer's, etc.
probability vs difficulty (Score:2)
Disaster? Type it in again. (Score:2)
Print it out in a readable monospace font that differentiates between 1/I and 0/O. Droid Sans Mono modified to have a zero-dot or zero-slash is pretty good. Keep it in a safe deposit box.
When you lose lose a key, type it in twice and use a good visual differencer to make the two copies identical (and as close as possible to the printed original by using it as a guide to choose between the A/B copies). Try the key. If it fails, type in another copy and use a visual differencer to update again. Repeat until t
Keepass (Score:2, Informative)
You can put the master and recovery instructions into a QR - but where are you going to hide that and protect it?
My wife has her o
Yubikey (Score:4, Insightful)
In my organization, we've switched over to using Yubikeys for handling our private key storage. Our primary use case is SSH keys for remote terminals and git repositories, but there is no reason why it couldn't be used for other secure encryption methods too.
Qubes Split-GPG (Score:2)
Here is their description:
Split GPG implements a concept similar to having a smart card with your private GPG keys, except that the role of the “smart card” plays another Qubes AppVM. This way one, not-so-trusted domain, e.g. the one where Thunderbird is running, can delegate all crypto operations, such as encryption/decryption and signing to another, more trusted, network-isolated, domain. This way the compromise of your domain where Thunderbird or another client app is running – arguably a not-so-unthinkable scenario – does not allow the attacker to automatically also steal all your keys. (We should make a rather obvious comment here that the so-often-used passphrases on private keys are pretty meaningless because the attacker can easily set up a simple backdoor which would wait until the user enters the passphrase and steal the key then.)
The diagram below presents the big picture of Split GPG architecture.
https://www.qubes-os.org/doc/s... [qubes-os.org]
Re: (Score:2)
the so-often-used passphrases on private keys are pretty meaningless because the attacker can easily set up a simple backdoor which would wait until the user enters the passphrase and steal the key then.
If that's true, then why bothe with a Rube Goldberg machine such as 'Split GPG', rather than just use a Smartcard type solution?
No.... passphrases are still useful, as protection of data at rest. Without the passphrase, someone could potentially just copy the file when you're not looking or due t
Re: (Score:2)
"just copy the file when you're not looking"
Most threats will come from the network, which means malware attacks. The malware can easily wait for you to enter your passphrase. Also note the assumption made by Qubes' threat model: kernel-based security is too complex (in fact, too Rube-Goldberg like) to prevent privilege escalations from a determined attacker. This makes the VM-based solution actually simpler and more secure than normal key use, and at least needing less specialized hardware than the smartca
Re: (Score:2)
Most threats will come from the network, which means malware attacks.
The fact that 'most threats will come from the network'; does not necessarily mean that this is always your highest risk.
Malware is a risk, but it's not the only risk.
First you have to figure what your GPG key is protecting, how persistent and intelligent the attacker is, and what the benefits are for someone compromising it in the first place.
It's true, that some random malware flying around could infect your machine, but what ar
Re: (Score:2)
Most threats will come from the network, which means malware attacks.
The fact that 'most threats will come from the network'; does not necessarily mean that this is always your highest risk.
That's why physical security is important, too. (See Qubes anti-evil-maid, USBVM, etc.)
Actually, I have yet to hear of any malware stealing GPG keys and doing anything meaningful with them.
So i'm going to say your suggested post-compromise abuse by malware is plausible but theoretical.
Not so theoretical...
https://motherboard.vice.com/r... [vice.com]
http://www.theverge.com/2015/2... [theverge.com]
They even seem willing to steal a vendor's SIM keys in order to steal an individual's PGP key. You can say they don't seem to be doing anything with stolen keys, but decryption has no obvious effects.
They could also use stolen keys to launch _targetted_ attacks, such as signing backdoored code that is inserted into an update MITM fashio
Security through antiquity (Score:2)
Re: (Score:2)
Exactly. Stripe it to 100 floppy disks. Then place the floppy disks in different parts of the world. Make retrieving each disk like a scene out of Mission Impossible.
Wait, how big are these keys? (Score:2)
I presume you have your single, digital version on a USB device or other machine-readable, portable format which you keep in your possession. How big is the key? Is it less than 8000 characters? Print two copies out on acid free paper and put them in two safety deposit boxes in banks in different cities - one local, and one remote. In the local SDB, also place a digitally readable version on a USB key.
In order to lose your key, you would need to have a physical disaster which simultaneously destroys two sep
One word: Bioprinter (Score:2)
Encode your secret keys as DNA sequences, then print them out, multiply them on a petri dish, and have them sent out for cryo storage.
They'll last a lot longer than flash media, and there will be much internal redundancy.
You could also make a 3-Way mirror'd ZFS pool of USB sticks, and set NCOPIES to like 100000, before writing the keys to disk and sending them out to storage.... repeat again for each of at least 3 offsite locations, so have at least 3 USB sticks per storage vault, and work
Re: (Score:2)
Sorry, it seems your backup has developed cancer.
Two People (Score:2)
Store on Floppy (Score:2)
I store my private keys on an Amiga 5 1/4" Floppy Disks. Lets see how many people still own Amiga's much less own a 5 1/4" floppy drive FOR and Amiga. Oh and can read a custom non-dos disk format. :)
It's for your own good, as you can plainly see (Score:2)
Escrow the keys with your federal government. You'll soon be forced to do this soon, anyway,
Master Password (Score:2)
Check out Master Password:
https://github.com/Lyndir/MasterPassword
A single master root password that is used to derive all other passwords that you need. You can put it on an android device that isn't connected to the internet, and go from there.
Since it's stateless, it doesn't matter if the device you use is destroyed. And as long as you remember this one password, you will be able to derive all the rest.
In a file .... (Score:2)
Security Through Obscurity (Score:2)
Basically, do not keep a single key on your storage medium. CD-R, USB, even your HDD.
Generate thousands, hundreds of thousands, even millions of keys. Making your key, a needle in the haystack.
0000.key ~ 9999.key is easy to find, as secure as an ATM PIN. Maybe
Depends if the encryption method raises an error when the wrong key is used.
Of course you could leave some decoy encrypted data with your keys, too.
Why not EPROM? (Score:2)
A trusted friend? (Score:2)
I was a bit shocked to not see this offered by anyone... but... captain obvious chiming in... give them to a trusted friend?
A Solid, Recoverable Text String (Score:2)
In order to avoid the possibility of a string of text being unrecoverable in the future due to some minor change in the text you used versus the available copies (a potential issue with printed or online versions of even classic texts such as The Odyssey, Shakespeare's Romeo and Juliette, etc), use a specific version of the Bible. For example the King James Version of a Psalm; that text will always be the same, character for character, if you use a specific version (interpretation and language translation)
Where's the fucking problem? (Score:2)
Encryption: Use a tool with PGP. duplicity is fine.
Decrytion: You have a usb key with the private key, protected by a strong password. If you need restore, you can copy the key where you need it.
Re: Best thing to do (Score:2, Insightful)
Saying this isn't any better than saying "if you've done nothing wrong, you've got nothing to hide."
You use encryption to protect your privacy from a US government that no longer understands what the 4th amendment is.
As for backups, you can backup your private key with a password and throw it on a couple USB drives stored in different locations. I've printed out my encrypted RSA key. Elliptic curve keys are small enough that you can usually print them out with QR codes (even after encrypted).
Failing figurin
Re:Putting a lock on your door (Score:2)
You realize that the use case that having a locked door to your house helps is along the lines of "an optimistic but generally inept burglar comes around every so often and turns the doorknob of all the houses in your neighbourhood hoping they will come upon one where the door is not locked."
Does that seem that likely to you? Particularly if you live in a city, where the working assumption of everyone (including burglars) is that everyone's house door is locked.
Re:Fuck, is this really so hard? (Score:4)
Mod parent up.
Yes - USB drives are not archival quality storage. But no - they're not expensive. I have several dozen el cheapo flash drives in my desk drawer, most of which were freebies. Just back up on to a cheap storage medium multiple times. If you're so worried that a flash drive won't survive until you need it (Protip: it will, for about 10 years. Then just rewrite it and you're good for another ten years. They wear out from use, not electrical charge leakage.), then make 10 backups. I'd bet my big toe that at least one of them will survive a couple of generations. Keep one or two passphrase encrypted copies online somewhere (not necessarily cloud storage - online meaning you don't need to fetch a thumb drive for it), and you've got a good compromise. For corporate use, just use a safety deposit box with a few thumbdrives and reflash them once a year. That's simple, effective, and secure enough for most applications.
What do I do? I keep my KeePass database (which contains many encryption keys) on a cloud storage provider. The combination of passphrase and keyfile encryption is good enough for me, and strikes the balance I need between ease of use, accessibility, and security.
You're overanalyzing. This is a solved problem. Make multiple backups, some offline, and store them in a secure location, e.g. the parent's suggestion of a safety deposit box.
Re: (Score:2)
Congratulations, you completely missed the point. And you were an ass about it. And no, for anybody competent, this is most decidedly not a settled question, unless you spend a lot of money on it (archival-grade tape) and even there it takes constant re-evaluation and people manage to screw it up.
Re: (Score:2)
Well, I'm not afraid to say it next to my name; the answer was just horseshit.
There isn't a one-size-fits-all answer. I've contracted for restaurants, and I've contracted for banks. The answer is very different depending which one it is. You can't generalize the answer from the question, you have to extend the question to include use cases or other context analysis.
The fact he even said it makes me wonder if he even knows what things like specifications and requirements are.
Re: (Score:2)
For those curious, I am guessing AC is refering to this:
http://ollydbg.de/Paperbak/ [ollydbg.de]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I have done that in the past, namely using Aladdin eTokens which worked well... but they required hunting down the PKCS drivers, and those were extremely hard to find.
For security, these very nice, especially for TrueCrypt/VeraCrypt volumes, PGP Desktop keys, and such. Because they don't have a USB flash drive partition, they don't work well for NetBackup backup key storage, or keyfile storage for BorgBackup, attic, zbackup, and other utilities. The biggest advantage is the brute force resistance. Someon