[Cryptography] [RNG] on RNGs, VM state, rollback, etc.

[Arnold Reinhold]

On  Mon, 28 Oct 2013 21:05:13 David Mercer wrote
> 
> Date: Mon, 28 Oct 2013 21:05:13 -0700
> From: David Mercer <radix42 at gmail.com>
> To: Philipp G?hring <pg at futureware.at>
> Cc: Alexandre Anzala-Yamajako <anzalaya at gmail.com>,	Cryptography
> 	<cryptography at metzdowd.com>, John Denker <jsd at av8n.com>
> Subject: Re: [Cryptography] [RNG] on RNGs, VM state, rollback, etc.
> Message-ID:
> 	<CADpjbE3P+-d7K3Uc28U1GROkKtrJ299bVyyu-HPQMSoTPXkQrw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> On Sun, Oct 27, 2013 at 3:53 PM, Philipp G?hring <pg at futureware.at> wrote:
> 
>> Hmm, if someone is able to run secret opcodes, then we already have
>> local code execution, right? And in this case there might be far more
>> powerful secret opcodes that give ring 0, ring -1 , ... access, and we
>> usually have to care about much larger problems than RNG attacks.
>> 
> 
> Uhm, yes, if I as an attacker have "ring -1" level access to your
> machine/hypervisor/VM/whatever, you are so toast that I have already
> succeeded, and am not going to give a hoot about attacks on your RNG.
> I can grab all your keystrokes, private keys when used, unencrypted data,
> etc.
> 
> I can't think of ANY threat model in which an attacker would continue
> attacking
> an RNG if they have that. ANY. Disproof by counter-example from history or
> the literature appreciated.
> 
> -David Mercer

The beauty of an RNG attack is that it does not require any communications back to the attacker, unlike the other attacks you mention.  Such back communications can arouse suspicion.  And done right, an RNG attack does not introduce any insecurity in the attacked system that others can exploit. NSA may want to monitor Angela Merkle's traffic without making it easier for Russia or China to do so, for example. 

Arnold Reinhold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131031/83f49eb5/attachment.html>