initially it's not that great, as we will reseed when we seed too many collisions and if the newer seeds are better we'll eventually be protected. Now, neither getrandom() (in its two modes), nor /dev/urandom is the perfect API to use for this, (cont)
Conversation
for the aforementioned reasons. Hence we try to use getrandom() in these case, and are fine if it fails. and if it fails we fill up pseudo random crap, because that's goo enough, and we know that eventually getrandom() will be more helpful and that's all we need (cont)
1
so, yes, I'd argue we do the right thing. No we do not use rand() for anything where we shouldn't. There's no better API for "give me a bit of entropy, that ideally is good, but is OK if not initially", and quite frankly you are just being a dick on Twitter.
1
1
Replying to
Are you saying you are not using RANDOM_EXTEND_WITH_PSEUDO|RANDOM_DONT_DRAIN|RANDOM_ALLOW_RDRAND for DNS TRXIDs? twitter.com/rfc1459/status
This Tweet is unavailable.
1
5
Replying to
Yes, we do. But DNS transactions IDs are hardly a cryptographic concept, are they? I mean, if DNS transaction IDs is what you build your security on, then you probably didn't understand security very well. It's a 16bit field, ffs... wherever we pull the transaction ID (cont)
1
1
2
from, it's easily guessable. Hence, yes, we use getrandom() preferably to generate them, but if we can't use that, it's not going to make a crappy security measuer much crappier if we eventually go for rand() for them. This is early boot stuff again, (cont)
1
not quite as early as PID 1, but still quite early, since used for finding remote storage in the initrd, and so on. And no, I dn't think it's worth letting the boot in virtualized environments hang for 5min or more just because you boot from an HTTP image...
1
Replying to
No, you don't use getrandom if RDRAND is available (RANDOM_ALLOW_RDRAND), so on that machine with a broken RDRAND your DNS client is vulnerable to textbook cache poisoning attacks.
Yes, 16 bits is a very slim security margin, but enough for ephemeral values, if it's good random.
2
3
Anything actually depending on the security of DNS such as SPF / DKIM / DMARC for email or Domain Validated certificate issuance should be using DNSSEC. It's not just a slim security margin. It completely doesn't work against an attacker with control / influence over the network.
2
This misses the point. There is no excuse for a random number generator to behave like that in 2019.
1
1
What do you mean specifically? RDRAND? It's specified as possibly failing anyway. If you mean getrandom, it only blocks until there are at least 128 bits of entropy, which is a non-issue in any environment that's not broken. I wouldn't work around it like they're doing.
But for example, for GrapheneOS, the 1st generation Pixels don't pass entropy in early boot from the bootloader, so there is a point in early init before hw_random is brought up that there isn't enough entropy available for getrandom to avoid blocking.
2
And since I added uses of getrandom that happen for init, it had to be worked around, since it's init that brings up hw_random and adds in the saved entropy from previous boots. It's a problem specific to init and isn't a problem on the more modern Pixel 2 and Pixel 3 anymore.
1
Show replies
No this is about systemd prng that falls back to rand()!