Hello,
after upgrading OpenSSL to 1.1.1g on an armv5 based embedded target I had a
deeper look into entropy generation for that device and stumbled over the in
kernel 'jitterentropy_rng' module.
As far as I understood it's supposed to do the same as the well known
'haveged' or the userspace daemon 'jitterentropy-rngd' by Stephan M?ller [1],
right? (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 so, then how is it supposed to be set up? I built it for 4.9.x LTS, but
after loading it with 'modprobe' I see nothing in the kernel log and there's
no significant change in /proc/sys/kernel/random/entropy_avail (stays well
below 100 most of the time). Isn't that module supposed to gather entropy from
cpu timing jitter?
Puzzled
Alex
[1] https://www.chronox.de/jent.html
Am Freitag, 8. Mai 2020, 13:40:08 CEST schrieb Alexander Dahl:
Hi Alexander,
> Hello,
>
> after upgrading OpenSSL to 1.1.1g on an armv5 based embedded target I had a
> deeper look into entropy generation for that device and stumbled over the in
> kernel 'jitterentropy_rng' module.
>
> As far as I understood it's supposed to do the same as the well known
> 'haveged' or the userspace daemon 'jitterentropy-rngd' by Stephan M?ller
> [1], right?
Yes, precisely. In fact, it is the identical code base of the core
functionality that both the kernel and the jitterentropy-rngd uses. See the
comment at the top of the kernel source code.
> (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.
>
> If so, then how is it supposed to be set up?
It is intended for in-kernel purposes (namely to seed its DRBG).
> I built it for 4.9.x LTS, but
> after loading it with 'modprobe' I see nothing in the kernel log and there's
> no significant change in /proc/sys/kernel/random/entropy_avail (stays well
> below 100 most of the time). Isn't that module supposed to gather entropy
> from cpu timing jitter?
>
> Puzzled
> Alex
>
> [1] https://www.chronox.de/jent.html
[1] https://www.chronox.de/libkcapi.html
[2] https://github.com/smuellerDD/jitterentropy-library
Ciao
Stephan
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
Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:
Hi Alexander,
> > > 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 ?
Nope, it is used as part of the kernel crypto API and its use cases.
> Then where do the random
> numbers for that come from (in the current or previous kernels without your
> new lrng)?
The DRBG is seeded from get_random_bytes and the Jitter RNG.
Ciao
Stephan
Hello,
Am Freitag, 8. Mai 2020, 14:22:02 CEST schrieb Stephan Mueller:
> Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:
> > Okay and DRBG has nothing to do with /dev/random ?
>
> Nope, it is used as part of the kernel crypto API and its use cases.
>
> > Then where do the random
> > numbers for that come from (in the current or previous kernels without
> > your
> > new lrng)?
>
> The DRBG is seeded from get_random_bytes and the Jitter RNG.
Oh, I was not precise enough. I wanted to know where /dev/random gets its
numbers from. As far as I understood now: not from DRBG? (Which is sufficient
knowledge for my current problem.)
Greets
Alex
Am Freitag, 8. Mai 2020, 14:26:41 CEST schrieb Alexander Dahl:
Hi Alexander,
> Hello,
>
> Am Freitag, 8. Mai 2020, 14:22:02 CEST schrieb Stephan Mueller:
> > Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:
> > > Okay and DRBG has nothing to do with /dev/random ?
> >
> > Nope, it is used as part of the kernel crypto API and its use cases.
> >
> > > Then where do the random
> > > numbers for that come from (in the current or previous kernels without
> > > your
> > > new lrng)?
> >
> > The DRBG is seeded from get_random_bytes and the Jitter RNG.
>
> Oh, I was not precise enough. I wanted to know where /dev/random gets its
> numbers from. As far as I understood now: not from DRBG? (Which is
> sufficient knowledge for my current problem.)
Interrupts, HID events, block device events, external sources.
For a full analysis, see [1]
[1] https://bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/
LinuxRNG/LinuxRNG_EN.pdf
Ciao
Stephan