[Cryptography] We need a new encryption algorithm competition.

Phillip Hallam-Baker hallam at gmail.com
Sun Mar 16 19:45:04 EDT 2014


On Sun, Mar 16, 2014 at 4:44 PM, ianG <iang at iang.org> wrote:

> On 16/03/2014 12:40 pm, Phillip Hallam-Baker wrote:
> > 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 ...
> >> Trust individuals.
> > One of the side discussions that came up at the STRINT workshop was on
> the
> > need for better management of crypto algorithms in standards.
> ...
> > So we can hypothesize a backup set of algorithms:
> >
> > ??, SHA3, HMAC-SHA3 / ??-CCM, ECDH, ECDSA
>
>
> First question -- when was a backup suite last successfully fielded?
>

Actually that was the case for TLS which required MD5 and SHA1 in the first
incarnation. So when MD5 was found to be faulty, the switch to SHA1 was
painless.




> Second question -- what proportion of problems are addressed by a
> suite algorithm?
>

Every IETF crypto protocol has specified a mandatory to implement algorithm
to ensure a minimal level of interoperability. If the spec designers don't
choose one cipher the market will - and we may not like the choice.



> Which is to say, in challenging your assumptions, I'm not sure your
> going to get any benefit form the huge amount of work you need to do to
> handle a backup suite.
>

IETF already requires algorithm agility so there is no more complexity.

Today there is no backup algorithm specified so the tendency is that
implementations offer the kitchen sink. Which does not work because
security is determined by the least secure algorithm.

Specifying one required and one recommended algorithm as backup means there
is a chance that might be all the implementations support unless there is
good reason.


> Another indicator is this:  when you come to launch the backup
> algorithm, will everything have changed?
>

No, we have had pretty good notice of past issues.



> Since I last designed a packet suite using AES/SHA1/HMAC, we have
> shifted over to a fanboy consensus of ChaCha20/Poly1305;  which as it
> happens is a stream-based mechanism, so the code to implement it looks
> entirely different.
>

I don't think the IETF are fans of stream ciphers or anything that looks
like one.

So, in a sense, there is an emerging consensus that competitions are
> what we need to re-establish trust in a process.  h/t to Ralf as well.
>
> That isn't going to go away.  We're kind of left with a sense that we
> need a competition for every darn problem we have.  So why not do that?
>
> Why not start COMPETE 2014 -- the yearly event for crypto competitions?
>

Well, they take five years for a start.



On Sun, Mar 16, 2014 at 3:23 PM, Jerry Leichter <leichter at lrw.com> wrote:

>I don't buy that contention.  It certainly doesn't describe the
relationship of
>EC to RSA - I haven't heard any claims that EC is inherently more secure
>than RSA (in fact one might argue that the underlying hard problem in EC
>is less well-understood than the one in RSA); rather, the claim is that
RSA
>is becoming too slow to be practical to retain adequate security in the
>face of advances in attacks, while EC gets by with much smaller keys
>(hence gets much better performance) at the required level of security.

It isn't that EC is stronger the reason it is interesting is that RSA key
size stops delivering interesting improvements in strength after about 2048
bits.


>A fallback for AES with significantly worse performance simply wouldn't be
>used.  People put as much hardware as needed out there to solve a
>problem; they don't add a whole bunch extra "just in case".

Not any more, its now a cloud thing. If more computing grunt is required
they will up their server farm size as necessary to deploy it.

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


More information about the cryptography mailing list