The paper “Explicit Two-Source Extractors and Resilient Functions” (PDF) by Eshan Chattopadhyay and David Zuckerman is described by some as being a technological leap in RNG – opposed to slow and incremental benefits over time.
What benefits would a faster RNG have for cryptography in general? Does this make some formerly implausible scenarios possible?
This paper isn't about a faster RNG, and it's mostly only of interest in a computer science context rather than in an applied cryptographic context. These results reduce the theoretical requirements needed from two weak sources of randomness in order to combine them into a source of true randomness. However, in the applied world, we already have "enough" — a few bytes can seed a CSPRNG that will generate effectively infinite computationally-random bytes.
When systems today fall over due to randomness issues, it's usually due to systems-engineering failures: a good RNG wasn't used (despite them being widely and easily available), or not enough initial randomness was seeded (e.g., /dev/urandom on an embedded device), or a virtual machine was copied and restarted with the same initial random seed. These classes of problems aren't solved by improving our sources of randomness.
To your question directly, a faster RNG isn't of much practical use. A stream cipher seeded with enough randomness is effectively a DRBG, and can produce random bits extremely quickly — far more quickly than is needed for the overwhelming majority of use-cases. The operations that use that randomness typically execute far more instructions than do the operations to generate it.
Thomas Ptacek's response to this story on Hacker News is how I expect most crypto people feel about this.
Stephen correctly points out that the paper isn't about RNGs. I'll take the question literally, though, and remark that there are non-cryptographic applications that could potentially benefit from faster CSPRNG. Non-cryptographic users of PRNGs have to balance two concerns:
Faster generators tend to have more statistical biases, while less biased ones tend to be slower. Building a faster cryptographic PRNG would, effectively, give you more speed without introducing biases (or at least no biases observable to a computationally-bound adversary).
There are also PRNGs that, despite not being intended for cryptographic use, use cryptographic designs as part of a correctness argument. See for example Claessen and Pałka's splittable pseudo random number generators, which use cryptographic components not for security, but rather for correctness. This is an interesting elaboration of the previous point, however: correctness is lack of bias. But clearly, this is a case where faster crypto would allow faster non-cryptographic RNGs.
