Re: [Cryptography] Keeping backups (was Re: Separating concerns
Phillip Hallam-Baker hal...@gmail.com writes: To backup the key we tell the device to print out the escrow data on paper. Let us imagine that there there is a single sheet of paper which is cut into six parts as follows: You read my mind :-). I suggested more or less this to a commercial provider a month or so back when they were trying to solve the same problem. Specifically it was if you lose your key/password/whatever, you can't call the helpdesk to get your data back, it's really gone, which was causing them significant headaches because users just weren't expecting this sort of thing. My suggestion was to generate a web page in printable format with the key shares in standard software-serial-number form (X-X-X etc) and tell people to keep one part at home and one at work, or something similar, and to treat it like they'd treat their passport or insurance documentation. Peter. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
Want to collaborate on an Internet Draft? This is obviously useful but it can only be made useful if everyone does it in the same way. On Tue, Sep 3, 2013 at 10:14 AM, Peter Gutmann pgut...@cs.auckland.ac.nzwrote: Phillip Hallam-Baker hal...@gmail.com writes: To backup the key we tell the device to print out the escrow data on paper. Let us imagine that there there is a single sheet of paper which is cut into six parts as follows: You read my mind :-). I suggested more or less this to a commercial provider a month or so back when they were trying to solve the same problem. Specifically it was if you lose your key/password/whatever, you can't call the helpdesk to get your data back, it's really gone, which was causing them significant headaches because users just weren't expecting this sort of thing. My suggestion was to generate a web page in printable format with the key shares in standard software-serial-number form (X-X-X etc) and tell people to keep one part at home and one at work, or something similar, and to treat it like they'd treat their passport or insurance documentation. Peter. -- Website: http://hallambaker.com/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
On 8/29/13 11:30 AM, Perry E. Metzger wrote: On Wed, 28 Aug 2013 20:04:34 +0200 Faré fah...@gmail.com wrote: One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? So, as has been discussed, I envision people having small cheap machines at home that act as their cloud, and the system prompting them to pick a friend to share encrypted backups with. Why not share some parts with some friends and some with others? This is related to the recently-discussed idea of a network of friends (maybe it's because I've worked on Jabber for so long, but I like the idea of leveraging your buddy list for many interesting features, including data backup and mix networking). Peter -- Peter Saint-Andre https://stpeter.im/ ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
On Thu, Aug 29, 2013 at 01:30:35PM -0400, Perry E. Metzger wrote: On Wed, 28 Aug 2013 20:04:34 +0200 Faré fah...@gmail.com wrote: One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? So, as has been discussed, I envision people having small cheap machines at home that act as their cloud, and the system prompting them to pick a friend to share encrypted backups with. This is precisely the use case for Freedombox running Tahoe LAFS. ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
On Thu, Aug 29, 2013 at 01:30:35PM -0400, Perry E. Metzger wrote: So, as has been discussed, I envision people having small cheap machines at home that act as their cloud, and the system prompting them to pick a friend to share encrypted backups with. The Least-Authority Filesystem is designed for this use case (among a small number of other use cases). Inevitably this means that said backups are going to either be protected by a fairly weak password or that the user is going to have to print the key out and put it in their desk drawer and risk having it lost or stolen or destroyed in a fire. In LAFS, the keys are strong, computer-generated keys, so you have to print them out or write them down. Printing them in triplicate and storing them in separate locations seems like a good trade-off of the risk of theft vs. the risk of loss, for the reasons you give: I think I can live with either problem. Right now, most people have very little protection at all. I think making the perfect the enemy of the good is a mistake. If doing bad things to me requires breaking in to my individual home, that's fine. If it is merely much less likely that I lose my data rather than certain that I have no backup at all, that's fine. BTW, automation *does* do a good job of making such things invisible. I haven't lost any real data since I started using Time Machine from Apple, and I have non-technical friends who use it and are totally happy with the results. I wish there was an automated thing in Time Machine to let me trade backups with an offsite friend as well. The Least-Authority Filesystem comes with a nice backup tool (tahoe backup), but it does not come with a nice GUI for your non-technical friends. Regards, Zooko ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Keeping backups (was Re: Separating concerns
On Thu, Aug 29, 2013 at 1:30 PM, Perry E. Metzger pe...@piermont.comwrote: On Wed, 28 Aug 2013 20:04:34 +0200 Faré fah...@gmail.com wrote: One thing that irks me, though, is the problem of the robust, secure terminal: if everything is encrypted, how does one survive the loss/theft/destruction of a computer or harddrive? So, as has been discussed, I envision people having small cheap machines at home that act as their cloud, and the system prompting them to pick a friend to share encrypted backups with. Inevitably this means that said backups are going to either be protected by a fairly weak password or that the user is going to have to print the key out and put it in their desk drawer and risk having it lost or stolen or destroyed in a fire. I think I can live with either problem. Right now, most people have very little protection at all. I think making the perfect the enemy of the good is a mistake. If doing bad things to me requires breaking in to my individual home, that's fine. If it is merely much less likely that I lose my data rather than certain that I have no backup at all, that's fine. BTW, automation *does* do a good job of making such things invisible. I haven't lost any real data since I started using Time Machine from Apple, and I have non-technical friends who use it and are totally happy with the results. I wish there was an automated thing in Time Machine to let me trade backups with an offsite friend as well. Now this is an area where QR codes might be useful First point of simplification is that we only ever need to worry about symmetric key backup since we can always add a private key to the rest of our encrypted archive. We can encrypt the key and backup the encryption key or we can use a deterministic keygen algorithm and escrow the seed. either way we only need to escrow 256 bits. Second point is that we can reduce exposure to risk by using some sort of key splitting scheme. We can also use this to effect key transport between devices. The problem with 'end to end' encryption these days is that most of us have multiple devices we receive email on, which is why WebMail has become so attractive. I have to be able to read my email on any of my 5 principal machines (Windows, 2 MacBooks, iPhone, iPad). Any email scheme that does not support all of them is useless. Third point of simplification: ditch key rollover. Don't expire a key unless it is necessary because of a suspected or known compromise. Use a sufficiently strong key to make cryptanalysis infeasible. I know that key rollover is part of the ideology but it introduces more vulnerability than it eliminates. Any encryption key you have that ends up compromised is likely a maximum damage situation. So using ten keys in ten years gives the attacker ten opportunities to compromise you if you muck up the distribution or they manage to compromise a CA. Fourth point of simplification: Just duplicate the key into every end point rather than attempting a key service with split control and key shares. A better way to manage crypto in a mobile device like a phone would be to split the prime into two (or more parts) for each mobile device to be enabled. To decrypt data the device would have to ask a service(s) with the other part(s) of the key to do their work and then combine with the local result. So lets imagine the full key establishment sequence from the user's point of view. Key Generation. To generate my first key, I tell my MUA my email address and the CA domain name[1]. It checks to see if the email address already has a key registered. If so it will ask if I am really, really sure I want to replace it etc. Otherwise it generates for me a new keypair. The CA is hopefully going to do validation of my key before issuing the certificate. At minimum an email callback. We might push the encrypted escrowed key out to the CA at the same time. But that is orthogonal to the private key backup and distribution. To backup the key we tell the device to print out the escrow data on paper. Let us imagine that there there is a single sheet of paper which is cut into six parts as follows: 1) Three copies of the encrypted private key, either as raw data or a link to the raw data. 2) Three key shares allowing the key to be reconstructed from 2 of them. For a 256 bit key that would be no more than 512 bits doing it the simple way and there is probably a cleverer encoding. The data for each would be presented as both a QR code (for installing in a phone) and a BASE32 alphanumeric code (for installing on a machine without a camera. The user can easily escrow the keys by cutting the paper into 3 parts and storing them in an acceptably safe location. In my case that would probably mean mailing the shares to my parents and family for offsite backup. Or I might give them to my broker or a bank or... Banks are quite possibly going to be interested in helping this type of scheme because it helps them
