4 ms·

Even though not all architectures have an RTC or strong PRNG instructions, almost all of them have writable storage in the form of NVRAM/NAND/disk. Why can’t t

Even though not all architectures have an RTC or strong PRNG instructions, almost all of them have writable storage in the form of NVRAM/NAND/disk. Why can’t they just patch up the kernel to persist PRNG state there and require that the boot loader recovers it upon reboot? The kernel would then have high quality random data available as soon as it gets launched.

kurikuri 3y ago
The PRNG state is responsible for generating most of the users cryptographic material and is quite important to the system’s security. As such, the PRNG State is a security parameter that should never be exportable nor importable. There are many new attacks that could surface if import/export were possible; off the top of my head: quiet preloading of an attacker-selected state while the machine is off.
- 1000thVisitor 3y ago
  > quiet preloading of an attacker-selected state while the machine is off. That attacker with physical access can chose from multiple other attacks, so why bother making this one more secure. They can sniff keyboard strokes, install malware into the UEFI, etc. pp.
- yencabulator 3y ago
  You don't need to export the current running kernel PRNG internal state, all you need is to save an unpredictable seed that can be used to fill the kernel entropy pool after next boot. https://systemd.io/RANDOM_SEEDS/ https://systemd.io/RANDOM_SEEDS/
- Asmod4n 3y ago
  Just do what netbsd recommends and you should be fine https://man.netbsd.org/urandom.4 https://man.netbsd.org/urandom.4 They explicitly state you should dog feed the prng on every shutdown and boot and also explain why that isn’t an issue.
- GoblinSlayer 3y ago
  >quiet preloading Just preload the OS then.
dist-epoch 3y ago
Windows does that, persists a seed in the registry, but it's not enough. Imagine a virtual machine snapshot that you start multiple times. The separate runs would have the exact same persisted state.
- cratermoon 3y ago
  Very useful for certain kinds of testing, though.
- Asmod4n 3y ago
  Doesn’t matter, it just feeds more entropy during boot. Even when it’s the same on all pcs on the planet the output wouldn’t be in a degraded state. When you are dealing with an attacker which can feed your PRNG non stop with their own entropy you have other issues to deal with.
  - Aachen 3y ago
    With that reasoning, one doesn't need an initial randomness file to begin with. Either you think there's plenty of usable entropy soon enough after power on that values can't be predicted, or you think there isn't and we need to keep a file to initialise from > an attacker which can feed your PRNG non stop with their own entropy Is not needed if you know the initial state from the file (which was present in the image file an attacker got their hands on, for example): knowing a sufficient percentage of outputs (such as the tcp seq/ack number (I forget which one the server generates) when you send a decent rate of syn packets) lets you verify which entropy addition would have lead to that output being generated. That's a handful of bits to brute force at each step unless the entropy additions are processed in prohibitively large batches (say, ≥80 bits at a time) which means you start completely predictable until that entropy is accrued (which may or may not be an issue depending on circumstances)

kurikuri 3y ago

The PRNG state is responsible for generating most of the users cryptographic material and is quite important to the system’s security. As such, the PRNG State is a security parameter that should never be exportable nor importable. There are many new attacks that could surface if import/export were possible; off the top of my head: quiet preloading of an attacker-selected state while the machine is off.

1000thVisitor 3y ago
> quiet preloading of an attacker-selected state while the machine is off. That attacker with physical access can chose from multiple other attacks, so why bother making this one more secure. They can sniff keyboard strokes, install malware into the UEFI, etc. pp.
yencabulator 3y ago
You don't need to export the current running kernel PRNG internal state, all you need is to save an unpredictable seed that can be used to fill the kernel entropy pool after next boot. https://systemd.io/RANDOM_SEEDS/ https://systemd.io/RANDOM_SEEDS/
Asmod4n 3y ago
Just do what netbsd recommends and you should be fine https://man.netbsd.org/urandom.4 https://man.netbsd.org/urandom.4 They explicitly state you should dog feed the prng on every shutdown and boot and also explain why that isn’t an issue.
GoblinSlayer 3y ago
>quiet preloading Just preload the OS then.

dist-epoch 3y ago

Windows does that, persists a seed in the registry, but it's not enough. Imagine a virtual machine snapshot that you start multiple times. The separate runs would have the exact same persisted state.

cratermoon 3y ago
Very useful for certain kinds of testing, though.
Asmod4n 3y ago
Doesn’t matter, it just feeds more entropy during boot. Even when it’s the same on all pcs on the planet the output wouldn’t be in a degraded state. When you are dealing with an attacker which can feed your PRNG non stop with their own entropy you have other issues to deal with.
- Aachen 3y ago
  With that reasoning, one doesn't need an initial randomness file to begin with. Either you think there's plenty of usable entropy soon enough after power on that values can't be predicted, or you think there isn't and we need to keep a file to initialise from > an attacker which can feed your PRNG non stop with their own entropy Is not needed if you know the initial state from the file (which was present in the image file an attacker got their hands on, for example): knowing a sufficient percentage of outputs (such as the tcp seq/ack number (I forget which one the server generates) when you send a decent rate of syn packets) lets you verify which entropy addition would have lead to that output being generated. That's a handful of bits to brute force at each step unless the entropy additions are processed in prohibitively large batches (say, ≥80 bits at a time) which means you start completely predictable until that entropy is accrued (which may or may not be an issue depending on circumstances)