[Cryptography] We need a new encryption algorithm competition.

[Phillip Hallam-Baker]

On Sun, Mar 16, 2014 at 12:33 AM, James A. Donald <jamesd at echeque.com>wrote:

> On Sat, 15 Mar 2014 16:31:05 ianG wrote:
>
>> If people stop believing in institutions such as standards bodies,
>> certification bodies, and governments, the question is, what or whom
>> will they trust?  And what could actually deliver that trust?
>>
>> It seems that without a good answer to that, there isn't much point in
>> choosing one technical approach versus another.
>>
>
> Trust individuals.
>
> As I posted on this list previously:
>
> Let us have Jon Callas as unelected president for life of symmetric
> cryptography, Bernstein as God King of public key cryptography.
>
> Recall the long succession of Wifi debacles.  Has any committee ever
> done anything good in cryptography?
>
> IEEE 802.11 was stupid.  If NIST  was not stupid, it was because evil
> was calling the shots behind the scenes, overruling the stupid.


One of the side discussions that came up at the STRINT workshop was on the
need for better management of crypto algorithms in standards.

[I am working on the draft I agreed to write some time ago but hadn't
finished. It is almost done this time.]


Right now we have a fairly well established mandatory to implement set:

AES-128, SHA2-256, HMAC-SHA2-256, [DH & RSA-Encrypt], RSA-Signature

The use of RSA-Encrypt turns out to be redundant in Internet protocol use
as we never actually need public key encryption, what we actually use is
Key Exchange. Which is good since we don't have a EC version of RSA :-( so
we are going to need to to EC-DH anyway.


Although that set is pretty well established it is starting to look a
little on the old side. We have a consensus replacement for SHA2 but right
now we don't have solid consensus on replacements for anything else.

It seems that we are pretty close to a consensus on the use of EC as the
next generation digital signature algorithm. But there are a few more
degrees of freedom there which need to be nailed down. There is the choice
of curve in particular which is now subject to a lot of possibly justified
paranoia.

So we can hypothesize a backup set of algorithms:

??, SHA3, HMAC-SHA3 / ??-CCM, ECDH, ECDSA


Spot the problem? We currently have no backup for an encryption algorithm.

We really do need a backup for that slot and I don't think we can just take
one of the AES runners up. The criteria for a reserve algorithm are not the
same as for the default. Since the idea is that you can depend on the
reserve algorithm even if the default is broken, it has to be tuned for
security rather than performance.


I can't see how to get there unless we run a whole new crypto algorithm
competition.

Maybe that is something the Brazilians might want to take on.


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