←back to thread

317 points thunderbong | 5 comments | | HN request time: 1.808s | source
Show context
FiloSottile ◴[] No.42202326[source]
Hah, I wrote the crypto/rsa comments. We take Hyrum's Law (and backwards compatibility [1]) extremely seriously in Go. Here are a couple more examples:

- We randomly read an extra byte from random streams in various GenerateKey functions (which are not marked like the ones in OP) with MaybeReadByte [2] to avoid having our algorithm locked in

- Just yesterday someone reported that a private ECDSA key with a nil public key used to work, and now it doesn't, so we probably have to make it work again [3]

- Iterating over a map uses a randomized order to avoid exposing the internals

- The output of rand.Rand is considered part of the compatibility promise, so we had to go to great lengths to improve it [4]

- We discuss all the time what commitments to make in docs and what behaviors to disclaim, knowing we can never change something documented and probably something that's not explicitly documented as "this may change" [6]

[1]: https://go.dev/doc/go1compat

[2]: https://pkg.go.dev/crypto/internal/randutil#MaybeReadByte

[3]: https://go.dev/issue/70468

[4]: https://go.dev/blog/randv2

[5]: https://go.dev/blog/chacha8rand

[6]: https://go-review.googlesource.com/c/go/+/598336/comment/5d6...

replies(6): >>42202361 #>>42202405 #>>42203192 #>>42204222 #>>42204369 #>>42208970 #
1. mkesper ◴[] No.42202361[source]
The nil key case really makes me wonder how sane it is to support these cases. You will be forced to lug this broken behavior with you forever, like the infamous A20 line (https://en.wikipedia.org/wiki/A20_line).
replies(1): >>42202423 #
2. FiloSottile ◴[] No.42202423[source]
> You will be forced to lug this broken behavior with you forever

Yep, welcome to my life.

replies(2): >>42204137 #>>42204173 #
3. atsjie ◴[] No.42204137[source]
Wouldn't that broken behaviour be a potential security issue by itself?

I do remember Go making backwards incompatible changes in some rare scenarios like that.

(and technically the loopvar fix was a big backwards incompatible change; granted that was done with a lot of consideration)

4. whizzter ◴[] No.42204173[source]
Wouldn't a nil ECDSA key be a security risk?
replies(1): >>42205369 #
5. unscaled ◴[] No.42205369{3}[source]
If a private key is available, the public key can be derived from the private key using scalar multiplication. This is how ecdsa.GenerateKey works by itself - it first generates a private key from the provided random byte stream and then derives a public key from that private key.

I don't see how this can be a security risk, but allowing a public key that has a curve but a nil value is definitely a messy API.