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

From: [email-masked]
Date: Mon, 15 Feb 2016 06:56:43 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Crypto Forum of the IETF.

        Title           : SPAKE2, a PAKE
        Author          : Watson Ladd
	Filename        : draft-irtf-cfrg-spake2-03.txt
	Pages           : 7
	Date            : 2016-02-13

Abstract:
   This Internet-Draft describes SPAKE2, a secure, efficient password
   based key exchange protocol.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-cfrg-spake2-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-spake2-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Greg Hudson <[email-masked]>
Date: Mon, 15 Feb 2016 11:23:00 -0500

> 	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..

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.

---

From: Alex Elsayed <[email-masked]>
Date: Fri, 19 Feb 2016 12:16:51 +0000 (UTC)

> 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.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 19 Feb 2016 10:24:41 -0800

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 <[email-masked]> wrote:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

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

---

From: Alex Elsayed <[email-masked]>
Date: Fri, 19 Feb 2016 23:26:50 +0000 (UTC)

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:

>>> The formatting of the new formula for K' in section 2.2 is a little
>>> off in its use of whitespace.
>>>
>>>     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.
>>>
>>> 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..
>>
>>> 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 [email-masked]

---

From: Adam Langley <[email-masked]>
Date: Fri, 19 Feb 2016 17:53:35 -0800

> prefer that to inventing Yet Another Ad-Hoc Way To Extract Arbitrary-

The advantage of iterating SHA-256 is that it's trivial to do,
including in SAGE.

This is only for parameter generation, it's not part of the protocol.
HKDF would be overkill.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org