<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 29, 2013 at 1:30 PM, Perry E. Metzger <span dir="ltr"><<a href="mailto:perry@piermont.com" target="_blank">perry@piermont.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 28 Aug 2013 20:04:34 +0200 Faré <<a href="mailto:fahree@gmail.com">fahree@gmail.com</a>> wrote:<br>
> One thing that irks me, though, is the problem of the robust, secure<br>
> terminal: if everything is encrypted, how does one survive the<br>
> loss/theft/destruction of a computer or harddrive?<br>
<br>
So, as has been discussed, I envision people having small cheap<br>
machines at home that act as their "cloud", and the system prompting<br>
them to pick a friend to share encrypted backups with.<br>
<br>
Inevitably this means that said backups are going to either be<br>
protected by a fairly weak password or that the user is going to have<br>
to print the key out and put it in their desk drawer and risk having<br>
it lost or stolen or destroyed in a fire.<br>
<br>
I think I can live with either problem. Right now, most people<br>
have very little protection at all. I think making the perfect the<br>
enemy of the good is a mistake. If doing bad things to me requires<br>
breaking in to my individual home, that's fine. If it is merely much<br>
less likely that I lose my data rather than certain that I have no<br>
backup at all, that's fine.<br>
<br>
BTW, automation *does* do a good job of making such things invisible.<br>
I haven't lost any real data since I started using Time Machine from<br>
Apple, and I have non-technical friends who use it and are totally<br>
happy with the results. I wish there was an automated thing in Time<br>
Machine to let me trade backups with an offsite friend as well.<br></blockquote><div><br></div><div>Now this is an area where QR codes might be useful</div><div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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. </div>
<div><br></div><div>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.</div><div><br></div><div><br></div>
<div>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.</div><div><br>
</div><div>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.</div>
<div><br></div><div><br></div><div>Fourth point of simplification: Just duplicate the key into every end point rather than attempting a key service with split control and key shares. </div><div><br></div><div>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. </div>
<div><br></div><div><br></div><div>So lets imagine the full key establishment sequence from the user's point of view.</div><div><br></div><div>Key Generation.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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:</div><div><br>
</div><div>1) Three copies of the encrypted private key, either as raw data or a link to the raw data.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div><br></div><div>
The user can easily escrow the keys by cutting the paper into 3 parts and storing them in an acceptably safe location. </div><div><br></div><div>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...</div>
<div><br></div><div>Banks are quite possibly going to be interested in helping this type of scheme because it helps them meet their own commercial goals.</div><div><br></div><div>Escrowing a key share with my bank means that I may be subject to a warranted intercept. But that is lightyears from the abuses PRISM allows the government to commit. And in any case every device I have that can read email has a copy.</div>
<div><br></div><div><br></div><div>To enable a new device I either ask one of my existing devices to print out a new distribution paper or pull them from the safe. I can use them in a cell phone with the camera or on a desktop by typing them in. Exposure can be limited in this case by deleting the encrypted key rather than keeping it. </div>
<div><br></div><div> </div><div><br></div><div>[1] All Key Signers are a CA by definition. All CAs must have a domain name to support the enrollment protocol but someone can set up their own CA if they have a domain name (even if that domain name is local.)</div>
<div><br></div><div><br></div><div>-- </div></div>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>