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-ja...@zx2c4.com/
> -----Original Message----- > From: Bill Unruh <un...@physics.ubc.ca> > Sent: Tuesday, August 2, 2022 1:59 PM > To: chrony-dev@chrony.tuxfamily.org > 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 |____ un...@physics.ubc.ca > 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 |____ un...@physics.ubc.ca > > 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-requ...@chrony.tuxfamily.org with "unsubscribe" in the subject. For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the subject. Trouble? Email listmas...@chrony.tuxfamily.org.
