5 ms·

Massively parallel ultrafast random bit generation with a chip-scale laser

42 points by ycnews 6y ago

bjoli 6y ago
I didnt know what to expect. It was a lot lower than the claimed 250 terabit/second. The fastest I have ever gotten bits out of dedicated hardware is only about 500 b/s. Now. I didn't try very hard, but I didn't think anything in the gigabit range was possible on a single chip.
- lmilcin 6y ago
  I got something like 200Mb/s using RF noise and FPGA. I am not qualified to make any strong statements about quality of the resulting random bit stream. I wonder who would need more than that.
RobLach 6y ago
For the underprivileged: https://arxiv.org/abs/2004.07157 https://arxiv.org/abs/2004.07157 (Dunno the differences between the preprint and the published one. The preprint claims 100tb/s.)
- cocoafleck 6y ago
  The published one is significantly shorter which surprised me (6 pages vs 14 pages), but it does claim a different rate in the final paper "All these test results certify the randomness of our parallel random bits generated at a cumulative rate of 2 Tb/s × 127 = 254 Tb/s".
xiphias2 6y ago
Why is it any better than a slow true random seed and pseudorandom numbers based on a secure hash function? I can't think of any application.
- goalieca 6y ago
  There’s really no true seed unless you have some sort of quantum system. Many are based on sources of noise and are actually somewhat slow. Small IoT devices often have poor generation. A fast source of high quality numbers available to every computer is still an open problem.
  - JulianMorrison 6y ago
    Also anything that expects to seed based on keyboard and mouse is not going to get much to seed from, in a widget attached to your wall.
  - Enginerrrd 6y ago
    I don't understand why we dont, at this point, have a specific module built into every processor or motherboard whose purpose is to serve as a simple entropy source. It's bizarre to me that this isn't built into the architecture standards.
    - petertodd 6y ago
      We do: https://en.wikipedia.org/wiki/RDRAND https://en.wikipedia.org/wiki/RDRAND However it's difficult to be sure it hasn't been backdoored, so it's not advisable to use it directly for cryptographic purposes. Worse, as DJB explains, it's hard to mix a potentially backdoored random number generator with other random numbers in a secure fashion: http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html
      - oconnor663 6y ago
        That "malicious hardware RNG" scenario has always seemed odd to me. The idea is that it's going to spy on the contents of your entropy pool (or on your entropy sources, or both) and then generate malicious random bits to exactly cancel out what's in your pool, leaving you with all zeros or something like that. My question is, if you have the capability to pull off an attack like that, wouldn't you probably also have the capability to do much worse things? Like just reading and writing arbitrary memory?
cbetti 6y ago
Imagine blasting this sequence down to huge numbers of consumers, and letting independent nodes coordinate on intervals in the sequence in order to establish secure one time communications. The bit rate is so high it would be impossible to reproduce the pad despite having access to the full random bit stream, because you couldn't possibly store the historic stream for future analysis even if you could eventually determine the past communication's interval.
- mleonhard 6y ago
  This is an interesting idea. I see two limitations and I'm curious how they could be overcome: 1. The peers must communicate to decide in advance which intervals to use. If those communications are encrypted with the shared stream using previously exchanged intervals, then the security of each session depends on the previous session. Breaking one session also breaks all future sessions. 2. Attackers can capture and save samples of the random bit stream and test intercepted communications against those samples. They won't get all of the victim communications, but they will get some. Combined with the chaining problem above, this could let them eventually crack all established streams.
  - eru 6y ago
    About 1: the peers don't have to communicate in advance. They can just both do random sampling, and later on only use the overlap. That wastes a lot of bits, but requires no up-front communication. About 2: obviously you wouldn't just use straight one-time pad, but use the random bits to arrive at a shared key. With made up numbers: both parties sample randomly until they have eg 10k bits in common, then hash that down to eg 256 bits they need for a shared key. If they use a decent hashing scheme, the only requirement for its security is that they share at least about 256 bits that the attacker has not seen. (It doesn't matter how many common bits the attacker has seen, only how many Eve hasn't seen.)

