jitterentropy_rng on armv5 embedded target
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
Am Freitag, 8. Mai 2020, 13:40:08 CEST schrieb Alexander Dahl:
Hi Alexander,
Quoted 9 lines
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.
Quoted 3 lines
(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.
Quoted 2 lines
If so, then how is it supposed to be set up?
It is intended for in-kernel purposes (namely to seed its DRBG).
Quoted 10 lines
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/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:
Quoted 10 lines
Quoted 3 lines
(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_ALGfor RNGs compiled, you can use it through theAF_ALGinterface (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. ;-)
Quoted 3 lines
Quoted 1 line
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,
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 3 lines
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:
Quoted 11 lines
Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:
Quoted 1 line
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.
Quoted 4 lines
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_bytesand 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,
Quoted 13 lines
Hello,
Am Freitag, 8. Mai 2020, 14:22:02 CEST schrieb Stephan Mueller:
Quoted 10 lines
Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:
Quoted 1 line
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.
Quoted 4 lines
Then where do the random
numbers for that come from (in the current or previous kernels without your
new lrng)?
Quoted 5 lines
Quoted 1 line
The DRBG is seeded from
get_random_bytesand the Jitter RNG.Oh, I was not precise enough. I wanted to know where
/dev/randomgets 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