Re: [Cfrg] I-D Action: draft-irtf-cfrg-spake2-03.txt

Sent a first-cut PR for the code (is Brian Warner's repository the 
correct one? I saw it linked from your github) that would benefit from 
some review; where's the text of the draft so I can do up a patch for 
that? I didn't see it on your github or Brian Warner's.

On Fri, 19 Feb 2016 10:24:41 -0800, Watson Ladd wrote:

> Write the code and the text, and if I can run it, it goes in.
> 
> On Fri, Feb 19, 2016 at 4:16 AM, Alex Elsayed <eternaleye@gmail.com>
> wrote:
>> On Mon, 15 Feb 2016 11:23:00 -0500, Greg Hudson wrote:
>>
>>> On 02/15/2016 09:56 AM, internet-drafts@ietf.org wrote:
>>>>      Filename        : draft-irtf-cfrg-spake2-03.txt
>>>
>>> I am pleased to see progress on this draft.
>>>
>>> The formatting of the new formula for K' in section 2.2 is a little
>>> off in its use of whitespace.
>>>
>>> SPAKE2+ doesn't use w0 or w1 in the derivation of K'.  Obviously it
>>> can't use w1 as B doesn't have it, but can we call this an augmented
>>> version of SPAKE2 if it more closely resembles SPAKE1?  Should it use
>>> w0?
>>>
>>> The description of SPAKE2+ still refers to "Bob" in one place.
>>>
>>> In section 3, the formatting of the Python code is mangled.  Calls to
>>> ec.canon_pointstr() should be changed to canon_pointstr() since you've
>>> defined that as a function.
>>>
>>> In section 3, the description of the algorithm still doesn't match the
>>> actual algorithm used, although it's closer some details.  The first
>>> mismatch comes from these two passages:
>>>
>>>     This string is turned into an infinite sequence of bytes by
>>>     hashing with SHA256, and hashing that output again to generate the
>>>     next 32 bytes, and so on.
>>>
>>>     If this is impossible, then the next non-overlapping segment of
>>>     sufficient length is taken.
>>>
>>> The actual algorithm doesn't use non-overlapping segments of an
>>> infinite sequence of bytes; instead it uses overlapping concatenations
>>> of hash blocks for successive trials.  For P-521, the first trial uses
>>> H1|H2|H3 (where H1 is hash of the string, H2 is the hash of H1, etc.)
>>> truncated to 65 bytes; the second trial uses H2|H3|H4 truncated, etc..
>>
>> OOI, why not use HKDF, with the string as the IKM? Personally, I'd much
>> prefer that to inventing Yet Another Ad-Hoc Way To Extract Arbitrary-
>> Length Randomness.
>>
>>
>>> The second mismatch comes from this passage:
>>>
>>>     We multiply that point by the cofactor h, and if that is not the
>>>     identity, output it.
>>>
>>> The Python code multiplies the point by the generator order (p), and
>>> if that *is* the identity, outputs the point.  The difference is that
>>> the Python code discards points of order 2p, 4p, ..., hp.  This
>>> difference is irrelevant for P-256 and P-521 which have cofactor 1.
>>
>>
>> _______________________________________________
>> Cfrg mailing list Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg