This sounds interesting. Do you happen to have an article-link with more details handy?

score 1 · canonical

This is exactly what the linked python code is doing, right? Just retrying the random call if the sampled value is outside of the acceptable range (adjusted for the fact that Python generally makes random numbers only available between 0-1).

So for my simple coin flipping app, i have the choice between doing it right, and using up more of the randomness my computer has stored suring runtim, or doing it wrong, and by the end of human existence, the coin will have come up heads once too often. I think this isn’t something terribly problematic. Still an interesting read though.

Also, I don’t know that much about how the computer creates random numbers, but how certain can we be that the original random call actually is uniformely distributed to begin with?

score 1 · canonical

I agree with you. The article seems to pose this as a “we can avoid this pain by simply remaining on sha1” while in truth this seems like it would end up putting us in a worse situation 20 years into the future if sha1 gets more broken and there is even more legacy code still dependent on sha1 references remaining untouched. This feels a bit like setting ourselves up for a Y2K-like event if the new sha256 doesn’t start slowly being rolled out now.

score 1 · canonical

I’m assuming this is the (various) source code(s) for the EU age verification app’s open source publishings? Or is there a different source for that?

score 1 · canonical