Hacker News
points by somat 18 hours ago | 0 comments
In my mind rand() (and friends) and hash(thing) (and friends) are almost the same function, with a very similar set of features required, the main difference is that rand() is non-deterministic and hash() is deterministic.

They are so close that people can and often do build rand() as "internal state s = hash(s) return s" (or similar). then other people, wanting that deterministic hash() behavior thus accidentally exposed, build entire worlds(literally) out of rand().

Another problem with this is that the rand() internals are opaque and unknown and can change without violating the spec. hash(), because it is supposed to be deterministic, usually has an exposed stable algorithm.

A specific example. At one job I found they were storing long term customer order archives encrypted where the key was a hash of the date, this in itself is a little suspicious but the archives were offline and physically locked up on site, so not too bad. The real wtf was that the encryption was done on a win98 machine with a perl script that was basically "seed(date); key = rand(); encrypt(data, key)". expecting to regenerate the key if they ever wanted to look at the data. When I saw that I went "I don't know much about perl, but that does not feel stable" and did a few checks. Sure enough the behavior of rand() could change depending on the operating system or even version. making the keys highly dependent on that exact win98 machine with that exact version of perl, I think they ended up using that machine to generate and store all used keys in a database so other machines could decrypt the archives.

[–] lo0dot0 13 hours ago
Encrypted with a key that is a date can be broken by iterating likely dates. Did they add the time up to milliseconds into it or just the date? Not sure if it matters
Hacker News