PTO_ADIANTUM themselves. So, let's do
> the same for AES-128-CBC-ESSIV and CONFIG_CRYPTO_SHA256.
>
> Signed-off-by: Eric Biggers
Reviewed-by: Theodore Ts'o
On Mon, May 20, 2019 at 05:41:20PM -0700, Eric Biggers wrote:
>
> This was answered in the cover letter, quoted below:
Oops, thanks. My bad, I stopped reading when I saw the changelog, and
missed that part of the description.
- Ted
On Mon, May 20, 2019 at 10:25:36AM -0700, Eric Biggers wrote:
>
> This patchset makes major improvements to how keys are added, removed,
> and derived in fscrypt, aka ext4/f2fs/ubifs encryption. It does this by
> adding new ioctls that add and remove encryption keys directly to/from
> the filesys
Given the precedent that has been established for removing the SPECK
cipher from the kernel, I wonder if we should be removing Streebog on
the same basis, in light of the following work:
https://who.paris.inria.fr/Leo.Perrin/pi.html
https://tosc.iacr.org/index.php/ToSC/article/view
d attack its output
stream. And if RDRAND is in fact an honest DRNG, it will immeasurably
improve on what the Jitter entropy daemon might produce.
This also provides some protection against someone who is able to read
or set the entropy seed file.
Signed-off-by: Theodore Ts'o
Cc: sta...@vge
on State's law enforcement or intelligence
agencies).
This will prevent getrandom(2) from blocking, if there is a
willingness to trust the CPU manufacturer.
Signed-off-by: Theodore Ts'o
---
I'm not sure Linux distro's will thank us for this. The problem is
trusting
d attack its output
stream. And if RDRAND is in fact an honest DRNG, it will immeasurably
improve on what the Jitter entropy daemon might produce.
This also provides some protection against someone who is able to read
or set the entropy seed file.
Signed-off-by: Theodore Ts'o
Cc: sta.
crng_ready() function should only return true once we are in the
last state.
Reported-by: Jann Horn
Fixes: e192be9d9a30 ("random: replace non-blocking pool...")
Cc: sta...@kernel.org # 4.8+
Signed-off-by: Theodore Ts'o
Reviewed-by: Jann Horn
---
drivers/char/random.c | 10 +-
1
t;)
Cc: sta...@kernel.org # 4.13+
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 55 +++
1 file changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index c8ec1e70abde..2154a5fe4c81 1006
Reported-by: Jann Horn
Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly...")
Cc: sta...@kernel.org # 4.8+
Signed-off-by: Theodore Ts'o
Reviewed-by: Jann Horn
---
drivers/char/random.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
there's a lot of legacy code out there.
Reported-by: Jann Horn
Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly...")
Cc: sta...@kernel.org # 4.8+
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 46 +++---
Add a new ioctl which forces the the crng to be reseeded.
Signed-off-by: Theodore Ts'o
Cc: sta...@kernel.org
---
drivers/char/random.c | 13 -
include/uapi/linux/random.h | 3 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/dr
On Tue, Aug 15, 2017 at 10:45:17AM +0200, Stephan Mueller wrote:
> Am Dienstag, 15. August 2017, 00:21:05 CEST schrieb Theodore Ts'o:
>
> Hi Theodore,
>
> > Have you looked at section 3.1.1 of the above cited paper?
> >
> > http://eprint.iacr.org/2012/25
On Mon, Aug 14, 2017 at 10:20:18AM +0200, Stephan Mueller wrote:
> Hi Ted,
>
> drivers/char/random.c contains the following comment:
>
> """
> * Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and
> * Videau in their paper, "The Linux Pseudorandom Number Generator
> * Revisited
On Sun, Jul 23, 2017 at 02:05:38PM -0400, Sandy Harris wrote:
> Sandy Harris wrote:
>
> > The biggest problem with random(4) is that you cannot generate good
> > output without a good seed & just after boot, ...
> >
> > The only really good solution I know of is to find a way to provide a
> > chu
On Fri, Jul 21, 2017 at 04:55:12PM +0200, Oliver Mangold wrote:
> On 21.07.2017 16:47, Theodore Ts'o wrote:
> > On Fri, Jul 21, 2017 at 01:39:13PM +0200, Oliver Mangold wrote:
> > > Better, but obviously there is still much room for improvement by reducing
> > &g
On Fri, Jul 21, 2017 at 01:39:13PM +0200, Oliver Mangold wrote:
> Better, but obviously there is still much room for improvement by reducing
> the number of calls to RDRAND.
Hmm, is there some way we can easily tell we are running on Ryzen? Or
do we believe this is going to be true for all AMD de
On Thu, Jul 20, 2017 at 09:00:02PM +0200, Stephan Müller wrote:
> I concur with your rationale where de-facto the correlation is effect is
> diminished and eliminated with the fast_pool and the minimal entropy
> estimation of interrupts.
>
> But it does not address my concern. Maybe I was not cl
On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote:
> In the email [1] I have expressed the core concerns I see -- none of them
> address the need to keep the Jitter RNG as one noise source. To address
> those,
> a very deep dive into random.c needs to be made.
That's simply not tru
On Tue, Jul 18, 2017 at 09:00:10PM -0400, Sandy Harris wrote:
> The only really good solution I know of is to find a way to provide a
> chunk of randomness early in the boot process. John Denker has a good
> discussion of doing this by modifying the kernel image & Ted talks of
> doing it via the bo
On Tue, Jul 18, 2017 at 04:37:11PM +0200, Stephan Müller wrote:
> >
> > > I have stated the core concerns I have with random.c in [1]. To remedy
> > > these core concerns, major changes to random.c are needed. With the past
> > > experience, I would doubt that I get the changes into random.c.
> >
On Wed, Jul 05, 2017 at 09:16:09AM -0400, Paul Koning wrote:
>
> In the implementations I know, /dev/random and /dev/urandom are the
> same driver, the only difference is that when you read from
> /dev/random there's a check for the current entropy level.
It's in the same driver but /dev/random a
On Wed, Jul 05, 2017 at 09:03:43AM +0200, Ulrich Windl wrote:
> > Note, during the development of my /dev/random implementation, I added the
> > getrandom-like blocking behavior to /dev/urandom (which is the equivalent to
> > Jason's patch except that it applies to user space). The boot process lo
patch replaces the
current topmost patch on the random.git tree:
>From 25b683ee9bd5536807f813efbd19809333461f89 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o
Date: Thu, 8 Jun 2017 04:16:59 -0400
Subject: [PATCH] random: suppress spammy warnings about unseeded randomness
Unfortunately, on some mode
On Tue, Jun 20, 2017 at 11:49:07AM +0200, Jason A. Donenfeld wrote:
> Uh, talk about a totally unnecessary punch... In case my last email
> wasn't clear, I fully recognize that `default y` is a tad too extreme,
> which is why from one of the earliest revisions in this series, I
> moved directly to
On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote:
> > Suppressing all messages for all configurations cast a wider net than
> > necessary. Configurations that could potentially be detected and fixed
> > likely will go unnoticed. If the problem is not brought to light, then
> > it
On Mon, Jun 19, 2017 at 10:57:18PM +0200, Jason A. Donenfeld wrote:
>
> With rc6 already released and rc7 coming up, I'd really appreciate you
> stepping in here and either ACKing the above commit, or giving your
> two cents about it in case I need to roll something different.
I actually had set
On Thu, Jun 15, 2017 at 01:59:43PM +0200, Stephan Müller wrote:
> I would think that the issue regarding the logging is relevant for
> cryptographic use cases or use cases requiring strong random numbers only.
> Only those use cases should be fixed eventually to wait for a fully seeded
> DRNG.
>
On Thu, Jun 15, 2017 at 11:01:18AM -0400, David Miller wrote:
> As a side note, ext4 does something similar with a private
> implementation, but it doesn't use something the evaluates to an
> alloca. Instead it uses a fixed 4-byte size for the shash context
> value in the on-stack declaration.
In
least we probably should do a logical "uniq" on the output
(e.g., if we have complained about the previous callsite, don't whinge
about it again).
- Ted
commit 9d9035bc6d7871a73d7f9aada4e63cb190874a68
Author: Theodore Ts'o
Date: Thu
On Tue, Jun 06, 2017 at 07:48:03PM +0200, Jason A. Donenfeld wrote:
> This protocol uses lots of complex cryptography that relies on securely
> generated random numbers. Thus, it's important that the RNG is actually
> seeded before use. Fortuantely, it appears we're always operating in
> process co
On Tue, Jun 06, 2017 at 07:48:02PM +0200, Jason A. Donenfeld wrote:
> Using get_random_int here is faster, more fitting of the use case, and
> just as cryptographically secure. It also has the benefit of providing
> better randomness at early boot, which is when many of these structures
> are assig
On Tue, Jun 06, 2017 at 07:48:01PM +0200, Jason A. Donenfeld wrote:
> Using get_random_u32 here is faster, more fitting of the use case, and
> just as cryptographically secure. It also has the benefit of providing
> better randomness at early boot, which is when many of these structures
> are assig
On Tue, Jun 06, 2017 at 07:48:00PM +0200, Jason A. Donenfeld wrote:
> This is much faster and just as secure. It also has the added benefit of
> probably returning better randomness at early-boot on systems with
> architectural RNGs.
>
> Signed-off-by: Jason A. Donenfeld
> Cc: Thomas Graf
> Cc:
On Tue, Jun 06, 2017 at 07:47:58PM +0200, Jason A. Donenfeld wrote:
> Ceph uses the RNG for various nonce generations, and it shouldn't accept
> using bad randomness. So, we wait for the RNG to be properly seeded. We
> do this by calling wait_for_random_bytes() in a function that is
> certainly cal
On Tue, Jun 06, 2017 at 07:47:57PM +0200, Jason A. Donenfeld wrote:
> It's not safe to use weak random data here, especially for the challenge
> response randomness. Since we're always in process context, it's safe to
> simply wait until we have enough randomness to carry out the
> authentication c
On Tue, Jun 06, 2017 at 07:47:56PM +0200, Jason A. Donenfeld wrote:
> Otherwise, we might be seeding the RNG using bad randomness, which is
> dangerous. The one use of this function from within the kernel -- not
> from userspace -- is being removed (keys/big_key), so that call site
> isn't relevant
On Tue, Jun 06, 2017 at 07:47:55PM +0200, Jason A. Donenfeld wrote:
> -static inline void key_alloc_serial(struct key *key)
> +static inline int key_alloc_serial(struct key *key)
> @@ -170,7 +168,7 @@ static inline void key_alloc_serial(struct key *key)
> rb_insert_color(&key->serial_node, &
On Tue, Jun 06, 2017 at 07:47:59PM +0200, Jason A. Donenfeld wrote:
> Using get_random_u32 here is faster, more fitting of the use case, and
> just as cryptographically secure. It also has the benefit of providing
> better randomness at early boot, which is sometimes when this is used.
>
> Signed-
On Tue, Jun 06, 2017 at 07:47:54PM +0200, Jason A. Donenfeld wrote:
> These functions are simple convenience wrappers that call
> wait_for_random_bytes before calling the respective get_random_*
> function.
>
> Signed-off-by: Jason A. Donenfeld
Thanks, applied to the dev branch.
On Tue, Jun 06, 2017 at 07:47:53PM +0200, Jason A. Donenfeld wrote:
> This enables users of get_random_{bytes,u32,u64,int,long} to wait until
> the pool is ready before using this function, in case they actually want
> to have reliable randomness.
>
> Signed-off-by: Jason A. Donenfeld
Thanks, ap
On Tue, Jun 06, 2017 at 07:47:52PM +0200, Jason A. Donenfeld wrote:
> It's possible that get_random_{u32,u64} is used before the crng has
> initialized, in which case, its output might not be cryptographically
> secure. For this problem, directly, this patch set is introducing the
> *_wait variety
On Wed, Jun 07, 2017 at 07:00:17AM +0200, Stephan Müller wrote:
> > On that same idea, one could add an early_initramfs handler for entropy
> > data.
>
> Any data that comes from outside during the boot process, be it some NVRAM
> location, the /var/lib...seed file for /dev/random or other approa
On Tue, Jun 06, 2017 at 07:19:10PM -0300, Henrique de Moraes Holschuh wrote:
> On that same idea, one could add an early_initramfs handler for entropy
> data.
>
> One could also ensure the kernel command line is used to feed some
> entropy for the CRNG init (for all I know, this is already being d
On Tue, Jun 06, 2017 at 02:34:43PM +0200, Jason A. Donenfeld wrote:
>
> Yes, I agree whole-heartedly. A lot of people have proposals for
> fixing the direct idea of entropy gathering, but for whatever reason,
> Ted hasn't merged stuff. I think Stephan (CCd) rewrote big critical
> sections of the
On Tue, Jun 06, 2017 at 02:50:59AM +0200, Jason A. Donenfeld wrote:
> Otherwise, we might be seeding the RNG using bad randomness, which is
> dangerous.
>
> Cc: Herbert Xu
> Signed-off-by: Jason A. Donenfeld
> ---
> crypto/rng.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
>
On Sat, Jun 03, 2017 at 01:58:25AM +0200, Jason A. Donenfeld wrote:
> Hi Ted,
>
> Based on the tone of your last email, before I respond to your
> individual points
May I gently point out that *your* tone that started this whole thread
has been pretty terrible? Quoting your your first messa
On Fri, Jun 02, 2017 at 07:44:04PM +0200, Jason A. Donenfeld wrote:
> On Fri, Jun 2, 2017 at 7:26 PM, Theodore Ts'o wrote:
> > I tried making /dev/urandom block.
> > So if you're a security focused individual who is kvetching
> > And if we're breaking
>
&
t; ifdef? I suspect because people would see the lines in their dmesg and
> write emails like this one to the list.
The #ifdef and the printk was there from the very beginning.
commit 392a546dc8368d1745f9891ef3f8f7c380de8650
Author: Theodore Ts'o
Date: Sun Nov 3 18:24:08 2013 -0500
On Thu, Feb 09, 2017 at 01:13:22AM -0700, Alden Tondettar wrote:
> And using:
>
> $ qemu-system-x86_64 --version
> QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-12+deb8u6), Copyright (c)
> 2003-2008 Fabrice Bellard
> $ qemu-system-x86_64 -nographic -enable-kvm -m 1024M -kernel bzImage -append
>
OK, I figured out what is going on with your test results.
If you use qemu-system-x86_64 **without** --enable-kvm, then on both
the Debian Jessie version of qemu as well as the Debian Stretch
version of qemu, crng_fast_load() will be called _twice_ before
crng_initialize has a chance to be called.
On Wed, Feb 08, 2017 at 08:31:26PM -0700, Alden Tondettar wrote:
> The new non-blocking system introduced in commit e192be9d9a30 ("random:
> replace non-blocking pool with a Chacha20-based CRNG") can under
> some circumstances report itself initialized while it still contains
> dangerously little e
On Tue, Dec 27, 2016 at 11:41:46PM +0100, Stephan Müller wrote:
> Since the introduction of the ChaCha20 DRNG, extract_entropy is only
> invoked with the input_pool. For this entropy pool, xfer_secondary_pool
> is a no-op and can therefore be safely removed.
>
> Signed-off-by: Stephan Mueller
In
On Tue, Dec 27, 2016 at 11:40:23PM +0100, Stephan Müller wrote:
> The variable ip is defined to be a __u64 which is always 8 bytes on any
> architecture. Thus, the check for sizeof(ip) > 4 will always be true.
>
> As the check happens in a hot code path, remove the branch.
The fact that it's a ho
On Tue, Dec 27, 2016 at 11:39:57PM +0100, Stephan Müller wrote:
> The random_ready callback mechanism is intended to replicate the
> getrandom system call behavior to in-kernel users. As the getrandom
> system call unblocks with crng_init == 1, trigger the random_ready
> wakeup call at the same tim
On Thu, Dec 22, 2016 at 07:08:37PM +0100, Hannes Frederic Sowa wrote:
> I wasn't concerned about performance but more about DoS resilience. I
> wonder how safe half md4 actually is in terms of allowing users to
> generate long hash chains in the filesystem (in terms of length
> extension attacks ag
On Thu, Dec 22, 2016 at 05:16:47PM +0100, Jason A. Donenfeld wrote:
> Could you offer a bit of advice on how to manage dependencies between
> patchsets during merge windows? I'm a bit new to the process.
>
> Specifically, we how have 4 parts:
> 1. add siphash, and use it for some networking code.
On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote:
> I find this compelling. We'll have one csprng for both
> get_random_int/long and for /dev/urandom, and we'll be able to update
> that silly warning on the comment of get_random_int/long to read
> "gives output of either rdrand qu
On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
> wrote:
> > following up on what appears to be a random subject: ;)
> >
> > IIRC, ext4 code by default still uses half_md4 for hashing of filenames
> > in the htree. siphash
On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote:
>
> Funny -- while you guys were sending this back & forth, I was writing
> my reply to Andy which essentially arrives at the same conclusion.
> Given that we're all arriving to the same thing, and that Ted shot in
> this directio
On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote:
> SipHash annihilates the competition on 64-bit superscalar hardware.
> SipHash dominates the field on 64-bit in-order hardware.
> SipHash wins easily on 32-bit hardware *with enough registers*.
> On register-starved 32-bit machines, i
On Mon, Dec 19, 2016 at 06:32:44PM +0100, Jason A. Donenfeld wrote:
> 1) Anything that requires actual long-term security will use
> SipHash2-4, with the 64-bit output and the 128-bit key. This includes
> things like TCP sequence numbers. This seems pretty uncontroversial to
> me. Seem okay to you?
On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote:
> >> - Ted, Andy Lutorminski and I will try to figure out a construction of
> >> get_random_long() that we all like.
We don't have to find the most optimal solution right away; we can
approach this incrementally, after all.
So long
On Fri, Dec 16, 2016 at 03:17:39PM -0500, George Spelvin wrote:
> > That's a nice analysis. Might one conclude from that that hsiphash is
> > not useful for our purposes? Or does it still remain useful for
> > network facing code?
>
> I think for attacks where the threat is a DoS, it's usable. Th
On Wed, Dec 14, 2016 at 04:10:37AM +0100, Jason A. Donenfeld wrote:
> This duplicates the current algorithm for get_random_int/long, but uses
> siphash24 instead. This comes with several benefits. It's certainly
> faster and more cryptographically secure than MD5. This patch also
> hashes the pid,
On Thu, Nov 03, 2016 at 03:03:02PM -0700, Eric Biggers wrote:
> With the new (in 4.9) option to use a virtually-mapped stack
> (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for
> the scatterlist crypto API because they may not be directly mappable to
> struct page. get_crypt_in
On Thu, Nov 03, 2016 at 03:03:01PM -0700, Eric Biggers wrote:
> With the new (in 4.9) option to use a virtually-mapped stack
> (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for
> the scatterlist crypto API because they may not be directly mappable to
> struct page. For short fi
On Sun, Aug 21, 2016 at 12:53:15PM +0300, Jan Varho wrote:
> On Mon, Jun 13, 2016 at 6:48 PM, Theodore Ts'o wrote:
> > +static inline void maybe_reseed_primary_crng(void)
> > +{
> > + if (crng_init > 2 &&
> > + time_after(jiffies, primary
On Thu, Aug 18, 2016 at 08:39:23PM +0200, Pavel Machek wrote:
>
> But this is the scary part. Not limited to ssh. "We perform the
> largest ever network survey of TLS and SSH servers and present
> evidence that vulnerable keys are surprisingly widespread. We find
> that 0.75% of TLS certificates s
On Wed, Aug 17, 2016 at 11:42:55PM +0200, Pavel Machek wrote:
>
> Actually.. I'm starting to believe that getting enough entropy before
> userspace starts is more important than pretty much anything else.
>
> We only "need" 64-bits of entropy, AFAICT. If it passes statistical
> tests, I'd use it.
On Mon, Aug 15, 2016 at 08:13:06AM +0200, Stephan Mueller wrote:
>
> According to my understanding of NAPI, the network card sends one interrupt
> when receiving the first packet of a packet stream and then the driver goes
> into polling mode, disabling the interrupt. So, I cannot see any batchi
On Fri, Aug 12, 2016 at 11:34:55AM +0200, Stephan Mueller wrote:
>
> - correlation: the interrupt noise source is closely correlated to the HID/
> block noise sources. I see that the fast_pool somehow "smears" that
> correlation. However, I have not seen a full assessment that the correlation
>
On Thu, Aug 11, 2016 at 02:24:21PM +0200, Stephan Mueller wrote:
>
> The following patch set provides a different approach to /dev/random which
> I call Linux Random Number Generator (LRNG) to collect entropy within the
> Linux
> kernel. The main improvements compared to the legacy /dev/random is
On Tue, Aug 09, 2016 at 02:04:44PM +, Jason Cooper wrote:
>
> iiuc, Ted, you're saying using the hw_random framework would be
> disasterous because despite most drivers having a default quality of 0,
> rngd assumes 1 bit of entropy for every bit read?
Sorry, what I was trying to say (but fail
On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote:
> Agree with Jason's point, also understand Stephan's concern. The
> date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> 1000', the average speed is .294Kibits/s. I will sent the patch
> to disable ath9k RNG by def
is a bug, since
> based on my previous statement, in this scenario, getrandom should
> never block.
This is correct; and it has been fixed in the patches in v4.8-rc1.
The patch which fixes this has been marked for backporting to stable
kernels:
commit 3371f3da08cff4b75c1f2dce742d460539d6566d
Aut
x27;s.
Theodore Ts'o (1):
random: use for_each_online_node() to iterate over NUMA nodes
drivers/char/random.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "un
On Mon, Jul 25, 2016 at 02:44:24AM -0400, Theodore Ts'o wrote:
> The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
>
> Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/
On Mon, Jul 25, 2016 at 05:15:15PM +1000, Stephen Rothwell wrote:
> Hi Ted,
>
> On Mon, 25 Jul 2016 02:44:24 -0400 Theodore Ts'o wrote:
> >
> > The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
> >
> > Linux 4.7-rc1 (2016-05-29
a hw random number
generator (if present) to initialize the /dev/urandom pool.
Eric Biggers (1):
random: properly align get_random_int_hash
Stephan Mueller (1):
random: add interrupt callback to VMBus IRQ handler
Theodore Ts
On Sun, Jun 26, 2016 at 08:47:53PM +0200, Pavel Machek wrote:
>
> You are basically trying to turn CRNG into one way hash function here,
> right? Do you have any explanation that it has the required
> properties?
Well, not really. A CRNG has the property that if you generate a
series of outputs:
On Sun, Jun 26, 2016 at 08:47:43PM +0200, Pavel Machek wrote:
> 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 interna
On Mon, Jun 20, 2016 at 09:00:49PM +0200, Stephan Mueller wrote:
>
> The time stamp maintenance is the exact cause for the correlation: one HID
> event triggers:
>
> - add_interrupt_randomness which takes high-res time stamp, Jiffies and some
> pointers
>
> - add_input_randomness which takes h
On Mon, Jun 20, 2016 at 05:49:17PM +0200, Stephan Mueller wrote:
>
> Is speed everything we should care about? What about:
>
> - offloading of crypto operation from the CPU
In practice CPU offland is not helpful, and in fact, in most cases is
harmful, when one is only encrypting a tiny amount of
On Mon, Jun 20, 2016 at 07:51:59AM +0200, Stephan Mueller wrote:
>
> - Correlation of noise sources: as outlined in [1] chapter 1, the three noise
> sources of the legacy /dev/random implementation have a high correlation.
> Such
> correlation is due to the fact that a HID/disk event at the sam
On Mon, Jun 20, 2016 at 01:19:17PM +0800, Herbert Xu wrote:
> On Mon, Jun 20, 2016 at 01:02:03AM -0400, Theodore Ts'o wrote:
> >
> > It's work that I'm not convinced is worth the gain? Perhaps I
> > shouldn't have buried the lede, but repeating
On Mon, Jun 20, 2016 at 09:25:28AM +0800, Herbert Xu wrote:
> > 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)
On Wed, Jun 15, 2016 at 10:59:08PM +0800, Herbert Xu wrote:
> I think you should be accessing this through the crypto API rather
> than going direct. We already have at least one accelerated
> implementation of chacha20 and there may well be more of them
> in future. Going through the crypto API
On Fri, Jun 17, 2016 at 03:56:13PM +0200, David Jaša wrote:
> I was thinking along the lines that "almost every important package
> supports FreeBSD as well where they have to handle the condition so
> option to switch to Rather Break Than Generate Weak Keys would be nice"
> - but I didn't expect t
On Mon, Jun 13, 2016 at 08:00:33PM +0200, Stephan Mueller wrote:
>
> 1. The ChaCha20 is seeded with 256 bits (let us assume it is full entropy)
>
> 2. The ChaCha20 block operation shuffles the 256 bits of entropy over the 512
> bit state -- already here we see that after shuffling, the entropy t
help it from running, lemming-like, straight
over the locking cliff.
Reported-by: Andi Kleen
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 62 +++
1 file changed, 58 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c
triggered.
This patch adds the interrupt entropy collection callback into the VMBus
interrupt handler function.
Cc: sta...@kernel.org
Signed-off-by: Stephan Mueller
Signed-off-by: Stephan Mueller
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 1 +
drivers/hv/vmbus_drv.c | 3 +++
2
If we have a hardware RNG and are using the in-kernel rngd, we should
use this to initialize the non-blocking pool so that getrandom(2)
doesn't block unnecessarily.
Cc: sta...@kernel.org
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 16 +++-
1 file changed, 11
Since systemd is consistently using /dev/urandom before it is
initialized, we can't see the other potentially dangerous users of
/dev/urandom immediately after boot. So print the first ten such
complaints instead.
Cc: sta...@kernel.org
Signed-off-by: Theodore Ts'o
---
drivers/cha
: Theodore Ts'o
---
drivers/char/random.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 64e35a4..83f5cd0 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1778,13 +1778,15 @@ int random_int_secret_init
The CRNG is faster, and we don't pretend to track entropy usage in the
CRNG any more.
Signed-off-by: Theodore Ts'o
---
crypto/chacha20_generic.c | 61
drivers/char/random.c | 374 +-
include/crypto/chacha20.h | 1 +
li
: add interrupt callback to VMBus IRQ handler
Theodore Ts'o (5):
random: initialize the non-blocking pool via
add_hwgenerator_randomness()
random: print a warning for the first ten uninitialized random users
random: replace non-blocking pool with a Chacha20-based CRNG
random:
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 54 ++-
1 file changed, 49 insertions(+), 5 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d640865..963a6a9 100644
--- a/drivers/char/random.c
+++ b/dr
On Mon, May 30, 2016 at 10:53:22AM -0700, Andi Kleen wrote:
>
> It should work the same on larger systems, the solution scales
> naturally to lots of sockets. It's not clear it'll help enough on systems
> with a lot more cores per socket, like a Xeon Phi. But for now it should
> be good enough.
O
On Mon, May 30, 2016 at 08:03:59AM +0200, Stephan Mueller wrote:
> > static int rand_initialize(void)
> > {
> > +#ifdef CONFIG_NUMA
> > + int i;
> > + int num_nodes = num_possible_nodes();
> > + struct crng_state *crng;
> > +
> > + crng_node_pool = kmalloc(num_nodes * sizeof(void *),
> >
1 - 100 of 183 matches
Mail list logo