<div dir="ltr"><div>Thanks. <br></div><div>I did some more analysis and now I understand it completely.</div><div><br></div><div>ECC curve equation:<br></div><div>y^2 = x^3 + ax + b (mod p), where p is prime</div><div><br></div><div>Elliptic Curve parameters are:</div><div><span class="gmail-ILfuVd"><span class="gmail-hgKElc">p, a, b, G, n, h</span></span>

</div><div>G = Generator Point used to generate other points<br></div><div>Private Key = Random Number</div><div>Public Key = Point on Curve = (Generator Point)*(Private Key)</div><div><br></div><div>If the public key point is (x0, y0) then the client will send (x0,y0) to the server. But, clients can use point compression and send x0 with a sign of y0 as y0 can have two values i.e. +ve and -ve.<br></div><div>Server will compute y0 using the curve equation and p. <br></div><div>y0 = sqrt(x0^3 + bx0 + c) (mod p) <br></div><div><br></div><div>If p is incorrect then due to a bug in calculation of modular square root in openssl, vulnerability will get triggered.</div><div>If the server has the correct value of p then there will be no vulnerability.<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 26, 2022 at 1:01 PM Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org">openssl-users@dukhovni.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Mar 26, 2022 at 12:32:03PM +0530, Vipul Mehta wrote:<br>
<br>
> If we consider ECDHE_ECDSA cipher based TLS handshake, then it is possible<br>
> that the client can send invalid public session key to the server causing<br>
> the vulnerability. Is this assumption correct ?<br>
<br>
The CVE only affects situations in which the untrusted peer can specify<br>
malign "explicit" curve *parameters*, not just the public point.<br>
<br>
> If yes, then I think disabling ECC cipher suites should prevent the<br>
> vulnerability if we don't want to upgrade openssl considering there is no<br>
> other cryptographic operation except w.r.t. TLS.<br>
<br>
Unless I'm missing something, there's no need to disable ECC ciphers,<br>
since with TLS 1.0 through 1.2 the curve parameters are chosen by the<br>
server.<br>
<br>
With the TLS 1.3, the client typically sends a key share first, which<br>
consists of a named group and again a public point.  There is no<br>
mechanism for conveying "explicit" ECC parameters<br>
<br>
    <a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8</a><br>
    <a href="https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8.2" rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.8.2</a><br>
<br>
So either way, TLS servers are safe if they don't solicit client<br>
certificates, or otherwise in some form consume X.509 SPKI public keys<br>
(which with ECC do signal either a named group or provide explicit<br>
parameters).<br>
<br>
-- <br>
    Viktor.<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Regards,<br>Vipul<br></div>