I thought an "interesting" part of the change was actually how they made a 50% chance work for the extra read. They select across a closed channel twice -- and it results in a mostly even distribution of chance.

    for i := 0; i < 100000; i++ {
        select {
        case <-closedChan:
            a++
        case <-closedChan:
            b++
        case <-closedChan:
            c++
        case <-closedChan:
            d++
        }
    }

Results in an almost even distribution across the select choices!

https://play.golang.org/p/cnAXBEZJm2B

(fixed playground link)

You're printing `b` three times in that Playground which makes it a look skewed.

    a: 25100
    b: 25080
    c: 25080
    d: 25080

vs

    a: 24973
    b: 25010
    c: 25013
    d: 25004

So it's deterministic. I got the same numbers.

On the Playground or on your PC? The Playground has an execution cache, so the same input code always gives the same (thus "deterministic") result.

Ah OK, it was on the playground. Is it deterministic when not cached?

It is not deterministic on playground if it is not cached.

You can add dummy code to the file to break free from the cache.

Adding some white space also does the trick

> or changing hashtable iteration order.

This is a builtin feature of Go.

https://blog.golang.org/go-maps-in-action

Interesting. In contrast, the JavaScript standard says Map object iteration must return values in original insertion order. Firefox used to randomize the iteration order (to help find bugs), but (surprise!) it broke some web content. :(

https://bugzilla.mozilla.org/show_bug.cgi?id=743107

I don't think this is to shake out bugs. This is just to have a more random pseudo-random number generator so that applications using the crypto package for encryption will be more secure.

Why would it do it randomly then? Just read in the extra byte if you want extra entropy.

Starting at the link above, click on the #21915 in the commit message, which takes you to https://golang.org/issue/21915.

So for no reason, it is about forcing code not to rely on the behavior.

There's a reason given.

As in, the reason has nothing to do with entropy, and it is just about breaking code relying on an unspecified behavior.

One really easy way to break any encryption scheme is to crack the random number generator. This works because random number generators are deterministic and you can get them to output the exact same stream of random numbers as they did before if you have the same seed / state. This is presumably about making the output of the random number generator harder to predict.

> This is presumably about making the output of the random number generator harder to predict.

Randomly deciding to add an extra byte of entropy only adds 1 bit of entropy. Adding the extra byte always adds 8 bits of entropy.

There is no cryptographic reason to do this. It is just to break assumptions about the API.