Re: [Cfrg] Security proofs v DH backdoors

[John Mattsson <[e-mail]>]

Very much agree with you Hanno, the ONLY reason I can see to still support
DH at all, is to have a fallback if someone comes up with a way of solving
ECDLP faster that O(q^1/2).


/John

On 27/10/16 12:51, "Cfrg on behalf of Hanno Böck" <[e-mail]
on behalf of [e-mail]> wrote:

>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