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

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

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.