Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
From:   Mike Brooks <m@ib.tc>
Date:   Sat, 8 May 2021 17:33:48 -0700
Message-ID: <CALFqKjSnOWyFjp7NQZKMXQ+TfzXMCBS=y8xnv5GE56SHVr5tCg@mail.gmail.com>
Subject: Lockless /dev/random - Performance/Security/Stability improvement
To:     linux-crypto@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hello Everyone,

I am a cryptographer, a hacker, and exploit developer.  I am an
accomplished security engineer, and I've even hacked Majordomo2, the
maling list we are using now (CVE-2011-0049).

It is highly unusual that /dev/random is allowed to degrade the
performance of all other subsystems - and even bring the system to a
halt when it runs dry.  No other kernel feature is given this
dispensation, and I wrote some code to prove that it isn't necessary.
Due to a lockless design this proposed /dev/random has much higher
bandwidth for writes to the entropy pool.  Furthermore, an additional
8 octets of entropy is collected per syscall meaning that the random
source generated will be difficult to undermine.

This is an experimental subsystem that is easy to compile and to verify:
https://github.com/TheRook/KeypoolRandom

Should compile right after cloning, even on osx or windows - and
feedback is welcome.  I'm making it easy for people to verify and to
discuss this design. There are other cool features here, and I have a
detailed writeup in the readme.
A perhaps heretical view is that this design doesn't require
handle_irq_event_percpu() to produce a NIST-compliant CSPRNG.  Which
is a particularly useful feature for low power usage, or high
performance applications of the linux kernel.   Making this source of
entropy optional is extremely interesting as it appears as though
Kernel performance has degraded substantially in recent releases, and
this feature will give more performance back to the user who should be
free to choose their own security/performance tradeoff.  Disabling the
irq event handler as a source of entropy should not produce an
exploitable condition,  A keypool has a much larger period over the
current entropy pool design, so the concerns around emptying the pool
are non-existent in the span of a human lifetime.

All the best,
Micahel Brooks

https://stackoverflow.com/users/183528/rook
https://stackoverflow.com/tags/cryptography/topusers #9
https://stackoverflow.com/tags/security/topusers #4