Re: [Cfrg] Adoption of draft-ladd-spake2 as a RG document

["Dan Harkins" <[e-mail]>]

On Mon, December 15, 2014 10:47 am, Watson Ladd wrote:
> On Mon, Dec 15, 2014 at 10:19 AM, Dan Harkins <[e-mail]> wrote:
>>
>>   Hello,
>>
>> On Sun, December 14, 2014 8:41 am, Alexey Melnikov wrote:
>>> Hi,
>>> This message starts 3 weeks adoption call for draft-ladd-spake2. Please
>>> reply to this message or directly to CFRG chairs, stating one of the
>>> following
>>>
>>> 1) that you are happy to adopt the draft as a starting point
>>> 2) that you are not happy to adopt this draft
>>> or
>>> 3) that you think the document needs more work before the RG should
>>> consider adopting it
>>
>>   I'm in favor of another PAKE being documented but I'm not sure
>> why SPAKE2 is the one.
>>
>>> While detailed document reviews are generally welcome, this not a call
>>> to
>>> provide detailed comments on the document.
>>
>>   SPAKE2 seems to be the Dual_EC_DRBG of PAKEs (and I'm very surprised
>> the author isn't being accused by a bunch of people on twitter, and some
>> hack tech blogger, of being an NSA plant out to subvert the Internet).
>> There
>> are 2 constant elements used in the calculation and knowledge of the
>> scalar
>> used to generate either of them would allow an attacker to break the
>> exchange. This draft will need to go through a rigorous NUMS procedure
>> in
>> order to populate (the currently empty) section 3, a contentious step
>> that
>> other PAKEs would not need to go through.
>
> Google has deployed this protocol with parameters generated by the
> following code:
> http://src.chromium.org/viewvc/chrome/trunk/src/crypto/p224_spake.cc

  A very rudimentary hunting-and-pecking loop!

> Do you see any way in which the discrete logarithm could be determined
> from this or any other substantially similar procedure? If so, please
> provide the procedure to this list, give us a week or two to think
> about it, and then reveal the logarithm of the generated points.

  Well there's baby step giant step but I'm not going to be revealing the
scalars in a week or two. But then I am not a tinfoil hat conspiracist
(like the aforementioned twitter army and hack tech blogger) either so
I don't actually think a secret cabal knows the scalars, only pointing
out that more has been made over less and if SPAKE2 is pursued the
draft will have to address this issue.

  So instead of populating section 3 with Ms and Ns for various groups
you could describe a hunting-and-pecking loop with a constant seed
(or deterministic way to get a seed for a particular named group). But
again, this is unnecessary if you choose a different PAKE.

>>
>>   There are other PAKEs out there so it would be nice to know why SPAKE2
>> is the one that should be pursued.
>
> I understand there is an AugPAKE draft already. But AugPAKE is
> patented. There are alternatives, and I'm not committed to the
> particular choice of PAKE: I've been informed of a few others to look
> at and am examining them to see if they offer any advantages to
> switch. I do think we need a PAKE with a solid security proof, and
> several people have placed augmentation on the list of desiderata.

  Wouldn't RFC 2945 satisfy those people?

  regards,

  Dan.