3

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?

kelalaka
  • 48,443
  • 11
  • 116
  • 196
  • Note: the zero is using only $x$ coordinate as ECDH. – kelalaka Mar 04 '21 at 20:30
  • See https://crypto.stackexchange.com/questions/25086/is-it-ever-unsafe-to-compress-an-ec-point/62356#62356 – Eugene Styer Mar 04 '21 at 21:28
  • @EugeneStyer actually, it says never send, the attack talked in the second answer talks about getting compressed vs uncompressed. – kelalaka Mar 04 '21 at 21:34
  • That answer mentions an attack that was only made possible by sending uncompressed points. I expect you want more detail than that, but if it doesn't answer your question at all, then this question might need more refining. – Aman Grewal Mar 04 '21 at 22:32
  • @AmanGrewal The attack was possible since the programmer was not validated the points. The point is if the attacker sends me a point compressed or not, I need to validate it. Arguing compressed easy to validate is a false alarm, one does lots of works for uncompressing. Instead, work on validation. Now, why should I send compressed? How does it reduce? Or should I read the line as, as a protocol designer must never accept uncompressed points? However, the programmer can decide these two. – kelalaka Mar 04 '21 at 22:41
  • 1
    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. – Aman Grewal Mar 04 '21 at 22:57
  • 1
    @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 04 '21 at 23:02
  • 1
    I see. I think you're reading too much into the word send, but maybe there's something here – Aman Grewal Mar 04 '21 at 23:17

1 Answers1

3

If the implementation is using uncompressed point exchange, The attacker gets an opportunity to supply points to Bob that are not in the Curve which was selected by Alice and Bob. The attacker will supply points to Bob that are in curves of a lower order which makes it possible to estimate Bobs secret.

Therefore if the implementation ensures that Bob has to calculate the point then he will come to know that the point being provided is not on the curve selected by Alice and Bob in the first place and will result in coming to know about the attack or the corruption.

Two basic constructs in ECC are the standard curves and Implementation by programmers. The argument is should use of compression be specified in the standard or should be left to the implementation. Since compression is so important for ensuring security it should be made part of the standard( As per the presenters ) to prevent implementation errors.

Uraguan
  • 171
  • 1
  • 7
  • More clarity may merit this answer more upvotes. – DannyNiu Mar 05 '21 at 06:37
  • Upvoted, however, actually, your approach is the same. Forcing some validation due to the compression and is costlier than usual validation. Yes, if you define your protocol only compressed then you can force some of the validation naturally. I think people unconditionally assume that uncompressed sending implies not validation. So, what if the implementation accepts compressed and uncompressed and does validation of the key. Is there an attack vector if I send uncompressed? – kelalaka Mar 05 '21 at 08:48
  • "I think people unconditionally assume that uncompressed sending implies not validation." – We IT security people are pessimists, justified by loads of bad experience: A sizeable amount of implementations did not (and do not) validate critical prerequisites like points actually being on the curve. If you design a protocol for use by a non-neglible amount of implementations, you are practically guaranteed to have every foot-gun triggered that is present. If you control and audit every aspect of your software stack this advice does not need to apply to you, though. @kelalaka – Perseids Mar 04 '22 at 08:06
  • "So, what if the implementation accepts compressed and uncompressed and does validation of the key. Is there an attack vector if I send uncompressed?" – With proper point validation (and only allowing a known good set of curves) accepting uncompressed points is fine. @kelalaka – Perseids Mar 04 '22 at 08:10