Cryptography-Digest Digest #60, Volume #9 Tue, 9 Feb 99 14:13:03 EST
Contents:
Re: Newbie Says Thanks! (wtshaw)
Re: GPL'ed RNG (Colin Plumb)
Re: Encryption for telemedicine (Themos Dassis)
Summary of Eleven Ciphers (wtshaw)
Re: 128 bit Everest, 64 bit Coin ("Trevor Jackson, III")
Re: hardRandNumbGen (Mok-Kong Shen)
Re: On a Method of Session Key Generation (revised) (Patrick Juola)
block ciphers ("Vonnegut")
Re: Q: Obtaining session key (Mok-Kong Shen)
Re: What is left to invent? ("Trevor Jackson, III")
Re: SCOTT COMPRESSION ("Peter K. Boucher")
Re: Encryption Algorithms ("Brian Gladman")
Everybody Seems to Have a Web Site These Days! (John Savard)
Re: Intel's description of the Pentium III serial number ("Jimmy D. Smith")
Re: hardRandNumbGen (R. Knauer)
Re: How to get gov't approval for crypto (fungus)
Re: On a Method of Session Key Generation (revised) (R. Knauer)
Re: What is left to invent? (R. Knauer)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Newbie Says Thanks!
Date: Tue, 09 Feb 1999 07:03:17 -0600
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DonGraft) wrote:
> I justed wanted to thank you for your responses to
> my query on cracking variable length codings. I am
> impressed with the level of expertise and the range of
> interesting topics that come up. So, I'm going to stick
> around!
>
We will be looking for your next looking for your next posting.
Thanks for jumping in.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
Subject: Re: GPL'ed RNG
From: [EMAIL PROTECTED] (Colin Plumb)
Date: Tue, 09 Feb 1999 10:23:21 GMT
In article <79lql2$1i3$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> Is there a GPL or LGPL random number generator that produces "good"
> random numbers? rand() just isn't cutting it :P
Um, you have to define your metric of "good". It is not possible
to implement a true RNG without hardware help, so information about
your execution environment is required.
If you just want a pseudo-random number generator, random() is
better than rand(), and George Marsaglia's recently posted
KISS generator is extremely good for a non-cryptographic generator.
KISS can be written as:
struct rand_state {
word32 w, x, y, z;
};
#define wnew(w) ((w)=18000*((w)&65536)+((w)>>16))
#define LCG(x) ((x)=69069*(x)+1234567)
#define SHR3(y) ((y)^=(y)<<17, (y)^=(y)>>13, (y)^=(y)<<5)
#define znew(z) ((z)=36969*((z)&65536)+((z)>>16))
#define KISS(r) ( ( (znew(r->z)<<16+wnew(z->w)) ^ LCG(r->x) ) + SHR3(r->y) )
The period of w is 18000*2^15-1 = 589823999, a prime.
The period of x is 2^32 = 4294967296
The period of y is 2^32-1 = 4294967295
The period of z is 36969*2^15-1 = 1211400191, a prime
Thus, the total period is 13180436693658741103741078002865274880,
1.318e37, a bit over 2^123. The least significant bit has a lower period
of only 5066549571022225410, 5.067e18, a bit under 2^62, which is still
plenty for most applications.
w and z should be initialized to values between 1 and their periods.
y should be initialized to a non-zero value, and x can be set to anything.
I seeded this from 3 32-bit values w, x and z where I know they are not
all zero using the following snippet.
/*
* Now ensure that seed constraints are met.
* w should be between 1 and 589823999.
* x can be anything between 0 and 2^32-1.
* y should be between 1 and 2^32-1.
* z should be between 1 and 1211400191.
*/
r->w = w % 589823999 + 1;
r->x = x;
r->z = z % 1211400191 + 1;
/*
* Finally, we initialize y. Since the range desired for y,
* 2^32-1, exactly divides the range available from the
* triple-width number wxz, 2^96-1, the remainder modulo 2^32-1
* will be uniformly distributed. Fortunately, due to the special
* form of the modulus, this computation is easy.
* Since tv_usec always has the high bit clear, the input x is never
* zero. And since mix() preserves non-zeroness, the full value wxz
* here is never 0, so the result computed here is never 0.
*/
y = w+x;
y += y<x; /* End-around carry */
y += z;
y += y<z; /* End-around carry */
r->y = y;
This will do for most simulation purposes.
If you need cryptographic strength, please be more specific about your
needs. Note that cryptographic strength also requires some truly
random seed material. The sources you have available will affect
the optimal design.
--
-Colin
------------------------------
From: Themos Dassis <[EMAIL PROTECTED]>
Subject: Re: Encryption for telemedicine
Date: Tue, 09 Feb 1999 16:48:38 +0200
On the line we need integrity protection, protection against
non-repudiation, masquerade and source
authentication. Thinking about a software solution do you think
that the second solution that you propose me is suitable?
Where can I get more information about it?
Why do you think that a hardware solution is not suitable?
Thank you for your time
Themos Dassis
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Summary of Eleven Ciphers
Date: Tue, 09 Feb 1999 08:07:33 -0600
The series of simple block ciphers that convert from Base 100 to Base N,
using digits as an intermediary and for transposition is completed within
the initial limiatations of using numbers <= about10^10, and translation
constants +/- 10% of a power of ten.
Pt.Base/Ct.Base, Name, Info Units Transposed, Transposition Block Sizes in
same units, Size of Substition key in characters, Input Block Sizes in
characters of input base, Output Block Sizes in characters of the output
base.
100/64 Wharton 10 18/36/64 64 9/18/27 10/20/30
100/57 Granville 10 14/28/42/56 57 7/14/21/28 8/16/24/32
100/47 Tuttle 10 10/20 47 5/10 6/12
100/40 Sappa 10 8/16/24 40 4/8/12 5/10/15
100/32 Winters 10 6/12/18/24 32 3/5/9/12 4/8/12/16
100/27 Salado 10 10/20 25 5/10 7/14
100/22 Rimfire 10 8/12/16/20/24 22 4/6/8/10/12 6/9/12/15/18
100/18 Balsas 10 10/20 18 5/10 8/16
100/16 Ping 10 6/12/18/24 16 3/6/9/12 5/10/15/20
100/14 Bangkok 10 8/16/24 14 4/8/12 7/14/21
100/13 Gemini 10 10/20 26 5/10 9/18
Counting different block sizes, its really 34 ciphers.
Rimfire through Gemini all have the capacity to add nulls or optional
characters, resulting in 26 character output.
Concerning the most recent applications: Wharton does exactly what I
wanted it to, but the block lengths, like Granville are rather large and
cumbersome. Look around 100W and 64N for the name. Salado is a river in
northern Mexico at about 100 W and 27N.
Still using Base 100 for input, there are four non-digit based simple
block ciphers that beg to be done: Three use base six hexits as an
intermediary, and one uses bits as an intermediary. There are other
options too, but I chose to do certain ones for example purposes.
The trick is to convert a block of digits representing several base 100
characters to a string of convenient hexits, or bits, transpose those
elements, and output in substituted characters in the new base. As we are
stiil going from a greater to a lesser base, there will be some expected
inflation from plaintext to ciphertext.
--
A much too common philosophy:
It's no fun to have power....unless you can abuse it.
------------------------------
Date: Thu, 28 Jan 1999 23:19:15 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: 128 bit Everest, 64 bit Coin
handWave wrote:
> I
> made
> some rough
> calculations
> yesterday comparing
> 64 bit keys to 128 bit keys.
> There are about 2^64 atoms in a coin.
> There are about 2^128 atoms in Mount Everest.
So there are 2^64 coins in Mt. Everest? I think that number is too
large. Way too large.Ever hear of covering a chessboard with kernels of
grain, doubling on each cell?
> The Universe has about 10^88 particles or 2^291 particles.
You must be counting photons too.
> All of the gold owned today could fit in my house.
Your house must be enormous. In all of history we've mined about
100,000 tons (1e11 grams) of gold. Most of it is still around.
> Donations are welcome.
> handWave
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: hardRandNumbGen
Date: Tue, 09 Feb 1999 16:27:44 +0100
R. Knauer wrote:
>
> A TRNG has a specific definition - it must be capable of generating
> all possible finite sequences equiprobably. The best example of a TRNG
> is a fair coin toss.
I believe lots of people would be very happy if you could tell them
how to obtain a fair coin! Isn't evident now that one can never get
an ideal OTP?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: On a Method of Session Key Generation (revised)
Date: 8 Feb 1999 12:06:17 -0500
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (R. Knauer) wrote, in part:
>
>>Keep in mind the famous dictum that one cannot
>>generate crypto-grade random numbers algorithmically.
>
>I've never heard of this "famous dictum".
>
>One cannot generate truly random numbers algorithmically, and seeking
>to generate "random" numbers by some easy way that can't, as you know,
>work perfectly may indeed indicate one is in a "state of sin" (the
>famous John von Neumann quote)...
Actually, you have heard of this dictum. The Neumann quote *IS*
the famous dictum.
Mr. Knauer simply belives that the only thing that qualifies as
"crypto-grade" is provably perfect secrecy. Which is a defensible
position, if a bit on the wing-nut paranoiac side.
-kitten
------------------------------
From: "Vonnegut" <[EMAIL PROTECTED]>
Subject: block ciphers
Date: Tue, 9 Feb 1999 11:02:12 -0500
Ok, given a cipher w/ block length of n, the odds are pretty good, i.e.
(n-1)/n that the last bit in the last block is a null. Could this be
exploited in some way to reveal a part of the key, or is it standard to use
some character other than an ASCII 0 for the nulls to fill the last block.
I reallly have no level of experience in this stuff, but I thought I'd ask.
-Vonnegut
[EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Obtaining session key
Date: Tue, 09 Feb 1999 17:21:46 +0100
Michael Kjorling wrote:
>
> I would suggest to concentate the current plaintext with the last two hash
> values, then hashing the result. I'd say that this scheme is much better than
> yours, but cryptography is a black art, so if anyone knows better, please let
> me know.
I have posted a extended revision to the group on 02 Feb in the thread
'On a Method of Session Key Generation (revised)', where I indicated
that only a hash record, not the plaintexts, need be stored.
You apparently missed that, because my name in the post became
'lmu14871' due to an error in the mailer.
M. K. Shen
http://www.stud.uni-muenchen.de/~mok-kong.shen/
------------------------------
Date: Tue, 09 Feb 1999 11:36:04 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: What is left to invent?
R. Knauer wrote:
> On Mon, 08 Feb 1999 18:05:09 -0600, Jim Felling
> <[EMAIL PROTECTED]> wrote:
>
> >Nope. PROOVE the coin is fair, and proove that you flip it in a "random
> >manner".
>
> Actually I do not believe that chaotic classical events can be proved
> to be random in the sense of complete indeterminancy.
>
> Only Quantum Mechanical phenomena can be proved to be completely
> indeterminant.
That's a religious statement. The meta-paraphrase goes like this: Even QM is
not *truly* random because there are hidden variable theories that may make
QM phenomena dependent on the prior state of the Universe. Since that prior
state can be manipulated QM phenomena are not only biased but subject to
manipulation by an adversary.
Now there is one class of phenomena that are, by definition, totally
indeterminate and impossible to influence (although some charlatans have
claimed to have influence, their claims are similar to the claims of
perpetual motion vendors).
There is an extensive literature on this phenomena. Because these phenomena
orgininate from outside the observable universe they are provably independent
of any other observable event. These phenomena are called Divine
Intervention. The only know weakness of the DRNG is the difficulty of
detecting a sufficient quantity of events to form a useful output rate.
------------------------------
From: "Peter K. Boucher" <[EMAIL PROTECTED]>
Subject: Re: SCOTT COMPRESSION
Date: Tue, 09 Feb 1999 09:52:21 -0700
There are only two reasons to do compression before encryption in a
scheme like Scott's, where every bit in the ciphertext depends on every
bit in the entire plaintext message: 1) to reduce the size, and/or 2) to
make it more difficult for an attacker to mount a chosen-plaintext
attack.
Notably, he need not worry too much about including standard headers, if
you agree with his premise that it is impossible to decrypt the headers
without decrypting the entire message.
If one did want to do away with the headers, in order to make it more
difficult to recognize a successful decryption, here is another idea:
Setup: Generate 255 Huffman headers, so that for almost any non-random
file, one of the headers will compress it, at least a little. These
headers could then be hard-coded into the software.
On encryption: Before encrypting a file, perform a statistical analysis,
select one of the 255 headers, and compress the file. Then, prepend a
value to identify which header was used (0..254, or 255, if compression
wasn't done because none of the headers would have compressed the
file). Finally, encrypt the compressed file.
On decryption: Decrypt the compressed file. Then, use the zero'th byte
to determine which header, if any, will be used to decompress the file.
Finally, decompress the file with the appropriate header (if the zero'th
byte didn't contain the value 255).
An attacker then has to decrypt the entire message, and also decompress
some number of bytes, before plaintext recognition can be attempted.
--
Peter
Eric W Braeden wrote:
>
> Horst Ossifrage wrote in message <[EMAIL PROTECTED]>...
>
> >
> >Compression of plaintext is a good idea before encryption. I commend you
> >for proposing to write a compression program as a front end. It would be
> >valuable since it would not have a HEADER BLOCK like pkzip. Without a
> >header text it is harder to identify a correct cryptanalysis.
> >
> I agree that compression of plaintext before encryption is good.
> I disagree that you should make compression a builtin frontend to your
> encryption code. This will gain you little. Most will use their favorite
> compression utility before encryption anyway. The fact that there
> are standard headers in standard files, compressed or otherwise,
> is an overstated danger. Don't worry about it especially if you are
> using CBC.
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Encryption Algorithms
Date: Tue, 9 Feb 1999 17:01:55 -0000
Asher Pressman wrote in message <[EMAIL PROTECTED]>...
>Does anyone know of any good sites where i can find encryption
>algorithms? I've been looking for a while and i just can't find
>anything...
>
I have all the AES algorithms in C source code on my site at:
http://www.seven77.demon.co.uk/aes.htm
These are worth studying as one (or more) of them will become the DES
replacement.
Brian Gladman
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Everybody Seems to Have a Web Site These Days!
Date: Tue, 09 Feb 1999 17:13:30 GMT
Remember that, a while back, I noted that GCHQ had a web site of
sorts?
Well, looking for information about teletypewriter codes in Russia, I
came across this web site:
http://www-vips.icn.gov.ru/
which is the (Russian-language) web site for FAPSI, which, according
to FAS, is the post-Soviet Russian counterpart to the NSA.
John Savard
http://www.freenet.edmonton.ab.ca/~jsavard/index.html
------------------------------
From: "Jimmy D. Smith" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.intel
Subject: Re: Intel's description of the Pentium III serial number
Date: Mon, 8 Feb 1999 23:39:42 -0600
>>> The "reset trick" you talk about is still supported in the
Pentium/Pentium II/IIIs but DOESN"T use the -RESET signal. It uses a signal
called INIT. Thus this trick will NOT re-enable the processor ID.
Good Luck!
>>>
Peter Gutmann wrote in message <79mu0n$a5i$[EMAIL PROTECTED]>...
>Anthony Naggs <[EMAIL PROTECTED]> writes:
>
>> Enabling Processor Serial Number
>
>> When the processor serial number feature is disabled, it can only be
>> re-enabled by executing a hardware reset. The hardware reset is
>> executed by triggering the RESET# pin of the processor. Triggering the
>> RESET# signal can be done in three ways:
>
>> Turning the system power from off to on
>> Hitting the reset button on the front panel of most systems
>> Resuming from deep sleep in mobile systems is often done by
>> activating the RESET# signal The exact means for triggering the
>> RESET# signal of the processor are often specific to a given
>> system and manufacturer.
>
>What about the keyboard-controller reset trick used to switch 80286's back
>into real mode? This is (presumably) still supported in current systems,
>which means you'd have a recoverable, software-controlled means of
resetting
>the CPU (and therefore the serial number readability).
>
>Peter.
>
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: hardRandNumbGen
Date: Tue, 09 Feb 1999 18:34:07 GMT
Reply-To: [EMAIL PROTECTED]
On 8 Feb 1999 10:42:38 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>Therefore the very thing you are testing the RNG for, namely its
>>suitability for use with the OTP system, is not determinable. You
>>might be able to determine that a RNG is not suitable, but you cannot
>>determine that an RNG is suitable.
>No. There are two things you need to do to produce a certifiable
>TRNG.
I meant "you cannot determine that an RNG is suitable"... using
statistical tests on the output.
>One is to confirm that the device is, in fact, a "random number generator"
>in the sense that it produces random bits. The main thing to confirm
>then is that you can get an unbounded number of random (although not
>necessarily equiprobable) bits out of the system.
I do not know what you mean by "random" in that sentence. I will take
it to mean "indeterminant".
Which brings up a question I was going to bring up earlier and have
been waiting for the right place. We speak of the ills of bit-bias in
terms of random number generation, but what if the generator were
designed with a deliberate bias? As an analog (and only as an analog)
imagine a symmetric polygonal die with one more 1 than 0. That would
have a built in bias, yet each outcome of a throw would be
indeterminant. So you subject the output of that die to a statistical
test for bit-bias and it flunks. Now what?
Also, imagine actually using the output for an OTP and your attacker
tries to figure out why the bits in the ciphers are biased. Will that
do him any good? IOW, does using the pad from a deliberately biased
RNG (which is otherwise completely indeterminant) leak any information
that is useful for decrypting your ciphers?
It would seem that any bias, even bias that is deliberately introduced
and accounted for, is going to weaken the random number generation
process cryptographically, since in the limit that the bias becomes
very large, you have a totally unsecure system? Yet the TNG is
completely indeterminant from one throw of the die to the next
[NB: For those of you who were here a year ago, this very important
point was discussed at length - and is the reason we define a TRNG in
terms of equiprobable sequences, and not just independent bit
generation.]
>This requires
>examination of the generator -- and is probably impossible unless
>you're willing to make certain assumptions about various physical
>processes such as radioactive decay or wave height or something.
Therefore you must have a known source of randomness to avoid such
assumptions. Radioactive decay suffices - unless you are prepared to
take on the entire scientific community with a refutation of
indeterminancy in Quantum Mechanics, in which case be sure to bring
your lunch because you are gonna be at it for a while.
>The other is to confirm that the outputs are bias-free -- or more
>accuratley as bias-free as possible, since there's no way to prove
>ZERO bias. And this is best done statistically, although if you
>really trust your engineers you can probably do it by design analysis
>as well.
If you know that your RNG is supposed to be bias-free, then testing it
for bias may be necessary but is certainly not sufficient to
demonstrate that it is working properly - with the proviso that you
know that it is designed to be a TRNG so you can avoid the possibility
that you have a PRNG which passes the tests and fools you.
Bob Knauer
"The world is filled with violence. Because criminals carry guns,
we decent law-abiding citizens should also have guns. Otherwise
they will win and the decent people will loose."
--James Earl Jones
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: How to get gov't approval for crypto
Date: Wed, 10 Feb 1999 05:05:37 +0100
Tim Mavers wrote:
>
> Does the NSA or commerce dept have to approve it?
Yes.
>
> It's almost as if it's
> against the law to write certain types of code.
>
This is basically what they're trying to achieve...
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: On a Method of Session Key Generation (revised)
Date: Tue, 09 Feb 1999 18:11:44 GMT
Reply-To: [EMAIL PROTECTED]
On 8 Feb 1999 12:06:17 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>Mr. Knauer simply belives that the only thing that qualifies as
>"crypto-grade" is provably perfect secrecy. Which is a defensible
>position, if a bit on the wing-nut paranoiac side.
You have just misrepresented me on two counts.
First I never said that I "belives (sic) that the only thing that
qualifies as crypto-grade is provably perfect secrecy". Secondly I am
not on any "wing-nut paranoiac side."
This is a discussion about what constitutes crypto-grade randomness,
including proveable security. As long as ciphers can be shown to be
unbreakable, I will accept them as crypto-grade, even if a small but
inconsequential amount of information leaks from the ciphers.
That hardly constitutes "wing-nut paranoia" - unless you can make a
case for the acceptance of less than crypto-grade security in all
situations, including long term secrecy of very valuable information.
Either the cipher is unbreakable or it is not. If it is not, then it
is hardly worthy of further consideration. And just because the RNG
passes some necessary condition does not mean it has passed a
sufficient condition.
Bob Knauer
"The world is filled with violence. Because criminals carry guns,
we decent law-abiding citizens should also have guns. Otherwise
they will win and the decent people will loose."
--James Earl Jones
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: What is left to invent?
Date: Tue, 09 Feb 1999 19:06:30 GMT
Reply-To: [EMAIL PROTECTED]
On Tue, 09 Feb 1999 11:43:19 -0500, "Trevor Jackson, III"
<[EMAIL PROTECTED]> wrote:
>Let me get this straight, Radioactive decay is *provably* indeteminate,
>but only within a fractional confidence, and this proff depends on testing
>the output of systems that decay radioactively.
I never siad that.
I said that certain kinds of radioactive decay are proveably
indeterminant in Quantum Mechanics. I never said that such proof is
"within a fractional confidence". I did say that there is experimental
confirmation, and that those experiments do have a fractional
confidence that is determinable, and can be made arbitrarily small.
But I never said that the intrinsic indeterminability of certain
Quantum Mechanical process depend on experimental results.
>I thought you said that this kind of statistical testing was worthless for
>proving indeterminacy.
I never said any such thing. Experiments to determine the shape of
time and energy spectra are not designed to demonstrate indeterminancy
directly, only show that certain expected properties of indeterminancy
are present. IOWm they confirm what is already known theoretically.
The exponential time decay law and the Lorentzian spectral line shape
are consequences of the indeterminancy in the Quantum Mechanical
process for spontaneous decay, not its cause. The cause of the
indeterminancy is second order perturbation theory which yields the
Lorentzian line shape, whose Fourier transform to the time domain is
an exponential with a constant half life.
Statistical testing confirms that the radioisotope has those
properties, which in turn confirms that the decay process is
indeterminant as expected from a theoretical analysis in Quantum
Mechanics. If the statistical testing had gotten anything other than
an exponential in time or a Lorentzian in energy, then the process
would not be indeterminant.
In fact, a second process can come into play which dramatically alters
the line shape - diffusive hopping of the nuclei in a solid at a rate
comparable to the reciprocal of the half life. In that case the gamma
ray emission is hardly indeterminant *in itself* since the emission
can be disturbed by an outside influence - and that phenomenon can be
measured directly. I ought to know, I was the first person ever to
measure it many years ago. We got a factor of 2 anomoly from
theoretical expectations, which I later published several papers
explaining that the anomoly was due to so-called "correlation" effects
in the vacancy diffusion mechanism.
IOW, there were a total of three processes - the emission of the gamma
ray, the diffusive hopping of the nucleus and the presence of lattice
vacancies necessary to achieve diffusive hopping. Each has a different
(comparable) time constant and so all three rates have to be taken
into account. Based on reasonable assumptions regarding vacancy
diffusion I was able to show that the anomolous line broadening can be
explained. Check out The Physical Review and some other journals I
have forgotten for my papers, back nearly 30 years ago.
>I thought you also said that the right way to test
>a system was a design analysis. Where is your detailed design analysis of
>subatomic particle physics? Where is the "audit" you describe below?
The audit comes from testing the source *itself* as described above,
and testing the each subsystem in a manner to prove that they are
working as designed,
BTW, this is not all that strange - experimental scientists do it all
the time. They do a design audit and a test audit on every aspect of
their equipment. One thing is for sure - they do not rely on the final
output to determine if the equipment is working. That would be
suicidal.
>You have the same kind of proof that you have been criticizing. Tests
>that have predictive power. Statistical predictive power. Not proof.
See the comments above.
Bob Knauer
"The world is filled with violence. Because criminals carry guns,
we decent law-abiding citizens should also have guns. Otherwise
they will win and the decent people will loose."
--James Earl Jones
------------------------------
** 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
******************************
