From: Sandy Harris <sandyinchina@gmail.com>
To: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
"Ted Ts'o" <tytso@mit.edu>, Stephan Mueller <smueller@chronox.de>,
John Denker <jsd@av8n.com>,
m@ib.tc
Subject: Re: Lockless /dev/random - Performance/Security/Stability improvement
Date: Fri, 11 Jun 2021 17:43:52 +0800 [thread overview]
Message-ID: <CACXcFmmW+tCUf8JS=a=wJEnBY2JojP8VwEGLncYcGLZqiU+5Jw@mail.gmail.com> (raw)
In-Reply-To: <CACXcFmnRAkrj0Q3uFjyLu7RaWQh0VPbmErkj+cUaxZMb=YiGCw@mail.gmail.com>
Sandy Harris <sandyinchina@gmail.com> wrote:
> The basic ideas here look good to me; I will look at details later.
Looking now, finding some things questionable.
Your doc has:
" /dev/random needs to be fast, and in the past it relied on using a
cryptographic primitive for expansion of PNRG to fill a given request
" urandom on the other hand uses a cryptographic primitive to compact
rather than expand,
This does not seem coherent to me & as far as I can tell, it is wrong as well.
/dev/random neither uses a PRNG nor does expansion.
/dev/urandom does both, but you seem to be saying the opposite.
" We can assume AES preserves confidentiality...
That is a reasonable assumption & it does make the design easier, but
is it necessary? If I understood some of Ted's writing correctly, one
of his design goals was not to have to trust the crypto too much. It
seems to me that is a worthy goal. One of John Denker's papers has
some quite nice stuff about using a hash function to compress input
data while preserving entropy. It needs only quite weak assumptions
about the hash.
https://www.av8n.com/turbid/
You want to use AES in OFB mode. Why? The existing driver uses ChaCha,
I think mainly because it is faster.
The classic analysis of how to use a block cipher to build a hash is
Preneel et al.
https://link.springer.com/content/pdf/10.1007%2F3-540-48329-2_31.pdf
As I recall, it examines 64 possibilities & finds only 9 are secure. I
do not know if OFB, used as you propose, is one of those. Do you?
next prev parent reply other threads:[~2021-06-11 9:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-09 0:33 Lockless /dev/random - Performance/Security/Stability improvement Mike Brooks
2021-06-11 3:59 ` Sandy Harris
2021-06-11 5:59 ` Stephan Müller
2021-06-11 9:53 ` Stephan Mueller
2021-06-11 9:43 ` Sandy Harris [this message]
[not found] ` <CALFqKjTAHvORw_U3sGe0ZRvAH8kTVKCdgVKQu+SK6h=C7B-jbA@mail.gmail.com>
2021-06-27 16:35 ` Mike Brooks
2021-08-16 10:59 ` Sandy Harris
2021-08-16 14:25 ` Theodore Ts'o
2022-01-27 0:35 ` Sandy Harris
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='CACXcFmmW+tCUf8JS=a=wJEnBY2JojP8VwEGLncYcGLZqiU+5Jw@mail.gmail.com' \
--to=sandyinchina@gmail.com \
--cc=jsd@av8n.com \
--cc=linux-crypto@vger.kernel.org \
--cc=m@ib.tc \
--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.