There is still a lot of crypto out there that works off of using the current timestamp as a seed.
Being able to control he time could theoretically let you control any PRNGs that rely on it.
Being able to control he time could theoretically let you control any PRNGs that rely on it.
There is no problem with using low-resolution time signatures as a cryptographic seed. Using time as an entropy source is only a problem if you sample at a lower resolution than your clock's error rate.
Ummm, no. NTP normally runs on machines that have a local clock/battery, but which need an established network clock anyway.
> Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.
Using time as a random seed is probably a mistake in the first place. You could perhaps try to add entropy from a clock, but you'd want another source of entropy. Generally crypto code needs network clocks for other things (think of Kerberos ticket expiration).
Are you familiar with something other than NTP as a time source for devices without CMOS? I have a project that desperately needs crypto without a clock.
Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline.
Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).