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;
From:   Alexander Dahl <ada@thorsis.com>
To:     linux-crypto@vger.kernel.org
Cc:     Stephan Mueller <smueller@chronox.de>
Subject: Re: jitterentropy_rng on armv5 embedded target
Date:   Fri, 08 May 2020 14:17:25 +0200
Message-ID: <2049720.SxWqT2AVQ6@ada>
In-Reply-To: <6309135.Bj5FvMsAKG@tauon.chronox.de>
References: <2567555.LKkejuagh6@ada> <6309135.Bj5FvMsAKG@tauon.chronox.de>
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hello, Stephan,

Am Freitag, 8. Mai 2020, 13:58:14 CEST schrieb Stephan Mueller:
> > (Although those daemons would solve my problem, I currently try
> > to avoid them, because memory on my platform is very restricted and every
> > additional running userspace process costs at least around 1 MB.)
> 
> If you compile it and you also have AF_ALG for RNGs compiled, you can use it
> through the AF_ALG interface (see [1] for a library). But IMHO if you are
> space-constrained, you do not want that code.
> 
> Rather use the jitterentropy-library from [2] and link it straight from your
> application.

That would be dropbear or openssl (and applications using libssl). While that 
would certainly be nice, I fear it's out of my scope. ;-)

> > If so, then how is it supposed to be set up?
> 
> It is intended for in-kernel purposes (namely to seed its DRBG).

Okay and DRBG has nothing to do with /dev/random ? Then where do the random 
numbers for that come from (in the current or previous kernels without your 
new lrng)?

Curious
Alex