Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

On Tue, Aug 02, 2022 at 11:58:43AM -0700, Bill Unruh wrote:
> I think it depends on what the purpose of the randomness is. If you need real
> cryptgrphic randomness-- ie, unpredictable by an attacker (as for example in
> encryption, or signatures) then you have to pay the price in time. If however
> what you just want it to have a stream of bytes which does not repeat, so that
> two instances will not give the same value (eg uuids or, I suspect filling the
> ntp time packets with cruft so that successive packets on time scales less
> than the precision of the clock do not give the same values) then must facter
> "random" stream generators would suffice. Calling a cryptogrphic random stream
> for the latter would seem to overkill, and much slower than necessary. Does
> anyone care if the time stamp bits which are better than the precision are
> predictable by someone outside? Does this give any attacker a attack vector?

Good question.

I think it matters more for the client rather than the server. chronyd
as a client randomizes all 64 bits of the timestamp. If an off-path
attacker could predict the bits, it would be easier to spoof a valid
response from the server.

There might be some cases where it's important also for the server,
e.g. with the interleaved mode, but I'm not really sure.

Peers in the symmetric mode are clients and servers at the same time.

Currently, the same code path is used for randomizing the timestamp of
the client and server and I'd prefer to keep it that way.

-- 
Miroslav Lichvar


-- 
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.