Am Freitag, 12. August 2016, 15:22:08 CEST schrieb Theodore Ts'o:
Hi Theodore,
> On Fri, Aug 12, 2016 at 11:34:55AM +0200, Stephan Mueller wrote:
> > - correlation: the interrupt noise source is closely correlated to the
> > HID/
> > block noise sources. I see that the fast_pool somehow "smears" that
> > correlation. However, I have not seen a full assessment that the
> > correlation is gone away. Given that I do not believe that the HID event
> > values (key codes, mouse coordinates) have any entropy -- the user
> > sitting at the console exactly knows what he pressed and which mouse
> > coordinates are created, and given that for block devices, only the
> > high-resolution time stamp gives any entropy, I am suggesting to remove
> > the HID/block device noise sources and leave the IRQ noise source. Maybe
> > we could record the HID event values to further stir the pool but do not
> > credit it any entropy. Of course, that would imply that the assumed
> > entropy in an IRQ event is revalued. I am currently finishing up an
> > assessment of how entropy behaves in a VM (where I hope that the report
> > is released). Please note that contrary to my initial
> > expectations, the IRQ events are the only noise sources which are almost
> > unaffected by a VMM operation. Hence, IRQs are much better in a VM
> > environment than block or HID noise sources.
>
> The reason why I'm untroubled with leaving them in is because I beieve
> the quality of the timing information from the HID and block devices
> is better than most of the other interrupt sources. For example, most
> network interfaces these days use NAPI, which means interrupts get
> coalesced and sent in batch, which means the time of the interrupt is
> latched off of some kind of timer --- and on many embeded devices
According to my understanding of NAPI, the network card sends one interrupt
when receiving the first packet of a packet stream and then the driver goes
into polling mode, disabling the interrupt. So, I cannot see any batching
based on some on-board timer where add_interrupt_randomness is affected.
Can you please elaborate?
> there is a single oscillator for the entire mainboard. We only call
> add_disk_randomness for rotational devices (e.g., only HDD's, not
> SSD's), after the interrupt has been recorded. Yes, most of the
> entropy is probably going to be found in the high entropy time stamp
> rather than the jiffies-based timestamp, especially for the hard drive
> completion time.
>
> I also tend to take a much more pragmatic viewpoint towards
> measurability. Sure, the human may know what she is typing, and
> something about when she typed it (although probably not accurately
> enough on a millisecond basis, so even the jiffies number is going to
> be not easily predicted), but the analyst sitting behind the desk at
> the NSA or the BND or the MSS is probably not going to have access to
> that information.
Well, injecting a trojan to a system in user space as unprivileged user that
starts some X11 session and that can perform the following command is all you
need to get to the key commands of the console.
xinput list | grep -Po 'id=\K\d+(?=.*slave\s*keyboard)' | xargs -P0 -n1
xinput test
That is fully within reach of not only some agencies but also other folks. It
is similar for mice.
>
> (Whereas the NSA or the BND probably *can* get low-level information
> about the Intel x86 CPU's internal implementation, which is why I'm
> extremely amused by the arugment --- "the internals of the Intel CPU
> are **so** complex we can't reverse engineer what's going on inside,
> so the jitter RNG *must* be good!" Note BTW that the NSA has only
Sure, agencies may know the full internals of a CPU like they know the full
internals of the Linux kernel with the /dev/random implementation or just like
they know the full internals of AES. But they do not know the current state of
the system. And the cryptographic strength comes from that state.
When you refer to my Jitter RNG, I think I have shown that its strength comes
from the internal state of the CPU (states of the internal building blocks
relative to each other which may cause internal wait states, state of branch
prediction or pipelines, etc.) and not of the layout of the CPU.
> said they won't do industrial espionage for economic for economic
> gain, not that they won't engage in espionage against industrial
> entities at all. This is why the NSA spying on Petrobras is
> considered completely fair game, even if it does enrage the
> Brazillians. :-)
>
> > - entropy estimate: the current entropy heuristics IMHO have nothing to do
> > with the entropy of the data coming in. Currently, the min of
> > first/second/
> > third derivative of the Jiffies time stamp is used and capped at 11. That
> > value is the entropy value credited to the event. Given that the entropy
> > rests with the high-res time stamp and not with jiffies or the event
> > value, I think that the he
