4 ms·
This change is interesting: crypto: randomly read an extra byte of randomness in some places. https://go-review.googlesource.com/c/go/+/64451 https://go-revie
by cpeterso 8y ago
This change is interesting:
crypto: randomly read an extra byte of randomness in some places.
https://go-review.googlesource.com/c/go/+/64451 https://go-review.googlesource.com/c/go/+/64451
Firefox has a similar testing feature called "chaos mode" that tries to shake out bugs by doing things like randomly forcing short file or socket reads or changing hashtable iteration order. Due to the increased chance of buggy behavior or performance issues, this isn't the sort of thing you would do in production (unless you're on Netflix's chaos engineering team. :)
- omarforgotpwd 8y agoI 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.
- staticassertion 8y agoWhy would it do it randomly then? Just read in the extra byte if you want extra entropy.
- rsc 8y agoStarting at the link above, click on the #21915 in the commit message, which takes you to https://golang.org/issue/21915 https://golang.org/issue/21915.
- staticassertion 8y agoSo for no reason, it is about forcing code not to rely on the behavior.
- baq 8y agoThere's a reason given.
- staticassertion 8y agoAs in, the reason has nothing to do with entropy, and it is just about breaking code relying on an unspecified behavior.
- omarforgotpwd 8y agoOne 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.
- staticassertion 8y ago> 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.
- pquerna 8y agoI 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 https://play.golang.org/p/cnAXBEZJm2B (fixed playground link)
- zimpenfish 8y agoYou'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
- cup-of-tea 8y agoSo it's deterministic. I got the same numbers.
- akavel 8y agoOn the Playground or on your PC? The Playground has an execution cache, so the same input code always gives the same (thus "deterministic") result.
- cup-of-tea 8y agoAh OK, it was on the playground. Is it deterministic when not cached?
- dosshell 8y agoIt is not deterministic on playground if it is not cached. You can add dummy code to the file to break free from the cache.
- nnx 8y ago> or changing hashtable iteration order. This is a builtin feature of Go. https://blog.golang.org/go-maps-in-action https://blog.golang.org/go-maps-in-action
- cpeterso 8y agoInteresting. 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 https://bugzilla.mozilla.org/show_bug.cgi?id=743107