We need it to seed our hash tables. To avoid vulns like the famous rt.perl.org/Public/Bug/Dis. That entropy doesn't have to be good initially, it is fine if it is crap, as long as it gets better if we encounter too many hash table collisions and thus acquire a new seed. (cont.)
Conversation
why is that? because we just want to avoid that attackers can guess our seed and systematically trigger hash collisions and thus degrade our hash table access complexity from the usual O(1) to O(n). As long as the entropy gets better during runtime, we are just fine if (cont.)
1
1
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)
1
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.
Other than email security and certificate issuance, I don't think there's much use case for DNSSEC, because DNS simply isn't trusted by proper authentication mechanisms in the first place. I feel it's way past the point where something like this passes muster as real security.
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
Show replies