[Cryptography] a question on consensus over algorithmic agility

[Phillip Hallam-Baker]

On Mon, Jun 30, 2014 at 3:27 PM, Jerry Leichter <leichter at lrw.com> wrote:

> On Jun 30, 2014, at 3:01 PM, Phillip Hallam-Baker <phill at hallambaker.com>
> wrote:
>
> 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'm responding to John Kelsey's point that a fallback is only useful if
> you're willing and able to throw the primary away.  You're basically saying
> that you trust the primary, but will kind of accept the fallback if you're
> forced to.  Not at all the same thing.  And if that's really how you feel
> ... many will argue that the threat to the primary isn't really so bad, we
> aren't really so confident in the fallback, no one's seen an actual break
> yet ... and you're left in the position that many won't move to the
> fallback, so you're forced to use the primary you no longer trust in order
> to communicate with them.
>

Of course the primary has to be (almost) completely trusted. But you also
want to plan ahead for the next transition. And at a given time you might
be at a different stage in the lifecycle of your different algorithms.

The backup is always the candidate for the next primary so it should make
use of a different principle to the primary (SHA2 was a bad choice of
backup for SHA1)


I suggest the following stages:

Green: You have a primary algorithm and you are 100% happy with it. There
is no backup

Amber: You have a primary algorithm that you are less than 100% happy with,
there is no backup

Red: You have a primary algorithm that is broken and no backup


Gold: As for Green except that you also have a deployed backup that is
based on a different principle and appreciably stronger (e.g. more rounds).

Silver: As for Amber, except that you have a deployed backup that you are
transitioning to and an agreement for the next.

Bronze: As for silver, except that you don't know where to go after the
transition.


The key objective is to avoid ever ending up in the state Red. From a
security point of view, a breach is unlikely in any other state. But the
difference between Silver and Amber is that if you are in Silver you have a
chance of getting back to Green or Gold while if you are in Amber you have
a much higher risk of ending up in Red.


Right now the situation as I see it is that we are in the following states:

Symmetric Encryption: Green (AES, no backup)
Symmetric Hash: Silver (SHA-1 transitioning to SHA-2 with SHA3 as the new
backup)
Asymmetric Signature: Green (RSA is OK right now)
Asymmetric Key Exchange: Gold (RSA with ECDH the likely successor)


Agreeing on what the next signature algorithm is, is only hard because
there are a few parameter choices that might matter. But we could probably
agree on those if we had a summit with the relevant folk to all agree to go
the same direction.

I would like to get to the gold state on symmetric encryption and the hash
function is moving towards gold naturally.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140630/1cf3bc1d/attachment.html>