Cryptography-Digest Digest #202, Volume #9 Mon, 8 Mar 99 15:13:04 EST
Contents:
RC5 and RC6 code (free code) ([EMAIL PROTECTED])
Re: Doing It Right: The Next Chip Controversy (test)
Re: AES2 papers now available at NIST (Robert Harley)
Re: Limitations of testing / filtering hardware RNG's (R. Knauer)
Re: Limitations of testing / filtering hardware RNG's ("Douglas A. Gwyn")
Re: Quantum PRNG (R. Knauer)
Re: ElGamal vs RSA ([EMAIL PROTECTED])
Re: Quantum PRNG ("Douglas A. Gwyn")
Re: Limitations of testing / filtering hardware RNG's (R. Knauer)
Re: RC5 and RC6 code (free code) ([EMAIL PROTECTED])
Re: British Crypto Fascists (Jim Dunnett)
Re: PGP signature mecanisms ("Chris Odom")
Re: Looking for encryption algorithm ([EMAIL PROTECTED])
Re: British Crypto Fascists (R. Knauer)
Re: DES => problems with decryption (Chris Monico)
Scramdisk - Possible Virus (Paul Roskos)
Re: Limitations of testing / filtering hardware RNG's (Medical Electronics Lab)
DIE HARD and Crypto Grade RNGs. ([EMAIL PROTECTED])
Re: RC5 and RC6 code (free code) (Jim Gillogly)
Re: DIE HARD and Crypto Grade RNGs. (Jim Gillogly)
Re: Limitations of testing / filtering hardware RNG's (R. Knauer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: RC5 and RC6 code (free code)
Date: Mon, 08 Mar 1999 14:39:30 GMT
I have written RC6 and RC5 in C (16-bit models). If you would like a copy
they are at:
http://members.tripod.com/~tomstdenis/rc5.c
http://members.tripod.com/~tomstdenis/rc6.c
They both use 16-bit 'words', 20 rounds and 32 byte (256 bit) keys. In the C
code, 'unsigned's must be 16-bits, so you may have to convert them to
'unsigned short'. They were designed and tested in Micro-C (C) Dave
Dunfield, but RC5 was tested under Symantec C. You can customize the ammount
of rounds and the size of the key.
I still have to code proof RC5 but it passed the simple zero vector test. To
the best of my knowledge RC5 and RC6 are both free (maybe only for free
projects) I am not too sure.
Enjoy.
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (test)
Subject: Re: Doing It Right: The Next Chip Controversy
Date: 8 Mar 1999 14:24:40 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
[snip]
>Each chip has in it the secret master private key. The public key is known
>to software authors. A standard format exists for placing an encrypted
>program in memory.
[snip]
If every chip shares some form of secret, then it would only be a matter of
time before someone will crack the tamper-proofing and reveal the secret to
all.
Mark Currie
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: AES2 papers now available at NIST
Date: 08 Mar 1999 17:08:46 +0100
[EMAIL PROTECTED] (Bruce Schneier) writes:
> We believe that it is pretty much impossible to design an algorithm
> that is resistant to side channel attacks, such as timing and power
> analysis.
I think that many people would go further and argue that resistance or
lack of resistance to such attacks is not a property of codes or
algorithms at all. It is only a property of specific implementations
and so is an orthogonal concern.
Bye,
Rob.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Mon, 08 Mar 1999 17:28:51 GMT
Reply-To: [EMAIL PROTECTED]
On 8 Mar 1999 16:42:39 GMT, [EMAIL PROTECTED] (Mark Currie) wrote:
>When a hardware RNG is used for generating keys in a security system, the
>output should be tested
Tests in general are worthless. At best they are misleading, at worst
they give false confidence. In order to gain confidence that the TRNG
is performing correctly, you must do a full design audit and provide
diagnostics for each subsystem.
>and perhaps, even (dare I say it) filtered.
Any filtering will cause the output to be ruined.
>At a bare
>minimum the output should be tested for the "stuck at 1" or "stuck at 0"
>condition.
Yes, but you treat that as a diagnostic condition, and shut the TRNG
down. If it is performing properly you turn it back on and proceed to
generate more numbers.
A uniform Bernoulli process is guaranteed to generate long runs of all
one digit, so the appearance of such runs is not necessarily a bad
thing. If the cryptanalyst knows you are deliberately filtering such
runs out, you have given him information about the keystream.
>However, when higher level statistical tests are applied to
>the output, and values are accepted or rejected based on the outcome of these
>tests, then the range of usable values may be severely limited. If the testing
>is too stringent, the limited range of usable values may allow an exhaustive
>key search on this range to be feasable.
You have hit precisely on the problem of using statistical tests on
the output. First, they do not tell you anything definitve, and
secondly if you act on them you will ruin the randomness of the
output.
>Ideally the RNG output should be left alone, assuming that it is a good random
>source. However, for reliability reasons some sort of testing / filtering /
>failure reporting may be necessary where high security is required.
Yes, the output of the TRNG must be left alone, or shut down if there
is a reason to suspect that it is broken.
The only way to know that the TRNG is reliable is to treat it as a
piece of scientific equipment and test all of the subsystems
thoroughly.
>Given the amount of discussion on RNG's in this group, this may have been
>covered before. Any comments ?
There have been over 1,000 posts to sci.crypt in the past year or so
on the subject of true random number generation, and I suspect there
will be another 1,000 in the year to come. Welcome aboard.
Let me leave you with a definition which was distilled from the
prevailing consensus from those discussions:
A True Random Number suitable for use as a crypto-grade keystream is
one produced by a process (a TRNG) which is capable of generating all
possible finite numbers equiprobably, namely in an independent and
equidistributed manner.
Obviously, any filtering of the output destroys some of the entropy
inherent in that process. But nothing is wrong with shutting the TRNG
to run routine diagnostics when an alarm is sounded that something is
likely wrong, like a shorted or floating output.
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Mon, 08 Mar 1999 17:39:25 GMT
Mark Currie wrote:
> Ideally the RNG output should be left alone, assuming that it is a good random
> source. However, for reliability reasons some sort of testing / filtering /
> failure reporting may be necessary where high security is required.
The question is, which is more likely: that the generator has broken,
or that it is working properly but has generated a statistical fluke?
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Quantum PRNG
Date: Mon, 08 Mar 1999 17:57:59 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Mar 1999 17:37:19 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>Actual implementations (e.g. on crypto chips) are carefully designed
>to avoid bias. Techniques for this have been known since at least
>the days of the Rand Corp.'s published book of a million random
>deviates. For example, if the generated sequence might have a
>relative imbalance in the quantity of 1-bits versus 0-bits,
>combining the bits pairwise by taking 10 to produce 1 and 01 to
>produce 0 (with 11 and 00 ignored) removes that particular bias.
Yes, that's the von Neumann anti-skewing algorithm. Has anyone proven
that it does not result in a higher degree of correlation?
>The "randomness" at the foundation of quantum phenomena is quite
>different in character from ordinary statistical randomness, as
>can be seen from its obeying different mathematical laws for
>combined events.
I realize that. But my question centers around the simulation of
quantum computation. For example, the Feynmann computer can be
simulated adequately with a PRNG providing the random input. So why
not run a quantum random number algorithm on the simulator?
Call it a "virtual" TRNG, in the sense that Deutsch uses that term - a
"VTRNG". I believe it was he who proved that any quantum mechanical
process can be simulated correctly if there were truly random inputs
at some stage of the simulation. So why not use a VTRNG to generate
bias-free and correlation-free true random numbers?
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ElGamal vs RSA
Date: Mon, 08 Mar 1999 03:54:49 GMT
In article <7buglm$a6g$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "F. Arndt" <[EMAIL PROTECTED]> wrote:
> > A novice question: Is it generally accepted that the ElGamal is much
> > less secure than the RSA for comparable key lengths?
>
> No. DH /Elgamal offers slightly more security per key bit than RSA.
Please. For my edification and enlightenment, define what you mean by
"slightly more". Please explain why you think the claim is true.
I have heard this remark before. While it is true, "slightly" should be
"very slightly". And the reason why is subtle. And it depends if the
field is GF(p) or GF(2^k).
I'd like to find out if anyone in this newsgroup knows the REAL reason
why solving a DL problem over Z_p is slightly harder than factoring N = st
when log(N) ~ log(p). Note that solving a DL problem over GF(2^k) where
k ~ log_2(N) is EASIER than factoring N.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Quantum PRNG
Date: Mon, 08 Mar 1999 17:37:19 GMT
"R. Knauer" wrote:
> One of the criticisms of a TRNG is that you cannot do it in a
> perfectly random manner, even with a truly random input. That is,
> there will always be some small amount of bias and correlation that
> gets into the output from errors in the hardware design.
Actual implementations (e.g. on crypto chips) are carefully designed
to avoid bias. Techniques for this have been known since at least
the days of the Rand Corp.'s published book of a million random
deviates. For example, if the generated sequence might have a
relative imbalance in the quantity of 1-bits versus 0-bits,
combining the bits pairwise by taking 10 to produce 1 and 01 to
produce 0 (with 11 and 00 ignored) removes that particular bias.
> So, instead of building a hardware TRNG, why not build a simulation of
> a quantum TRNG and drive it with the simplest possible true random
> input - no additional circuits to cause bias or correlation. The
> output is then presumably guaranteed to be a true random number
> because the quantum algorithm is a true random number generator.
No, it's not the simulation algorithm that is "true random";
it is the quantum phenomena that are supposed to be "random".
To the extent that the simulation approximates this, it is a
sufficient model of the physics (for the specific application).
The simulation amounts to a complicated hash of the underlying PRNG.
If it is sufficiently complicated, it can hide a presumed statistical
bias inherent in the PRNG, but there is no "magic" involved.
The "randomness" at the foundation of quantum phenomena is quite
different in character from ordinary statistical randomness, as
can be seen from its obeying different mathematical laws for
combined events.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Mon, 08 Mar 1999 18:00:57 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Mar 1999 17:39:25 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>> Ideally the RNG output should be left alone, assuming that it is a good random
>> source. However, for reliability reasons some sort of testing / filtering /
>> failure reporting may be necessary where high security is required.
>The question is, which is more likely: that the generator has broken,
>or that it is working properly but has generated a statistical fluke?
Whatever the answer to that question is, it is prudent to use it as an
alarm of a potentially serious malfunction, namely a shorted or
floating output. Shutting the TRNG down for diagnostics is allowed
since the sequences generated by a properly functioning TRNG do not
lose their random character if the output is interrupted.
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: RC5 and RC6 code (free code)
Date: Mon, 08 Mar 1999 18:00:29 GMT
In article <7c0nf0$3ek$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> To the best of my knowledge RC5 and RC6 are both free (maybe only for free
> projects) I am not too sure.
>
> Enjoy.
>
> Tom
You might be interested in my assembly language version of RC6; in
order to comply with EAR it is encrypted, and you will have to send me
your PGP public key (RSA only) to get the decryption key. It is available
at: members.tripod.com/~afn21533/tinyrc.pgp or
www.afn.org/~afn21533/tinyrc.pgp
This is a CFB block chaining mode and is less than 500 bytes length.
As far as the free availability of RC6, note that the intellectual
property statement for RC6 gives several patents that have already been
issued. On the other hand, RIJNDAEL says that it is not now and will not
be in the future subject to any patents. Working on a TinyRijndael but
have not proven it compatible yet.
Robert G. Durnal
Web pages at www.afn.org/~afn21533
and members.tripod.com/~afn21533
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Jim Dunnett)
Subject: Re: British Crypto Fascists
Date: Mon, 08 Mar 1999 18:46:56 GMT
Reply-To: Jim Dunnett
On Sun, 07 Mar 1999 18:06:31 GMT, [EMAIL PROTECTED] (R.
Knauer) wrote:
>On Sat, 06 Mar 1999 21:48:52 GMT, [EMAIL PROTECTED] (Jim
>Dunnett) wrote:
>
>>The one good thing about this rubbish is the tacit admission
>>that they can't break PGP!
>
>I believe they will be able to at a later date, when quantum computers
>come on line.
>
>The really hilarious thing about their demanding that you decrypt your
>ciphers is that with the OTP system you can decipher it into any
>message you want. All you have to do is make a false key by XORing the
>cipher with the false message.
>
>Anyway, with the OTP system you are supposed to destroy the real key
>once the message is encrypted or decrypted) - that is part of the
>protocol. Therefore, you cannot be expected to be able to decrypt the
>cipher later.
Right.
>I wonder if anyone behind this nonsense knows anything about crypto.
Of course not.
--
Regards, Jim. | Der Staat wird nicht 'abgeschaft',
olympus%jimdee.prestel.co.uk | er stirbt ab.
dynastic%cwcom.net |
nordland%aol.com | - Friedrich Engels, 1820-1895.
marula%zdnetmail.com |
Pgp key: pgpkeys.mit.edu:11371
------------------------------
From: "Chris Odom" <[EMAIL PROTECTED]>
Subject: Re: PGP signature mecanisms
Date: Mon, 8 Mar 1999 13:01:11 -0600
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
Most of your answers are in the "Intro to Crypto" pdf that comes with
PGP. I think that's all available for free?
When you sign a message, the message is hashed. The hash is then
encrypted with your private key. Only your public key can decrypt it.
The receiver of the message decrypts your signature with your public
key. He then creates his own hash of the same message. The two
hashes should match perfectly. If they do not, that means one of two
things:
1) "your" public key that I am decrypting with does not correspond to
the private key you signed with.
2) the message has been tampered with after it was signed.
- --
// -------------------------------------------------------------
// Chris Odom [EMAIL PROTECTED]
// PGP Public Key: http://www.enteract.com/~chris#pgp
//
// Dump your bank and use e-gold:
// http://www.e-gold.com/e-gold.asp?cid=101730
// -------------------------------------------------------------
[EMAIL PROTECTED] wrote in message
<7c0oq7$4kt$[EMAIL PROTECTED]>...
>Hello,
>
>I would like to know the signing and verifying mecanisms of PGP, how
the key
>generator works and how the PGP recipient application verifies the
interity
>and authenticity of the message.
>
>Thank you!
>
>P/S: If you could tell me where I can find out these informations it
will be
>very appreciated!
>
>-----------== Posted via Deja News, The Discussion Network
==----------
>http://www.dejanews.com/ Search, Read, Discuss, or Start Your
Own
=====BEGIN PGP SIGNATURE=====
Version: PGP Personal Privacy 6.0.2
iQA/AwUBNuQedzMT8cKYbug5EQIB3wCdESVy8g4UFUEza8VGw/4bVApgibsAoMq9
ZoOy6aW0GQOK0MgRUDRX6AdB
=ZIX3
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Looking for encryption algorithm
Date: Mon, 08 Mar 1999 18:35:42 GMT
> Does anyone know any kind of encryption algorithm that
> using 2 or more keys to encrypt and using 1 key to decrypt,
> and the encryption speed will be as fast as symmetric
> encrypt algorithm?
>
>
Well that wouldn't be a good algorithm if more then one key is available. You
may want to look for RSA type public key algorithms. If you are looking for
symetric see my versions of RC5 and RC6 for 16-bit embeded and PC's (16-bit
memory model) in C. They are at:
http://members.tripod.com/~tomstdenis/rc5.c
http://members.tripod.com/~tomstdenis/rc6.c
Tom
============= 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: British Crypto Fascists
Date: Mon, 08 Mar 1999 19:20:26 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Mar 1999 18:46:56 GMT, [EMAIL PROTECTED] (Jim
Dunnett) wrote:
>>I wonder if anyone behind this nonsense knows anything about crypto.
>Of course not.
I don't quite whether to take that as good news or bad news.
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
From: [EMAIL PROTECTED] (Chris Monico)
Subject: Re: DES => problems with decryption
Date: Mon, 08 Mar 99 18:36:04 GMT
In article <[EMAIL PROTECTED]>,
(Moh) wrote:
>Hi,
>
>the problem I have got is that I wrote using
>Bruce Schneiers "Applied Cryptographie"
>writing a DES Modul in C.
>The only thing I did not really understand is
>how to decrypt the Datablock.
>It is said that the "Keys" in the round
>should be used in invers order but using
>the samem algrorithm. This was not clear
>to me, so I pasted my high-level function
Sorry I don't have time to read your code, but the idea is this:
If your encryption key schedule is k_1, ...,k_16, set
K_1 := k_16, K_2 := k_15, ..., K_16 := k_1,
and apply the same exact algorithm to the ciphertext, using
K_1,...K_16 as your key.
Hope this helps.
------------------------------
From: Paul Roskos <[EMAIL PROTECTED]>
Subject: Scramdisk - Possible Virus
Date: Mon, 08 Mar 1999 13:41:17 -0500
Hello,
I just downloaded the program from the Scramdisk web site, and
our corporate anti-virus program detected a virus.
Can anyone point me to an anternate site where the program can be
downloaded?
Thanks for any help.
Paul
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Mon, 08 Mar 1999 13:31:48 -0600
Mark Currie wrote:
> When a hardware RNG is used for generating keys in a security system, the
> output should be tested and perhaps, even (dare I say it) filtered. At a bare
> minimum the output should be tested for the "stuck at 1" or "stuck at 0"
> condition. However, when higher level statistical tests are applied to
> the output, and values are accepted or rejected based on the outcome of these
> tests, then the range of usable values may be severely limited. If the testing
> is too stringent, the limited range of usable values may allow an exhaustive
> key search on this range to be feasable.
>
> Ideally the RNG output should be left alone, assuming that it is a good random
> source. However, for reliability reasons some sort of testing / filtering /
> failure reporting may be necessary where high security is required.
>
> Given the amount of discussion on RNG's in this group, this may have been
> covered before. Any comments ?
The testing before it's used will tell you if it needs filtering.
If it does, then monitor the output of the filter, both rate and
"stuck at 0/1" conditions. If the data rate falls or rises past some
limit, you can flag it as a problem and shut the RNG down.
Long range testing can't hurt, but it will all be after the fact.
If an RNG begins to give bad stats, and then they get slowly worse,
you can stop using the output. But you'll have already used some
10 to 100 Megabytes it took you to figure out that the stats were
changing. For high data rates that's probably ok, for high
security and low data rates it may not be.
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED]
Subject: DIE HARD and Crypto Grade RNGs.
Date: Mon, 08 Mar 1999 19:36:52 GMT
Hello All,
Is it reasonable to say that DIEHARD package is not meant to test
cryptographic security of the bit patterns, but statistical independence of
the numeric values generated by RNGs.
Does that mean a crypto-grade RNG should not be tested using statistical
tests ?
Sachin.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: RC5 and RC6 code (free code)
Date: Mon, 08 Mar 1999 11:50:01 -0800
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> To
> the best of my knowledge RC5 and RC6 are both free (maybe only for free
> projects) I am not too sure.
I don't speak for RSA Labs, but this isn't correct. RC5 is patented
and I think they assert some of the RC5 claims cover RC6 as well.
RC6 will be available free for all purposes if and only if it is
chosen as the AES winner.
--
Jim Gillogly
Highday, 16 Rethe S.R. 1999, 19:45
12.19.6.0.1, 9 Imix 14 Kayab, First Lord of Night
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: DIE HARD and Crypto Grade RNGs.
Date: Mon, 08 Mar 1999 12:05:39 -0800
Reply-To: [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
> Is it reasonable to say that DIEHARD package is not meant to test
> cryptographic security of the bit patterns, but statistical independence of
> the numeric values generated by RNGs.
Yes (to a first approximation).
> Does that mean a crypto-grade RNG should not be tested using statistical
> tests ?
No. Passing statistical tests is necessary but not sufficient for a
crypto-grade PRNG. DIEHARD can give a quick heads-up on correlations
that might not be immediately apparent. It cannot be used to demonstrate
that a cipher is strong.
--
Jim Gillogly
Highday, 16 Rethe S.R. 1999, 20:02
12.19.6.0.1, 9 Imix 14 Kayab, First Lord of Night
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Limitations of testing / filtering hardware RNG's
Date: Mon, 08 Mar 1999 20:05:17 GMT
Reply-To: [EMAIL PROTECTED]
On Mon, 08 Mar 1999 13:31:48 -0600, Medical Electronics Lab
<[EMAIL PROTECTED]> wrote:
>The testing before it's used will tell you if it needs filtering.
>If it does, then monitor the output of the filter, both rate and
>"stuck at 0/1" conditions. If the data rate falls or rises past some
>limit, you can flag it as a problem and shut the RNG down.
>Long range testing can't hurt, but it will all be after the fact.
>If an RNG begins to give bad stats, and then they get slowly worse,
>you can stop using the output. But you'll have already used some
>10 to 100 Megabytes it took you to figure out that the stats were
>changing. For high data rates that's probably ok, for high
>security and low data rates it may not be.
Also make sure that you don't have a Snake Oil Generator, since a SOG
will also pass those tests.
Statistical testing of the output of a TRNG is worthless- it's like
running an experiment to confirm a theory and then using that theory
to prove that the experiments are correct.
Statistical testing of the output is the most notorious form of Snake
Oil in crypto, and it won't go away no matter how many times people
try to kill it off. It is based on the notion of "apparent" randomness
- IOW, it is a specification for a Snake Oil Generator.
The best you can use statistical testing for is a diagnostic alarm. If
you rely on statistical testing of the output to verify that a TRNG is
truly random, you are deceiving yourself.
The other day I asked on another thread what is the entropy of
Champernowne's number, and a couple of astute readers caught on and
pointed out that a given number has no entropy - or if it does it has
zero entropy by virtue of the process that creates it. IOW, since
Champernowne's number is a fixed number, the entropy of the process
that creates it must be zero.
That ought to tell you that testing the output of a TRNG for apparent
randomness is futile.
Bob Knauer
"Luckily for all, the State is only people. And, generally, the least
competent of people. They are the ones who cannot innovate, only steal.
They cannot reason, only kill. They are brutes who see the greatest
efforts of mankind as loot to seize and control."
--The Kings of the High Frontier
------------------------------
** 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
******************************
