-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit ID randomness decision based on new performance data #1037
Comments
Also, here's a CPU profile of that benchmark showing the CPU usage of crypto/rand is very low relative to the rest of the program.
|
This seems reasonable to me. It’s probably how I would write the code. It might be better on (massively) multi-core systems as it avoids holding a mutex lock. |
I'm also fine with making this change. Thanks @jsha |
Thanks! I started work on this today and ran into a bit of a hurdle: Right now I see two ways forward: (a) panic if |
Is there anywhere to externalize the source of randomness, such that default behavior (presumably either |
The exported |
I would like to just revert to the "random" the stdlib still uses, which uses time.Now() essentially. This also saves a syscall, although I'm not sure if Go does vDSO |
@miekg Go does use vDSO for certain syscalls. On Linux/amd64 this is only for The runtime uses an xorshift64+ generator for 'fast' random uses, seeded from I doubt the overhead of using crypto/rand would be noticeable in basically any use case and it seems far more secure then using math/rand. @jsha Falling back to math/rand definitely seems like the better choice. |
Ack, but I honestly can't understand how 16 bits warrant a discussion this
deep. Any on the wire attacker can just spray the target with packets,
which is totally doable because of the limited "key" space
…On Wed, 4 Dec 2019, 07:38 Tom Thorogood, ***@***.***> wrote:
@miekg <https://github.com/miekg> Go does use vDSO for certain syscalls.
On Linux/amd64 this is only for gettimeofday and clock_gettime see
vdso_linux_amd64.go
<https://github.com/golang/go/blob/acf3ff2e8a0ee777a35b42879c90a1d5a130988f/src/runtime/vdso_linux_amd64.go>
.
The runtime uses an xorshift64+ generator
<https://github.com/golang/go/blob/acf3ff2e8a0ee777a35b42879c90a1d5a130988f/src/runtime/stubs.go#L99-L111>
for 'fast' random uses, seeded from /dev/urandom amongst other things.
I doubt the overhead of using crypto/rand would be noticeable in basically
any use case and it seems far more secure then using math/rand.
@jsha <https://github.com/jsha> Falling back to math/rand definitely
seems like the better choice.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1037?email_source=notifications&email_token=AACWIW5BWXWIM6UUKGRDYXDQW5NA7A5CNFSM4JNT4KT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF4BD2Y#issuecomment-561517035>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACWIW5VN6BDJZZ5QZECPKTQW5NA7ANCNFSM4JNT4KTQ>
.
|
This should have been closed by #1044. |
* Use crypto/rand for random id generation. Fixes miekg#1043 and miekg#1037 * Panic on rare crypto/rand error. * Fixes in response to review.
In #48 and #102 some benchmarking data was provided showing that
math/rand
is faster thancrypto/rand
(for use in generating query IDs). However, those tests took too narrow a view. It's important to look at ID generation in the actual context in which it's used.I wrote a more robust benchmark that stands up a trivial DNS server, and sends a lot of queries at it. You can fiddle with values of
parallel
to try and max out local CPU. On my laptop,-parallel 40
came close to maxing out my CPUs, and I was able to get an average qps of 147,210 for crypto/rand vs 147,350 for math/rand. This is a pretty tiny difference, and that's in optimal conditions. Across a real network, the qps would be much lower, which means the impact of using crypto/rand would be much lower.I'd like to propose making
crypto/rand
the default, so users don't have to worry about whether they need more secure ID generation.The text was updated successfully, but these errors were encountered: