[4588] in cryptography@c2.net mail archive
Re: Testing RNG devices
daemon@ATHENA.MIT.EDU (Brad Martin)
Mon May 3 12:53:42 1999
Date: Mon, 03 May 1999 10:19:48 -0500
From: Brad Martin <brad@nshore.com>
To: Nick Szabo <szabo@best.com>
Cc: cryptography@c2.net
This is a multi-part message in MIME format.
--------------04EDAB053FC84538BCD6B71F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Nick Szabo:
>
> (...) Statistical tests don't solve this problem (...)
Hmmm. I get your point, precisely.
I'd been using a spectrum analyzer to check the analog
front ends and numerical analysis to check the numerical
back ends - but I KNOW the circuit inside and out.
Once you've decided that everthing's O.K. with your RNG
vendor & product, verification is a different problem.
Since I'm a small entity, I wasn't assuming that any of
my buyers were going to "take my word for it", thus I
encouraged customer validation. That worked good, because
I didn't put any hardware in the box to look at the
numbers themselves.
> (1) publish the design specification.
>
> (2) design and distribute both software and hardware which
> verifies whether a particular device is operating according
> to that specification. This involves testing the physical
> characteristics and circuit design of the device, _not_
> the statistical characteristics of the data it generates.
>
Yes, yes, yes. The extent of (1) depends on satisfying
customer requirements for depth of specification and (2)
depends on everyone's ad-hoc approval of what's going on.
Thank you for your insightful comments. For those with
interest, I've provided text below, responsive to the
above comments, relating to my own box.
Brad Martin
NSCD LLP
TEXT FOLLOWS
Regarding (1) the design specification, it was an informal
design, the schematics & code are in the manual. Because of
the cost, I didn't develop a specification for the quality
of the numbers. I would be thrilled to do so, and then to
test the box to that specification, if there's a customer
who needs it enough to help pay for it. Even at that, I'll
still sell the present low-cost, low-test, low-spec version.
Regarding (2), I agree that test software would be a really
fine thing to ship with it, but I don't have any. If anyone
is motivated enough to help out with this, the things I
worry most about with this box are:
1) A bias of about one bit in 3,000 toward ones or zeros.
Depends on the parts I use and the voltage of the
different batteries. This is a worst-case number
as far as I can tell. I test each box to make sure
that the bias is less than one bit in 5,000 under
what I think is the worst case voltage scenario.
As far as I can tell, this bias is due to the
uncharacterized input switch point characteristics
of the CMOS inverters (CD4049) I use for squaring-up
the noise before it hits the uP.
2) Signal injection (RF & 60Hz EMF).
That's why the big steel box. You would not believe
how efficient batteries are as antenna. I have seen
NO problems with the circuit in the box, but I have
bad dreams about folks running this thing next to a
conduit with the cover off. User training would
prevent problems here.
I don't worry about RF from the digital stuff into the
analog any more. The digital stuff is on a separate
power supply and it's physically separated from the
analog hardware. I just don't see much spectrum in
the data any more.
3) Entropy. Always due to dead batteries (self-tested).
This is why we put the battery monitor circuits in
the box. The sample rate is so slow compared to the
bandwidth of the noise source that entropy is not
measureable as long as the batteries are O.K.
4) Hardware failure. This is why the online testing.
I've done my best, but the rated life of a solder
joint is 10 years. Parts? Anything can happen. Not
only that, if one of the power supplies fails
instantly (rather than graceful degredation) from
a solder joint faliure (battery holders are under
spring tension), the unit won't shut things down
until the end of the current 64K packet. This would
leave about a minute's worth of bad data in the
system.
It would be a good thing for a live data user to think
about holding a block of numbers in queue until
the following block of numbers is received.
- brad martin
EOF
--------------04EDAB053FC84538BCD6B71F
Content-Type: text/x-vcard; charset=us-ascii;
name="brad.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brad Martin
Content-Disposition: attachment;
filename="brad.vcf"
begin:vcard
n:Martin P.E.;Brad
x-mozilla-html:FALSE
org:North Shore Circuit Design L.L.P.
version:2.1
email;internet:brad@nshore.com
title:Managing Partner
tel;fax:(512) 448-1415
tel;work:(512) 448-1114 x111
adr;quoted-printable:;;3910 South IH-35=0D=0ASuite 255;Austin;TX;78704;USA
x-mozilla-cpt:;0
fn:Brad Martin P.E.
end:vcard
--------------04EDAB053FC84538BCD6B71F--
