3 ms·

because 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

because 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 ago
  I 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 ago
    If 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 ago
      MAC addresses are not used in a purely routed/virtualized network. qemu uses the same MAC address by default.
- mehrdadn 7y ago
  date -u just returns 1-second resolution? It's trivial to go through all the possibilities...
  - throw0101a 7y ago
    $(date -u | wc --bytes) says there is 29 bytes worth of output, which is 232 bits. Are you telling me there is not even, say, 8 bits' worth of entropy credit in there? (Especially when hashed with other data?) Remember: the context of this discussion is VMs (and not embedded systems without a battery-backed RTC).
- viraptor 7y ago
  MACs are very much not random. Especially on a series of machines for a given provider, you can likely predict one. Date of the bootup is also not random if it's got only seconds resolution and you can figure out when a machine comes online by constantly trying to connect. In practice you added much fewer than 48 bits.
mehrdadn 7y ago
All this is literally just concern for the first ~minute or two of the very first boot after disk cloning? It should be irrelevant for subsequent boots once they reseed on the next boot... hardly seems like such a huge deal.
- throw0101a 7y ago
  Except that SSH keys are often generated on first boot, so there's the risk that they're all the same--unless you put some code in your deployment recipes to regenerate them.
  - mehrdadn 7y ago
    Isn't that the user's and the SSH devs' problem? SSH can just wait for new randomness if it sees that as a risk when generating keys. Key generation is already slow anyway. Why is systemd trying so hard to "fix" a problem that might by some chance come up in SSH during the first minute of the the first boot after an improper disk clone? Especially with the currently proposed solutions it seems like such a crazy way to attack somebody else's problem...
    - throw0101a 7y ago
      > Isn't that the user's and the SSH devs' problem? Per some of the comments in the Debian bug(s): if you tell users and devs simply "you deal with it", you will get a multitude of ad hoc, half-baked solutions that may nor may not be secure. You will have dozens of people trying to re-invent the wheel. The whole point of things like /dev/urandom and getentropy() is that the problem is solved once properly, and then you allow everyone to benefit. By having the above solutions not-work, we are basically going back to the days of where they did not exist--in which case what was the point of creating them? The BSDs seem to not have a problem with this, so I have no idea why the Linux folks can't seem to get their act together. > Key generation is already slow anyway. Define "slow". Key generation was slow in the early 1990s when I first started using PGP (nee GPG) back in the day. It is generally not-slow nowadays IMHO--as in, it takes less than ten minutes to find p and q for RSA 1024 (nevermind 2048+).
Hello71 7y ago
example: https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf

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 ago
I 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 ago
  If 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 ago
    MAC addresses are not used in a purely routed/virtualized network. qemu uses the same MAC address by default.
mehrdadn 7y ago
date -u just returns 1-second resolution? It's trivial to go through all the possibilities...
- throw0101a 7y ago
  $(date -u | wc --bytes) says there is 29 bytes worth of output, which is 232 bits. Are you telling me there is not even, say, 8 bits' worth of entropy credit in there? (Especially when hashed with other data?) Remember: the context of this discussion is VMs (and not embedded systems without a battery-backed RTC).
viraptor 7y ago
MACs are very much not random. Especially on a series of machines for a given provider, you can likely predict one. Date of the bootup is also not random if it's got only seconds resolution and you can figure out when a machine comes online by constantly trying to connect. In practice you added much fewer than 48 bits.

mehrdadn 7y ago

All this is literally just concern for the first ~minute or two of the very first boot after disk cloning? It should be irrelevant for subsequent boots once they reseed on the next boot... hardly seems like such a huge deal.

throw0101a 7y ago
Except that SSH keys are often generated on first boot, so there's the risk that they're all the same--unless you put some code in your deployment recipes to regenerate them.
- mehrdadn 7y ago
  Isn't that the user's and the SSH devs' problem? SSH can just wait for new randomness if it sees that as a risk when generating keys. Key generation is already slow anyway. Why is systemd trying so hard to "fix" a problem that might by some chance come up in SSH during the first minute of the the first boot after an improper disk clone? Especially with the currently proposed solutions it seems like such a crazy way to attack somebody else's problem...
  - throw0101a 7y ago
    > Isn't that the user's and the SSH devs' problem? Per some of the comments in the Debian bug(s): if you tell users and devs simply "you deal with it", you will get a multitude of ad hoc, half-baked solutions that may nor may not be secure. You will have dozens of people trying to re-invent the wheel. The whole point of things like /dev/urandom and getentropy() is that the problem is solved once properly, and then you allow everyone to benefit. By having the above solutions not-work, we are basically going back to the days of where they did not exist--in which case what was the point of creating them? The BSDs seem to not have a problem with this, so I have no idea why the Linux folks can't seem to get their act together. > Key generation is already slow anyway. Define "slow". Key generation was slow in the early 1990s when I first started using PGP (nee GPG) back in the day. It is generally not-slow nowadays IMHO--as in, it takes less than ten minutes to find p and q for RSA 1024 (nevermind 2048+).

Hello71 7y ago

example: https://factorable.net/weakkeys12.extended.pdf https://factorable.net/weakkeys12.extended.pdf