From: Pavel Machek <pavel@ucw.cz>
To: Theodore Ts'o <tytso@mit.edu>,
Herbert Xu <herbert@gondor.apana.org.au>,
Linux Kernel Developers List <linux-kernel@vger.kernel.org>,
linux-crypto@vger.kernel.org, smueller@chronox.de,
andi@firstfloor.org, sandyinchina@gmail.com, jsd@av8n.com,
hpa@zytor.com
Subject: Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG
Date: Sun, 26 Jun 2016 20:47:43 +0200 [thread overview]
Message-ID: <20160626184743.GA11162@amd> (raw)
In-Reply-To: <20160619231827.GB9848@thunk.org>
Hi!
> Yes, I understand the argument that the networking stack is now
> requiring the crypto layer --- but not all IOT devices may necessarily
> require the IP stack (they might be using some alternate wireless
> communications stack) and I'd much rather not make things worse.
>
>
> The final thing is that it's not at all clear that the accelerated
> implementation is all that important anyway. Consider the following
> two results using the unaccelerated ChaCha20:
>
> % dd if=/dev/urandom bs=4M count=32 of=/dev/null
> 32+0 records in
> 32+0 records out
> 134217728 bytes (134 MB, 128 MiB) copied, 1.18647 s, 113 MB/s
>
> % dd if=/dev/urandom bs=32 count=4194304 of=/dev/null
> 4194304+0 records in
> 4194304+0 records out
> 134217728 bytes (134 MB, 128 MiB) copied, 7.08294 s, 18.9 MB/s
>
> So in both cases, we are reading 128M from the CRNG. In the first
> case, we see the sort of speed we would get if we were using the CRNG
> for some illegitimate, such as "dd if=/dev/urandom of=/dev/sdX bs=4M"
> (because they were too lazy to type "apt-get install nwipe").
>
> In the second case, we see the use of /dev/urandom in a much more
> reasonable, proper, real-world use case for /de/urandom, which is some
> userspace process needing a 256 bit session key for a TLS connection,
> or some such. In this case, we see that the other overheads of
> providing the anti-backtracking protection, system call overhead,
> etc., completely dominate the speed of the core crypto primitive.
>
> So even if the AVX optimized is 100% faster than the generic version,
> it would change the time needed to create a 256 byte session key from
> 1.68 microseconds to 1.55 microseconds. And this is ignoring the
Ok, so lets say I'm writing some TLS server, and I know that traffic
is currently heavy because it was heavy in last 5 minutes. Would it
make sense for me to request 128M of randomness from /dev/urandom, and
then use that internally, to avoid the syscall overhead?
Ok, maybe 128M is a bit much because by requesting that much in single
request i'd turn urandom into PRNG, but perhaps 1MB block makes sense?
And I guess even requesting 128M would make sense, as kernel can
select best crypto implementation for CRNG, and I'd prefer to avoid
that code in my application as it is hardware-specific...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2016-06-26 18:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-13 15:48 [PATCH-v4 0/7] random: replace urandom pool with a CRNG Theodore Ts'o
2016-06-13 15:48 ` [PATCH 1/7] random: initialize the non-blocking pool via add_hwgenerator_randomness() Theodore Ts'o
2016-06-13 15:48 ` [PATCH 2/7] random: print a warning for the first ten uninitialized random users Theodore Ts'o
2016-06-13 15:48 ` [PATCH 3/7] random: add interrupt callback to VMBus IRQ handler Theodore Ts'o
2016-06-13 15:48 ` [PATCH 4/7] random: properly align get_random_int_hash Theodore Ts'o
2016-06-13 15:48 ` [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG Theodore Ts'o
2016-06-13 18:00 ` Stephan Mueller
2016-06-13 19:03 ` Theodore Ts'o
2016-06-15 14:59 ` Herbert Xu
2016-06-19 23:18 ` Theodore Ts'o
2016-06-20 1:25 ` Herbert Xu
2016-06-20 5:02 ` Theodore Ts'o
2016-06-20 5:19 ` Herbert Xu
2016-06-20 15:01 ` Theodore Ts'o
2016-06-20 15:49 ` Stephan Mueller
2016-06-20 18:52 ` H. Peter Anvin
2016-06-20 23:48 ` Theodore Ts'o
2016-06-26 18:47 ` Pavel Machek [this message]
2016-06-26 19:10 ` Stephan Mueller
2016-06-26 22:51 ` Theodore Ts'o
2016-06-13 15:48 ` [PATCH 6/7] random: make /dev/urandom scalable for silly userspace programs Theodore Ts'o
2016-08-21 9:53 ` Jan Varho
2016-08-21 11:36 ` Theodore Ts'o
2016-06-13 15:48 ` [PATCH 7/7] random: add backtracking protection to the CRNG Theodore Ts'o
2016-06-26 18:47 ` Pavel Machek
2016-06-26 23:05 ` Theodore Ts'o
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160626184743.GA11162@amd \
--to=pavel@ucw.cz \
--cc=andi@firstfloor.org \
--cc=herbert@gondor.apana.org.au \
--cc=hpa@zytor.com \
--cc=jsd@av8n.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sandyinchina@gmail.com \
--cc=smueller@chronox.de \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.