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.
[chrony-dev] [GIT] chrony/chrony.git branch master updated. 4.2-66-gd91ae20
This is an automated email from git. It was generated because a ref
change was pushed to the "chrony/chrony.git" repository.
The branch, master has been updated
via d91ae2094fa87094430392acd9fd54b4132ba9f1 (commit)
via 30a584509895a29a573c9546bdede13d877ce13e (commit)
via 0f367efac53c45157807c99de45ce7e721960cf3 (commit)
via 24c011d4a61c889b2ee3c955318a874c75b6864b (commit)
via 0c2cdd2fb14652b9274a09291452fd22c54d5116 (commit)
via cd1a666e1bee6ce0e14278106e2f937430ada91c (commit)
from 070b4f69d0c2e2037102a64abd9e385fad45a33b (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit d91ae2094fa87094430392acd9fd54b4132ba9f1
Author: Miroslav Lichvar
Date: Wed Aug 3 13:17:42 2022 +0200
configure: disable arc4random on Linux
In glibc 2.36 was added the arc4random family of functions. However,
unlike on other supported systems, it is not a user-space PRNG
implementation. It just wraps the getrandom() system call with no
buffering, which causes a performance loss on NTP servers due to
the function being called twice for each response to add randomness
to the RX and TX timestamp below the clock precision.
Don't check for arc4random on Linux to keep using the buffered
getrandom().
commit 30a584509895a29a573c9546bdede13d877ce13e
Author: Miroslav Lichvar
Date: Tue Aug 2 15:09:38 2022 +0200
configure: avoid -Wnonnull warnings
Replace NULL in test code of functions which have (at least in glibc) or
could have arguments marked as nonnull to avoid the -Wnonnull warnings,
which breaks the detection with the -Werror option.
commit 0f367efac53c45157807c99de45ce7e721960cf3
Author: Miroslav Lichvar
Date: Tue Aug 2 16:51:48 2022 +0200
doc: suggest self-signed certificates for NTS in FAQ
commit 24c011d4a61c889b2ee3c955318a874c75b6864b
Author: Miroslav Lichvar
Date: Tue Aug 2 14:45:18 2022 +0200
test: catch definite leaks with valgrind
commit 0c2cdd2fb14652b9274a09291452fd22c54d5116
Author: Miroslav Lichvar
Date: Mon Aug 1 16:20:13 2022 +0200
test: fix ntp_core unit test to disable source selection
If the randomly generated timestamps are close to the current time, the
source can be selected for synchronization, which causes a crash when
logging the source name due to uninitialized ntp_sources.
Specify the source with the noselect option to prevent selection.
commit cd1a666e1bee6ce0e14278106e2f937430ada91c
Author: Miroslav Lichvar
Date: Mon Aug 1 13:04:00 2022 +0200
test: fix sources unit test to call SRC_ReportSource() correctly
Call the function with current time instead of latest sample of the
first source to avoid undefined conversion of negative double to long
int.
Fixes: 07600cbd714f ("test: extend sources unit test")
---
Summary of changes:
configure | 35 ---
doc/faq.adoc| 12
test/compilation/003-sanitizers | 6 --
test/unit/ntp_core.c| 2 +-
test/unit/sources.c | 1 +
5 files changed, 38 insertions(+), 18 deletions(-)
hooks/post-receive
--
chrony/chrony.git
--
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.
