<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 24, 2019 at 9:17 AM Ralf Senderek <<a href="mailto:crypto@senderek.ie">crypto@senderek.ie</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On Sat, 23 Mar 2019, Phillip Hallam-Baker wrote:<br>
<br>
> <br>
> All of which is why I have spent the past five years working on making end to end email security<br>
> practical and easy to use. <br>
> <br>
> I can now make end to end encryption exactly as easy as regular email. Just put the email<br>
> address in the message as normal and send.<br>
> <br>
> If the email client is Mesh enabled, it can recognize this as a SIN and work out that it needs<br>
> to apply a security policy (OpenPGP or S/MIME) that has the fingerprint mb2gk--<br>
> <br>
> The Mesh code is all open source. I am currently working methodically through the documentation.<br>
> If someone would write an SMTP proxy that intercepts the outbound email and applies<br>
> enhancements, we could get this into people's hands sooner than if I write all the code on my<br>
> own.<br>
<br>
I'd like to see a concise threat model for the MESH here.<br>
<br>
If switching to a different email address ist all the user<br>
has to do (plus using the proxy) then all the crypto has<br>
to be done in that proxy on the user's machine and you'll<br>
have to answer at least<br>
    a) which crypto library you use, how and why<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">The code is in C# because that is the most popular C like language that is unencumbered and provides array bounds checking with type safety.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The native crypto libraries are used for everything except for the Ed25519/448 and X25519/448 and SHA3 which is not supported in dotnetCore right now.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    b) how you intend to protect the encryption keys<br></blockquote><div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">The Mesh master profile keys are ideally escrowed using Shamir secret sharing and erased from the machine. The secrets can be recorded as paper shares. Application keys may also be escrowed if desired. </div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Protection of application keys depends on the algorithm chosen and the platform. Wherever possible I use the native capabilities of the platform. As far as implementation goes, the priorities are Windows and Mac. There are ways to secure Linux but I will not be the one implementing them.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As far as RSA keys goes, I don't really care. I consider this obsolete. My focus is on the ECDH modes.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For ECDH I use key cogeneration to combine keys created on the device with keys generated on the administrator machine. This provide protection against weak key choices on constrained devices and also against manufacturer key compromise. It is sufficient for either the admin machine or the application machine to generate a secure key and not compromise it for the user to be secure.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    c) how key management is done on the user's machine<br>
       without the user selecting keys<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">By default, keys are unlocked by the user logging into the machine, their login is used to decrypt the key store.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If higher degrees of security are required, keys can be encrypted by an additional password. But the near term goal is to unlock the use of application private keys using a trusted personal device (watch, phone) ideally with biometric security.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    d) why the user can be sure she is talking to the<br>
       right person and no one else.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">See my other reply on the introduction problem. I have also written this but it is now out of sync with the code and the other specs.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><a href="https://tools.ietf.org/html/draft-hallambaker-mesh-trust-00">https://tools.ietf.org/html/draft-hallambaker-mesh-trust-00</a></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
    e) how you will ensure proper performance of a-d<br>
       on a bunch of different OS (some of them proprietary)<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Microsoft has already done a great deal of work on Trustworthy computing. My ultimate objective is to make is possible for them to use the native capabilities of their platform they have been working to establish. Combined with the use of split key generation techniques, this enables the use of 'blackbox' crypto tied to the machine without trusting what is in the black box to do anything more than prevent the application keys being used off the machine.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If the crypto is not done on the user's machine, then you <br>
are in "We're running an invincible server, give us your<br>
plaintext via https and we'll do the rest to make you <br>
secure" land and then you should stop calling this thing<br>
end-to-end encryption.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I am doing the crypto on the user's machine and in the cloud. I am not using two key public key crypto, I am using three and four key techniques. In particular I split the decryption key into two so that use of both halves is required to decrypt. This allows the use of a cloud service to block decryption by lost or stolen devices. Or just temporarily when going through an airport.</div><br></div><div><div class="gmail_default" style="font-size:small">This is not just openPGP or S/MIME crypto. It is making use of techniques developed by Matt Blaze, Torben Pedersen and others since OpenPGP and S/MIME were developed. It is true end-to-end encryption but with the same flexibility and ease of use that Ford-Wiener style key release affords.</div><br></div></div></div>