42 points by ycnews 6y ago

I didnt know what to expect. It was a lot lower than the claimed 250 terabit/second. The fastest I have ever gotten bits out of dedicated hardware is only about 500 b/s. Now. I didn't try very hard, but I didn't think anything in the gigabit range was possible on a single chip.

lmilcin 6y ago
I got something like 200Mb/s using RF noise and FPGA. I am not qualified to make any strong statements about quality of the resulting random bit stream. I wonder who would need more than that.

RobLach 6y ago

For the underprivileged: https://arxiv.org/abs/2004.07157 https://arxiv.org/abs/2004.07157 (Dunno the differences between the preprint and the published one. The preprint claims 100tb/s.)

cocoafleck 6y ago
The published one is significantly shorter which surprised me (6 pages vs 14 pages), but it does claim a different rate in the final paper "All these test results certify the randomness of our parallel random bits generated at a cumulative rate of 2 Tb/s × 127 = 254 Tb/s".

xiphias2 6y ago

Why is it any better than a slow true random seed and pseudorandom numbers based on a secure hash function? I can't think of any application.

goalieca 6y ago
There’s really no true seed unless you have some sort of quantum system. Many are based on sources of noise and are actually somewhat slow. Small IoT devices often have poor generation. A fast source of high quality numbers available to every computer is still an open problem.
- JulianMorrison 6y ago
  Also anything that expects to seed based on keyboard and mouse is not going to get much to seed from, in a widget attached to your wall.
- Enginerrrd 6y ago
  I don't understand why we dont, at this point, have a specific module built into every processor or motherboard whose purpose is to serve as a simple entropy source. It's bizarre to me that this isn't built into the architecture standards.
  - petertodd 6y ago
    We do: https://en.wikipedia.org/wiki/RDRAND https://en.wikipedia.org/wiki/RDRAND However it's difficult to be sure it hasn't been backdoored, so it's not advisable to use it directly for cryptographic purposes. Worse, as DJB explains, it's hard to mix a potentially backdoored random number generator with other random numbers in a secure fashion: http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html
    - oconnor663 6y ago
      That "malicious hardware RNG" scenario has always seemed odd to me. The idea is that it's going to spy on the contents of your entropy pool (or on your entropy sources, or both) and then generate malicious random bits to exactly cancel out what's in your pool, leaving you with all zeros or something like that. My question is, if you have the capability to pull off an attack like that, wouldn't you probably also have the capability to do much worse things? Like just reading and writing arbitrary memory?

cbetti 6y ago

Imagine blasting this sequence down to huge numbers of consumers, and letting independent nodes coordinate on intervals in the sequence in order to establish secure one time communications. The bit rate is so high it would be impossible to reproduce the pad despite having access to the full random bit stream, because you couldn't possibly store the historic stream for future analysis even if you could eventually determine the past communication's interval.

mleonhard 6y ago
This is an interesting idea. I see two limitations and I'm curious how they could be overcome: 1. The peers must communicate to decide in advance which intervals to use. If those communications are encrypted with the shared stream using previously exchanged intervals, then the security of each session depends on the previous session. Breaking one session also breaks all future sessions. 2. Attackers can capture and save samples of the random bit stream and test intercepted communications against those samples. They won't get all of the victim communications, but they will get some. Combined with the chaining problem above, this could let them eventually crack all established streams.
- eru 6y ago
  About 1: the peers don't have to communicate in advance. They can just both do random sampling, and later on only use the overlap. That wastes a lot of bits, but requires no up-front communication. About 2: obviously you wouldn't just use straight one-time pad, but use the random bits to arrive at a shared key. With made up numbers: both parties sample randomly until they have eg 10k bits in common, then hash that down to eg 256 bits they need for a shared key. If they use a decent hashing scheme, the only requirement for its security is that they share at least about 256 bits that the attacker has not seen. (It doesn't matter how many common bits the attacker has seen, only how many Eve hasn't seen.)