How to make the Internet secure

[Phillip Hallam-Baker <[e-mail]>]

One of the big problems I have found in trying to argue for ways we can
improve Internet security is that there are two camps. The incrementalists
will only look at solutions that provide an improvement on the status qujo
in one area and the perfectionists insist that any solution that does not
solve every possible problem isn't worth considering.

How about we do both?

Also to save time:

* Yes, I understand the deployment problem very well, I worked with the guy
who solved the network hypertext deployment problem after 20 years of
people failing.
* Yes, everything is end to end secure,
* Yes the transport is also secure to prevent metadata attacks.
* Yes it works with OpenPGP
* Yes it works with S/MIME
* Yes you can use it with SMTP/IMAP/POP
* Yes you can use it with Jabber
* No, you do not have to use a CA
* Yes, you may use a CA where a CA adds value
* Yes, I have considered the lock in problem
* Yes, you can bolt in your own trust model
* REST/HTTPS/JSON.
* AES/RSA/DiffieHelman, moving to CurveX for production.
* Yes it is unencumbered, apart from one part which will unlock this year.
* Yes I have a strategy for QRC
* No, it is not a walled garden
* Yes, you can adapt the system to use escrow cryptography but not without
the parties knowing so this is a frontdoor, not a backdoor.
* My employer sells endpoint protection systems, the Mesh is not a
substitute for endpoint protection, thank you for your interest.
* Reference code runs on Windows, Linux and should run on OSX. It is all
MIT license, so are the protocol compiler tools.

* Yes, it is easy to use. In fact it is exactly as easy to use as the
existing protocols because the user doesn't need to know that they are
doing security
* Yes it is easy to configure.
* Yes, I need help, a lot of help

OK so how is this possible?

First observation is that we now have several protocols that provide users
with end to end security that are really easy to use. The only real problem
I have with those systems is that they operate inside walled gardens. They
are not going to be a replacement for email.

Second is that public key cryptography is now cheap in terms of both cost
and performance. We couldn't do very interesting crypto in the 90s because
machines bogged


There are three contributions made by the Mathematical Mesh:

1) An infrastructure for managing and using client keypairs.

Adding cryptography to a protocol is actually quite easy when both parties
have public keypairs. So if we have an infrastructure that allows a user to
'glue' all their devices together into a personal mesh such that they all
have keypairs provisioned for each cryptographic purpose they might need
them for, cryptography becomes really easy for the user.

2) Extend a direct trust model into the DNS

We all know about TOR and onion routing. Well what if I could have an email
address that included my OpenPGP fingerprint? Well we can. Just use the
xx-- DNS label prefix to mark the fingerprint as not an ICANN DNS labnel
and we can make the fingerprint the TLD:

[e-mail]--MBTVK-ZKCWT-KHMTE-XM3I7-GSQNK-MLFYE

This means, 'only send mail to this address in compliance with a policy
signed under the fingerprint MBTVK...' Said policy could be an OpenPGP key
or it could be a Mesh mail profile.

3) Use of Proxy Re-Encryption (Recryption)

HTTPS provides end to end encryption between the user's client and the web
site serving the content. Using Proxy Re-Encryption we can provide end to
end encryption between the content creator and the user's client. This is
the part of the system that will be locked until late this year, (not that
I am sure the patent is valid, why bother checking when it expires)

We all know that two key cryptography is better than one. It is better
because encryption and decryption are different functions and using
separate keys for separate functions allows these to be done by different
parties. Recryption is three key cryptography and it is better than two key
for the same exact reason.

Using recryption allows us to develop protocols in which Alice is able to
publish a single encryption key but read her email on three different
devices, each of which has a separate decryption key so that she can
mitigate the risk if one of the devices is lost.


Job one is making it easy to manage client side keys.

Once we have that infrastructure, all else becomes straightforward. My
original goal with the Mesh was to make it easy to configure S/MIME and
OpenPGP. David Clark asked me to add SSH which I immediately realized could
be the killer app because the big problem with configuring SSH is that if
you do it to a machine at a remote site, 1000 miles away and you screw up,
someone has to get on a plane to fix it.

However, any infrastructure that allows mail application to say 'here are
the encryption keys to use to send mail to me and when to use them' can
also say 'I accept JSON format nextgen mail'. So this is an infrastructure
that allows us to lock down the legacy email systems as best as can be
managed but also eliminates the biggest barrier to deployment of a
successor system.


I am looking for help to make this happen.

http://prismproof.org/