| Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
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 ______|_ www.theory.physics.ubc.ca/
On Tue, 2 Aug 2022, Bill Unruh wrote:
[CAUTION: Non-UBC Email]
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 ______|_ www.theory.physics.ubc.ca/
On Tue, 2 Aug 2022, Miroslav Lichvar wrote:
[CAUTION: Non-UBC Email]
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.
--
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.
--
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.