> This DoS vulnerability in the crypto/elliptic implementations of the P-521 and P-384 elliptic curves may let an attacker craft inputs that consume excessive amounts of CPU.

> These inputs might be delivered via TLS handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH private key is reused more than once, the attack can also lead to key recovery.

> The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See the Go issue for more details.

The fix, for anyone who is interested: https://github.com/golang/go/commit/42b42f71cf8f5956c09e6623...

Is there anyone who can ELI5 what `beta8.Mod(beta8, curve.P)` does?

It is hard to explain what is `beta8` and `curve.P` specifically, but they are arbitrary-precision integers so you can see what went wrong with an appropriate pseudocode:

    x3 = alpha * alpha
    beta8 = beta << 3
    // beta8 %= curve.P
    x3 -= beta8
    while x3 < 0 {
        x3 += curve.P
    }

Essentially we want to compute `(alpha * alpha - beta * 8) % curve.P`, so to say. The modulo is expensive though, so for typical cases we can just repeatedly add `curve.P` to compute the modulo a few times. This is indeed a valid optimization when we are sure of the range of `alpha` and `beta`, but `beta` can be controlled outside. So a very large `beta` from an attacker will cause the while loop run forever---a denial-of-service attack.

Here's the new code:

    beta8.Mod(beta8, curve.P)
    x3.Sub(x3, beta8)
    if x3.Sign() == -1 {
        x3.Add(x3, curve.P)
    }
    x3.Mod(x3, curve.P)

I don't understand it why it's all necessary. This is shorter and seems to do the exact same thing:

    beta8.Mod(beta8, curve.P)
    x3.Sub(x3, beta8)
    x3.Mod(x3, curve.P)

Also, beta8 is never used after this code. So this should do the same thing as well:

    x3.Sub(x3, beta8)
    x3.Mod(x3, curve.P)

I think you are right. Go `big.Mod` should be Euclidean (i.e. `x % y` follows `y`'s sign) so the code is redundant. It doesn't seem to be required to run in constant time (if so we won't have `if` at all), probably the committer wanted a minimal change?

I cannot ELI5 this for you, but here’s more context:

  beta8 := new(big.Int).Lsh(beta, 3)
  beta8.Mod(beta8, curve.P)

https://golang.org/pkg/math/big/#Int.Mod

Non mobile link: https://groups.google.com/forum/#!topic/golang-announce/mVeX...

Edit: the message starts off with "Hi gophers".

I'm not a "gopher".

Does this label bother anyone else? I love the go programming language but I'm definitely not on board with this.

I happen to be a software developer who found effectiveness and value in Go and will continue to use it as long as it proves effective. That is all.

they tried to be cheeky. is ignoring that a problem sufficiently inconveniencing you that it requires a post on a forum?

I know they mean well. I'm just wondering if anyone else feels the same way I do.

It could be worse. You could be a "rustacean."

Back in the 70s, Peugeot, Renault, and Volvo collaborated on an engine design (used in the DeLorean among other cars). It's got some utterly bizarre design features but attracted its own relatively dedicated following called… PRVerts.

90° V6 engines are a perversion, anyway.

Dunno, I don't mind being called a Rustacean, though I think Rustafarian is a lot cooler. The Gopher term doesn't bother me either, at least it wasn't "Yo Goats!" or something worse. I also like Pythoneer / Pythonista (don't ask me why I like that one). Not sure what D programmers are called, I guess just D programmers. That or Walter Bright's Heissenbuds? I don't know.

>Not sure what D programmers are called

They are called "Real Programmers", a nickname shared with the Assembly, C, Lisp, Prolog, and Ada programmers.

We, Java men, got used to it long ago.

Nope, only you.