@AviD I exchanged a few messages with him more than a decade ago, on Usenet, where he was his usual arrogant self (and technically wrong, too, but that's not important).
@AviD Apparently he is talking about a situation where some TLS server computes thing wrongly, and also reuses ephemeral secrets non-ephemerally, and this has bad consequences.
e.g. @Simon's ween is at small risk of not being implemented securely because it's used in a rather simple way, but that doesn't mean there's no risk of using it
@AviD For the situation described in the attack, it requires that the server implementation receives an alleged curve point which is not at all on the curve, and still agrees to use it.
and where you say "... in such a way that it would be hard to implement it securely", you're saying that TLS uses it simply, so that it would NOT be hard to implement securely, notwithstanding the fact that they DID succeed in implementing it not securely?
@AviD What I was saying at that point was that side-channel leakages of the shared secret were not a problem when they are forced by the client who has, by definition, the shared secret.
Now here someone found some servers who reuse their own ephemeral secrets for other connections, and do so poorly, since they process their ephemeral secrets with invalid incoming data.
I know that my own implementations would never have fallen to such a thing because, when receiving an alleged point, checking that it complies with the curve equation is easy and natural.
That some implementers succeeded in failing at this makes me doubt in Evolution.
4
But none of the so-called "safe curves" would be more or less at risk here.
If we want to point fingers at somebody else than the implementer, then we can say that the TLS protocol should have allowed, even mandated, curve point compression.
Curve point compression removes redundant parts of the point representation, which in turns implies that the point cannot be decompressed outside of the curve.
@TildalWave You reveice X and Y. You just check that Y^2 = X^3+aX+b for the two a and b values that define the curve. This is a matter of 4 multiplications and a few additions; it will be insignificant with regards to the cost of doing the ECDH itself.
With point compression you only have X so you compute X^3+aX+b and then do a square root to recover Y.
It is more expensive, but still less so than ECDH, so it's OK.
@TildalWave The curve equation is traditionally Y^2 = X^3 + aX + b, but if you want to note it with subtraction, that's not a problem: just use -a and -b...
@AviD From past experience, I know that Internet-based flamewars are fruitless, so I won't engage any further. And for the record, you tweeted, not me.
@AviD If you want a simple summary, I can only repeat what I already wrote in my answer: "Therefore, in your use case, there is no risk of private key leakage that would be specific to the used curve. If your SSL implementation is poor, it will be poor for all curves, not for just some of them."
Hi all, Quick question to the Rory's, have you heard anything from the securi-tay people? it's all gone a bit quiet, or have I just been quietly rejected?
@ColinCassidy on the talk front? I heard back that I'd been accepted, but with that said I'm not sure they've finalised everything as I've not seen a schedule as yet, so they may still be in process...
@ColinCassidy I know a couple of people who were involved in it in the past, I can ping them and see if they can find out if it's just a bit of dis-organisation at the conf. end.
@ColinCassidy just checked, I think it may be a touch of dis-organisation...
@ColinCassidy also apparently checking your spam folder they've had some problems with that...
that said, found it is my spam filter afterall :( aparently the don`t want to know how switches get stitches... oh well I'll just turn up and enjoy the show then
