<div dir="ltr"><div class="gmail_default" style="font-size:small">I am currently wrapping up the Mesh code. At this point I am halfway through the set of test cases for the line mode client. And almost all the functionality being tested is already tested at the library level.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One area I am still working to get right is the offline escrow mechanism. The basic idea of the Mesh is that we want to enable people to use a single fingerprint to identify their personal root of trust and this should be able to last their entire life. I have eliminated the idea of pre-determined certificate expiry completely.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So the root of trust comes down to:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) The master signature key</div><div class="gmail_default" style="font-size:small">2) A list of master encryption escrow keys</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yes, there are certainly cases where you do not want to escrow an encryption key. Transport encryption keys should never be escrowed but encryption keys for static data usually do require escrow. In 99% of cases, the loss of the data would be a far more serious risk than disclosure.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One corollary of this is that all message encryption schemes require separate transport and message level security. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Trusted hardware is really interesting and useful. But I don't think it actually helps in this application. The main advantage of using HSMs in CA Key Ceremony is that they allow audit. The use of the key requires a physical device and that can be monitored. Even better of course would be HSMs that track each private key operation.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But no hardware can really be trusted beyond a ten year service life. CAs provide continuity using a very expensive to manage set of processes. These really don't work for the individual. So I prefer a process in which the only data that needs to be trusted can be written down on a sheet of paper by hand. Hence Shamir secret sharing.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So my current escrow scheme looks like this:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default">meshman /personal <a href="mailto:test@prismproof.org">test@prismproof.org</a><br></div><div class="gmail_default"><div class="gmail_default">Created new personal profile MD2DE-5Y2KJ-DIIFI-GNKOA-NG6YX-EKRDZ</div><div class="gmail_default">Profile registered to <a href="mailto:test@prismproof.org">test@prismproof.org</a></div></div><div class="gmail_default"><br></div><div class="gmail_default">meshman  /escrow /quorum 2 /shares 3<br></div><div class="gmail_default"><br></div><div class="gmail_default"><div class="gmail_default">Created offline escrow entry Shares=3, quorum=2</div><div class="gmail_default">Share ECTQR-Z3C2F-GJSPM-PNX4K-TY7IL-E5QC</div><div class="gmail_default">Share EERHF-HOJTU-YZQV2-OCXM3-WYLAL-QAQ</div><div class="gmail_default">Share EKCNW-UZQNI-LJO4I-NXW44-3X6XL-3DQA</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">The escrow record itself is stored in the cloud encrypted using AES-256. To decrypt the escrow record, you need the escrow record data plus two of the three shares. The master escrow key is 128 bit, a KDF is used to extract the AES256 key. The secret sharing scheme is based on Shamir.</div><div class="gmail_default"><br></div><div class="gmail_default">So this means that the brute force difficulty of breaking the key is 128 bits but conventional cryptanalysis is almost certain to present a 256 bit workfactor. </div><div class="gmail_default"><br></div><div class="gmail_default">The index of the escrow record is the fingerprint (SHA-512-T) of the encryption key. This provides a simple mechanism to validate the recovery process.</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">OK so that is the default way to store keys. If we assume the Mesh business model works then it seems pretty certain someone will store the offline escrow blobs in perpetuity even if only out of curiosity. The blobs are 21K in JSON encoding and would be rather smaller in JSON-B encoding. The escrow records for the entire planet could sit comfortably on a $5K RAID array.</div><div class="gmail_default"><br></div><div class="gmail_default">But as John Gilmore points out, that isn't going to be enough for everyone. So in addition, I have an option to write out an escrow entry to a file instead.</div><div class="gmail_default"><br></div><div class="gmail_default">meshman /escrow /quorum 2 /shares 3 /file escrow.json</div><div class="gmail_default"><div class="gmail_default">Written to file escrow.json</div><div class="gmail_default">Share EBOOQ-VFCBQ-BZNXV-NX76I-MDII3-X2QA</div><div class="gmail_default">Share EGAS3-LKK2K-SFILU-S3J5N-HTSYO-GOQC</div><div class="gmail_default">Share EK7XE-BPTS5-DBG7T-W6X4B-7EFJA-VCQ</div></div><div class="gmail_default"><br></div><div class="gmail_default">OK so far, not controversial. Now I am also thinking about providing an option to simply write out the private keys without any encryption. This will greatly simplify my development/debugging process but will introduce a possibility that end users screw up bad.</div><div class="gmail_default"><br></div><div class="gmail_default">Ideas?</div><div class="gmail_default"><br></div></div></div>