TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Linux /dev/urandom and concurrency

90 点作者 drsnyder大约 11 年前

11 条评论

kijin大约 11 年前
If your program needs to read 4K from &#x2F;dev&#x2F;urandom multiple times per second, you&#x27;re doing it wrong. There is little benefit in reading anything over 32 bytes at a time.<p>According to the man page for &#x2F;dev&#x2F;random and &#x2F;dev&#x2F;urandom:<p>&gt; <i>no cryptographic primitive available today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel random pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is not skillfully implemented.</i>
Glyptodon大约 11 年前
So why is there a lock for reads from urandom? I suppose if there weren&#x27;t a lock concurrent reads would all get the same random values?
评论 #7610799 未加载
评论 #7610771 未加载
sebcat大约 11 年前
As a user of libcares (which is awesome for bulk DNS lookups btw) I&#x27;ll add that I&#x27;ve only ever needed one ares_channel per process. Having one ares_channel for every CURL-handle seems a bit excessive. This is probably the main problem here, not the kernel spinlock.<p>Edit: Come to think about it, why isn&#x27;t the CURL-handle reused? Sounds like a new CURL-handle is inited for every request, which I don&#x27;t recall being necessary.
评论 #7611074 未加载
Mister_Snuggles大约 11 年前
A more important question would be &quot;Why does asynchronous DNS resolution require random data in the first place?&quot;
评论 #7610864 未加载
评论 #7610872 未加载
评论 #7612736 未加载
aidenn0大约 11 年前
Seed a secure userspace PRNG from urandom, perhaps?
评论 #7610951 未加载
评论 #7611590 未加载
mike-cardwell大约 11 年前
Interestingly enough, I have actually been working on writing a DNS client library in C++ with Boost ASIO this very afternoon. I was going to get my source of random data using the following C++11 standard library code. I would really appreciate any comments from people here if there is anything wrong with what I&#x27;m doing:<p><pre><code> #include &lt;random&gt; std::uniform_int_distribution&lt;uint32_t&gt; dist; &#x2F;&#x2F; Seed a Mersenne twister PRNG with random data: std::mt19937 eng; std::random_device rd; eng.seed(dist(rd)); &#x2F;&#x2F; Now to generate random numbers, simply: uint32_t random_number = dist(eng);</code></pre>
评论 #7611045 未加载
评论 #7611268 未加载
rcoh大约 11 年前
The stdlib rand() function on unix has a global lock around it provided by many versions of Linux. As such, if rand() is called in performance critical parallel code, performance will tank as each thread or process attempts to acquire this lock. Even if this lock is not acquired, you will still have a race condition on the state of the random number generator and may produce bad (non-random) randomness.<p>Use rand_r(unsigned int *state) instead in parallel and concurrent applications.<p>Sources: man 3 rand [unix command] <a href="http://unixhelp.ed.ac.uk/CGI/man-cgi?rand+3" rel="nofollow">http:&#x2F;&#x2F;unixhelp.ed.ac.uk&#x2F;CGI&#x2F;man-cgi?rand+3</a>
评论 #7611505 未加载
X-Istence大约 11 年前
I love how Theodore Ts&#x27;o suggests using a user space PRNG that is seeded from &#x2F;dev&#x2F;urandom. OpenBSD are ripping out all of the user space PRNG stuff from OpenSSL in favour of arc4random_buf()...
评论 #7612856 未加载
ape4大约 11 年前
Why does he need so much pseudorandomness. And why use &#x2F;dev&#x2F;urandom directly. Maybe using the random library from the programming environment would make more sense.
评论 #7611354 未加载
rafekett大约 11 年前
overreliance on &#x2F;dev&#x2F;urandom in the presence of little entropy is a well known performance problem on servers. that&#x27;s why <a href="http://en.wikipedia.org/wiki/Hardware_random_number_generator" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Hardware_random_number_generato...</a> exist
评论 #7610691 未加载
评论 #7610685 未加载
评论 #7610861 未加载
评论 #7610696 未加载
bcl大约 11 年前
The code he pointed to is for kernel 2.6.18 which at this point could be considered ancient history. If you look at current master - <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?id=refs/tags/v3.15-rc1#n1365" rel="nofollow">https:&#x2F;&#x2F;git.kernel.org&#x2F;cgit&#x2F;linux&#x2F;kernel&#x2F;git&#x2F;torvalds&#x2F;linux....</a><p>it looks like it has been re-factored somewhat, although the lock is still in there.