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

[Greg Hudson <[e-mail]>]

On 3/12/19 11:43 PM, Benjamin Kaduk wrote:
> Perhaps the most drastic change is the switch from multiplying by the
> cofactor before transmission and recipients verifying that points are on
> the curve (but in essence trusting the peer on prime subgroup membership),

In the old draft, each side chooses a multiple of the cofactor as its
private coefficient, and multiplies that coefficient by the unmasked
point, points of order greater than p (p times a divisor of h) will
become points of order p.  This is the same strategy as X25519 uses.

Points of small order (after unmasking) become I after multiplication by
the scaled coefficient.  I recall some debate around whether X25519
should require a check for whether the result is the identity point,
with the conclusion that it is not necessary.  I believe the same
applies here.

> This should probably be (3) in my list above.  I think when I was merging
> Chris's PR, I had convinced myself that only order-p and order-h subgroups
> were possible (or factors of h), so that (e.g.) 2p would not be possible.
> But I can't back that up right now -- Chris, can you say more?

https://safecurves.cr.yp.to/twist.html lists the possible orders of
group points.  It includes p times divisors of h.  There is also some
discussion of small-subgroup attacks and why scaled coefficients are
useful against them.

>> * This revision includes allowances for omitting one or the other
>> identity from key derivation.  I think this departs from the SPAKE2
>> security proof, and I don't recall discussion here about relaxing that
>> requirement.
> 
> I also don't recall discussion, though the text is attempting to indicate
> that this can only happen in cases where the identity in question is
> implicit in the containing protocol.

That doesn't seem like a helpful property.  One concern is that a
message (or a derivative of a message) might be taken from one session
and used in another.  If different sessions have different implicit
identities, omitting an identity from key derivation definitely seems to
potentially compromise the security proof.

>> * scrypt seems like an outdated choice of memory-hard hash function.
> 
> That's fair.  I assume you're thinking of draft-irtf-cfrg-argon2?

Yes.

> I did not get to think about this question particularly hard, but the main
> barrier here seemed to be the change in cofactor multiplication; a lot of
> the other changes could be wrapped into a specific "ciphersuite" for the
> kerberos usage, if needed.  (Since that protocol does do the transcripting,
> key derivation, and key confirmation steps that are needed, just with a
> somewhat tighter integration with the containing kerberos context.)

Rather than put a lot of Kerberos-specific stuff in the CFRG document, I
think it will make more sense to fully describe the SPAKE math in the
Kerberos document.