2 ms·
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
by 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 agoThe 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 agoInsufficient 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/...