Cryptography-Digest Digest #38, Volume #9 Fri, 5 Feb 99 08:13:09 EST
Contents:
openssl ("Ng Wei Yang")
CI and Letter Freq for other languages (ChaosX)
Re: RSA implementation (Florent Dudan)
Re RSA implementation questions (Florent Dudan)
Re: Threat Models: When You Can't Use a One-Time Pad ([EMAIL PROTECTED])
Re: [question/challenge/HELP ME! IEE!] Another unheard of punk who (Nathan Kennedy)
To all RSA responses concern with the above questions (Florent Dudan)
Re: Encoding for telephone over Internet (Patrick Juola)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: hardRandNumbGen (Patrick Juola)
Re: Loony question (Nathan Kennedy)
Re: Crypto mailing lists (Mok-Kong Shen)
Re: Random numbers generator and Pentium III (R. Knauer)
Re: Java random ([EMAIL PROTECTED])
Re: CI and Letter Freq for other languages (Mok-Kong Shen)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Random numbers generator and Pentium III (Patrick Juola)
Re: What cipher is used by iomega in ZIP products ? (Richard Herring)
----------------------------------------------------------------------------
From: "Ng Wei Yang" <[EMAIL PROTECTED]>
Subject: openssl
Date: Fri, 5 Feb 1999 16:55:30 +0800
i wonder anybody knows about how to build dll for windows world from source
provided by openssl, pls email me if u have any info : [EMAIL PROTECTED]
------------------------------
From: ChaosX <[EMAIL PROTECTED]>
Subject: CI and Letter Freq for other languages
Date: Fri, 05 Feb 1999 01:01:56 -0800
Hi,
I was wondering if anybody knows a URL or a reference book that contains
Letter Frequencies for English and other languages. Also, could anyone
please prime me on how one can distinguish rubbish from plaintext using
this frequency.
Thanks and have a nice day.
ChaosX
------------------------------
Date: Fri, 05 Feb 1999 11:53:44 +0100
From: Florent Dudan <[EMAIL PROTECTED]>
Subject: Re: RSA implementation
Florent DUDAN
EPFL - DI
=============================================================================
Hi
About my portable random generator you write:
> If it always gives the same sequence of numbers, then it is not
> suitable for cryptography. This type of PRNG may give you statistical
> randomness. However, a cryptographically strong PRNG must make it
> impossible to predict the next number from all of the previous numbers
> it has generated or, as mentioned below, anything else.
I know it was not a very good idea but I really cannot use the Smalltalk
random generator, it is given in every implementation of this language.
By the way you must remember that everyone using your application in
Smatallk may have access to your code !!!
So it is first based on trust, that an owner would not distributes the
random generator....
On the initialisation with milliseconds:
> They may not have the same sequence, but I can find the random number
> in minutes to hours by simply trying every millisecond around the
> estimated time the application was loaded.
It may takes ca. 1000 times to find it...
> You need to seed your PRNG with a lot more entropy than time to the
> nearest millisecond. As pointed out, this mistake has been made before
> and the results were disasterous and embarssing.
So what do you propose as a good random generator ?
Do you have source codes to propose (by the way my project won't be
commercialized !).
Remember also that in Smalltalk you cannot based your random generator
on how the compiler (as in C) does make roundings of numbers (i.e.
9.87566 to 10) !!
> Try doing an RSA encryption and decryption on some value. If they are
> not primes (with a few rare exceptions) the decrypted plaintext will
> be different than the plaintext initially encrypted. It may be quicker
> to do the true RSA test than it is to really convince yourself that
> they are probably prime.
There is no problem, I always have what I input as the ouput. But I used
before a pseudoprime test with which my system also works, but the
Miller-Rabin tests answers me that were ca. 1 number on 10 that were NOT
prime with the pseudoprime test. So I hope that Miller-Rabin is THE good
test for finding primes using Fermat theorem.
> I'm not sure what you are asking here, but I can guess.
You guess it more or less well...
> I guess that you are breaking a long plaintext into blocks that will
> be RSA-encrypted separately. We generally avoid doing that, because
> the algorithm is slow. Instead, we use conventional encryption for the
> message with a randomly chosen key and RSA-encrypted only a single
> block containing the conventional/symmetric key.
In fact I do not really divides a text into groups, I packed with binary
shift all the first ASCII codes in a Largeinteger while I test each time
I add an ASCII code that the Largeinteger isn't > n. Then when I cannot
add any more ASCII codes to the number, I compute its modular
exponentiation...
Then I takes the following next ASCII codes and so on till the end...So
it is never determined the exact numbers of characters in a group...
The problem is that it gives me (after encryption) largeintegers of
different size and I don't know I can append them to form a unique
seuquence of numbers and thereafter subdivides this sequence to refind
the largeIntegers that composed it.
Example:
123455 and 54543543 two blocks of grouped characters and encrpyts
with modular exponentiation.
I append them to form the sequence 12345554543543.
How now can I refound 123455 and 54543543 from this sequence ???!!!!
In the decrypt process it is not known anything about the numbers that
composed the above sequence of numbers !!!!
____ ____ _____________ __________ ____ ____
\ \ / / | | | __ | | \ / |
\ \/ / |____ ____| | |__| | | \/ |
\ / _____ | | | __| | |
/ \ |_____| | | | |\ \ | |\ /| |
/ /\ \ | | | | \ \ | | \/ | |
/___/ \___\ |___| |___| \___\ |___| |___|
------------------------------
Date: Fri, 05 Feb 1999 11:55:57 +0100
From: Florent Dudan <[EMAIL PROTECTED]>
Subject: Re RSA implementation questions
Florent DUDAN
EPFL - DI
=============================================================================
Hi
About my portable random generator Doug write:
> If it always gives the same sequence of numbers, then it is not
> suitable for cryptography. This type of PRNG may give you statistical
> randomness. However, a cryptographically strong PRNG must make it
> impossible to predict the next number from all of the previous numbers
> it has generated or, as mentioned below, anything else.
I know it was not a very good idea but I really cannot use the Smalltalk
random generator, it is given in every implementation of this language.
By the way you must remember that everyone using your application in
Smatallk may have access to your code !!!
So it is first based on trust, that an owner would not distributes the
random generator....
On the initialisation with milliseconds:
> They may not have the same sequence, but I can find the random number
> in minutes to hours by simply trying every millisecond around the
> estimated time the application was loaded.
It may takes ca. 1000 times to find it...
> You need to seed your PRNG with a lot more entropy than time to the
> nearest millisecond. As pointed out, this mistake has been made before
> and the results were disasterous and embarssing.
So what do you propose as a good random generator ?
Do you have source codes to propose (by the way my project won't be
commercialized !).
Remember also that in Smalltalk you cannot based your random generator
on how the compiler (as in C) does make roundings of numbers (i.e.
9.87566 to 10) !!
> Try doing an RSA encryption and decryption on some value. If they are
> not primes (with a few rare exceptions) the decrypted plaintext will
> be different than the plaintext initially encrypted. It may be quicker
> to do the true RSA test than it is to really convince yourself that
> they are probably prime.
There is no problem, I always have what I input as the ouput. But I used
before a pseudoprime test with which my system also works, but the
Miller-Rabin tests answers me that were ca. 1 number on 10 that were NOT
prime with the pseudoprime test. So I hope that Miller-Rabin is THE good
test for finding primes using Fermat theorem.
> I'm not sure what you are asking here, but I can guess.
You guess it more or less well...
> I guess that you are breaking a long plaintext into blocks that will
> be RSA-encrypted separately. We generally avoid doing that, because
> the algorithm is slow. Instead, we use conventional encryption for the
> message with a randomly chosen key and RSA-encrypted only a single
> block containing the conventional/symmetric key.
In fact I do not really divides a text into groups, I packed with binary
shift all the first ASCII codes in a Largeinteger while I test each time
I add an ASCII code that the Largeinteger isn't > n. Then when I cannot
add any more ASCII codes to the number, I compute its modular
exponentiation...
Then I takes the following next ASCII codes and so on till the end...So
it is never determined the exact numbers of characters in a group...
The problem is that it gives me (after encryption) largeintegers of
different size and I don't know I can append them to form a unique
seuquence of numbers and thereafter subdivides this sequence to refind
the largeIntegers that composed it.
Example:
123455 and 54543543 two blocks of grouped characters and encrpyts
with modular exponentiation.
I append them to form the sequence 12345554543543.
How now can I refound 123455 and 54543543 from this sequence ???!!!!
In the decrypt process it is not known anything about the numbers that
composed the above sequence of numbers !!!!
____ ____ _____________ __________ ____ ____
\ \ / / | | | __ | | \ / |
\ \/ / |____ ____| | |__| | | \/ |
\ / _____ | | | __| | |
/ \ |_____| | | | |\ \ | |\ /| |
/ /\ \ | | | | \ \ | | \/ | |
/___/ \___\ |___| |___| \___\ |___| |___|
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Threat Models: When You Can't Use a One-Time Pad
Date: Fri, 05 Feb 1999 09:22:30 GMT
Case 1
Unencrypted OTP
If there is no covert physical access, just ensure you destroy bits of OTP you
use, or overwrite used bits with new random ones (preferable - make it less
obvious). Once it's gone people cannot decrypt the old messages.
Case 2 Encrypted OTP If you encrypt an OTP with say 56 bit DES. You'll have
to do a brute 56 bit DES XOR every result with a sample encrypted message,
sliding it bit by bit till you get the suspects. If the encrypted OTP is
replaced as its used it could very difficult if the current starting point is
unknown.
I know I've asked about PCBC before. I've got to check out the attack on PCBC
mentioned to see if it will work if the "plaintext" is an unknown random
string which is to be XOR'ed with a known encrypted string at an unknown
point.
Link.
p.s. Yo Scott.. Here's where you do your advertising bit :).
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: [question/challenge/HELP ME! IEE!] Another unheard of punk who
Date: Thu, 04 Feb 1999 16:21:25 +0800
Vektor wrote:
<snip quote>
> ok...i phrased this badly...i've looked at RC4, and its not the same
> thing, or you didnt read my previous posts (which i believe is the case,
> since you sited RC4).
What do you mean by same thing?
> ok .. its like this...
>
> key1 -> split up into 3 seeds for prng -> RndTable[255] is created
>
> key1 and key2 -> a 2x256x256 Encrypt matrix is derived from RndTable,
> and both keys.
>
> EncryptMatrix -> The decrypt matrix is derived from the encrypt matrix
>
> key2, RndTable, EncryptMatrix -> the IV is derived from RndTable and
> Key2, and used to start the stream, and is encrypted like so (basically)
> Previousbyte AND 1 -> PPBit
> encryptedbyte -> EncryptMatrx[ppbit,previousbyte,enencryptedbyte]
I've tried to hack my way through your thick writing patiently. Please
don't rip *me* for being vague and ambiguous.
Now, if I get you right, this is essentially a PRNG with a few state arrays
which are seeded by two secret keys, and the PRNG stream is combined with
the plaintext to form the ciphertext.
> If your going to tell me 'its been done', please tell me what scheme
> does it.
What's been done? You said you were creating an algorithm that utilizes
the properties of a pseudorandom number generator. "That's been done." We
call those, stream ciphers. I am not commenting on the quality or
originality of your PRNG.
> 'just because it looks random, doesnt mean it is', is an almost
> meaningless statement...i KNOW its not random...thats the whole point of
> it.
Meaningless statement? Hardly. If you can perform some sort of
statistical analysis or differential attack to determine the state of the
state arrays, then your algorithm is broken.
The important thing is--
o The PRNG stream is uniformly indistinguishable from white noise. Any
biases will let plaintext show through, which is a nono.
o The stream cannot be analysed to determine the state array or the key.
It's not hard to write a PRNG that passes Diehard and looks random. It's
another thing to say it resists analysis.
> I see your point about RC4, but there aren't many similarities,
> aside from it uses a know PRN sequence as a base for encrypting.
IMO, this is a BIG similarity. It seemed to me you were claiming to have
something fundamentally new.
> In my
> estimates (lacking some sort of miracle algo that could duplicate the
> RndTable, AND the encrypt matrix), it would take at LEAST several years,
> given a fast machine completely dedicated to trying keys, to even have a
> hope of cracking the encoded text.
How have you shown there are no fundamental weaknesses that can be
analyzed?
> I've sited what i see as the strong points. If you can give me some sort
> of indication, or possibility that there is a solve-all algo, or
> several algos, to break this scheme, PLEASE tell me. vague half-truths,
> and non-sensical phrases aren't the least bit helpfull to me.
There isn't any solve-all algorithm. You haven't clearly defined
specifically how your scheme works, and I'm not in the cryptanalysis
business and I don't grok VB, so I'm not going to say "Your system is
strong or broken." I was merely pointing out a few relevant points.
> -Alex
> (btw, if your going to reply to a post, its usually courteous to read
> the ENTIRE strand, rather than reading the last message and throwing in
> your 2 cents. my method is NOT RC4.)
I did. And I did not claim your method == RC4. I merely pointed out RC4
as an example of an encryption algo that is essentially a PRNG. Yours is
also essentially a PRNG unless I completely misunderstand you, which I do
not think would be entirely my fault ;). Virtually all stream ciphers are
basically PRNGs. The underlying mechanism for the stream may be completely
different, but the concept is identical--you have a state array initialized
according to the seed/key, from which you extract a stream and XOR against
the plaintext (like RC4). (as opposed to a fundamentally different concept,
say a Feistel network (like RC5/6 or Twofish or DES), or prime factoring
(like RSA), or the logarithms (DH))
------------------------------
Date: Fri, 05 Feb 1999 12:08:30 +0100
From: Florent Dudan <[EMAIL PROTECTED]>
Subject: To all RSA responses concern with the above questions
===================================================================
Florent DUDAN
EPFL - DI
Departement d'Informatique
Lausanne
===================================================================
I forgot I cannot acces my mail here at the EPFL during our forthcoming
holidays, please answers to the follwoing adress:
[EMAIL PROTECTED]
Thank you
____ ____ _____________ __________ ____ ____
\ \ / / | | | __ | | \ / |
\ \/ / |____ ____| | |__| | | \/ |
\ / _____ | | | __| | |
/ \ |_____| | | | |\ \ | |\ /| |
/ /\ \ | | | | \ \ | | \/ | |
/___/ \___\ |___| |___| \___\ |___| |___|
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Encoding for telephone over Internet
Date: 3 Feb 1999 14:37:00 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 1 Feb 1999 09:17:06 -0500, [EMAIL PROTECTED] (Patrick Juola)
>wrote:
>
>>>why do you you think that a real time communication doesnt need
>>>as much security ?
>
>>Because, as I stated below, most real-time communications don't need
>>to stay secret as long. The interesting lifespan of the sort of data
>>communicated by telephone is typically measured in hours or day. There's
>>a reason that people don't "sign" contracts over the phone.
>
>I think Clinton and Lewinsky might have something to challenge that
>assertion.
That's why I said "months" and not "all."
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 3 Feb 1999 12:13:08 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 1 Feb 1999 09:25:38 -0500, [EMAIL PROTECTED] (Patrick Juola)
>wrote:
>
>>It's the same scoping error that you were making earlier.
>
>I do not recall ever having made any "scoping error" earlier. Several
>people have challenged me regarding the specification of a TRNG
>suitable for use in a proveably secure cryptosystem like the OTP, but
>that does not mean that I was in error. Until it is demonstrated
>convincingly that I was in error, all I can conclude is that the
>others were in error.
Well, I was one of the ones who pointed out the scoping error.... 8-)
>The defintion of a TRNG that I have been using was constructed from
>the prevailing consensus of our discussions a year ago, and I intend
>to stick with that prevailing consensus until it can be clearly
>demonstrated that the consensus was in error. [snip]
>
>Here is the current specification I have been using, which is
>identical to the one given by the prevailing consensus a year ago:
>
>+++++
>A TRNG must be capable of generating all possible sequences of a given
>finite length equiprobably.
>+++++
>
>Here equiprobability means that the probability for generating any
>string of a given finite length is the same for any other string of
>the same length. Note that equiprobability applies to the generator
>and not any of the actual strings produced by the TRNG.
The reason that I'm apparently having "second thoughts" is because
you're not interpreting the definition correctly.
Formally, the definition should read :
i) For all finite lengths N, a TRNG should be capable of outputting
all possible N-bit sequences equiprobably.
(the second clause, beginning "a TRNG" is implicitly univerally
quantified -- you can rewrite it as "all TRNGs" if you like.)
Instead, you're interpreting it as
ii) For any TRNG, there exists a finite length N such that the TRNG
is capable of outputting all possible N-bit sequences equiprobably.
First, i) implies ii), as you can easily. However, ii) does not
necessarily imply i). The first interpretation is the stronger
condition and the necessary one.
>>Similarly, the string 01010101010101010101... will output all possible 1-bit strings
>>equiprobably but not all 2-bit strings, and hence isn't allowed.
>
>Who ever said that an actual string was "allowed" or not. Re-read the
>specification for the TRNG - it applies to the generation process, not
>any actual string.
Sorry, you are correct. Rephrasing : A generator that only generates the
periodic sequence 010101010101010101010... is NOT a TRNG in the sense
defined above.
We first notice that there *is* an N (specifically, N == 1) for which
definition ii) holds. However, definition i) does *NOT* hold, in
particular, by construction, the two-bit sequence 11 (or 00) will never
be observed. (and hence, for N == 2, condition i) does not hold.)
Hence we conclude, formally, that the generator is not a TRNG.
It's fairly easy to construct an algorithmic generator such that
condition ii) holds -- or even such that condition ii) holds for
all strings less than a given (finite) length.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: hardRandNumbGen
Date: 3 Feb 1999 14:34:40 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On 1 Feb 1999 08:55:04 -0500, [EMAIL PROTECTED] (Patrick Juola)
>wrote:
>
>>>Then you accept bad generators and reject good ones.
>
>>Absolutely. With a particular, known, measured probability.
>
>I am not as concerned about rejecting good TRNGs as accepting bad
>RNGs, although you aren't gonna do a lot of OTP encryption when your
>tests keep rejecting good TRNGs all the time. And your tests will
>eventually reject every TRNG you test long enough (I assume correctly
>that will sumbit your RNG to tests periodically).
Ooooooh, repeated testing! Now that's a different kettle of fish.
Actually, I don't need to necessarily reject every TRNG eventually;
I "know" that a given TRNG will fail 1/20 of the tests at a 5%
level, so if I get an approximate failure rate of 1 in 20, then
I keep that one.... and I reject, paradoxically enough, a generator
that doesn't fail 5% of the tests on repeated testing.
And of course, that itself constitutes a meta-test that itself can
be passed or failed with some probability. Eventually along that
path lies madness.
But the point is for any well-defined testing scheme, I can make
the probability that a good generator will fail as small as I
like, to the point where the expected number of functioning generators
that I throw out in my professional lifetime is less than 1 (or less
than 1/1000 of a generator, for that matter).
That's not a problem. Yes, *eventually* I will throw out a working
generator. But I'll run out of solar energy to power the testing
equipment at some point, too.
>The specification for the OTP does not permit accepting bad RNGs with
>any statistical measure that yields a probability other than zero.
In that case, you'll never get one. Statistics -- nor engineering
practice, for that matter -- will never allow you to get a probability
all the way down to zero. The best I can do is to get the probability
down to darn-small, where I accept one bad generator per million
lifetimes. There comes a point where keeping a secret becomes silly;
I think the point where you're no longer worried about the NSA and
are now considering Buddha qualifies.
>For example, earlier you criticized rejecting the sequence 000...0 for
>use as a complete pad on the basis that it would permit the
>cryptanalyst to rule out one possible decryption, and yet that string
>would certainly be cause for rejecting all TRNGs that produced it,
>based on statistical tests.
Depends on how often it was produced. Give me a million 20 bit sequences
and I'll bet I can find one. If I find 500,000, I'll worry.
-kitten
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Loony question
Date: Thu, 04 Feb 1999 19:19:47 +0800
"Trevor Jackson, III" wrote:
>
> Michael Sierchio wrote:
>
> > AbsolutAF3 wrote:
> > >
> > > >Would a particularly awful track off a CD with a lot of
> > > >screeching guitars and howling monkeys be a decent source
> > > >of random numbers?
> > >
> > > It really depends on your use of the numbers
> >
> > It depends on nothing. Any published "text" is a bad starting
> > place for randomness -- if your post has anything to do with
> > sci.crypt.
> >
> > read RFC 1750 - Randomness Recommendations for Security
> >
> > esp. these sections
> >
> > 4.3 The Fallacy of Complex Manipulation.................. 8
> > 4.4 The Fallacy of Selection from a Large Database....... 9
>
> Do you believe that these considerations apply to the random numbers
> CD-ROM?
If it's published, *of course*. Get your own random numbers.
Nate
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Crypto mailing lists
Date: Fri, 05 Feb 1999 13:33:06 +0100
Dan Moniz wrote:
>
> In any event, I was looking for such a list. It would be great if it
> included off-shore (from the US anyways) lists like aucrypto.
Of the non-US lists there is the ukcrypto, as far as I know. There
are certainly others, probably not all in English.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Random numbers generator and Pentium III
Date: Fri, 05 Feb 1999 12:34:24 GMT
Reply-To: [EMAIL PROTECTED]
On 3 Feb 1999 12:00:44 -0500, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>>Anyway, all numbers produced by a properly functioning TRNG are valid
>>output, so the number you just alluded to is a valid output, yet you
>>would have shut the TRNG down if it had occured.
>Yes, but the chances of that happening are smaller than the chance
>of the generator being hit by lightning.
Not if it is caused by a shorted output.
>So don't worry about it.
The purpose of correct analysis is to lessen worry. IOW, you worry in
advance so you don't have to worry later.
Bob Knauer
"Sometimes it is said that man cannot be trusted with the government
of himself. Can he, then, be trusted with the government of others?"
--Thomas Jefferson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Java random
Date: Fri, 05 Feb 1999 07:33:20 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
> Even if you hadn't told the entire world, it's still a bad idea
> to rely on "obscurity" for protection. The enemy could get hold
> of a copy of your client program and disassemble it to find out
> how it works.
In thread sci.crypto.Need Help. Need Protocol Advice, I pretty much found
out that obscurity is the only security software crypto implementations can
offer, what little security it is. Lines can be tapped to gather the data
stream, and clients can be decompiled, etc. I came up with only a partial
solution.
Why conform?
...by the way, where are we going? And why am I in this handbasket?
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CI and Letter Freq for other languages
Date: Fri, 05 Feb 1999 13:36:59 +0100
ChaosX wrote:
>
> I was wondering if anybody knows a URL or a reference book that contains
> Letter Frequencies for English and other languages. Also, could anyone
Take a look at F. L. Bauer, Decrypted Secrets, Springer-Verlag.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 3 Feb 1999 09:23:12 -0500
In article <01be4ee4$a8c2c7c0$[EMAIL PROTECTED]>,
John Feth <[EMAIL PROTECTED]> wrote:
>
>Jumpin' Jehoshaphats Bob, since I want you to think I'm right and not smug
>(my mom would just hate that!), I'm going to remind you just one more time
>that dividing random strings into True Random Numbers and Pseudo Random
>Numbers creates a distinction without a difference since no test exists to
>distinguish them.
It's not a distinction without a difference. You're just doing the
wrong test. There's a test to distinguish Chryslers from Fords.
But it's not a test you're going to perform by measuring the gas mileage.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Random numbers generator and Pentium III
Date: 3 Feb 1999 12:00:44 -0500
In article <[EMAIL PROTECTED]>,
R. Knauer <[EMAIL PROTECTED]> wrote:
>On Tue, 02 Feb 1999 15:12:30 -0600, Jim Felling
><[EMAIL PROTECTED]> wrote:
>
>>I do not suggest a selection of 'bad' and 'good' strings. However, if one takes say
>>10^6 bits and finds that 6*10^5 of them are 1 and 4*10^5 are 0, the odds that you
>>are in possession of a working generator are so low as to be effectively 0. Similar
>>reality check statistics must also be satisfied for me to rely on any generator.
>
>Numbers that are presumed to be random can have long runs of one
>digit.
>
>Anyway, all numbers produced by a properly functioning TRNG are valid
>output, so the number you just alluded to is a valid output, yet you
>would have shut the TRNG down if it had occured.
Yes, but the chances of that happening are smaller than the chance
of the generator being hit by lightning.
So don't worry about it.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Crossposted-To: alt.iomega.zip.jaz,alt.iomega.zip.jazz
Subject: Re: What cipher is used by iomega in ZIP products ?
Date: 5 Feb 1999 12:05:50 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Paul Rubin ([EMAIL PROTECTED]) wrote:
> In article <[EMAIL PROTECTED]>,
> Geoffrey Milos <[EMAIL PROTECTED]> wrote:
> >Can anyone shed some light on which cipher Iomega uses to encrypt data
> >when a ZIP drive is password protected ? It troubles me that this
> >info is not revealed on their www site (at least, I couldn't find it
> >there).
> The data is not encrypted. The passwords are quite easy to defeat.
... using an everyday household object, in fact ;-)
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
** 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
******************************
