Ben Hutchings dixit:
>On Thu, 2019-02-28 at 14:52 +0000, Ian Jackson wrote:
>>Thorsten Glaser writes ("FYI/RFC: early-rng-init-tools"):
>>> • during postinst, creates a 128-byte random seed file in /
>>
>>Can you confirm that this is done with data from
>>getrandom(,,GRND_RANDOM) ? (Presumably with GRND_NONBLOCK too.)
No. The mechanism is to initialise a local arc4random instance,
which is then used to stretch the seed into the kernel and the
new content of the seed file.
>>This latter stuff is fine but not really critical IMO.
It’s merely used to attempt to make the boots more dissimilar.
>>> to initialise a stretching RNG (arc4random)
>>
>>Why are you feeding this through a separate hashing function rather
>>than letting the kernel PRNG's hasher do it ? I am seriously
>>unconvinced that arc4random is a good idea here.
>
>I agree.
This is the basic design decision (see above). I’m not reading from
the kernel to write to the seed file because
① the entropy given might not be enough to make it initialise,
depending on future kernel changes; this should not block boot,
just make it better if it can
② I only let the kernel attribute the random bytes AFTER the seed
file has been successfully written to disc with the new content,
in order to guarantee that either the next boot differs or that
the script does not make the system think it has more entropy
than it really has
>>> ‣ writes between 32 and 256 bytes to /dev/urandom (but does not
>>> accredit them yet, just remembers the amount written)
>>
>>Why not write the whole lot ?
The whole lot of what?
My only constraint here is that I need to write enough bits to
justifyably accredit at least 128 bits, and that the total number
of bits I accredit is at most the seed file size (128 bytes) times
a trust factor smaller than 1 (using ⅞ here).
>>IMO you should promise to the kernel an amount of entropy exactly
>>equal to the size of the saved seed.
Why is it a problem to use less? This is commonly called a security
margin.
>>> I am fully aware that it is not suitable for everyone:
>>> • it’s Linux-only (the RNG on kFreeBSD is very different, and
>>> I didn’t even look into Hurd’s urandom translator)
>>
>>I think the same principles will apply. If your utility on BSD uses
>>BSD's /dev/random instead of Linux's getrandom() syscall, then it will
Some of the BSDs don’t even have /dev/random. It’s also not about
getrandom(), which is not used (read() from /dev/urandom is), but
about the RNDADDTOENTCNT ioctl, which is pretty much specific to
the Linux RNG and the ones deriving from it (OpenBSD/MirBSD).
>> > • it means you trust a seed file and the arc4random algorithm (to make
>> > a uniform enough stream from the various seeds)
>>
>> The question is nothing to do with its uniformity. The kernel PRNG
>> will hash its input. I think you can feed it whatever.
It’s not about what we feed to the kernel, but about the property
of it distributing the input evenly across the output. The basic tenet
here is that, if I have 128 bytes of random input from the seed file,
then, if I write the output of an SRNG to both the kernel and back to
the seed file, each has about 128 bytes worth of entropy iff only one
is used (and somewhat less otherwise, but, again, according to tytso
and I believe even Ben in some Debbug against OpenSSL, 16 or 32 bytes
of input “should be enough”).
>>> • it prevents you from booting with / mounted read-only
>>
>>I think this is an undesirable side effect. There is a tradeoff here:
[…]
>>I missed the beginning part. Is it not possible to defer all of this
>>to make it run just after / is mounted rw ?
No, because we’re already in parallel boot by then, and this would
mean extremely invasively patching of all init scripts/systems.
Do you see any practical concern with mounting / read-write before
init, as opposed to rather quickly after init by one of the init
scripts?
>> If the RC4 were critical to the security properties of your scheme,
>> then I would be making a much stronger complaint, because RC4 is (of
>> course) broken (when used as a supposedly cryptographically secure
>> pseudorandom bitstream generator).
“of course”?
Not all applications of RC4 are broken. If you use it as a generator
of random bytes after seeding it with suitably large, suitably random
input (as opposed to an 8-byte IV that’s reused *cough*WEP*cough*) and
throw away some amount of initial keystream (which cannot be done in
things like TLS, because that would change the protocol), then, no, RC4
is not broken. (There’s additional throwing-away-stuff-randomly-during-
execution in place. UTSL if interested.)
>The "arc4random" functions really use ChaCha20 today, anyway.
Not all of them. This utility ships its own implementation, which
is derived from the original BSD one, so it’s still using aRC4,
although with all the changes from newer security research applied.
(I had hopes for Spritz, but it turns out it misbehaves worse.)
>> I hope you have found this review helpful.
Somewhat. Thank you for taking the time, nevertheless.
I still believe that the concept has merit. Of course, it’s not for
people whose CPU has RNG instructions and who trust them (as I said
already), and people who mistrust the algorithms involved (such as
arc4random). But I believe that to be a minority, and that all of
them have a suitably large base of people who do trust them, so that
even those who distrust do so out of their own preferences, not due
to a general problem with it. (One of the reasons I’m asking for
feedback here is to improve it enough so that nobody finds it bad
when others use it even if they don’t use it themselves, and to see
that it will be welcomed into Debian at some point in time later.)
And that’s why this would be an optional package, anyway. You don’t
*have* to install it, but you *can* if you want.
It needs a README anyway, and I’m willing to write all kinds of
stuff into both it and the long package description to make sure
people know exactly what they trust when using it, and welcome
text suggestions.
(Plus, it’s a stopgap measure, until bootloaders do the entropy into
the kernel early dance as is done in BSD land. (If early userland
then updates the seed file, it’s not even a problem if the bootloader
doesn’t and it gets repeated between boots since, if the boot did not
even reach early userland, it’s likely been used for almost nothing.)
But as I don’t expect that to become reality any time soon, this will
likely live for quite some time.)
bye,
//mirabilos
--
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
