undefined | Better HN

0 pointsevil-olive1y ago0 comments

> That will give you RF noise, which isn't really random.

what does "really" random even mean in this context? does it actually matter?

given 3 hypothetical devices in a homelab:

a) does no specialized hardware entropy collection, and instead relies entirely on the standard Linux kernel mechanisms

b) does entropy collection based on the RF noise that you're saying isn't "really" random

c) does entropy collection based on whatever mechanism you have in mind that generates "real" randomness (hand-carving bits of entropy out of quantum foam, or whatever)

even if your threat model includes "the NSA tries to break into my homelab"...device A will almost certainly be fine, they'll have ways of getting access that are much simpler than compromising the entropy pool.

I suppose device B has a theoretical vulnerability that if the NSA had physical access to your homelab, they could monitor the RF environment, and then use that to predict what its inputs to the entropy pool were. but...that's assuming they have physical access, and can plant arbitrary equipment of their own design. at that point, they don't need to care about your entropy pool, you're already compromised.

0 comments

XorNot1y ago

Suitably similar RSA keys well compromise each other.

https://www.infoq.com/news/2019/12/rsa-iot-vulnerability/

So bad randomness can let a remote attacker break them much more easily.

theamk1y ago

No one puts raw bit source directly into private key, they always whiten it via some method (often entropy pool setup using strong hash/encryption functions).

That means that even if you "random inputs" are totally predictable, the random values which come out of whitener are completely distinct, and generated RSA keys have virtually zero chances of being similar.

XorNot1y ago

That's arguing that you can just seen an RNG with the current time and use a PRNG as your randomness source - a whitener can't give you randomness out which isn't there to start with.

In the above, fairly extreme case, the risk should be obvious: if someone has a decent guess on what the uptime of your system is, and knows you're doing this, then the search space to crack certificates can be made accessibly small.

Like if you know see a certificate with a Valid From date of say, January 1, 2025 but you know the service definitely wasn't running on January 1, 2024, then by guessing what the PRNG is you've constrained your search space to 1704027600 through 1735650000. So the issue isn't whether the numbers you emit are distinct - it's that an adversary can make it suitably likely that they can produce colliding RSA keys themselves anyway (and remember, they get unlimited attempts at this - they only have to succeed once).

EDIT: And while you can certainly argue that they couldn't predict the exact noise environment of say, your server room, it's also not impossible to model which also might constrain the search space enough to accessible. It's not "haha! we know your every move" it's just making the problem space small enough to brute force.

j / k navigate · click thread line to collapse

0 comments

XorNot1y ago

Suitably similar RSA keys well compromise each other.

https://www.infoq.com/news/2019/12/rsa-iot-vulnerability/

So bad randomness can let a remote attacker break them much more easily.

theamk1y ago

No one puts raw bit source directly into private key, they always whiten it via some method (often entropy pool setup using strong hash/encryption functions).

XorNot1y ago

That's arguing that you can just seen an RNG with the current time and use a PRNG as your randomness source - a whitener can't give you randomness out which isn't there to start with.

j / k navigate · click thread line to collapse