Cryptography-Digest Digest #982, Volume #8 Wed, 27 Jan 99 16:13:02 EST
Contents:
Re: Random numbers from a sound card? (Medical Electronics Lab)
Re: My comments on Intel's Processor ID Number ("Roger Schlafly")
Re: Random numbers from a sound card? ([EMAIL PROTECTED])
Re: hardRandNumbGen (R. Knauer)
Re: hardRandNumbGen (Medical Electronics Lab)
Re: hardRandNumbGen (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
Re: Some simple questions on ECC implementation (Francois Grieu)
Re: My comments on Intel's Processor ID Number (chris)
The Challenge ([EMAIL PROTECTED])
Comments on Pentium-III ("Scott A. Berg")
Re: Random numbers from a sound card? (David Ross)
Re: hardRandNumbGen ("Trevor Jackson, III")
Re: hardRandNumbGen (Patrick Juola)
----------------------------------------------------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Random numbers from a sound card?
Date: Wed, 27 Jan 1999 12:02:38 -0600
Mok-Kong Shen wrote:
> I am not against having something ideal and perfect as a standard
> for approximation (to be strived at in practice) or for pedagogical
> purpose. But to say there IS (in the sence of EXISTS) something
> perfect can be misleading.
Kind of depends on how you define "perfect". Perfect for what and
measured in what way? We can certainly build a TRNG which is
perfect in any measureable sense.
> To 'just look' is certainly not ensuring (compare watching a
> magician pulling rabits out of his hat). We have to ascertain
> how 'random' the sequence we get really is. And that's one of
> the real and big problem for the practice.
Which is what makes this whole discussion so much fun. DIEHARD
and Diaphony and autocorrelation all measure "random" in a slightly
different way. If the output of a TRNG appears random to all those
tests, we can say it "looks" random. It is "perfect" as far
as we can measure. Isn't that good enough?
Patience, persistence, truth,
Dr. mike
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: My comments on Intel's Processor ID Number
Date: Wed, 27 Jan 1999 10:42:06 -0800
Trevor Jackson, III wrote in message <[EMAIL PROTECTED]>...
>There are two interpretations of the phrase "used for ID". One is proof
>of ID and the other is uniqueness of ID. He is using the former in the
>sense of authentication. You are using the latter in the sense of
>labeling.
The SSN is used for authentication all the time. Eg, UC Santa Cruz
uses the SSN as the student ID, and students frequently authenticate
themselves by giving a SSN. Likewise banks, brokers, etc
frequently use SSN for that purpose.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Random numbers from a sound card?
Date: Wed, 27 Jan 1999 18:31:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Tue, 26 Jan 1999 22:20:11 GMT, [EMAIL PROTECTED] (Paul Rubin) wrote:
>
> >Run the audio bits through a cryptographic
> >hash function or something similar before using it.
>
> Any recommendations on which hash function or something similar?
>
> Bob Knauer
You'll be told to use an established one, say MD5. Doesn't matter
too much.
But what you *must* be careful with is this:
A sample output of MD5 will look random -that's its job :-)
It will appear to have full entropy.
In order to know how many bits you have to distill with MD5,
or any other hash, you need to measure your entropy/raw bit.
Then you can convince skeptics that you are driving the hash
with enough entropy.
If your hash function is *not* a crypto-strong one, then
you can directly measure the quality of its output ---since its not
crypto strong, by definition its output (when given
very redundant input) will be crappy. Parity-of-N
has this property. When N is large enough, for a given
raw-entropy-rate, the parity output is indistinguishable from
crypto-strong (ie, uniformly distributed) output. When N
is insufficient, you can see it with an entropy measure.
=====
"Many tame, conformist types felt the need to describe anti-social actions as
'sick'." -Ted K
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 18:44:52 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 27 Jan 1999 12:13:29 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>R. Knauer wrote:
Could I ask you to keep the header information with my attribution,
just like you did for the nested poster below. Thanks.
>> On 27 Jan 1999 10:21:56 -0500, [EMAIL PROTECTED] (Patrick Juola)
>> wrote:
>> >On the other hand, if I can get a copy of your code, I can just read
>> >the code and determine your biases. But you can't rely on keeping
>> >your code secret....
>> I can rely on keeping it just as secret as I keep my keys. If my code
>> has been compromised, so have my keys.
>Hardly. One can change keys arbitrarily. Once cannot change code so often
>(here code == algorithm not .EXE).
How about making your algorithm (code) part of the key? That way you
could change algorithms as often as you change keys.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 12:31:11 -0600
Mok-Kong Shen wrote:
>
> If you make a metal sphere, there is a common definition of precision.
> What is the 'precision' you are referring to about your TRNG design?
> You have to define that 'precision' in scientific terms, in particular
> establish a 'unit' and provide a precise method to measure that
> 'precision' in that unit. Before that, you have nothing.
Usually it's chi-square and KS-tests which output a probability
parameter (usually called "p"). Precision of more than 3 digits
isn't really necessary, either the p value is within a reasonable
range (+/- 1.5 sigma from some mean) or it isn't. testing multiple
blocks of data of the same length will give different p's (or you
know something's crooked!) but they should all be with in the
correct range.
The "unit" is expectation value. Precision isn't a good term,
what you want is "uniformity". A TRNG should have expectation
values for *all* imaginable tests, i.e. it should be uniformly
random no matter how you look at it. While not easy to do, it
is possible with careful attention to details.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 18:02:02 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 27 Jan 1999 18:01:00 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Please note I don't claim PRNGs are good. I simply doubt that
>hardward generators are good because I have no tools to determine
>that they are good, except by using statistical tools.
You must be skilled at designing a TRNG. Statistical tools are
worthless.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Wed, 27 Jan 1999 18:10:02 GMT
Reply-To: [EMAIL PROTECTED]
On 27 Jan 1999 12:01:50 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>>Secondly, your equiprobability is not at all sufficient.
>>I never said it was. I said that the TRNG must be *CAPABLE* of:
>>1) Outputting all possible sequences of a given finite length; and
>>2) Outputting each of them equiprobably.
>>>If the said given finite length is 2, is a physical device outputting
>>>0001101100011011..... a TRNG?????
>>Sure, why not - if you group the number above in 2-bit sequences:
>>
>>00 01 10 11 00 01 10 11
>>
>>Pad1: 00
>>Pad2: 01
>>Pad3:10
>>....
>>Pad8: 11
>
>
>Minor quantification error :
>
>Mr. Knauer's criterion should not be interpreted as:
>
>There exists a length such that all possible sequences of that
>length are outputted equiprobably,
>
>but as :
>
>For all (finite) lengths, all possible sequences of that length are
>outputted equiprobable.
>
>So if that's really the output of your generator, it's *NOT* a TRNG
>as it's a single 8-bit sequence repeated with probability 1.
I assumed the poster had generated the 16 bit sequence above using a
TRNG, like a fair coin toss. I then assumed that he wanted to use it
to make a pad. Then he says something about a length of 2, which I
assumed he meant as message lengths - that he planned to send 8
messages of 2 bits in length.
Given all those assumptions, I see no problem with using the sequence
above as for an OTP - unless I am missing something.
Bob Knauer
"No Freeman shall ever be debarred the use of arms. The strongest
reason for the people to retain the right to keep and bear arms is,
as a last resort, to protect themselves against tyranny in government."
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED] (Francois Grieu)
Subject: Re: Some simple questions on ECC implementation
Date: Wed, 27 Jan 1999 18:52:27 +0100
someone said:
> recently there has been an announcement about a new book:
the title is : Implementing Elliptic Curve Cryptography
Michael Rosing
see <http://www.manning.com/Rosing/>
Another usefull source of info is the P1363 mailing list
For info send a message with title "help" to:
<mailto:[EMAIL PROTECTED]>
Francois Grieu
------------------------------
From: [EMAIL PROTECTED] (chris)
Subject: Re: My comments on Intel's Processor ID Number
Date: Wed, 27 Jan 1999 20:37:51 GMT
On Wed, 27 Jan 1999 10:55:11 -0600, "Michael A. Greenly"
<[EMAIL PROTECTED]> wrote:
>The processor ID may not have any practical cryptographic value but it
>can still be useful. For example in software development it could be
>used to produce GUID's for use with COM/OLE etc... In this case the
>primary concern is to produce a unique number which no one will
>duplicate on accident.
>I suspect that there are many other situations where it would be a
>practical means to prevent accidental collisions.
>
yes. i, for one, would love to have such a number. right now,
programmers looking for such unique items on a PC must do crazy things
like trying to grab the serial # from a HDD, network card ID , Windows
regsitered-to name, etc.. a per-processor ID would be a great help.
i can't see why people worry about this stealing their privacy
while they are perfectly happy giving out phone #s and VISA #s on the
LL Bean or Amazon websites.
------------------------------
From: [EMAIL PROTECTED]
Subject: The Challenge
Date: Wed, 27 Jan 1999 20:06:12 GMT
Welcome All Programmers / Hardcoders to the "The Millenium Challenge!!!"
Test your analytical skills an informal, yet an exciting way!
What you need to do: 1. request me for an encrypted ASCII-character sequence
2. Manipulate these characters' ASCII values in such a way that it turns out
to be a short meaningful story (i.e. you need to decrypt this story).
That's it! and you know your skills very well!!!
interested?... then just fire an email, requesting me for this encrypted
story.
Go(o)d Luck!
[EMAIL PROTECTED]
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Scott A. Berg" <[EMAIL PROTECTED]>
Subject: Comments on Pentium-III
Date: Wed, 27 Jan 1999 13:50:48 -0600
I've read the many threads and have a few comments. Please add your own.
First, the processor serial number and the random number generator are two
separate and independent features. I have read several garbled press
reports about how the serial number itself is a random number. Of what use
would randomness be here?
Second, embedding a serial number in the processor has some advantages over
a dongle, but it depends on the application. The dongle offers portability
to many machines while the embedded number does not. If you want to
restrict access to truly sensitive information, allow it only from a machine
chained down to a desk in an office with a guard at the door. With a dongle
you could: 1) steal the dongle, 2) leave behind cache files filled with
sensitive information, 3) call from an unsecured phone line, etc., all of
which compromise security. I don't see one as a replacement for the other
but rather complementary solutions depending on what you are guarding
against.
Third, Intel has promised to not keep a database matching serial numbers to
individuals. If true, it sort of weakens their argument about theft
protection. After all, how could they start the chain of custody of a
processor if they don't know which PC vendor they sold it to? Besides,
someone down the line (Dell, Compaq, etc.) could keep their own database
and, in fact, are more likely to know the identity of the person using that
machine.
Finally, another capability of the P-III is a user accessible EEPROM. That
could be used to burn in identifying information, including machine serial
numbers to tie a software package to a specific machine.
Scott
------------------------------
From: [EMAIL PROTECTED] (David Ross)
Subject: Re: Random numbers from a sound card?
Date: Wed, 27 Jan 1999 20:47:32 GMT
On Wed, 27 Jan 1999 18:18:17 GMT, [EMAIL PROTECTED] wrote:
>In article <[EMAIL PROTECTED]
>[EMAIL PROTECTED] (David Ross) wrote:
> What sort of audio source would you suspect would be the best to use
>in generating random numbers?
>
>>> I tune a cheap AM radio to a loud static channel, and wire that into the
>>> mic port.
>
>>FM has better hiss. I leave it to RF folks to explain why. Probably
>>because FM listens to wider chunks of the aether than AM. Or because
>>of the design of FM receivers amplifying component-noise more?
I see this 'better hiss' quality too, and suspect that it is due to
the FM detection scheme.
In my case, the FM limiter & detector puts out a waveshape which is
more linear in the voltage range where I'm digitizing. This yields a
flatter distribution of A->D output bytes but is a bit slower.
David Ross [EMAIL PROTECTED]
------------------------------
Date: Wed, 27 Jan 1999 16:00:55 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
R. Knauer wrote:
> On Wed, 27 Jan 1999 12:10:17 -0500, "Trevor Jackson, III"
> <[EMAIL PROTECTED]> wrote:
>
> >To boil all this verbiage down, analysis of the generation process is more
> >efficient than analysis of the generator output. One reason for the
> >improved efficiency is that understanding the generation process provides
> >hints of the potential defects worth testing. Another reason is that the
> >description of the generation process is logarithmicaly smaller than the
> >description of the generated output.
>
> Algorithmic analysis of the generated output itself is completely
> worthless if that output is finite in length. If the number 111...1 is
> generated by a TRNG, then it is a perfectly valid crypto-grade random
> number, just like all the other 2^N-1 numbers of the same length.
False. Analysis of output is insufficient to prove the entropy density is
100%, but it can easily provide useful information. For instance, a page of
business text is around 2^16 bits (of data, not information). If we divide up
the (?)RNG output into samples of this size we can establish a confidence that
the samples are statistically random. If the samples are not statistically
random, we can, with statistical confidence, eliminate that RNG as appropriate
for key generation. If the samples are statistically random we have not proved
that they are appropriate for key generation, but we have shown, to the limit
of our testing capability, the absence of predictability. If the limit of our
testing capability is equal or greater than the capabilities of our
adversaries, then the samples are adequate key material.
Note that the last statement does NOT mean that future samples may be
adequate. The pattern established by the samples inspected might begin
repeating on the very next bit generated. It DOES say that, withint the bounds
of analytic capability, one can inspect keys for effectiveness.
The evaluation of the limits of statistical testing is probably tougher than I
can address because I am insufficiently versed in fundamental statistical
theory. But it's an interesting operational question...
>
>
> Since all of these 2^N sequences of length N are random numbers, what
> analysis of them is going to tell you that they are or are not random?
> If you apply your analysis to each of the 2^N numbers, then you must
> get the same result for each one since they are generated by a TRNG,
> otherwise your analysis is fatally flawed.
>
> If your analysis does give the same result for each number, what value
> is it in determining randomness or non-randomness? If it correctly
> gives the same result for each number, there is no discrimination
> being performed. In fact, the analysis needs to say: "I cannot decide
> if that number is random or not", for each number, or it is wrong.
>
> If you could prove algorithmically that a given finite sequence is
> truly random, then you could also solve both the Godel incompleteness
> problem and the Turing halting problem - which are related.
>
> See Chaitin (op. cit.) for the details why.
Prove? No.
Express confidence in? Certainly.
Arbitrarily high confidence? Yes, given adequate sample size.
Higher confidence than is proper for the other components of the security
system? Almost always.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: hardRandNumbGen
Date: 27 Jan 1999 15:06:39 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>>Having only reasonably-sized
>>amounts of funding, computing power, and patience at my disposal,
>>there's a limit to what can be detected -- and if I get something
>>that's indistinguishable from random by this test, then I'm probably
>>willing to pass it as a "good" RNG.
>
>I assumed that you had all the existing resources at your disposal
>that you wanted - like the NSA has.
Um... the NSA does *NOT* have infinite resources. Far from it.
The GNP of the United States is only measured in the trillions,
so any hardware costing more than a quadrillion dollars or so is
probably out of reach.
That's the problem with infinite. It's *BIG*. Of a scale that
dwarfs anything we can possibly imagine. From the standpoint of
"perfect secrecy", a block cypher with a 10,000 bit key is exactly
as a strong as a Captain Midnight secret decoder ring -- i.e., not
perfect and hence infinitely less strong. God has no more difficulty
reading message that the NSA would pound against for a billion years
than he has reading something rot13ed.
For us mortals, the NSAs capacities are huge. It's easy to hide
something from the NSA....
>>a complexity curve looking
>>something like this :
>>
>> _/
>> _/
>> _/
>> _/
>> _/
>> _/
>>/
>
>What is a "complexity curve" and how do you generate one?
x axis == length of string in bits, y axis == linear complexity of
the prefix of the (infinite) string of such length. I think
there's a brief discussion in the RSA Labs Stream Ciphers tech
report -- if not, check the various complexity-related citations
contained therein. RSA Labs is on the Web somewhere, as is the
TR.
>>The problem is that the Bayesian attack only works if I know -- or
>>can guess -- the type of bias likely to be in your generator.
>
>So, the Bayesian attack is not all that powerful against stream
>ciphers *in general*.
If all you know is that someone used "a stream cypher", then, no,
they're not useful. But usually you know more than that. Or unless
you guess lucky, which is half the skill in cryptography.
-kitten
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
