# 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. – kelalaka Mar 4 at 20:30
• – Eugene Styer Mar 4 at 21:28
• @EugeneStyer actually, it says never send, the attack talked in the second answer talks about getting compressed vs uncompressed. – kelalaka Mar 4 at 21:34
• @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. – kelalaka Mar 4 at 23:02
• I see. I think you're reading too much into the word send, but maybe there's something here – Aman Grewal Mar 4 at 23:17