3 ms·

So, the Linux kernel can't just persist 32 little random bytes? That shouldn't be hard. Even giving a seed for the first boot (or when booting a VM image) shoul

So, the Linux kernel can't just persist 32 little random bytes? That shouldn't be hard. Even giving a seed for the first boot (or when booting a VM image) shouldn't be hard. Heck, we don't even need to collect entropy. Like, ever. Just use Chacha20 with fast key erasure and be done with it. If your system is too small to be able to persist 32 bytes, it's probably too small to perform any amount of meaningful cryptography anyway.

loeg 7y ago
Yes, the availability problem hinges on being able to persist a handful of bytes. The problem isn't the number, which, sure, is small. The problem is the availability of any persistent media in general. There are absolutely devices with exclusively RO media with plenty of processing power to perform meaningful crypto (e.g., embedded devices with 802.11 wifi). So: > If your system is too small to be able to persist 32 bytes, it's probably too small to perform any amount of meaningful cryptography anyway. This sentence is not based in reality.
- magicalhippo 7y ago
  > There are absolutely devices with exclusively RO media with plenty of processing power to perform meaningful crypto (e.g., embedded devices with 802.11 wifi). Don't most microcontrollers have some EEPROM that could be used for this? I'm assuming even 4 bytes would help a lot. I am pretty sure STM32's with hardware crypto have EEPROM good for a million write cycles.
  - loeg 7y ago
    4 bytes isn't enough, but yes, it's quite possible some SoCs could persist 256-512 bits of entropy in some hardware-specific way. It's hard to abstract that into a general-purpose operating system, though it could be a good solution for specific applications.
    - loup-vaillant 7y ago
      > It's hard to abstract that into a general-purpose operating system Linux has lots and lots of hardware specific drivers. This shouldn't be any different.
      - loeg 7y ago
        Feel free to start writing device drivers for 1000s of individual SoCs and figure out a way to solicit testing. I agree hardware-specific drivers are a solution for the SoCs with RW media of some kind, but it's not as trivial as you paint it. And (AFAIK) there are still SoCs without RW media. I think jitterentropy is a better and more easily tested use of developer hours than implementing 1000s of SoC drivers, but it's open source; work on what you like.
        loup-vaillant 7y ago
        The onus is not on Linux to support devices. The onus is on the devices to support Linux. Linux support is a selling point, that should be leveraged. The current way of gathering initial entropy should not be the default, it should be a fallback. If a device have neither persistent storage (32 bytes for crying out loud) nor a hardware random generator, they should be treated like second class citizen, with only best effort random numbers. Right now, everyone is a second class citizen. Kind of insane, don't you think? > it's not as trivial as you paint it It is, under one (extremely hard to fulfil) condition: collaboration from hardware vendors. It's just 32 persistent bytes. Just bury them in a chip and memory map the damn thing! The driver can be reduced to an offset. > I think jitterentropy is a better and more easily tested use of developer hours than implementing 1000s of SoC drivers That one? https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-basic https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-... It's one of the first links I found, I hope it is obsolete: they say the internal state of Jitterentropy is puny 64 bits number. What were they thinking, we need four times as much! That kind of thing is why people are tempted to shed the system's RNG, and ask users to wiggle their mouse instead.
        7y ago
- loup-vaillant 7y ago
  > There are absolutely devices with exclusively RO media with plenty of processing power to perform meaningful crypto (e.g., embedded devices with 802.11 wifi). Well, those devices are flawed. Unless they have special hardware to generate random numbers? I mean, the ability to generate random number is such a basic feature. If your communication hardware doesn't have it, your communication hardware is crap, and that's the end of it. I maintain what I said: if a system is big enough to do crypto, it is big enough to persist 32 bytes. When you can process a 64-byte Chacha20 block in RAM, you can spare 32 bytes of EEPROM or flash. I think this is reasonable enough to be "grounded in reality". That said, of course many devices out there are so badly designed that even though they're powerful enough to process elliptic curves (and I presume the entire Linux kernel), they don't even have enough persistent memory to store 256 bits of entropy, and they don't have a reliable, fast way to generate 256 bits of entropy. Stupidity is a thing, I know. Acknowledging such stupidly designed devices is of course very important. We do what we can with what we have. But let's not go the C standard route, and use that stupidity as an excuse to never use persistent state or random generation instructions. Let's use the capabilities of our platforms, dammit. For instance, that stupid WiFi router is not an excuse to not persist state on a freaking desktop. (Or laptop. Or palmtop. Or R-Pi. Or virtualised server. Etc.)

