Subject: Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-03.txt

From: Greg Hudson <[email-masked]>
Date: Wed, 1 Nov 2017 10:41:00 -0400

On 11/01/2017 01:45 AM, Stanislav V. Smyshlyaev wrote:
> 4. The PKEX protocol translates code into an elliptic curve point in the
> following way. The code is hashed within other parameters and the hash
> value is used as a scalar which an elliptic curve point is multiplied
> by. There exists small but still non-null probability that this hash
> value turns to zero modulo q, where q is the order of the used elliptic
> curve point group. If that happens, an ephemeral key is not masked and
> the overall security of the PKEX protocol is violated. It seems useful
> to add checks here and introduce some algorithm that changes zero hash
> value to a nonzero value in a deterministic way.

An active attack against this case (attempting to subvert the DH
exchange as if there is no mask) succeeds with probability 1/q, which is
no more likely than attempting to subvert the DH exchange using any
other specific mask value as an offset.  Is that a sufficient reason to
add an impossible-to-test special case?

> 2. It seems useful to add checks of X' and Y' for not being equal to the
> point at infinity.

Similarly, what's the justification for adding this special case?

---

From: Ахметзянова Лилия Руслановна <[email-masked]>
Date: Wed, 1 Nov 2017 16:59:02 +0000

Good evening, Greg!

Answering your questions:

>An active attack against this case (attempting to subvert the DH exchange as if there is no mask) succeeds with probability 1/q, which is no more likely than >attempting to subvert the DH exchange using any other specific mask value as an offset. Is that a sufficient reason to add an impossible-to-test special case?

	We agree that the absence of these checks is not critical for the protocol security.

>Similarly, what's the justification for adding this special case?

	Firstly, if we do not add these checks then we should define the result of mapping function F for the point at infinity.

	Also, in the case of using PKEX in the WiFi protocol, the adversary has the physical access to devices, that can authenticate their public keys using PKEX. 
	Suppose the adversary can affect the RNG of devices (for example, by changing the voltage). In our practice there were cases, when RNG produced a 	sequence of only zeros in the case of hardware failures. If PKEX correctly processes the case of point at infinity (waits for non-null multiplier), it will not 	be vulnerable to this kind of dictionary attacks.

Best regards,
Liliya Akhmetzyanova

On 11/01/2017 01:45 AM, Stanislav V. Smyshlyaev wrote:
> 4. The PKEX protocol translates code into an elliptic curve point in 
> the following way. The code is hashed within other parameters and the 
> hash value is used as a scalar which an elliptic curve point is 
> multiplied by. There exists small but still non-null probability that 
> this hash value turns to zero modulo q, where q is the order of the 
> used elliptic curve point group. If that happens, an ephemeral key is 
> not masked and the overall security of the PKEX protocol is violated.
> It seems useful to add checks here and introduce some algorithm that 
> changes zero hash value to a nonzero value in a deterministic way.

An active attack against this case (attempting to subvert the DH exchange as if there is no mask) succeeds with probability 1/q, which is no more likely than attempting to subvert the DH exchange using any other specific mask value as an offset. Is that a sufficient reason to add an impossible-to-test special case?

> 2. It seems useful to add checks of X' and Y' for not being equal to 
> the point at infinity.