Mitigate Twist Attacks

Problem

From the link in the references section:

Group structure and the small subgroup attack

The addition operation described above defines a group structure on the points of an elliptic curve. Suppose we have an elliptic curve where the corresponding group of points E has a subgroup H with few elements (say a few billion) and assume that the number of elements in the subgroup is a prime. The number of elements of a group is called the order of the group.

Suppose Bob has a private key b that Alice wishes to learn something about. She can take a point P in the subgroup H (this point is not a public key corresponding to any particular private key, but there is no way for Bob to know this) and tell Bob that this is her public key and can Bob please send an encrypted message to her.

Bob will compute what he thinks is a shared secret Q = b*P. He will use the data in Q to encrypt a message to Alice and send her the encrypted message C.

Since Alice knows that the point Q is in the group H (and H has a small number of elements) she can attempt to brute-force decrypt the message C with the points

P, 2*P, 3*P, 4*P, ...

etc until the decryption succeeds. Suppose the decryption succeeds at k*P. She then knows that Q = k*P and also Q = b*P so Alice has now learned that k = b mod q, where q is the number of elements (i.e. the order) of the subgroup H.

Thus Alice was able to get information about Bobs private key by giving him a maliciously chosen curve point.

This specific attack on Bobs private key will not work as described for the elliptic curve secp256k1 since the number of elements of the group is a prime number. By Lagrange’s Theorem this means that there are no non-trivial subgroups to this group.

Twist attacks on secp256k1

We can make a slight modification to the small subgroup attack mentioned above by having Alice choose a point on a modified curve.

The way she does this is as follows: Instead of using the secp256k1 curve defined by

y^2 = x^3 + 7

she uses a curve with a different constant term, for instance the curve E2 defined by

y^2 = x^3 + 2.

Unlike the original secp256k1 curve this new curve will have some small subgroups and Alice can pick a point P in one of them and give to Bob. Recall in our discussion on elliptic curve addition and multiplication that the algebraic operations of addition and multiplication are not actually using the constant term of the curve.

If Bob has a naive implementation of the elliptic curve multiplication (Q = b*P) that does not check if P is actually on the secp256k1 curve (which it isn’t) then his software will instead perform the computation on the curve E2, and Alice can perform the small subgroup attack described above.

Solutions

There are a few potential solutions, again copying from the link in the references section:

Summary & mitigations

We’ve shown that if Bob has a problematic implementation of elliptic curve encryption using the curve secp256k1 then Alice can steal Bob’s private key by giving him a number of maliciously chosen curve points and having Bob encrypt messages using those curve points.

For instance, using a simple Sage function like

def compute_shared_secret(myPrivateKey, theirPublicKey):
    return (myPrivateKey * theirPublicKey)

will be susceptible to this attack. Also implementing the elliptic curve multiplication algebraically without first confirming that the point is on the correct curve will be vulnerable to the attack.

How can Bob protect himself? In order to protect against this attack one needs to make sure to not compute elliptic curve multiplication on another curve than secp256k1. We can do either of the following:

• Do a verification that the curve point we are about to multiply is actually on the correct curve, by verifying that the equation is fulfilled.
• Require use of compressed public keys. These are curve points represented not by a pair of integers (x, y) but instead by the number x along with a one-bit value that allows us to compute the number y using the curve equation. This makes the public key shorter and since we need to use the curve equation to get the complete point we can be sure that we are not using a different curve.
• Use a different curve for encryption like curve25519 which has a robust implementation that is not vulnerable to this attack.>

References

• blog/secp256k1_twist_attacks.md at master · christianlundkvist/blog

[seresistvanandras]

What I wanted to say with ECDH is that once you have the shared secret you can use even asymmetric-crypto with that shared secret, e.g. AES. Random number would be encrypted with AES and then you don’t need to worry about twist attacks and other pitfalls of ECC/secp256k1.

[mds1]

Since both (1) announcement events, and (2) ENS public keys both use compressed public keys, I believe this attack is mitigated so I’m closing this issue

@seresistvanandras Feel free to reopen if you disagree 🙂