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

On Fri, Oct 20, 2017 at 10:10 AM, Greg Hudson <ghudson@mit.edu> wrote:

> On 10/17/2017 07:18 AM, Benjamin Kaduk wrote:
> > This version is intended to have minimal changes from the -03, and was
> > intended to un-expire the draft and add me as editor to effect that
> change.
> > I want this draft to advance so that it can be used as a reference by
> > draft-ietf-kitten-krb-spake-preauth.
> >
> > There is some reformatting due to having to rewrite the source into XML,
> > and I took advantage of that opportunity to un-wrap the python snippet.
>
> Thanks.  I found my old feedback on this draft in
> https://www.ietf.org/mail-archive/web/cfrg/current/msg07928.html and
> this update resolves one of those issues (the misformatted Python code).
>
> I do not know how to resolve the problem that SPAKE2+ doesn't use w0 or
> w1 in the transcript hash, and therefore more closely resembles SPAKE1
> than SPAKE2.  I suggest the following edits for the other issues:
>

Yeah, I'll have to look at the source (SPAKE2+ comes from an upublished
book...)

>
> * In section 2.2, remove the spaces around the || operators starting
> after K.
>
> * In section 2.3, replaces "here Bob" with "here B".
>
> * In the Python code, replace "ec.canon_pointstr" with "canon_pointstr".
>
> * Replace the introductory text of section 3 with:
>
>   Every curve presented in the table below has an OID from [RFC5480].
>   We construct a string using the OID and the needed constant, for
>   instance "1.3.132.0.35 point generation seed (M)" for P-512.  This
>   string is turned into a series of blocks by hashing with SHA256, and
>   hashing that output again to generate the next 32 bytes, and so on.
>   This pattern is repeated for each group and value, with the string
>   modified appropriately.
>
>   A byte string of length equal to that of an encoded group element is
>   constructed by concatenating as many blocks as are required,
>   starting from the first block, and truncating to the desired length.
>   The byte string is then formatted as required for the group.  In the
>   case of Weierstrass curves, this means setting the first byte to
>   0x02 or 0x03 depending on the low-order bit.  For Ed25519 style
>   formats this means taking all the bytes as the representation of the
>   group element.  The byte string is then interpreted as an element in
>   the group.  If this interpretation yields a valid group element with
>   the correct order (p), the byte string is the output.  Otherwise,
>   the initial hash block is discarded and the process is repeated
>   until a valid element is found.
>

Thanks for you comments

>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>

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