[Cryptography] a question on consensus over algorithmic agility

[Phillip Hallam-Baker]

On Mon, Jun 30, 2014 at 9:28 AM, Jerry Leichter <leichter at lrw.com> wrote:

> On Jun 26, 2014, at 5:21 PM, John Kelsey <crypto.jmk at gmail.com> wrote:
> > a.  The security benefit of algorithm agility is entirely in being able
> to *stop* using some algorithms while still functioning.
> >
> > This means that you only really get this benefit if you have at least
> two ciphersuites that are both SHALLs.  If everyone implements RC4 + CRC32
> (the SHALL), and some people also implement AEC-GCM (the SHOULD), then when
> someone finally realizes that RC4+CRC32 is insecure, you can't actually get
> rid of it.
> But this leads us to an interesting position.  We have two schemes
> (algorithms, protocols what have you), A and B, that both ends definitely
> implement and which in other ways (performance, cost) are essentially
> interchangeable (else, again, we would not be in a position to stop
> supporting either).  We think both are secure, but one of them *may* have
> been broken - we just don't know which.
>
> This is then simple game theory:  We have two strategies, with equivalent
> payoffs that may be low (if the opponent "chose" to attack the same
> strategy we chose), or high otherwise.  And game theory tells us that the
> optimal strategy is a mixed one:  Choose A or B at random with equal
> probability.  (You can weight the probability to match knowledge of a
> weighted probability on the opponent's side.)
>
> So the logical outcome of asking for algorithm agility is ... a single
> more complex algorithm.
>

Not really.

The reason I specify AES as the mandatory to implement algorithm in
protocol specifications is that it is the only algorithm currently in use
that satisfied all the following criteria:

1) Informed option considers the algorithm to be acceptably secure for all
encryption applications.

2) Is the result of an open selection competition that is generally agreed
to have been reasonably transparent and to have made the decision on
empirical grounds,

3) Is ubiquitously supported on all platforms including hardware.

A new more complex algorithm would not meet those criteria. But that is OK
because my criteria for a backup algorithm are not the same as my criteria
for a default algorithm. I am quite happy with the idea that SHA-2 is the
current mandatory to implement algorithm (because even though it was not
developed in an open process it is the defacto standard) and SHA3 is the
mandatory to implement backup algorithm.

We do need a replacement backup algorithm for symmetric encryption though,
it is the only major algorithm class that we do not currently have an
acceptable replacement algorithm for. It is easy to see that we will in due
course transition from RSA+DH to some variation of ECSignature + ECDH and
the only thing holding us back is Patent FUD.

It is about time we had another cryptography competition. And I have at
least one sponsor interested in funding part of one. Just about the right
time has elapsed since the last one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140630/f37ce2cb/attachment.html>