RE: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom

["Elliott, Robert (Servers)" <elliott@xxxxxxx>]

The Linux kernel RNG vDSO getrandom() patch series stalled out before, but has
been revived. See "[PATCH v15 0/5] implement getrandom() in vDSO" on
https://lore.kernel.org/lkml/20240521111958.2384173-1-Jason@xxxxxxxxx/


> -----Original Message-----
> From: Bill Unruh <unruh@xxxxxxxxxxxxxx>
> Sent: Tuesday, August 2, 2022 1:59 PM
> To: chrony-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
> 
> 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?
> In fact it would seem that using a different generator for this purpose
> rather
> than for instances where cryptographic randomness is needed would be an
> advantage in that you would be giving less information about the
> cryptographic
> stream generator to an attacker.
> 
> Of course this is irrelevant prediction  of  the random cruft in the
> timestamps
> gives  an attacker an advantage.
> 
> 
> 
> William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
> Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
> UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
> Canada V6T 1Z1 ____|____ and Gravity ______|_
> 
> On Tue, 2 Aug 2022, Bill Unruh wrote:
> 
> > Does the added "randomness" need to be crypographically secure or does it just
> > need to be messed up. Ie is there some attack that someone could lauch against
> > chrony if they could predict the random stream for that fuzz in the
> > timestamps? If not then using the full force of
> > urandom/getrandom/arc4random
> > would seem expensive overkill. For example using something like A New Class
> > of Random Number Generators
> > George Marsaglia, Arif Zaman
> > Ann. Appl. Probab. 1(3): 462-480 (August, 1991). DOI:
> > 10.1214/aoap/1177005878
> > might be much faster.
> >
> > William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
> > Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
> > UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
> > Canada V6T 1Z1 ____|____ and Gravity ______|_
> >
> > On Tue, 2 Aug 2022, Miroslav Lichvar wrote:
> >
> >> On Mon, Aug 01, 2022 at 02:07:53AM +0000, Elliott, Robert (Servers)
> >> wrote:
> >>> I see the glibc discussion about arc4random has led to a proposal this
> >>> weekend to add a vDSO for the linux kernel's getrandom(). It'll be
> >>> interesting to see if that is accepted - Linus' initial reaction was
> >>> "no".
> >>
> >> I was surprised to see they switched arc4random in glibc to
> >> getrandom(). That has a significant performance impact on chronyd, as
> >> it calls the function for each generated RX and TX timestamp. In my
> >> test the maximum number of requests per second handled as a server
> >> dropped by about 25%. That's not great.
> >>
> >> We'll need to disable the function on Linux, at least until the vDSO
> >> getrandom() is widely available.
> >>
> >> --
> >> 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.