RE: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
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/2024052958.2384173-1-ja...@zx2c4.com/ > -Original Message- > From: Bill Unruh > 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 _|___ 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 _|___ 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 +, 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.
RE: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
> From: Elliott, Robert (Servers) ... > 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". This is progressing in the kernel and glibc - see https://lore.kernel.org/lkml/y30tqdresmn8v...@zx2c4.com/ -- 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.
Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
un...@physics.ubc.ca said: > Are you stating that /dev/urandom is not available on the machine you are > using? No. A crypto package is needed for shared keys. I/we hadn't considered building without shared keys. > You are using Linux I believe. NTPsec builds/runs on Linux, FreeBSD, NetBSD, and probably anything that is POSIX enough and supports ntp_adjtime(). -- These are my opinions. I hate spam. -- 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.
Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
Are you stating that /dev/urandom is not available on the machine you are using? You are using Linux I believe. What version of Linux does not have /dev/urandom. Note that /dev/random, which should also be available, should not be used. It has the same strength as urandom, but can block indefinitely if it thinks it does not have enought "entropy" to finish delivering the bytes it thinks it needs (esssentially /dev/random does not deliver more bytes that contained in its "seed" which is harvested from various "randomness" sources like disk access times, typing intervals, Unfortunately things like the RP computers have no disks, or keyboards, etc. and so as I understand it, play badly with /dev/random (ie, run out of seed easily and thus could block.) On Wed, 3 Aug 2022, Hal Murray wrote: [CAUTION: Non-UBC Email] mlich...@redhat.com said: Is OpenSSL required in NTPsec? chrony can be built with no crypto library, so it needs a random generator that's always available. That's /dev/urandom. Not currently. Thanks for the suggestion. -- These are my opinions. I hate spam. -- 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. -- 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.
Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
mlich...@redhat.com said: > Is OpenSSL required in NTPsec? chrony can be built with no crypto library, so > it needs a random generator that's always available. That's /dev/urandom. Not currently. Thanks for the suggestion. -- These are my opinions. I hate spam. -- 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.
Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
On Tue, Aug 02, 2022 at 09:32:34AM -0700, Hal Murray wrote: > mlich...@redhat.com said: > > 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 > > NTPsec uses OpenSSL and their crypto package. I noticed significant CPU > going > into randomness. On investigation, there is high overhead. The cycles per > byte isn't horrible for longer chunks. It's things like calling getpid() > called during setup. Is OpenSSL required in NTPsec? chrony can be built with no crypto library, so it needs a random generator that's always available. That's /dev/urandom. > > I've contemplated using a big buffer. Fill it with one call to amortize the > overhead. Pass out small chunks as needed. I haven't written any code. That's what chrony does, but not with arc4random as that is assumed to have its own buffer. -- 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.
Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
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-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.
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 _|___ Advanced Research _| Fax: +1(604)822-5324 UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca 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 _|___ Advanced Research _| Fax: +1(604)822-5324 UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca 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 +, 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. -- 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. -- 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.
Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
mlich...@redhat.com said: > 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 NTPsec uses OpenSSL and their crypto package. I noticed significant CPU going into randomness. On investigation, there is high overhead. The cycles per byte isn't horrible for longer chunks. It's things like calling getpid() called during setup. I've contemplated using a big buffer. Fill it with one call to amortize the overhead. Pass out small chunks as needed. I haven't written any code. --- The code I use to poke around is in attic/random.c Intel(R) Core(TM) i3-2120 CPU @ 3.30GHz Running on OpenSSL 3.0.5 5 Jul 2022 times in ns avg fastest lng getpid():389(simple kernel call) clock_gettime:19(overhead of fastest) random(): 18 36 RAND_bytes(): 2122 20384 RAND_bytes(): 2110 2041 16 RAND_bytes(): 2363 2231 32 RAND_bytes(): 2720 2628 160 RAND_bytes(): 3090 2980 320 RAND_priv_bytes(): 2120 20344 RAND_priv_bytes(): 2107 2025 16 RAND_priv_bytes(): 2326 2231 32 RAND_priv_bytes(): 2732 2625 160 RAND_priv_bytes(): 3107 2981 320 -- These are my opinions. I hate spam. -- 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.
RE: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
> -Original Message- > From: Miroslav Lichvar > Sent: Tuesday, August 2, 2022 6:00 AM > To: chrony-dev@chrony.tuxfamily.org > Subject: Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom > > On Mon, Aug 01, 2022 at 02:07:53AM +, 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. The concern with userspace libraries creating their own random values or using a buffer of previously fetched random values from the kernel seems to be (quoting Ted Ts'o): "all of the attendant opportunities for security vulnerabilities in the face of VM snapshots, or VM's getting duplicated with a pre-spun execution image, etc., etc." Perhaps Linus will be more receptive if a use case where vDSO performance is important, like a chrony server, is described. -- 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.
Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
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 _|___ Advanced Research _| Fax: +1(604)822-5324 UBC, Vancouver,BC _|_ Program in Cosmology | un...@physics.ubc.ca 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 +, 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. -- 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.
Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
On Mon, Aug 01, 2022 at 02:07:53AM +, 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.
Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
On Mon, Aug 01, 2022 at 02:07:53AM +, Elliott, Robert (Servers) wrote: > Since chrony is using a library (e.g., gnutls) for cryptography, perhaps > it should use that library's random function as well rather than use > a function from glibc or go directly to the /dev/urandom file. > Let the library figure out the best technique to use. The chronyc keygen command is supposed to work even when not built with the SECHASH or NTS feature, i.e. not using a crypto library, so there has to be some support for generating keys. AFAIK there is nothing wrong with using /dev/urandom for generating keys and the crypto libraries use it for seeding their own (fast) random generators. In any case, it is documented in the chronyd and chronyc man pages. > Relying on one library would help eventual FIPS validation efforts - > it would be easier to demonstrate that chrony is also FIPS compliant > if it relies on a library that is in FIPS mode. Sounds like an unnecessary complication to me, which would need additional testing. > Red Hat recommends that at https://access.redhat.com/articles/3655361: > "In order to access a CSPRNG in an application, the use of the kernel's > getrandom() interface is recommended only when no cryptographic library > is used. When an application is already depending on one of our core > crypto libraries, we recommend using that library's provided interfaces." chronyd doesn't use getrandom() for generating keys or anything that would require a CSPRNG. In the two instances where a CSPRNG is needed, it's always /dev/urandom and that is easy to verify. -- 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.
RE: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom
> -Original Message- > From: Miroslav Lichvar > Sent: Thursday, July 28, 2022 9:53 AM > To: chrony-dev@chrony.tuxfamily.org > Subject: Re: [chrony-dev] nts_ke_server calling UTI_GetRandomBytesUrandom > > On Thu, Jul 28, 2022 at 02:46:38PM +, Elliott, Robert (Servers) > wrote: > > Two places call UTI_GetRandomBytesUrandom rather than > UTI_GetRandomBytes. > > > > 1. nts_ke_server.c generate_key (from patch a420ed57q): > > + UTI_GetRandomBytesUrandom(server_keys[index].key, key_length); > > + if (!SIV_SetKey(server_keys[index].siv, server_keys[index].key, > key_length)) > > +assert(0); > > + > > + UTI_GetRandomBytes(_keys[index].id, sizeof > (server_keys[index].id)); > > > > 2. client.c process_cmd_keygen (from patch 7fcf69ce): > > + UTI_GetRandomBytesUrandom(key, length); > > > > Is there any reason for them to call the Urandom version directly? > > They generate long-term keys, i.e. need a higher-quality random > generator. The non-Urandom version can use arc4random() which is fast, > but not described as suitable for long term keys, at least as I > understand it. The upcoming glibc has arc4random(), so this will be > the case also on Linux. 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". Since chrony is using a library (e.g., gnutls) for cryptography, perhaps it should use that library's random function as well rather than use a function from glibc or go directly to the /dev/urandom file. Let the library figure out the best technique to use. Relying on one library would help eventual FIPS validation efforts - it would be easier to demonstrate that chrony is also FIPS compliant if it relies on a library that is in FIPS mode. (FIPS mode will require getting AES-SIV or AES-GCM-SIV approved by NIST, and NIST will probably require the variations that are based on 256-bit AES, so chrony will need to make some changes for that) Red Hat recommends that at https://access.redhat.com/articles/3655361: "In order to access a CSPRNG in an application, the use of the kernel's getrandom() interface is recommended only when no cryptographic library is used. When an application is already depending on one of our core crypto libraries, we recommend using that library's provided interfaces." -- 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.
