[Cryptography] We need a new encryption algorithm competition.

[Phillip Hallam-Baker]

On Tue, Mar 18, 2014 at 5:57 AM, ianG <iang at iang.org> wrote:

> On 18/03/2014 04:35 am, Tony Arcieri wrote:
> > On Sun, Mar 16, 2014 at 1:44 PM, ianG <iang at iang.org> wrote:
> >
> >> Further, in some sort of foreseeable future, CAESAR comes out and we now
> >> have a suite of AE algorithms, so even ChaCha/Poly is starting to look
> >> like last year's fashion, not cool.
> >
> >
> > AES-GCM is arguably good enough. I wish more effort were invested in
> > creating a new, modern TLS stack that isn't completely terrible, or
> > creating a protocol to replace TLS which is built atop CAESAR-style
> > authenticated stream ciphers.
> >
> > If I were to try to create a crypto contest, its goal would be to create
> a
> > better transport encryption protocol.
>
>
> Sounds good to me.  There are two general efforts that I know of:
> google's QUIC and a project by DJB and friends called TP Curve or
> something (I can never find it, can anyone?).
>
> It's not impossible, I do one myself that is more purposed at financial
> transactions but has migrated over time to being an also-ran contender.
>  I reckon a competition would bring out o(10) contenders.
>
> Although with a nod to PHB, he's looking for help on his messaging
> project, not on his TCP/TLS replacement ;)


That is the aim. Only for obscure reasons I am this morning working on
transport layer encryption for DNS.

One of the modules on which I am building my messaging proposal is a scheme
called Omnibroker. The idea of Omnibroker is that in certain situations you
are better off putting complex trust decisions in a cloud based service
rather than embedding them into the end points.

For example, if you want to do research on new trust models, you probably
don't want to start off embedding that code in the end points. Otherwise
you have to change every client every time you tweak the trust model. That
is no way to run an experiment.

Alternatively, consider the day you want to run PKI to your SousVide,
coffee pot and telly. You probably don't want to have to manage PKI on a
device that has no user interface. So the trust configuration is going to
come from outside. Better to keep it there.

Now before people start getting hot under the collar, remember that 'the
cloud' simply means 'some place I haven't decided yet'. The cloud could be
off in an Amazon data center, a Comodo SOC or it might be on a RaPi that
you configured yourself using an SD card with a golden distribution of
ubuntu having personally checked the hash code with Mark Shuttleworth,
Linus Torvald and Rebecca Watson.


So to be completely general the Omnibroker service answers questions such
as:

* What is the trusted value of current time
* How does X connect to Y to perform protocol Z
* Is this credential valid for Y

The first only needs to be accurate to a second or a minute to be a vast
improvement on current security systems. I don't so much care about the
time being right to the milisecond as that an attacker can't unwind me by
more than a few minuted.

The second gives rise to

* How does alice at example.com send to bob at example.net using mail
* How does alice at example.com send to bob at example.net using chat
* How does * connect to www.example.com using HTTP

These are very abstract questions. The idea of having a trust service
answer them is that it can say things like

* Use SMTP to 10.1.2.3 port 25, expect STARTTLS, cert hash is X
* Use HTTPS to 10.3.4.3 port 443, cert hash is Y ignore the subject data,
don't put up UI chrome signaling security

And those answers can come in two flavors:

* Just the conclusions (a trusted query service)
* The conclusions with proof (DNSSEC, cert chains, etc)


So anyway, the protocol consists of two parts, a key exchange part to
establish a kerberos like ticket and a query/response part. The
query/response part is very simple, very easy to do. The key exchange part
is a lot more complicated because there are different use cases in which
the client must be authenticated using a lightweight scheme, a strong
scheme, not authenticated at all or possibly with some form of anonymity.

All the complexity goes into that key exchange. Which for crypto purposes I
am actually punting on to rely on TLS right now for the crypto part.


So having developed a scheme that does the very abstract protocol, it seems
completely sensible to then reuse the difficult and complex part to also
support the 'DNS Privacy' requirement that was raised at the last IETF.

Basically when someone binds to an Omnibroker service they get back a list
of service hosts which are IP address, port, protocol and credential
tuples. To support the DNSE use case, all I need to do is to add in a
transport binding for DNS query/response messages. I already separated out
the Omnibroker query scheme from the OmniConnect scheme.


My particular key exchange may not be the best way to do it. In fact I
deliberately stripped down the protocol to the minimum so as to minimize
possibilities for objection. It is easier to add bits in than take them
out. But if we divide up the DNS privacy problem in my particular way we
can then reuse the same mechanism for the messaging layer problems.


-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140318/416ab176/attachment.html>