reply on: waxwing commentary on twist attacks + bitcoin’s curve \ stacker news ~bitdevs

0 sats \ 2 replies \ @tomlaies 3 Jan \ on: waxwing commentary on twist attacks + bitcoin’s curve bitdevs

So the attack depends on the victim not checking if an externally given public key, is actually on secp256k1.

Uuuh? Is that a theoretical exercise to think about or something with real world occurrences? Is that even possible to create such a keypair that works on Bitcoin? Maybe I'm misunderstanding something here

100 sats \ 0 replies \ @niftynei OP 4 Jan

Nothing in the “core” bitcoin protocol involves a Diffie-Hellman key exchange, so there is no real surface area for such an attack (at least where funds are concerned).

It would be a problem if you had funds derived from a private key that you used in a key-exchange for a messaging protocol where you’re not verifying your peer’s provided pubkey.

If you’re using a seed + HD wallet, make sure your comms keys are on a different, distinct derivation path from your funds keys.

Note that this is going to be wallet implementation details, and probably not easy to verify as a consumer.

21 sats \ 0 replies \ @ek 3 Jan

I don't think it's only theoretical. It's an implementation error that can leak your private key given the right circumstances (that an adversary could probably engineer). What the NIP-44 security audit has to say about this might help:

NOS-01-001 WP1: Potential twist attacks in secp256k1 implementations (Info) Cure53 has evaluated NIP44 in terms of its resilience to twist attacks. Although the current implementation was not found to be vulnerable, further steps can be suggested to make sure this state persists.

Twist attacks are an issue with naive implementations of the secp256k1 curve. They envelope problems with certain sanity checks, which can cause leakage of sender’s private key in the NIP44 protocol.

More precisely, this applies to implementations of secp256k1, which accept uncompressed representations of public keys. This means public keys are represented with both x and y coordinates instead of just x and a sign bit. As such, failure to verify whether these public keys are actually on the curve or not should be considered.

Encryption with a key, which is derived from an ECDH-computation on long-term keys of different parties, leaks the private key of the sender. The risk appears when a sender is tricked into encrypting a message with an invalid public key, i.e., one that is not on the real curve, but on a similar curve which admits small subgroups. In this context, the sender can leak their private key. For a more precise description of the twist attack, refer to Lundkvist’s blog post.

It is noteworthy to mention that the related ECIES encryption scheme, due to not using the sender’s private key, does not suffer from this particular issue. Nevertheless, it is still important to avoid such naive implementations, since they may lead to suboptimal security. Similarly, key-exchange variants, where senders provide an ephemeral key pair in addition to their long-term secret key, cannot be securely implemented with uncompressed and unverified public keys.

The current NIP44 implementation includes tests that make sure that deriving keys from invalid public keys fails. Cure53 suggests including more tests specifically designed to catch twist attacks (see NOS-01-003) and also describing valid keys in the specification (see NOS-01-002). It is known that uncompressed and unverified public keys can lead to other security issues.