Topic: PRNG security in Virtual Machines - Possible BTC threat? (Read 949 times)

Not true. NIST (not the NSA!) suggested to merely increase the capacity of the SHA3 sponge construction. This only increases entropy and security. Bruce Schneier criticized this not because this would possible imply any backdoor, but simply because NIST changing parameters at all might reduce general acceptance.

And you have obviously no idea how SHA3 works. There is no (P)RNG in SHA3 whatsoever.

1. SHA3 has absolutely nothing to do with Bitcoin.
2. SHA3 has nothing to do with encryption, it's is a hashing function. That's something completely different. It's both part of a technology field we call 'cryptography', but encryption ≠ hashing.

This paper points out an interesting weakness in PRNG's, but the real threat to BTC with respect to PRNG's may be far more serious: Bruce Schneier has long written that the probability is unacceptably high that the NSA has installed a PRNG backdoor in the widely accepted SHA-3 standard protocol for cryptography (which NIST grudgingly accepted only with a footnoted caveat that one might prefer to use a more efficient alternative).  If such a backdoor exists (which seems nearly certain to me), the NSA can rather easily crack into any level it chooses of such encryption, and that means virtually all the BTC protocols - which would be the rather instant death of such cryptocurrencies.  Is Quarkcoin the only alternative cryptocoin that does not use the tainted PNRG?

Has anyone seen this: When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography?
http://www.isoc.org/isoc/conferences/ndss/10/pdf/15.pdf

Random number generators (RNGs) are consistently a weak link in the secure use of cryptography. Routine cryptographic operations such as encryption and signing can fail spectacularly given predictable or repeated randomness, even when using good long-lived key material. This has proved problematic in prior settings when RNG implementation bugs, poor design, or low-entropy sources have resulted in predictable randomness. We investigate a new way in which RNGs fail due to reuse of virtual machine (VM) snapshots. We exhibit such VM reset vulnerabilities in widely-used TLS clients and servers: the attacker takes advantage of (or forces) snapshot replay to compromise sessions or even expose a server’s DSA signing key. Our next contribution is a backwards-compatible framework for hedging routine cryptographic operations against bad randomness, thereby mitigating the damage due to randomness failures. We apply our framework to the OpenSSL library and experimentally confirm that it has little overhead.

I imagine some of the larger websites run in VMs and people might be running their wallet in a VM as well.

"The attacks work because the VM resets lead to cryptographic
operations (here, key exchange and signing) using
the same randomness more than once. These cryptographic
operations, in turn, fail to provide any security given repeat
randomness. One conceptually simple solution, then,
is to ensure that applications sample sufficiently fresh randomness
immediately before use. Unfortunately, there are
lurking complexities to overcome. Besides the difficulty of
ensuring every RNG-using application is updated, there is
the more subtle problem of where to find good randomness
after VM resets. For example, the state of traditional RNGs
(e.g., Linux’s /dev/random) is also reset with the rest of the
guest. We provide more discussion of systems solutions in
the body, but leave the bulk of this task to future work."