3 ms·

Bruce Schneier had a section on recognizing snake oil encryption. One of the things that gave it away was a ridiculous key length. “Standard AES uses 256 but ke

Bruce Schneier had a section on recognizing snake oil encryption. One of the things that gave it away was a ridiculous key length. “Standard AES uses 256 but keys, but ours uses 10,000 bit keys, so ours is much better.” In terms of using randomness is crypto, you actually don’t need that much. If you have 256 bits, or 512 bits for an crazy amount of safety factor, you should be good to go. A lot of the secure PRNG’s are built in the same principles as our encryption algorithms. If we don’t trust those, we likely have much bigger issues with the foundations of cryptography.

chairmanwow1 6y ago
I absolutely agree with you that the amount of randomness you need is incredibly small for modern cryptography relies on an objectively small amount of random values. Although, I wonder if an invention like this allows for some new developments in crypto protocols that are extremely "random hungry" in the same way that modern innovation in NNs was made possible by scaled up processors (GPUs / accelerated NN chips). ie just XOR your plaintext with a random "key" the length of your plaintext
- nemo1618 6y ago
  > ie just XOR your plaintext with a random "key" the length of your plaintext This is essentially what a modern cipher does, except that the key is a keystream and is generated deterministically from the actual key. This is objectively better than just using a really big key -- it means your shared secret only needs to be e.g. 32 bytes, rather than len(plaintext) bytes! I do still think there's an important use case for high-volume "good" entropy, though: it should replace essentially all uses of "bad" entropy (generated by weak pseudo-random generators, maybe seeded with a few dozen bits of entropy). Programmers should have to go out of their way to get weak entropy, rather than the other way around. Historically programmers have reached for weak RNGs because they tend to be much faster and more convenient to use than the strong RNGs. We should flip that equation. We don't necessarily need a device like this one to do that, but it might help.
  - Const-me 6y ago
    > it should replace essentially all uses of "bad" entropy Yes. One application is Monte-Carlo methods. When the function is fast to compute, especially when running on GPUs with thousands of concurrent threads, good RNG is hard.
nemo1618 6y ago
Yep. As djb pointed out, PGP is predicated on the idea that you generate a small amount of secure entropy once, and then keep that entropy safe indefinitely. And a good CSPRNG can be seeded with 32 bytes of entropy and generate essentially infinite secure output. Still, it would be nice to remove the CSPRNG from the equation entirely, and just read from the stream of "pure"/"true" randomness directly. On the other hand, there are obvious downsides to getting your entropy from a single source... I guess it comes down to a simple question: which do you trust more, your hardware or your software?
- xyzzyz 6y ago
  Yeah, I’d rather trust well understood, deterministic CSPRNGs than opaque hardware that might just have a non-obvious defect.
  - remus 6y ago
    On the other hand, if you are relying on software you're working higher up the stack so there's more room for bugs to creep in. Or put another way, that software is running on hardware that might have a non-obvious defect. Maybe it's better to just cut out the middleman?
  - 317070 6y ago
    Just xor them together. As long as they are uncorrelated, you will get the best of both worlds.
    - vlovich123 6y ago
      How did you choose to seed your CSPRNG initially?

chairmanwow1 6y ago

I absolutely agree with you that the amount of randomness you need is incredibly small for modern cryptography relies on an objectively small amount of random values. Although, I wonder if an invention like this allows for some new developments in crypto protocols that are extremely "random hungry" in the same way that modern innovation in NNs was made possible by scaled up processors (GPUs / accelerated NN chips). ie just XOR your plaintext with a random "key" the length of your plaintext

nemo1618 6y ago
> ie just XOR your plaintext with a random "key" the length of your plaintext This is essentially what a modern cipher does, except that the key is a keystream and is generated deterministically from the actual key. This is objectively better than just using a really big key -- it means your shared secret only needs to be e.g. 32 bytes, rather than len(plaintext) bytes! I do still think there's an important use case for high-volume "good" entropy, though: it should replace essentially all uses of "bad" entropy (generated by weak pseudo-random generators, maybe seeded with a few dozen bits of entropy). Programmers should have to go out of their way to get weak entropy, rather than the other way around. Historically programmers have reached for weak RNGs because they tend to be much faster and more convenient to use than the strong RNGs. We should flip that equation. We don't necessarily need a device like this one to do that, but it might help.
- Const-me 6y ago
  > it should replace essentially all uses of "bad" entropy Yes. One application is Monte-Carlo methods. When the function is fast to compute, especially when running on GPUs with thousands of concurrent threads, good RNG is hard.

nemo1618 6y ago

Yep. As djb pointed out, PGP is predicated on the idea that you generate a small amount of secure entropy once, and then keep that entropy safe indefinitely. And a good CSPRNG can be seeded with 32 bytes of entropy and generate essentially infinite secure output. Still, it would be nice to remove the CSPRNG from the equation entirely, and just read from the stream of "pure"/"true" randomness directly. On the other hand, there are obvious downsides to getting your entropy from a single source... I guess it comes down to a simple question: which do you trust more, your hardware or your software?

xyzzyz 6y ago
Yeah, I’d rather trust well understood, deterministic CSPRNGs than opaque hardware that might just have a non-obvious defect.
- remus 6y ago
  On the other hand, if you are relying on software you're working higher up the stack so there's more room for bugs to creep in. Or put another way, that software is running on hardware that might have a non-obvious defect. Maybe it's better to just cut out the middleman?
- 317070 6y ago
  Just xor them together. As long as they are uncorrelated, you will get the best of both worlds.
  - vlovich123 6y ago
    How did you choose to seed your CSPRNG initially?