Thursday, August 18, 2016

cross-domain ECDH trickery

Once again, opmsg is ahead of the curve, by introducing
what I will call cross-domain ECDH kex.

The idea behind it is straight forward and obvious,
so that I wouldn't claim to be the first who invented it.
Digging the interweb a bit, didnt show quick results,
so I named it cross-domain ECDH without walking to the
library to do more in-depth research about someone else
having different names for it. If there is, feel free
to point me to it.

ECDH is a neat way to do your Key Exchange (Kex). It has
small footprint in speed and size. Its even fast enough
to be done multiple times in a row, without the user really
noticing a slowdown. The drawback of ECDH is that the so called
domain parameters for the curves are chosen by an entity
that you have to trust. Trust by means of: Nobody in the
committee responsible for choosing the parameters would
introduce so called Nobody-But-Us (NOBUS) bits, that
would weaken the resulting ECDH Kex secret.

There are different ways to put trust into the domain
parameters, like using some kind of sane and "well-known"
seedings and algorithms to generate "reproducable" parameters
(like Brainpool is doing). Other curve designers don't mind about
it at all and resemble eat-or-die mentality. This leads
to some kind of flame-war and bashing between the different
cults of ECC evangelists. Nobody knows anything about the NOBUS,
but everyone believes the opposite curve has backdoored parameters.

opmsg puts an end to this war, by allowing users to
specify more than one curve to do the Kex with. Up
to three curves may be specified. The master secret is derived
from the multiple distinct ECDH Kex's which are made. The idea is that in case there are NOBUS backdoors - even within every single curve -
the different backdooring parties would not work together
and share their NOBUS knowledge to each other. They wont
share their knowledge, because a potential NOBUS inside
a NIST curve would be the holy grail that they are never
ever show to someone else, and in particular not to the
party who, lets say, put their NOBUS into the GOST curves.

So, even if each curve that you chose to do your ECDH Kex
would be weak, the overall cross-domain ECDH Kex is secure.
As long as you really choose your curves cross-domain, e.g.
not three of the NIST curves in a row.

This feature is experimental. Please refer to the chapter
in the README which explains the particular config options.
If you are not in this curve flame war, you don't need to
change anything at all. Its all in the compatibility-mix
and you can just as work as before, if you prefer.