Re: [Cfrg] Security proofs v DH backdoors

[Hanno Böck <[e-mail]>]

On Thu, 27 Oct 2016 10:32:17 +0000
Dan Brown <[e-mail]> wrote:

> For q=(p-1)/2, literally computing c^q for client public key is very
> slow.
> 
> Why not use a faster alternative, such as checking Legendre symbol
> (c/p), use cofactor DH,‎ or use even private keys?

This line of debate and all the recently released papers show one very
concerning thing: We haven't learned how to use Diffie Hellman properly
- although it's an algorithm at the end of its life.

I think when I read the logjam paper I became aware of how tricky of an
issue this is and how many things can go wrong with DH. It was also the
time when I concluded that the best is probably to just move beyond DH.

Sure, there is probably a way to use DH in a way that reflects all
security concerns, is still reasonably performant etc. But why should
we have this discussion when we already know DH is on its way out?
Chrome already decided to disable it, others will follow.
Is there a good reason to keep DH around? One I'm aware of is that some
people think due to its larger size it's more resistant against
quantum computers. But I have heard multiple people familiar with QC
and pqcrypto that they don't buy that argument.

I'm not arguing that ECC is simpler, but I'm arguing that we have
solved a lot of these issues facing DH already in a better way for ECC:
By simply not using random parameters which whoever decides, but by
using one or two good curves that have all desired properties. We
probably could do the same for DH, but we don't have to if DH is
deprecated anyway.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: [e-mail]
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42