Re: [Cfrg] Criteria for the selection of new ECC mechanisms

[Michael Hamburg <[e-mail]>]

On Apr 29, 2014, at 11:35 AM, David McGrew <[e-mail]> wrote:

> Hi Michael,
> 
> On 04/29/2014 01:38 PM, Michael Hamburg wrote:
>>  I will probably not be in the meeting this afternoon, because my employer is hesitant to agree to IP disclosure rules :-(
> 
> sorry to hear that.  The rules should not stop you from listening though :-)

Ah, then perhaps I will listen.

>> and this feature is not even required for PAKE.  SPEKE, SPAKE2EE and Dragonfly don’t even use indistinguishability, just an inverse-samplable map to a large subset of the curve (eg, SWU/BCIMRT or Elligator).  SPAKE2 and JPAKE don’t even use that.  It’s only EKE and anti-censorship applications that use this, and you can use Tibouchi’s “Elligator Squared” (which is actually the same as BCIMRT) on any curve with a small overhead in ciphertext size.
> 
> OK, so "required for some PAKE protocols"?   Any suggestions on requirements language around anti-censorship applications?

"Required for some PAKE protocols" is probably good enough.  But at least any elliptic curve can do this with acceptable efficiency loss.  I don’t know about hyperelliptic curves, though.

Cheers,
— Mike