How does sending compressed points in ECC can limit the attacker's capabilities?

While sending an EC point we mainly have two options, send it compressed or uncompressed. The uncompressed has prefix 04 and compressed has 02 or 03 which indicates which $$y$$ to choose. Actually, it is costly, first find the $$y$$ and $$-y$$ from the curve equation;

$$E(K): y^2=x^3+ax+b$$ a cube and a square root is required. If the base field is prime then select according to the last bit of $$y$$ or $$-y$$. Select the one with 0 if 02 is encoded and select the one with 1 if 03 is encoded.

For 32-byte coordinates, this can save 31-byte of message size ( one byte increased, we send 65 for uncompressed due to prefix). If we consider the cost, it increases the computation, and sending 64-bye instead of 33-byte is not really a huge issue.

Now, Bernstein in their slides mentions that

Never send uncompressed $$(x; y)$$. Design protocols to compress one coordinate down to $$1$$ bit, or $$0$$ bits! Drastically limits possibilities for attacker to choose points.

How does sending compressed points in ECC can limit the attacker's capabilities?

• Note: the zero is using only $x$ coordinate as ECDH. Mar 4, 2021 at 20:30
• Mar 4, 2021 at 21:28
• Bernstein is all about making it hard for implementers to shoot themselves in the foot (I know you've seen his safe curves page). If a protocol requires you to only accept compressed points, it also means that it requires you to only send compressed points. Don't let the implementer have the choice. Mar 4, 2021 at 22:57
• @AmanGrewal Yes, I know and aware of that. I stuck with the word sending. Instead of sending if it were the word communicating I would have no problem. I feel like if I send uncompressed then the attacker has some advantage. Mar 4, 2021 at 23:02
• I see. I think you're reading too much into the word send, but maybe there's something here Mar 4, 2021 at 23:17