Re: [Cfrg] [CFRG] PAKE / Hash2Curve First Internet draft for balanced CPace subcomponent available

["Björn Haase" <[e-mail]>]

Dear Feng,
 
thank you for your reply. I would like to respond point by point.
 
>First of all, it’s not safe to assume the sender must know the receiver’s exact identity before the key exchange.
>Identities are normally transmitted “in-flow” as part of the key exchange protocol, as each party may not always
>know the other party’s exact identity beforehand.
 
There seems to be the need for more clearly specify, what is "identity".
For the CPace draft, I assumed that the receiver or sender "identity", i.e. the content
of the strings A and B in the CPace draft, would be something like a destination IP address and
a destination port on this machine. I.e. information that is required for establishing the link and exchanging
the message.
 
This is also why I did denote the compiled information that enters CPace as "Channel Identifier" (CI).
In fact the "identities" are not actually the identities in the sense of "Name: Peter, Birthday: 29th of februrary"
but only the "communication identities" such as "Peter's phone number".
 
I think that it might be worth rephrasing this aspect in the draft as A and B denote the "Communication identity"
of the two parties, for making it more clear and explicit.
 
In this understanding the party identifier *will* be known before the protocol could start.
With including the "communication identity" mechanism, we are able to fend off "relay attacks" where A party is thinking it is communicating
with party B while in fact its messages are actually relayed by an adversary
to a party C (which might share the same password).
 
>I understand Watson Ladd is trying to modify SPAKE2 by hashing the user identities before the
>key exchange to avoid the trusted setup, but that wouldn’t work for the same reason. Also,
>I suggest you have a look at the SPEKE specification in the IEEE P1363.2 (2006). If you
>interpret that specification literally, you may find it’s basically the same as
>the CPace protocol you propose.
It is not astonishing to find close similiarities with SPEKE, since CPace *is* essentially SPEKE.
The difference IMO is 1) that with CPace
we *mandatorily* use a session identifier that makes the generator ephemeral and
2) that CPace comes with a proof of the security guarantees
without the requirement for explicit mutual authentication as part of CPace itself.
(Allowing for optionally subsequent mutual explicit authentication, as AuCPace is doing, e.g..)
 
Note that the latter aspects leaves the implementer the freedom to use the mutual explicit
authentication scheme of his personal choice (e.g. exactly the ones used in TLS1.3 or IPSEC).
 
>The trick is how you define the “shared secret”. In IEEE P1363.2, it’s defined as follows (also see [1])
>
>“A password-based octet string which is generally derived from a password or a hashed password,
>identifiers for one or more entities, an identifier of a communication session if more
>than one session might execute concurrently, and optionally includes a salt
>value and/or other data.”
Yes this is close, but CPace REQUIRES the session id.
 
>The items you define in the hash-to-curve function include the above. But obviously, the definition above is highly
>ambitious and makes the incorrect assumption that identities and session identifiers are always known by the
>other party even before the key exchange.
 
As described beforehand that depends on what we call "Identity". If a true identity is available: "Fine you should use it!"
if only the communication identity is available: "This needs to be used as a bare minimum for fending off relay attacks.".
 
>This is addressed in the latest SPEKE specification in ISO/IEC 11770-4:2017, in which the shared secret is
>defined as “the password only”. No assumption is made about knowing the other party’s precise
>identity before the key exchange.
 
The definitions like the SPEKE-"password only" definition would not be provably secure in UC
in my perception, because this would allow for "relay attacks".
 
>Second, some people on this list seem to assume hash-to-curve will provide you with an ideal RO-like
>mapping with negligible cost at a constant time. I would urge caution on that assumption until the
>fact is fully established.
>
>The use of hash-to-curve is not anything new; people in the PAKE field have been playing with that idea for
>nearly 2 decodes. There are previous efforts in IEEE P1363 (2000-2008) and ISO/IEC 11770-4 to define and
>standardize this function.
>However, over the past many years, hash-to-curve has been known to be notoriously difficult to get
>right. In fact, the original SPAKE2 protocol was designed with the motivation to avoid hash-to-curve
> (but it introduces the trusted setup assumption instead).
 
In my conviction, the true reason for all of the problems with efficient constant-time hash-to-curve algorithms
has nothing to do with techical aspects. I am convinced, it's all about legal stuff and IPR.
(Also note, that CPace does not require a true RO hashing to the curve but just an encoding.)
 
The IPR nightmare is exactly, why I have been so painfully picky regarding IPR in conjunction with hash-to-curve.
It's not because I love this awful and annoying attorney stuff: I HATE digging through that!
Still I am convinced that this IPR stuff is the only and
true source of all the awful "PACE-Generic-Mapping" complexity and at the source of the "Dragonblood" issue.
 
It's also all about patents, IMO, why J-PAKE has been integrated by companies like Mozilla, and SPEKE and
SPAKE2 were not considered.
(In fact, I  believe that very few people will be talking openly about this type of reasoning.)
 
Note also, while the SPEKE patent has expired, the PAK patent that I believe to be relevant for
SPAKE2 will still be a painful problem for the years to come.
 
In my opinion it is a major achievement of the hash-to-curve team (notably Riad!) to have found a
way to work around the IPRs! I am not able and willing to give any legal advice (IANAL!), but personally I
am now fully convinced that with the current specficiations for SSWU in hash-to-curve-05 the team has found
a way through the jungle also for short-Weierstrass curves.
 
>We may need to wait a bit until the ongoing IEFT effort on defining and standardizing hash-to-curve to
>finish and for that to become a really established secure primitive (which will be a major contribution
>to the field, but we should not underestimate that this is actually a very tricky and challenging task).
 
Actually as mentioned above, I personally don't see any remaining technical or security risks.
(This is also what I did take with me from discussions with the BSI people that designed the PAKE protocol
for the german identity cards.)
Also note, that there *are* already high security applications that use PAKE with mapping,
such as the "french" version of PACE.
 
Maybe you could be more specific, where exactly, you identify security issues with hashing to curves.
 
Yours,
 
Björn.