Cryptography-Digest Digest #991, Volume #8 Thu, 28 Jan 99 19:13:03 EST
Contents:
Re: Who will win in AES contest ?? ("Trevor Jackson, III")
Re: Who will win in AES contest ?? (Andrew Carol)
Re: Who will win in AES contest ?? (wtshaw)
Re: Who will win in AES contest ?? (Bauerda)
Re: My comments on Intel's Processor ID Number ("Trevor Jackson, III")
Re: My comments on Intel's Processor ID Number ("Trevor Jackson, III")
Re: Who will win in AES contest ?? (Robert Harley)
Re: Pentium III... ([EMAIL PROTECTED])
Re: Random numbers from a sound card? (R. Knauer)
Re: hardRandNumbGen (R. Knauer)
Re: Metaphysics Of Randomness (R. Knauer)
Re: RNG Product Feature Poll (Terry Ritter)
RNG bias considered harmful: NOT! ("Trevor Jackson, III")
Re: Comments on Pentium-III ("Trevor Jackson, III")
----------------------------------------------------------------------------
Date: Thu, 28 Jan 1999 17:28:11 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Who will win in AES contest ??
Fabrice Noilhan wrote:
> According to Brian Gladman <[EMAIL PROTECTED]>:
> > It would be useful to know whether you are saying that having three winners
> > would be a disaster or whether you are saying that having three winners
> > using these criteria would be a disaster
>
> The main goal of the AES is to have a standard. This means that you're
> looking for an encryption algorithm which will work on various platforms
> so that they can send and receive encrypted datas. Thus, having three
> winners would be a Bad Idea (tm); one will be able to use whatever
> algorithm he likes but there must be a standard... and only one.
>
> Fabrice
This rationale apears to me to be excessively simplistic. There is no reason
that smaret cards have to use the same encryption system as the hotline. In some
situations it might be convenient to have the same ciper used in separate parts
of a system, but different levels in a system could easily have distinct cipher
systems. E.g., link encryption versus end-to-end encryption.
------------------------------
From: [EMAIL PROTECTED] (Andrew Carol)
Subject: Re: Who will win in AES contest ??
Date: Thu, 28 Jan 1999 13:56:37 -0800
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Hironobu Suzuki) wrote:
>I think it's very difficult to compare between serpent and twofish
>because serpent has more rounds than twofish. It means serpent is
>stronger than twofish.
Simply comparing rounds is poor way to compare the strengths of a cipher.
Oh well....
--
Andrew Carol [EMAIL PROTECTED]
(Remove the spam avoiding 'X' from my e-mail address)
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Who will win in AES contest ??
Date: Thu, 28 Jan 1999 15:45:46 -0600
In article <78q3k2$nir$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Patrick Juola) wrote:
> In article <78pium$e1i$[EMAIL PROTECTED]>,
> Fabrice Noilhan <[EMAIL PROTECTED]> wrote:
> >
> >The main goal of the AES is to have a standard. This means that you're
> >looking for an encryption algorithm which will work on various platforms
> >so that they can send and receive encrypted datas. Thus, having three
> >winners would be a Bad Idea (tm); one will be able to use whatever
> >algorithm he likes but there must be a standard... and only one.
>
> I disagree. One standard means one basketful of eggs. This spells
> disaster somewhere down the road.
It would be good to forego trying to get beyond the weeding out process
currently under way. If one cipher is a winner, it will be obvious which
ones are close runners up. I suggest that they will also be widely used.
Imagine two or three standards and the temptation to chain the different
ciphers together, which might not be too bright depending on possible
interaction between them. That alone is another problem that would have
to be studied.
The disparity between formal goals of the project and traditional goals of
some areas of our government is alive and intact, which will make for some
good entertainment the sooner that the raw beef hits the butcher block.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
From: [EMAIL PROTECTED] (Bauerda)
Subject: Re: Who will win in AES contest ??
Date: 28 Jan 1999 22:40:46 GMT
>Do you want to say which of the entries the USA NSA can break? Have you any
>evidence (or is this just your opinion)?
For what type of attack? I bet they couldn't break Magenta, if I they had to
do a ciphertext only attack on a very short message. If they can break Loki
with a chosen key, chosen plaintext attack, but I don't allow them to chose the
key or the plaintext, does it count? If they can break Scott19u with an attack
requiring only 2^300 know-plaintexts (which is allowable because of the block
size...), does it count?
David Bauer
------------------------------
Date: Thu, 28 Jan 1999 17:43:51 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: My comments on Intel's Processor ID Number
Roger Schlafly wrote:
> Trevor Jackson, III wrote in message <[EMAIL PROTECTED]>...
> >The value of the SSN in these situations is that it crosses all
> >organizational boundaries. I.e., the bank can contact a credit agency, an
> >employer can contact the IRS, etc. It is the universality of the SSN that
> is
> >valued here, not the proof of identity. (Except in the weak case that by
> >knowing the relationship between name, address, phone, DOB, and SSN one
> shows
> >consistency and that is adequate "proof")
>
> You may regard SSN as a weak proof of identity, but it is in fact used
> as proof of identity all the time in the U.S.
It is in fact used as a unique identifier all the time in the United States.
It is never used for proof of identiy in the United States because I can recite
your 9-digit number as well as you can.
------------------------------
Date: Thu, 28 Jan 1999 17:46:26 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: My comments on Intel's Processor ID Number
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> > Roger Schlafly wrote:
> >
> > > Bruce Schneier wrote in message <[EMAIL PROTECTED]>...
> > > >I wrote a column on Intel's Processor ID number for ZDNet. You can
> > > >read it at:
> > > >
> > > >http://www.zdnet.com/zdnn/stories/comment/0,5859,2194863,00.html
> > >
> > > Your analogy is to a national ID number which is on a card that no
> > > one examines. Hence it is useless for identification, you argue.
> > >
> > > But that is almost precisely what we have. I have a Social Security
> > > number, but I have never shown my card to anyone because I lost
> > > it long ago. And yet my SSN is still used for identification.
> >
> > 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.
> >
> >
>
> My social securtiy fits more in line with the way the government
> really does things. THEY FUCKING LIE.
> on the bottom of my card it says
> "FOR SOCIAL SECURITY AND TAX PURPOSES-NOT FOR IDENTIFICATION"
> I like to point this out and show the card when I get asked
> in person to use my ID I argue in vain that it is illegal to
> use it for identification which was the real main purpose for
> its intorduction and if your younger than me the new id cards
> do not have this caption on the bottom.
If you feel this strongly about your SSN you should revoke it. There's a
procedure to do so (although the SSA will try hard to discourage you).
There's also a procedure for notifying employers that you do not agree to FICA
witholding. Use it.
[Apologies to the NG for off-topic issues]
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: Who will win in AES contest ??
Date: 28 Jan 1999 23:06:00 +0100
"Sam Simpson" <[EMAIL PROTECTED]> writes:
> Found your message entertaining (and much agrees with my thoughts about the
> current stage of AES...). One small comment;
Ah, so there is hope yet!
Actually, several people have expressed hearty agreement in email.
>>None are perfect. But one comes with proof. The others don't.
>
>There is a "proof" of DFC's security?
There are proofs (no quotes are necessary) of DFC's security against
various classes of attacks.
Consider differential attacks. These are pretty serious and several
codes which otherwise appear secure can be broken by them.
Of course most AES teams have taken them into account and can say "we
think our code is resistant". The DFC team doesn't say "we think".
It says "Our code is resistant. Here's the proof. End of story.
That's that. Any questions?"
The same holds for linear attacks.
The same holds for some iterated attacks.
Does this not strike anybody else as fundamentally different, better
and phenomenally useful?
A little-known fact about the decorrelation method is that it could be
used with other AES candidates. Essentially you start by designing an
algorithm with heuristic security, doing your best and ending up with
something like Mars or RC6. Then in a perfectly modular fashion, you
append a pass that guarantees, with proof, all sorts of security that
was previously relegated to conjecture (at best)!
If some algorithm other than DFC wins the AES process, then surely we
would want to apply this strengthening to make it even better than it
already was.
How could anyone not want this?
The thing is, the resulting algorithm would look to a large extent
just like DFC!
The only counter-argument that has been mustered against this that the
decorrelation module takes time and slows the code down somewhat.
If we take as granted that we want the security that the latest and
greatest research can give us, then how fast can we go? Probably not
a whole lot faster than DFC, but maybe a bit. This might be a
fruitful avenue of research.
However the criticism on grounds of speed is a red herring as is
becoming clearer by the day.
Several other candidates are significantly faster than DFC on Pentium Pro
and similar chips. That is a fact and DFC is not about to become the
fastest there. So should we hastily rule it out as being too slow?
DFC was not particularly fast on Alpha initially. Its designers are
in some ivory tower, talking amongst themselves about beautiful,
powerful theory and barely even pausing to program their ideas
properly.
Today DFC is the fastest candidate on several chips including Alpha
and is the fastest in absolute terms. On my own two-year-old machine
it chomps through 200 Mbps. No other AES candidate comes close with
currently available implementations. So should we hastily rule out
the others as being too slow? ;-)
NO! We should all do more implementations, taking advantage of
whatever coding tricks are necessary to go as fast as possible, before
making any definitive judgement based on speed.
I posted my previous message a few evenings ago, optimistically
suggesting that the implementation of DFC on Pentium Pro might be sped
up by 20 or even 200 cycles. The next morning when I arrived at work
my mailbox contained an implementation by a young Polish programmer,
Dominik Behr, saying "I think this should be 200 cycles faster but I
don't have a Pentium Pro to test it". Lo and behold, testing revealed
it to be... 200 cycles faster.
It would be a reasonable consensus to agree that a given candidate
algorithm is reasonably fast on a given chip if it is within a factor
of two of the fastest of all candidates on that chip. Several people
have now sent implementations of DFC on Pentium Pro, the fastest of
which is just outside the factor of two on Pentium Pro. Two
programmers have said, in essence, "we can knock off many more cycles,
just give us a few days".
So it is reasonable to expect that soon the only real criticism of DFC
will have fallen by the way-side. That's when I expect to start
seeing F.U.D. claiming that DFC is "just too damn good to be true"
and that "there must be a catch somewhere".
And I'll answer:
OK, so what's the catch?
SHOW ME!
But that's another post for another day.
Rob.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Pentium III...
Date: Thu, 28 Jan 1999 22:45:03 GMT
In article <[EMAIL PROTECTED]>,
Bruce Barnett <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] writes:
>
> > I can think of cases where having a machine serial number would be somewhat
> > handy. I'm not sure I would build it into the processor though.
>
> And what do you do with a 2,4,8 or 64-CPU server?
> It's the big servers that need it.
> Dynamic roll-over should be interesting...
I don't see any difference between 1 or 64 processors, big servers or handheld
devices. Pretty much every applications I can think of (except mabey reducing
CPU theft) would want a unique identity (serial number) for each system. A
system might even be a cluster. My preference would be to have that system
identity survive cpu and hardware upgrades/changes.
- Jan
============= 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: Random numbers from a sound card?
Date: Thu, 28 Jan 1999 23:07:11 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 28 Jan 1999 12:47:39 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>It's pretty clear we have different opinions. The best I can
>hope for is more descriptions so I can find out what the core
>assumption is that we disagree on. Neither one of us will change
You will change once you catch on. I did.
A year ago I came onto sci.crypt with ill-formed notions of
crypto-grade randomness. After what seemed like a thousand posts from
many participants, the truth emerged.
I have capsulized that truth several times recently but some people,
including you, still have not caught on. When you do catch on, you
will look back and wonder how you could have been so confused about
such a straightforward concept. I did.
>So you need an infinite sequence of bits to prove that something
>is crypto-grade random, yes?
You cannot prove the crypto-grade randomness of a finite number
algorithmically. You can for an infinite number, but that is useless.
The only way you can prove the crypto-grade randomness of a finite
number is to consider the method of generation. If the generator is a
TRNG, as we have defined it here several times recently, then the
numbers it generates are crypto-grade random numbers.
>Is a 10 megabyte block of random bits a single number?
Yes.
>Or is it 80 million individual numbers?
Yes.
>For the latter case, it looks
>random if it can pass all the tests for randomness that
>mathematicians have dreamed up.
Wrong. You might be able to infer some things about the numbers that
fool you into thinking they are random, but that does not make them
crypto-random.
Keep in mind that many PRNGs pass statistical tests.
>In the former case, if it isn't
>printable ascii, then it will probably look random no matter
>what.
Numbers don't "look" crypto-random.
The number 1111111111 is a crypto-grade random number, because it was
generated by a TRNG. Or, may it is not because it was not generated by
a TRNG. You cannot tell unless you know the generation process.
Tell me if you think 111111111 is crypto-grade random or not.
>> Why do you thing that characteristics that apply only to infinite
>> numbers can also apply to finite ones with equal certitude?
>What characteristics are you talking about?
The characteristic of randomness. Infinite numbers have
characteristics which can be related to randomness. If an infinite
number is a normal number, it is random. Finite numbers cannot be
normal numbers - they are not big enough.
For example, if you can prove that pi is a normal number, then it is a
random number.
>Integrals over a
>finite range and binomial or poisson distributions are all based
>on finite samples.
Do they measure crypto-grade randomness of finite numbers?
If they could, these algorithms you propose could also be used to
solve Godel's incompleteness problem, Turing's halting problem and
Chaitin's complexity problem.
>All the DIEHARD tests are based on finite
>samples. I am assuming that Marsaglia knows what he's doing,
>but maybe you can correct him?
You correct him, when you discover the truth.
>> What does "vanishingly small" mean to you?
>Less than I can measure.
Explain your method of measurement.
>Yes, well, expand on "crypto-grade" a bit.
Proveably secure when used with the OTP cryptosystem.
>:-) See, I told you we disagree. Let's keep it that way,
>makes for a nice long discussion.
Last time it was over 1,000 posts. I am beginning to think I was the
only one who got anything out of them.
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: Thu, 28 Jan 1999 23:18:56 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 28 Jan 1999 16:38:22 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>> Statistical tests are useless if applied to finite random numbers
>> generated by a TRNG.
>Are you going to REWITE the whole scientific theory of probability
>and statistics?????
I give up. Believe what you want.
You are beyond redemption.
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: Metaphysics Of Randomness
Date: Thu, 28 Jan 1999 23:17:36 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 28 Jan 1999 12:30:10 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>A laboratory is notorious for having equipment fail overnight.
Yes, that is why it needs to be watched by a standards committee.
>I see that every day.
Lucky you. :-)
>I still claim the average joe user won't
>have the equipment or the understanding to do the calibration.
The average joe has no business in crypto.
>All they have is the stats, so from a *practical* point of view,
>the stats are highly useful.
Yeah - and highly wrong.
But if that is good enough for Ol' Average Joe, then who cares. A
sucker is born every minute.
>> No! The only thing that tells you a TRNG is not working is its
>> internal diagnostics.
>I disagree. I can look at the scope and see a valid signal that
>"looks random".
How does something "look" random? Remember that the output of many
PRNGs "looks" random.
>When I use some algorithm to convert the voltage
>to bits, the internal diagnostics will tell me everything is OK,
>but the stats may tell me I've got a bias of .001% more 1's than
>0's and the OPSO test is failing 20% of the time. The stats tell
>me more than the diagnostics at that point.
The stats do not prove that you have crypto-grade random numbers. if
you are willing to drink snake oil, be prepared for a belly ache.
>The stats *are* a diagnostic, and a much better one than the
>hardware specs.
The stats are worthless in terms of characterizing the crypto-grade
randomness of a number. Remember that the output of many PRNGs
"looks" random.
>:-) Then every random number generator ever built in hardware is a
>TRNG?
I never said that at all.
>But the TRNG might be biased by 80% 1's to 0's. It's still random,
>it's still a TRNG, and it's quite useless.
If it is a TRNG, it generates crypto-grade random numbers which are
suitable for the porveably secure OTP system.
>I don't know what "random" is (let alone what "is" is :-)
I do - in terms of crypto-grade randomness.
>but I
>respect the mathematicians in the practice of computing statistics.
There are different kinds of randomness depending on the field of
study. Chaitin's randomness is not the same as crypto-grade
randomness. Statistical randomness is not the same as crypto-grade
randomness.
>If the math says it looks random, then it's close enough.
But, what kind of randomness does the math say it is? If the math is
incapable of saying that it is crypto-grade randomness, then it isn't
anywhere close enough for crypto.
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] (Terry Ritter)
Subject: Re: RNG Product Feature Poll
Date: Thu, 28 Jan 1999 19:07:30 GMT
On Thu, 28 Jan 1999 11:09:22 -0600, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Dan S. Camper) wrote:
>All:
>
>My company is developing a hardware random number generator, based on
>radioactive decay, which will be a component of a larger turnkey (server)
>product. The device is an external peripheral with a serial connection to
>the CPU and back-end serial connections that allow you daisy-chain these
>RNG devices to provide higher throughput.
>
>The device currently works. It's output is a measly 3K per second, but
>the raw data passes Diehard and every other test we've thrown at it. Of
>course, that doesn't prove that the output is random, but at least we know
>it passes those tests. ;)
My guess would be that the device itself produces independent unbiased
bits which are then simply collected into 32-bit values for Diehard
testing. Sensing randomness as single-bit results is probably why the
data rate is low. That is not necessarily bad.
But if any problems do exist, they will be bit-level problems. And it
would seem to be difficult to pick up bit-level problems when we
collect bits into 32-bit values with numeric interpretations.
>We are considering the addition of a hash algorithm to the setup. There
>have been messages posted to this newsgroup in the past regarding hashing
>hardware RNG outputs, but I haven't been able to discern a consensus on
>whether or not an additional hash is a Good Thing.
A hash takes arbitrarily large input to a fixed-size output. This can
buy several things:
1) It can collect "entropy" over time.
2) With sufficient "entropy," it can produce an even or flat
distribution.
But bit-level RNG devices may not need these things if the bit results
are almost unbiased. Bit-level correlations are to some extent
inherently confused by collecting bits into larger values. And if we
use enough bits we can afford some amout of imperfection.
>Basically, we're considering the following options:
>
>1) Don't add a hash. (This is the easy one!)
>
>2) Add a hash routine to the firmware within the RNG.
> a) It's always enabled.
> b) Enabled with a push button on the device.
>
>3) Add a hash routine in the software on the server.
> a) It's always enabled.
> b) Optionally enabled via admin interface.
>
>Addendum: If we include a hash in the firmware, which hash algorithm will
>be used? If we implement a hash in software, we can offer multiple
>algorithms for the administrator to choose from. We are considering both
>MD5 and SHA-1. We have also talked about a plug-in type architecture, and
>publishing the API for it, so savvy administrators and design their own
>hash algorithms.
I suppose that since the application is "cryptography," everyone
assumes that any hash, if used, must be a "cryptographic hash." This
is false, although it can be dangerous for a producer to instruct
their customers on reality.
The main technical advantage of a cryptographic hash is that it breaks
up the pattern of transformations between input and output values.
This means that it should be very difficult to find two different
inputs which hash to the same result. But this is not the property
which is used for collecting entropy and flattening the distribution.
In contrast, a linear CRC hash is fast and simple, and has a complete
mathematical basis for doing what we want. Fast CRC implementations
are table-driven and "fast" because they operate on multiple bits at
once, typically bytes. Any good polynomial will do.
The argument is sometimes made that a cryptographic hash will protect
weakness in the original sequence. But a hash is not a cipher: Any
hash has more input than output, so the transformation is not
reversible for any hash, if we have enough input.
It is always possible to actually encrypt the random values if we
can't stand even the thought of weakness.
There is also a systems-level tradeoff between using "perfect" random
values of exactly the size we need, versus using larger random values
of somewhat less quality.
>The purpose of this post is to solicit opinions and commentary and,
>hopefully, allow me to gain some kind of consensus regarding the various
>options. Of course, we could be barking up the wrong tree, too. It would
>even be helpful to realize _that_.
In randomness-sensing machines, there is often a conflict between data
rate and "entropy." If one is going to go all-out for perfection at
the expense of data rate, it would seem a shame to hash it down like
we must with a more ordinary sequence. But there should be no harm in
hashing even if not needed.
On the other hand, allowing an arbitrary hash plug-in may be allowing
a faulty hash implementation to damage your hard-won and costly
sequence, with you taking the blame.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Date: Thu, 28 Jan 1999 18:27:00 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: RNG bias considered harmful: NOT!
Medical Electronics Lab wrote:
> But the TRNG might be biased by 80% 1's to 0's. It's still random,
> it's still a TRNG, and it's quite useless.
I disagree with this statement. A biased RNG is an imperfect one, but if it
contain entropy (does not repeat) it has some use and thus value.
Any good RNG design is going to assume as a matter of principle that there
is some bias in the raw data. By processing the raw data we can distill out
the entropy, reducing the volume of data, and produce useful RNG output.
Consider the entropy density of the raw data. We do not have to insist on
100% density. If, as you suggest, the ratio is 1:4 ones to zeros but
otherwise unpredictable, we can filter out the excess zeros. Taking the
bits pair-wise, we discard those pairs with zero parity, and encode pairs
with odd parity according to the leading bit. This process would reduce
the volume by a factor of about 3 (25/8 actually) while raising the entropy
density by a like factor.
------------------------------
Date: Thu, 28 Jan 1999 18:40:07 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Comments on Pentium-III
fungus wrote:
> Bob Manson wrote:
> >
> > This type of copy protection will create certain problems for
> > legitimate users. The obvious one is that if a user has to replace a
> > CPU because it fails
>
> ...licensee must give 7 (seven) days notice of CPU failure for
> transfer clause to be valid.
>
> > It's true that a similar scheme is used on some Unix workstations.
>
> Yes...but this software is usually very low volume and high priced.
> Transferring licenses doesn't cause a lot of administrative overhead.
>
> For a mass market product this overhead would become significant.
>
> > In fact, I claim that the Pentium RNG will become more of a hindrance
> > than a help, because its pretty likely that it has one or more flaws
> > that will cause its output to be predictable in some cases.
>
> I'd give Intel a bit more credit than this. As people have pointed
> out, designing a hardware random number generator isn't all that
> difficult, and Intel has some of the best brains in the world.
Gee, is that why they produce some of the worst CPUs in the world? Who'd
'a thought???
> > If it really becomes the sole
> > RNG of choice, that means that the majority of applications that rely
> > on random numbers as part of their crypto system will eventually be
> > compromised.
>
> If the chip uses some sort of noisy diode, then each chip might
> even have its own individual biases. This could even vary depending
> on whether or not you had the air conditioning switched on that
> day, solar flares, the phase of the moon, etc.
>
> You might compromise one chip's output (unlikely), but breaking the
> world's communications net will be harder.
Are you willing to put odds on that unlikelyness?
------------------------------
** 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
******************************
