3 ms·

A few problems with the reasoning in this article. It assumes that either "cryptography works" (and you only need to seed the CSRNG once) or "cryptography does

A few problems with the reasoning in this article. It assumes that either "cryptography works" (and you only need to seed the CSRNG once) or "cryptography does not work" (and the entropy pool is necessary). In actuality, "cryptography" covers a wide range of algorithms, some of which seem to work, and some of which (like RC4) are known not to work. It's possible that (say) ECDSA works but Linux's CSRNG isn't as good as we think it is. The article also makes fun of the kernel for not trusting RDRAND. Well, here's a sequence of random numbers from RDRAND on the AMD Ryzen 3000: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff. Do you see a pattern? Was it indeed a foolish choice not to trust RDRAND?

baby 7y ago
Nothing malicious in this RDRAND output btw if you use through /dev/urandom or getrandom People were initially scared about it cancelling other entropy sources, which still hasn’t been proven.
cyphar 7y ago
Funnily enough, the kernel does trust RDRAND (for fetching a single-integer "random enough" value[1]). That's why WireGuard had a DoS bug on those chips until they patched around it to use the proper CSPRNG after a few failed attempts. [1]: https://elixir.bootlin.com/linux/v5.4.5/source/drivers/char/random.c#L2410 https://elixir.bootlin.com/linux/v5.4.5/source/drivers/char/...
saagarjha 7y ago
> Was it indeed a foolish choice not to trust RDRAND? From that output? No, not at all. It's not backdoored, it's the same as any other microcode bug. What would be more insidious was if it gave back 0xD82C07CD, 0x6BAA9455, 0x82E2E662, 0x7A024204: seemingly random but secretly predictable. (Hint: Python, random.seed(0))
- gus_massa 7y ago
  You can always check with Random Sanity https://www.randomsanity.org/ https://www.randomsanity.org/ In this case https://rest.randomsanity.org/v1/q/D82C07CD6BAA945582E2E6627A024204 https://rest.randomsanity.org/v1/q/D82C07CD6BAA945582E2E6627... It is not 100% sure, it was "true" until a few seconds ago.
  - Tomte 7y ago
    I strongly advise against trusting statistical entropy tests in the application layer. There are reasons to do statistical tests (for example, the USB key Ted mentioned needs to make sure the circuit is still generally functioning), but when you're in the application, there has already been so much de-biasing and whitening going on, that you will never really catch a problem. You will only obsess about a random (ha!) fluke where a tests sporadically fails.
    - gus_massa 7y ago
      It was a semi joke. It's an interesting project, but note that: It is not so popular, so they didn't have this string before. (Perhaps they can preload some common cases, but perhaps is too much memory.) Once you send your secret random stuff to a random site in the internet, it's no longer secret. You can send some samples as a test and discard them, and use other part of the random stream, but from a security point of view I'm not sure it is a good idea. I agree that flukes are a problem if you call something like this too much. I'm not sure about the implementation details to be sure how strict it is.

baby 7y ago

Nothing malicious in this RDRAND output btw if you use through /dev/urandom or getrandom People were initially scared about it cancelling other entropy sources, which still hasn’t been proven.

cyphar 7y ago

Funnily enough, the kernel does trust RDRAND (for fetching a single-integer "random enough" value[1]). That's why WireGuard had a DoS bug on those chips until they patched around it to use the proper CSPRNG after a few failed attempts. [1]: https://elixir.bootlin.com/linux/v5.4.5/source/drivers/char/random.c#L2410 https://elixir.bootlin.com/linux/v5.4.5/source/drivers/char/...

saagarjha 7y ago

> Was it indeed a foolish choice not to trust RDRAND? From that output? No, not at all. It's not backdoored, it's the same as any other microcode bug. What would be more insidious was if it gave back 0xD82C07CD, 0x6BAA9455, 0x82E2E662, 0x7A024204: seemingly random but secretly predictable. (Hint: Python, random.seed(0))

gus_massa 7y ago
You can always check with Random Sanity https://www.randomsanity.org/ https://www.randomsanity.org/ In this case https://rest.randomsanity.org/v1/q/D82C07CD6BAA945582E2E6627A024204 https://rest.randomsanity.org/v1/q/D82C07CD6BAA945582E2E6627... It is not 100% sure, it was "true" until a few seconds ago.
- Tomte 7y ago
  I strongly advise against trusting statistical entropy tests in the application layer. There are reasons to do statistical tests (for example, the USB key Ted mentioned needs to make sure the circuit is still generally functioning), but when you're in the application, there has already been so much de-biasing and whitening going on, that you will never really catch a problem. You will only obsess about a random (ha!) fluke where a tests sporadically fails.
  - gus_massa 7y ago
    It was a semi joke. It's an interesting project, but note that: It is not so popular, so they didn't have this string before. (Perhaps they can preload some common cases, but perhaps is too much memory.) Once you send your secret random stuff to a random site in the internet, it's no longer secret. You can send some samples as a test and discard them, and use other part of the random stream, but from a security point of view I'm not sure it is a good idea. I agree that flukes are a problem if you call something like this too much. I'm not sure about the implementation details to be sure how strict it is.