8 ms·
Yeah, I don't understand what's so cryptographically special about booting. If the system hadn't been turned off and on, it wouldn't have had a problem, right?
by mehrdadn 7y ago
Yeah, I don't understand what's so cryptographically special about booting. If the system hadn't been turned off and on, it wouldn't have had a problem, right? Sounds like the real problem is some part of the system can't be bothered to persist its state. Either that, or the problem should also come up during normal usage, in which case there's a security hole somewhere.
- pstrateman 7y agosystemd isn't using the right interface for adding the entropy in the seed file, so the kernel uses it but counts it as zero bits of entropy edit: but i guess that's on purpose to handle disk imaging
- mehrdadn 7y agoYeah I was just reading that. Why was that not an obvious bug to be fixed immediately? I haven't read much of the GitHub issues but it seems so weird to recommend trusting the CPU RNG instead of just pushing out a quick fix...
- raverbashing 7y ago> Why was that not an obvious bug to be fixed immediately? Welcome to SystemD
- Hello71 7y agobecause people are poorly educated and copy their system disks without changing the random seed. then, they generate similar long-term keys, e.g. RSA keys with common factors. digitalocean was well known to have identical SSH host keys for quite some time (one of many reasons I wouldn't trust them with any sort of remotely serious hosting job); I would be shocked if they knew to reset the random seed.
- throw0101a 7y ago> because people are poorly educated and copy their system disks without changing the random seed. To a first approximation: * SHA256( cat /var/lib/randomseed || ifconfig || date -u ) > /dev/urandom will get any decent stream-cipher-based PRNG going. Each machine will have a unique MAC address, so that's 48 bits right off the bat, even if randomseed is identical and every machine is booted at the exact same second.
- Hello71 7y agoI strongly suspect that this information is already included in the Linux kernel RNG, but it is not given much weight in the entropy calculation, on the basis that virtualized systems frequently have duplicated MAC addresses (as is allowed on a non-public system), and sometimes also have low initial timestamp resolution.
- throw0101a 7y agoIf a system will be communicating with other systems, it will need a unique Layer 2 address. This can be leveraged for some entropy (certainly you don't have to credit the full 48 bits, but are you tell saying that not even 1-2 bits of credit cannot be applied?). If the system is not communicating with other systems... what attack tree are you actually worried about if it is inaccessible? I would also be curious to know which virtualization environments generate duplicate MAC addresses over (say) dozens of systems?
- Hello71 7y agoMAC addresses are not used in a purely routed/virtualized network. qemu uses the same MAC address by default.
- mehrdadn 7y agodate -u just returns 1-second resolution? It's trivial to go through all the possibilities...
- deleted 7y ago[deleted]
- zajio1am 7y ago> Sounds like the real problem is some part of the system can't be bothered to persist its state. Persistent state is hard. For example, some systems run with read-only filesystem.
- mehrdadn 7y agoI thought about that, but then, if you setup that kind of a system, isn't it your responsibility to worry about how to generate and persist cryptographic state? It's such a niche and advanced use-case by someone who should really know better considering the setup... why should all the other >95% of users pay such a price for it? Edit: Replaced "host keys" with "cryptographic state".