<div dir="ltr">> +Pete Bentley as the other person who might be interested in this stuff. (because of prng_seeder, which is what boringssl-based stuff uses, but which might also care about us not calling the ioctl()?)<br><br>I don't think we care, anything using libcrypto (including Toybox) on Android should be largely insulated from any urandom quirks.<br><br>libcrypto only draws entropy to seed an internal NIST approved DRBG, one per thread, each of which is re-seeded every 'n' draws (I don't remember 'n' offhand).<div><br></div><div>If the device has a working /dev/hw_random then prng_seeder will be running and client libcrypto processes get their seeding data from it.  prng_seeder reads and conditions data from /dev/hw_random and uses that to seed its own internal DRBG every 'n' draws.</div><div><br></div><div>If prng_seeder is not running then libcrypto gets its seeding data via getrandom() from the urandom source, and will block until the entropy pool is initialised. (Which is why we needed to move boringssl_self_test later in init in order to prevent boot delays on low end devices with no hw_random).</div><div><br></div><div>So I think our only concern here is if the device has no hw_random and can somehow end up initialising urandom deterministically.<br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Sept 2023 at 12:16, Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/19/23 14:44, enh wrote:<br>
>> And I just noticed because somebody mentioned Android involvement. (I still try<br>
>> to check that mailing list twice/month for anything of obvious interest.)<br>
>><br>
>> <a href="http://lists.busybox.net/pipermail/busybox/2023-September/090471.html" rel="noreferrer" target="_blank">http://lists.busybox.net/pipermail/busybox/2023-September/090471.html</a><br>
> <br>
> (i think they were just talking about the busybox-for-android configuration?)<br>
<br>
I dunno what's AOSP and what's vendor mods off the top of my head. :)<br>
<br>
>> Might not matter on systems with a hardware random number generator with a<br>
>> kernel driver hooked up to it, but it breaks the embedded world. (Then again the<br>
>> embedded linux projects I've seen recently have been reverting _back_ to the 2.6<br>
>> kernel...)<br>
> <br>
> yeah, our high- and mid-end devices usually have a hw rng, but the<br>
> lowest of the low-end devices don't even necessarily have an rtc that<br>
> survives reboots. (i've definitely helped weaken CTS tests a few times<br>
> to allow this kind of thing.)<br>
<br>
That last board I banged on in that category was pre-pandemic, but the solution<br>
at the time involved:<br>
<br>
A) ifconfig -a > /dev/random in the boot scripts to get the mac addresses in<br>
there so it was at least per-board unique. (No, the kernel driver didn't do this.)<br>
<br>
B) dd-ing 32 bytes of random data into flash and back between boots,<br>
<br>
C) Never use /dev/random, use /dev/urandom to avoid blocking because "I'll use<br>
your data but it doesn't COUNT" did not, in fact, help.<br>
<br>
The result produced different keys each board and each boot, which was the<br>
proximate goal. (We were just trying to 80/20 the paranoia: state actors would<br>
just rip them out and strap extra hardware on or do something clever with a yagi<br>
antenna.)<br>
<br>
> A more insidious problem, perhaps, is that a seed written to the RNG<br>
> before it initializes will not actually be used until after the pool<br>
> is initialized properly; "you might write in a perfectly good seed to<br>
> /dev/urandom, but what you read out for the subsequent seed may be<br>
> complete deterministic crap", Donenfeld said. The data that gets<br>
<br>
That's the annoying bit. Even with the above boot dance, your initial session<br>
keys are then crap during the wake-up call.<br>
<br>
I don't claim to be an expert here, I'm just going "oh goddess, they're kicking<br>
THIS anthill again..."<br>
<br>
Rob<br>
</blockquote></div>