On Sun, 2019-02-24 at 19:52 +0000, Thorsten Glaser wrote:
[...]
> I’ve written something, a linux-any package, that…
>
> • during postinst, creates a 128-byte random seed file in /
> • updates that in a daily cronjob (using same tool as during
> boot except with more bits taken from the kernel)
> • updates (the second 64-byte half, from urandom) it on shutdown
> • hooks into initramfs to…
> – on x86, use “Jytter” (CPU jitter) to try and get some more
> random bytes (not accredited, just written to the pool)
> – makes it mount the root filesystem, after fsck, read-write
> instead of deferring that to the init scripts (this should
> be safe, though, as initramfs *does* fsck)
> – after the root filesystem is read-write,
> ‣ reads from the seed file (128 bytes)
> ‣ uses that and a number of other things (to make it differ)…
> ← md5sum of dmesg
Much of which is the same from boot to boot. Yes, timestamps will
differ, but the same systems that currently have little entropy
available from interrupts will likely also have very consistent
timestamps during boot.
> ← 3 random bytes written into initramfs during update-initramfs
That doesn't change from boot to boot.
> ← the current time
This doesn't add much entropy since RTCs typically have 1 second
resolution and some systems don't even have an RTC.
> ← a bit of kernel entropy (from AT_RANDOM auxvec, set anyway)
Feeding the kernel RNG output back to itself doesn't add any entropy.
> ← on x86, Jytter and the TSC
> to initialise a stretching RNG (arc4random)
> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
> accredit them yet, just remembers the amount written)
How do you determine the number of bytes here?
> ‣ updates the seed file with 128 bytes from the SRNG
> ‣ fsync(2)s and close(2)s the seed file to ensure the next run
> will be different
> ‣ now tells the kernel X random bits were added, where X is…
> → the number of bytes written earlier…
> → times 6 (so we count at best six bits per byte)…
> → capped at 128*7 bits, to both not overwhelm and because our
> seed is only 128 bytes in size, estimated conservatively
[...]
The major input into the new seed file contents is the old seed file
contents. You are adding very little entropy on x86, and possibly
almost none on other architectures.
Please reconsider this, as this description sounds dangerously
insecure.
Ben.
--
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill Gates
Attachment:
signature.asc
Description: This is a digitally signed message part