[148462] in cryptography@c2.net mail archive
Re: [Cryptography] An alternative electro-mechanical entropy source
daemon@ATHENA.MIT.EDU (Bill Cox)
Sat Dec 14 16:07:36 2013
X-Original-To: cryptography@metzdowd.com
Date: Sat, 14 Dec 2013 08:04:15 -0500
From: Bill Cox <waywardgeek@gmail.com>
To: cryptography@metzdowd.com
In-Reply-To: <7D72A130-61A0-4AE2-84C0-EDD687A5914B@me.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
This is a multi-part message in MIME format.
--===============8787539427849759145==
Content-Type: multipart/alternative;
boundary="------------030407090400000207040809"
This is a multi-part message in MIME format.
--------------030407090400000207040809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
On 12/13/2013 4:26 PM, Arnold Reinhold wrote:
> On Dec 13, 2013, at 1:59 PM, Steve Weis <steveweis@gmail.com
> <mailto:steveweis@gmail.com>> wrote:
>
>> On Thu, Dec 12, 2013 at 3:44 AM, Arnold Reinhold <agr@me.com
>> <mailto:agr@me.com>> wrote:
>>> My problem with the Intel design is that there is no way to audit it.
>>> ...
>>> Here is an idea I have been playing with to provide a slow but auditable
>>> source of entropy.
>>> ...
>>> Both the accelerometer chips and the
>>> vibration motors are made in huge quantities and cost under a dollar in
>>> quantity. They can be audited separately. The items could be
>>> mounted on the
>>> mother board, daughter board or a USB dongle.
>>
>> A few comments:
>> 1. You aren't trusting the CPU to generate random numbers, but you're
>> trusting the motherboard and chipset that your proposed RNG device is
>> plugged into. You're also ultimately still trusting the CPU which is
>> consuming those values.
>
> The threat I am responding to is devices with no source of randomness
> other than a RNG buried in the CPU, presenting a single point of
> attack that is impossible to detect or prevent. It is an emerging
> threat as hard drives, which served as a dependable source of entropy,
> are phased out in favor of solid state devices, and as the internet is
> increasingly used to control infrastructure with diskless devices.
I like the idea of a completely auditable source of entropy, and the
accelerometer is clever. However, why not use zener noise like many
have done before? I've used the reverse breakdown of a base-emitter in
a common N2222 NPN transistor with excellent results - commercial zeners
are specially designed to be quiet, but no one bothers with a reverse
Vbe. Just amplify that with discreet transistors, resistors, and
capacitors until it's large enough to digitize through an A/D converter,
and feed that into a cheap PLD for whitening. Every part of the flow
along the way is auditable.
I've always wanted to design the entropy source directly into an IC, and
I'll still do that with my little project, but this conversation has
convinced me that what we really need for entropy is low tech discrete
solutions. Your accelerometer idea is fine, but I'd prefer the bit
rates I can get from zener noise.
--------------030407090400000207040809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/13/2013 4:26 PM, Arnold Reinhold
wrote:<br>
</div>
<blockquote cite="mid:7D72A130-61A0-4AE2-84C0-EDD687A5914B@me.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>
<div>On Dec 13, 2013, at 1:59 PM, Steve Weis <<a
moz-do-not-send="true" href="mailto:steveweis@gmail.com">steveweis@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">On Thu, Dec 12, 2013 at 3:44 AM, Arnold
Reinhold <<a moz-do-not-send="true"
href="mailto:agr@me.com">agr@me.com</a>> wrote:<br>
<blockquote type="cite">My problem with the Intel design is
that there is no way to audit it.<br>
...<br>
Here is an idea I have been playing with to provide a slow
but auditable<br>
source of entropy.<br>
...<br>
Both the accelerometer chips and the<br>
vibration motors are made in huge quantities and cost under
a dollar in<br>
quantity. They can be audited separately. The items could
be mounted on the<br>
mother board, daughter board or a USB dongle.<br>
</blockquote>
<br>
A few comments:<br>
1. You aren't trusting the CPU to generate random numbers, but
you're<br>
trusting the motherboard and chipset that your proposed RNG
device is<br>
plugged into. You're also ultimately still trusting the CPU
which is<br>
consuming those values.<br>
</blockquote>
<div><br>
</div>
The threat I am responding to is devices with no source of
randomness other than a RNG buried in the CPU, presenting a
single point of attack that is impossible to detect or prevent.
It is an emerging threat as hard drives, which served as a
dependable source of entropy, are phased out in favor of solid
state devices, and as the internet is increasingly used to
control infrastructure with diskless devices. <br>
</div>
</blockquote>
<br>
I like the idea of a completely auditable source of entropy, and the
accelerometer is clever. However, why not use zener noise like many
have done before? I've used the reverse breakdown of a base-emitter
in a common N2222 NPN transistor with excellent results - commercial
zeners are specially designed to be quiet, but no one bothers with a
reverse Vbe. Just amplify that with discreet transistors,
resistors, and capacitors until it's large enough to digitize
through an A/D converter, and feed that into a cheap PLD for
whitening. Every part of the flow along the way is auditable.<br>
<br>
I've always wanted to design the entropy source directly into an IC,
and I'll still do that with my little project, but this conversation
has convinced me that what we really need for entropy is low tech
discrete solutions. Your accelerometer idea is fine, but I'd prefer
the bit rates I can get from zener noise.<br>
</body>
</html>
--------------030407090400000207040809--
--===============8787539427849759145==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8787539427849759145==--
