5 ms·

what if you add timestamp?

sillysaurusx 5y ago
From what source? That’s the hard part. Think of it in terms of VM snapshots. If you boot from a snapshot, there’s no way to get any timestamp guaranteed to be secure. But “secure” in this context is misleading. I subscribe to the “just use urandom” school of thought. It’s sufficiently secure in practice that no real security threats have emerged (can anyone point to a CVE?) and it seems like a waste of time to focus on this rather than the hundreds of other cases that cause dozens of CVEs.
- staticassertion 5y ago
  The source shouldn't be an issue even if the timestamp is reused. Timestamps just don't add a ton of entropy - a timestamp is generally 64bits, so even if it were actually random you could only ever get 64bits of entropy. And it's obviously way way way less than that since the clock is probably somewhat accurate, the computer is probably less than ~10 years old, and it's probably not way in the future. So it should be fine to add in, but I don't know how many bits you'd want to count that as.
- caf 5y ago
  Insufficient entropy is the root cause of this: https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf which is still happening: https://www.quintessencelabs.com/wp-content/uploads/2020/03/Factoring-RSA-Keys-in-the-IoT-Era-Paper.pdf https://www.quintessencelabs.com/wp-content/uploads/2020/03/...
AnonHP 5y ago
That would also make it predictable. Essentially, if you get a sequence of random numbers, it should be quite hard to predict what the next one would be.
staticassertion 5y ago
Yep, that is a good idea! But a timestamp only adds a little bit of entropy, and you want a few hundred if not a few thousand bits.
stouset 5y ago
Then if I know about when you turned your computer on, I can guess every random number you'll ever generate.
- anonymousiam 5y ago
  Not all computers have a RTC.
  - woodruffw 5y ago
    The presence or absence of a real-time clock doesn't significantly change the problem here.
- postalrat 5y ago
  If they used a timestamp then all you really need is a couple random numbers to find the seed. Just keep guessing timestamps until you find a sequence that matches.
richdougherty 5y ago
Here's a fun article about hacking online poker, in part by taking advantage of a time-based seed: https://www.developer.com/guides/how-we-learned-to-cheat-at-online-poker-a-study-in-software-security/ https://www.developer.com/guides/how-we-learned-to-cheat-at-... "The system clock seed gave us an idea that reduced the number of possible shuffles even further. By synchronizing our program with the system clock on the server generating the pseudo-random number, we are able to reduce the number of possible combinations down to a number on the order of 200,000 possibilities. After that move, the system is ours, since searching through this tiny set of shuffles is trivial and can be done on a PC in real time."

From what source? That’s the hard part. Think of it in terms of VM snapshots. If you boot from a snapshot, there’s no way to get any timestamp guaranteed to be secure. But “secure” in this context is misleading. I subscribe to the “just use urandom” school of thought. It’s sufficiently secure in practice that no real security threats have emerged (can anyone point to a CVE?) and it seems like a waste of time to focus on this rather than the hundreds of other cases that cause dozens of CVEs.

staticassertion 5y ago
The source shouldn't be an issue even if the timestamp is reused. Timestamps just don't add a ton of entropy - a timestamp is generally 64bits, so even if it were actually random you could only ever get 64bits of entropy. And it's obviously way way way less than that since the clock is probably somewhat accurate, the computer is probably less than ~10 years old, and it's probably not way in the future. So it should be fine to add in, but I don't know how many bits you'd want to count that as.
caf 5y ago
Insufficient entropy is the root cause of this: https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf which is still happening: https://www.quintessencelabs.com/wp-content/uploads/2020/03/Factoring-RSA-Keys-in-the-IoT-Era-Paper.pdf https://www.quintessencelabs.com/wp-content/uploads/2020/03/...

AnonHP 5y ago

That would also make it predictable. Essentially, if you get a sequence of random numbers, it should be quite hard to predict what the next one would be.

staticassertion 5y ago

Yep, that is a good idea! But a timestamp only adds a little bit of entropy, and you want a few hundred if not a few thousand bits.

stouset 5y ago

Then if I know about when you turned your computer on, I can guess every random number you'll ever generate.

anonymousiam 5y ago
Not all computers have a RTC.
- woodruffw 5y ago
  The presence or absence of a real-time clock doesn't significantly change the problem here.
postalrat 5y ago
If they used a timestamp then all you really need is a couple random numbers to find the seed. Just keep guessing timestamps until you find a sequence that matches.

richdougherty 5y ago

Here's a fun article about hacking online poker, in part by taking advantage of a time-based seed: https://www.developer.com/guides/how-we-learned-to-cheat-at-online-poker-a-study-in-software-security/ https://www.developer.com/guides/how-we-learned-to-cheat-at-... "The system clock seed gave us an idea that reduced the number of possible shuffles even further. By synchronizing our program with the system clock on the server generating the pseudo-random number, we are able to reduce the number of possible combinations down to a number on the order of 200,000 possibilities. After that move, the system is ours, since searching through this tiny set of shuffles is trivial and can be done on a PC in real time."