loeg 7y ago

Yes, the availability problem hinges on being able to persist a handful of bytes. The problem isn't the number, which, sure, is small. The problem is the availability of any persistent media in general. There are absolutely devices with exclusively RO media with plenty of processing power to perform meaningful crypto (e.g., embedded devices with 802.11 wifi). So: > If your system is too small to be able to persist 32 bytes, it's probably too small to perform any amount of meaningful cryptography anyway. This sentence is not based in reality.

magicalhippo 7y ago
> There are absolutely devices with exclusively RO media with plenty of processing power to perform meaningful crypto (e.g., embedded devices with 802.11 wifi). Don't most microcontrollers have some EEPROM that could be used for this? I'm assuming even 4 bytes would help a lot. I am pretty sure STM32's with hardware crypto have EEPROM good for a million write cycles.
- loeg 7y ago
  4 bytes isn't enough, but yes, it's quite possible some SoCs could persist 256-512 bits of entropy in some hardware-specific way. It's hard to abstract that into a general-purpose operating system, though it could be a good solution for specific applications.
  - loup-vaillant 7y ago
    > It's hard to abstract that into a general-purpose operating system Linux has lots and lots of hardware specific drivers. This shouldn't be any different.
    - loeg 7y ago
      Feel free to start writing device drivers for 1000s of individual SoCs and figure out a way to solicit testing. I agree hardware-specific drivers are a solution for the SoCs with RW media of some kind, but it's not as trivial as you paint it. And (AFAIK) there are still SoCs without RW media. I think jitterentropy is a better and more easily tested use of developer hours than implementing 1000s of SoC drivers, but it's open source; work on what you like.
      - loup-vaillant 7y ago
        The onus is not on Linux to support devices. The onus is on the devices to support Linux. Linux support is a selling point, that should be leveraged. The current way of gathering initial entropy should not be the default, it should be a fallback. If a device have neither persistent storage (32 bytes for crying out loud) nor a hardware random generator, they should be treated like second class citizen, with only best effort random numbers. Right now, everyone is a second class citizen. Kind of insane, don't you think? > it's not as trivial as you paint it It is, under one (extremely hard to fulfil) condition: collaboration from hardware vendors. It's just 32 persistent bytes. Just bury them in a chip and memory map the damn thing! The driver can be reduced to an offset. > I think jitterentropy is a better and more easily tested use of developer hours than implementing 1000s of SoC drivers That one? https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-basic https://fuchsia.dev/fuchsia-src/zircon/jitterentropy/config-... It's one of the first links I found, I hope it is obsolete: they say the internal state of Jitterentropy is puny 64 bits number. What were they thinking, we need four times as much! That kind of thing is why people are tempted to shed the system's RNG, and ask users to wiggle their mouse instead.
        7y ago
loup-vaillant 7y ago
> There are absolutely devices with exclusively RO media with plenty of processing power to perform meaningful crypto (e.g., embedded devices with 802.11 wifi). Well, those devices are flawed. Unless they have special hardware to generate random numbers? I mean, the ability to generate random number is such a basic feature. If your communication hardware doesn't have it, your communication hardware is crap, and that's the end of it. I maintain what I said: if a system is big enough to do crypto, it is big enough to persist 32 bytes. When you can process a 64-byte Chacha20 block in RAM, you can spare 32 bytes of EEPROM or flash. I think this is reasonable enough to be "grounded in reality". That said, of course many devices out there are so badly designed that even though they're powerful enough to process elliptic curves (and I presume the entire Linux kernel), they don't even have enough persistent memory to store 256 bits of entropy, and they don't have a reliable, fast way to generate 256 bits of entropy. Stupidity is a thing, I know. Acknowledging such stupidly designed devices is of course very important. We do what we can with what we have. But let's not go the C standard route, and use that stupidity as an excuse to never use persistent state or random generation instructions. Let's use the capabilities of our platforms, dammit. For instance, that stupid WiFi router is not an excuse to not persist state on a freaking desktop. (Or laptop. Or palmtop. Or R-Pi. Or virtualised server. Etc.)