Subject: Re: [dsfjdssdfsd] Risks of entropy available

From: Dan Brown <[email-masked]>
Date: Mon, 16 Apr 2018 21:05:34 +0000

Hi again random readers,
Just adding some credit and historical background to this thread .
The issue of keyboard timing leakage had already been raised long before:
http://archive.cert.uni-stuttgart.de/bugtraq/2003/08/msg00213.html
where /dev/random blocking (instead of entropy available in this thread) is
the keyboard-timing side channel
Thanks to 
https://en.wikipedia.org/wiki/Entropy_(computing)#cite_note-26

Best regards,
Dan

PS By the way, just so that I could be more sure about the topic of this
thread, I had tried to write some shell scripts that distinguish keyboard
inputs (button clicks and slow mouse movements) from any other entropy
inputs - using the way that the entropy available changes over time.  (But
without any precise timing info :) Basically, I noticed that with no
keyboard input or mouse movement - on my test device, a laptop, - the
pattern is that the entropy available usually increases by 1 every second or
so, and occasionally decreases by some larger amount. (I have no clue why.)
By contrast,  any keyboard input, mouse clicks/scrolls, or slow mouse
movement, seems to cause a more rapid increase.  (No clue why, either.)
Based on this pattern, I was able to devise a script that detected keyboard
input, with occasional false positives (one a minute?).  Of course, other
systems, Linux versions, may not have this pattern.  I would guess that this
pattern would only hold on a subset of personal laptops and Linux versions.
# Try this loop to look for a pattern like the one above 
while true; do printf \\r%5s%5s $(cat /proc/sys/kernel/random/entropy_avail)
bits; done