nebulouslabs / fastrand Goto Github PK

underlying int type is not guaranteed to be 64 bits,so fastrand will behave incorrectly on some architectures.

First, Go is not the go-to language for crypto. And BLAKE2 is relatively novel.

If any recursive-hashing-patterns-based attack becomes possible, which with BLAKE is slightly more likely than with SHA2, this will fail gruesomely.

For most lifetimes the padding bits will be all 0's, because of your extracounter, so it will be extra easy. After that the value of extracounter is very predictable (even over the network). initialise the counters randomly - just hashed out of the original entropy is still better than original randomness. Just /copying/ the original entropy is better too!

"little risk of overflow" fastrand.go:76 is still a race condition. Why not alternate incrementing the two counters? (I don't think our computers can overrun a 128 bit counter anytime soon, I wouldn't bother if I were you)

"The counter ensures that the result is unique to this thread." then use the threadID, not a massive counter...

Instead of using two huge counters, it would be better to use some of that space to add extra entropy throughout (as little as 1 bit). You may request extra random bits in another thread, and just hash them in. By adding a little bit of entropy like that, you compensate for the reduced security involved in producing more hashes. And, if you ever do overrun a 128bit counter, well, it's fine!

Actually, when you add entropy like that, I would just chose a 64 bit counter and allow it to overrun.

Hashes sure are amazing, to allow this sort of operation, aren't they? 👍

From Reddit:

I downloaded it last night and rand the benchmarks on my workstation, which has dual 24 core xeons. Your lib int32 was only 30mb vs 15mb from stdlib. I imagine on faster consumer machines with far less cores it would do much better, I didn't test it on my desktop machine.

https://www.reddit.com/r/golang/comments/616czq/fast_replacement_for_cryptorand_10x_faster_no/dfcplpx/