Re: [CFRG] I-D Action: draft-irtf-cfrg-spake2-24.txt

[Rene Struik <[e-mail]>]

Dear Watson, Ben:

I did have a brief look at rev24 of the SPAKE2 draft and noticed that 
the abstract now includes the statement "This document predated the CFRG 
PAKE competition and it was not selected, however, given existing use of 
variants in Kerberos and other applications it was felt publication was 
beneficial. Applications that need a symmetric PAKE and where hashing 
onto an elliptic curve at execution time is not possible can use 
SPAKE2". I was wondering which applications would not have the 
capability to perform a hash-to-curve operation (after all, if an 
application implements elliptic-curve arithmetic, it seems unlikely it 
could not easily implement a hash-to-curve mapping). In other words, 
what am I missing?

A few comments from rereading the draft (without trying to be exhaustive 
[I do realize this may be too late in the game, but wonder who looked at 
this stuff carefully]):
1) Proper naming. The draft mentions the curve P512 a few times. I 
presume this should be the NIST curve P-521 (I think I sent Watson an 
offline note on this two years ago). Shouldn't one have a proper 
reference to NIST curves (e.g., FIPS Pub 186-4) and denote these in 
slightly less sloppy way as P-256, P-384, and P-521? {The same remark 
applies to SHA2 hash function family members, which in FIPS 180-4 are 
denoted by SHA-256, SHA-384, and SHA-512.}
2) Representation. Table 1 of the draft refers to edwards25519 and 
edwards448, but RFC 7748 does not specify the encoding format of points 
of these curves. This leaves the transcript TT underspecified. Shouldn't 
one also specify whether one uses compressed or uncompressed formats?
3) Test vectors. Appendix B only gives test vectors for SPAKE2 with the 
{P-256, SHA-256, HKDF, HMAC} suite. Given that Table 1 lists many more 
ciphersuites, this makes me wonder why this particular one was singled 
out in Appendix B.
4) Ciphersuites. Table 1 uses two ciphersuites with P-256, viz. one wish 
SHA-256 and one with SHA-512. What is the reason for including SHA-512? 
If this was only included because SHA-256 was deemed "too short" for key 
derivation, this seems more an artifact of the key derivation itself 
(where one partitions Hash(TT) into two half-size strings) and would be 
easily remedied by using the (already used) hkdf function for key 
derivation).
5) Security Considerations. The main construction does not mention at 
all that M and N should be elements of the prime-order subgroup (of, 
unfortunately named, order "p"), while this is required to not leak w 
(mod h), where h is the co-factor of the group. It would be beneficial 
to have a reference that illustrates why "x" and "y" cannot be reused at 
all (or a simple illustration in a sentence or two that a single repeat 
destroys security [this is not entirely obvious]).
6) Some small notes:
-i) The set-up (Section 3.2) considers very general set-ups (groups in 
which the gap-Diffie-Hellman problem is hard), but then refers to 
"points at infinity" and SEC1 formatting, where the former is not 
defined for (complete) twisted Edwards curves and where the latter is 
only defined for short-Weierstrass curves. Lots of concepts are 
well-known to insiders, but not so much to others (as an example, "we 
will work in the quotient group" may make sense to people with a 
background in abstract algebra, but perhaps not too much to others. 
Moreover, there are many ways to represent elements of a quotient 
group...).
ii) According to the abstract, SPAKE2 is above all useful if one does 
not have access to hash-to-curve functionality, which makes me wonder 
why (in Section 3.2, p.4, 2nd para) one suddenly invokes hash-to-curve 
concepts. Even if one would use this (seemingly superfluous) reference, 
one should then at least properly introduce notions as DST and indicate 
which of the zillions of flavors of hash-to-curve constructs one wishes 
to recommend (since you use "SHOULD", one would expect some precision 
here). If hash-to-curve is somehow used in the draft, why weren't the M 
and N parameters generated that way (rather than using the 
trial-and-error method)? This would also make it much easier for an 
implementation to check whether  and N were indeed generated that way.
iii) In the informal introduction of KDF (Section 3.2, p. 5), both ikm 
and IKM are used, while MAC is used without arguments (e.g., 
MAC(key,msg)). Since the hash function has as output a bit string, 
shouldn't its minimum length be 256 bits (rather than 32 bytes)?


On 2021-11-24 5:53 p.m., [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Crypto Forum RG of the IRTF.
>
>          Title           : SPAKE2, a PAKE
>          Authors         : Watson Ladd
>                            Benjamin Kaduk
> 	Filename        : draft-irtf-cfrg-spake2-24.txt
> 	Pages           : 17
> 	Date            : 2021-11-24
>
> Abstract:
>     This document describes SPAKE2 which is a protocol for two parties
>     that share a password to derive a strong shared key without
>     disclosing the password.  This method is compatible with any group,
>     is computationally efficient, and SPAKE2 has a security proof.  This
>     document predated the CFRG PAKE competition and it was not selected,
>     however, given existing use of variants in Kerberos and other
>     applications it was felt publication was beneficial.  Applications
>     that need a symmetric PAKE and where hashing onto an elliptic curve
>     at execution time is not possible can use SPAKE2.  This document is a
>     product of the Crypto Forum Research Group (CFRG) in the IRTF.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-spake2/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-spake2-24
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-spake2-24
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]