Re: Tarsnap feature request: storing encrypted keys
On 09/24/12 16:59, Andy Lutomirski wrote: > I don't really trust CDs or USB keys as a long-term storage medium, This is why I made Tarsnap keys printable -- of course, printers bring some security concerns and paper has its own durability issues too. > and tarsnap keys are kind of long (~5kB). So here's a feature > request: let me upload a possibly encrypted key file to tarsnap.com so > I can re-download it if necessary, presumably using only my account > password to authenticate. This is something I've wondered about doing for a while; I'd prefer that people not use such a feature, but I can certainly imagine it making life easier for some people. > To clarify, here's a concrete proposal: > > $ tarsnap-upload-key keyfile.key > > This will generate a random 128-bit key, encrypt the key file against > that key, and send the result to tarsnap.com (i.e. somewhere in > AWS-land). It will then display that key in some nice form (base64 > with no I, l, or 1, for example), so I can print a few copies on > paper. Then I can stick those pieces of paper somewhere safe. Is having that utility generate a decryption key for you better than just using the (already existing) functionality for passphrase-protected key files? (One obvious advantage is that there's no way for someone to pick a poor passphrase if an encryption key is generated by the utility, I suppose.) My idea was that if I did this I wouldn't add any extra encryption but have the utility refuse to upload a key file which wasn't passphrased. > There are plenty of elaborations possible. For example, tarsnap.com > could refuse to let me download the encrypted key unless I can prove I > know the key-wrapping key (e.g. by presenting some hash of the key, > where that hash is stored along with the key). There could also be a > tool that implements basic secret-sharing on the wrapping key, so I > could require, say, 2 out of 5 pieces of paper to recover the key. > > Thoughts? This requires some server-side help to work. This is certainly something which I could add (and as I mentioned above have thought about before). I'd be interested in hearing from anyone else on the list who would like to see this functionality. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Re: Tarsnap feature request: storing encrypted keys
On Mon, Sep 24, 2012 at 7:07 PM, Colin Percival wrote: > On 09/24/12 16:59, Andy Lutomirski wrote: >> I don't really trust CDs or USB keys as a long-term storage medium, > > This is why I made Tarsnap keys printable -- of course, printers bring > some security concerns and paper has its own durability issues too. You mean you don't keep a stash of university library-approved archival paper around? :) > >> and tarsnap keys are kind of long (~5kB). So here's a feature >> request: let me upload a possibly encrypted key file to tarsnap.com so >> I can re-download it if necessary, presumably using only my account >> password to authenticate. > > This is something I've wondered about doing for a while; I'd prefer that > people not use such a feature, but I can certainly imagine it making life > easier for some people. > >> To clarify, here's a concrete proposal: >> >> $ tarsnap-upload-key keyfile.key >> >> This will generate a random 128-bit key, encrypt the key file against >> that key, and send the result to tarsnap.com (i.e. somewhere in >> AWS-land). It will then display that key in some nice form (base64 >> with no I, l, or 1, for example), so I can print a few copies on >> paper. Then I can stick those pieces of paper somewhere safe. > > Is having that utility generate a decryption key for you better than just > using the (already existing) functionality for passphrase-protected key > files? (One obvious advantage is that there's no way for someone to pick > a poor passphrase if an encryption key is generated by the utility, I > suppose.) > > My idea was that if I did this I wouldn't add any extra encryption but > have the utility refuse to upload a key file which wasn't passphrased. The idea was to prevent people from doing silly things. The key should be high-entropy -- otherwise, people are vulnerable to offline (by you) or online (by anyone) dictionary attacks. The main point would be to reduce the amount of typing I'd need to do to recover my key from ~5k keystrokes to ~32 keystrokes (fewer if base64). --Andy
Re: Tarsnap feature request: storing encrypted keys
On Sep 25, 2012, at 4:07 AM, Colin Percival wrote: >> and tarsnap keys are kind of long (~5kB). So here's a feature >> request: let me upload a possibly encrypted key file to tarsnap.com so >> I can re-download it if necessary, presumably using only my account >> password to authenticate. > > This is something I've wondered about doing for a while; I'd prefer that > people not use such a feature, but I can certainly imagine it making life > easier for some people. […] > This is certainly something which I could add (and as I mentioned above > have thought about before). I'd be interested in hearing from anyone else > on the list who would like to see this functionality. So, what we end up doing is having our collection of keys stored on a shared encrypted loopback volume with a long decryption passphrase. Something of that sort is essential since if things go boom there are folks other than myself that may need, at any hour of the night or day, to be able to access our backups. I presume that is a common case with tarsnap users. However, I do like having that out of band with tarsnap's storage itself. I'd prefer a tool that could do the above, but e.g. with options to push the key collection to a user controlled sftp / dropbox / s3 / etc. volume. -Scott -- Scott Wheeler | Co-founder | Directed Edge | www.directededge.com | @directededge
Re: Tarsnap feature request: storing encrypted keys
On 09/24/12 19:18, Andy Lutomirski wrote: > On Mon, Sep 24, 2012 at 7:07 PM, Colin Percival wrote: >> This is why I made Tarsnap keys printable -- of course, printers bring >> some security concerns and paper has its own durability issues too. > > You mean you don't keep a stash of university library-approved > archival paper around? :) Nope. Although even cheap paper will probably last a few decades... unless it gets too wet or too hot. > The idea was to prevent people from doing silly things. The key > should be high-entropy -- otherwise, people are vulnerable to offline > (by you) or online (by anyone) dictionary attacks. Right. That said, scrypt (used for key derivation in passphrased key files) is powerful enough that you need to be using an *abysmally* poor password for it to be easily cracked. > The main point > would be to reduce the amount of typing I'd need to do to recover my > key from ~5k keystrokes to ~32 keystrokes (fewer if base64). Oh, I was assuming that anyone who printed their key file would OCR it if they needed to read it back in. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
Re: Tarsnap feature request: storing encrypted keys
On Mon, Sep 24, 2012 at 9:00 PM, Scott Wheeler wrote: > On Sep 25, 2012, at 4:07 AM, Colin Percival wrote: > >>> and tarsnap keys are kind of long (~5kB). So here's a feature >>> request: let me upload a possibly encrypted key file to tarsnap.com so >>> I can re-download it if necessary, presumably using only my account >>> password to authenticate. >> >> This is something I've wondered about doing for a while; I'd prefer that >> people not use such a feature, but I can certainly imagine it making life >> easier for some people. > > […] > >> This is certainly something which I could add (and as I mentioned above >> have thought about before). I'd be interested in hearing from anyone else >> on the list who would like to see this functionality. > > > So, what we end up doing is having our collection of keys stored on a shared > encrypted loopback volume with a long decryption passphrase. Something of > that sort is essential since if things go boom there are folks other than > myself that may need, at any hour of the night or day, to be able to access > our backups. I presume that is a common case with tarsnap users. > > However, I do like having that out of band with tarsnap's storage itself. > I'd prefer a tool that could do the above, but e.g. with options to push the > key collection to a user controlled sftp / dropbox / s3 / etc. volume. I actually prefer having it in-band. That way, there's only one (technological) point of failure. If I stick my key in dropbox, for example, then there are two points of failure (dropbox and tarsnap), and the failure of either one is sufficient to make my key backup useless. Otherwise I'd email it to myself (possibly with a random 128-bit suffix on my passphrase) and be done with the whole thing. --Andy
