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

["Hao, Feng" <[e-mail]>]

Dear Bjorn,


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

At the protocol level, we normally don’t concern the communicating identities such as IP/MAC addresses (although they might be used as identities in special circumstances) as they are implementation details at a lower level. By “identity”, I mean the normal definition in a key exchange protocol in a general case: a unique string that identifies each party in the communication process. If you require the other party’s “identity” to be known beforehand, you need to state that assumption explicitly. I just wanted to point out that it’s not safe to make that assumption in the general case.


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

I can’t talk about other people’s reasoning (the decision to choose J-PAKE in Mozilla and Thread is entirely the result of the industry’s own “independent” assessment; as designers of J-PAKE we were not involved). But I want to clarify that the motivation of J-PAKE was not to avoid patent, but to actually solve the problem! Patented alternatives such as EKE and SPEKE have various idiosyncrasies that make technical analysis and implementation difficult. Patent is a thorny issue, but not a blocker as ultimately people need a secure and efficient solution (for that paying royalty is a common practice in business).


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

I suggest we wait until the hash-to-curve draft is complete and fixed first so we are not analysing a moving target. But as a suggestion, I recommend authors of the hash-to-curve draft to provide more explicit design requirements that the proposed function is supposed to satisfy. That would be helpful. Currently the draft mentions “plausibly constant time”, “random oracle encoding” … These are a bit vague. Presumably, with a hash-to-curve function, you want to (somehow) randomly maps an input string from an infinite domain to a point in a finite domain which satisfies specific curve constraints while keeping the operation constant-time. Clearly due to the domain mismatch, such an ideal (random oracle) mapping is theoretically impossible, so the best that can be done is to have one that is computationally secure. For that purpose specific requirements should be defined, e.g., they might include similar requirements as a hash such as pre-image, second pre-image and collision resistance + guaranteed validity of the output (valid point in the designated group) + constant time? With the list of requirements, it will help other researchers to analyse the functions in a more concrete way. The very tricky thing here is that there is a custom-built security primitive for each of the many curves that people want to support, so you need to ensure each must be secure and be analysed properly … Still this gives no forward compatibility – things might break in the future with new curves. A general solution that securely works with any elliptic curve suitable for cryptography at a reasonable cost will be far more attractive. That problem remains open as far I know.