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.
Conversation
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.
2
1
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.
They're targeting virtual machine environments that are essentially broken: they don't feed in entropy from the host, and in many cases don't have persistent data (not just on first boot since they may be stateless and first boot can also be quite common in a scaled environment).
1
I would just call getrandom and accept blocking indefinitely in broken environments with the expectation that virtual machines / cloud vendors get their act together and deal with this properly. They'd be blamed for the breakage and distros would likely just revert it though.