Computing desk
< December 11	<< Nov \| December \| Jan >>	December 13 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

December 12

NTP security with finite time-to-brute-force

If a device has been disconnected from power long enough to drain its clock battery, or has no clock battery at all, and its potential lifespan is longer than the duration of a certificate, what assurance can its NTP client have (assuming it can't rely on a trusted human to provide the approximate date) that its network connection is not controlled by an impostor who has had enough time to brute-force the server's private key, use it to backdate the time to when its certificate was still valid, and simulate an older time by e.g. truncating blockchains and Git branches to older versions? Neon Merlin 23:38, 12 December 2021 (UTC)[reply]

If the network connection of a device is controlled by an impostor, they can do basically anything. The device is living in the Matrix; it sees the world as it is served up through its network connection. --Lambiam 07:25, 13 December 2021 (UTC)[reply]

When you say enough time to brute-force the server's private key, you're talking about a seriously science-fictional scenario. Using brute force to find a typical 256-bit key would require checking, on average,

2^{255}

possible keys. If you had a network of a trillion computers, each of which could check a trillion keys per second, it would still take you over

10^{45}

years to test that many keys. CodeTalker (talk) 01:10, 14 December 2021 (UTC)[reply]

In other words you have a 1 in 2²⁵⁵ chance of getting on your first try. And if you do that, then you are the luckiest person on earth. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 03:09, 14 December 2021 (UTC)[reply]

It can't. However public key life-spans are set not to prevent brute-forcing, but incase the the corresponding private key is leaked (and has a insecure password, which might be common with server's keys). LongHairedFop (talk) 11:28, 14 December 2021 (UTC)[reply]

If the client's clock is set to an earlier time, it won't know that the public key has reached its end of life. CodeTalker (talk) 16:52, 14 December 2021 (UTC)[reply]