[Cryptography] Clinton email issues

Phillip Hallam-Baker phill at hallambaker.com
Sun Mar 24 18:16:54 EDT 2019


On Sun, Mar 24, 2019 at 9:17 AM Ralf Senderek <crypto at senderek.ie> wrote:

>
> On Sat, 23 Mar 2019, Phillip Hallam-Baker wrote:
>
> >
> > All of which is why I have spent the past five years working on making
> end to end email security
> > practical and easy to use.
> >
> > I can now make end to end encryption exactly as easy as regular email.
> Just put the email
> > address in the message as normal and send.
> >
> > If the email client is Mesh enabled, it can recognize this as a SIN and
> work out that it needs
> > to apply a security policy (OpenPGP or S/MIME) that has the fingerprint
> mb2gk--
> >
> > The Mesh code is all open source. I am currently working methodically
> through the documentation.
> > If someone would write an SMTP proxy that intercepts the outbound email
> and applies
> > enhancements, we could get this into people's hands sooner than if I
> write all the code on my
> > own.
>
> I'd like to see a concise threat model for the MESH here.
>
> If switching to a different email address ist all the user
> has to do (plus using the proxy) then all the crypto has
> to be done in that proxy on the user's machine and you'll
> have to answer at least
>     a) which crypto library you use, how and why
>

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.

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.

    b) how you intend to protect the encryption keys
>
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.

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.

As far as RSA keys goes, I don't really care. I consider this obsolete. My
focus is on the ECDH modes.

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.


>     c) how key management is done on the user's machine
>        without the user selecting keys
>

By default, keys are unlocked by the user logging into the machine, their
login is used to decrypt the key store.

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.


>     d) why the user can be sure she is talking to the
>        right person and no one else.
>

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.

https://tools.ietf.org/html/draft-hallambaker-mesh-trust-00


>     e) how you will ensure proper performance of a-d
>        on a bunch of different OS (some of them proprietary)
>

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.

If the crypto is not done on the user's machine, then you
> are in "We're running an invincible server, give us your
> plaintext via https and we'll do the rest to make you
> secure" land and then you should stop calling this thing
> end-to-end encryption.
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190324/6b727f85/attachment.html>


More information about the cryptography mailing list