Re: [dsfjdssdfsd] Risks of entropy available

Dan Brown <> Mon, 16 April 2018 21:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B996126CB6 for <>; Mon, 16 Apr 2018 14:05:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R4GMLtI9_Zkm for <>; Mon, 16 Apr 2018 14:05:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64121124B0A for <>; Mon, 16 Apr 2018 14:05:36 -0700 (PDT)
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Apr 2018 17:05:35 -0400
Received: from ([fe80::45d:f4fe:6277:5d1b]) by ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0319.002; Mon, 16 Apr 2018 17:05:34 -0400
From: Dan Brown <>
To: Dan Brown <>, "" <>
Thread-Topic: Risks of entropy available
Thread-Index: AdJJlYI5iB70z0jIQMOX0DbzkV0LDFBgHS8AEqfvTuA=
Date: Mon, 16 Apr 2018 21:05:34 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004B_01D3D5A5.1E6211A0"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dsfjdssdfsd] Risks of entropy available
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Apr 2018 21:05:39 -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:
where /dev/random blocking (instead of entropy available in this thread) is
the keyboard-timing side channel
Thanks to

Best regards,

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