Cryptography-Digest Digest #779, Volume #10 Tue, 21 Dec 99 17:13:01 EST
Contents:
Re: Analogue encryption (Jim)
Re: Q: transcendental pad crypto (Bob Silverman)
Re: Microsoft- PKI/E-comm Director Opening ([EMAIL PROTECTED])
Re: Not All Sophie Germain Primes Are "Safe". (Bob Silverman)
Re: ElGamal Opinions, Please (Bob Silverman)
Schoof's algorithm ("Michael Scott")
Re: Non-linear PRNGs ("Matt Timmermans")
unbreakable? (chuck davis)
Re: unbreakable? (John Savard)
Re: DES as pseudo random number generator (Eric Lee Green)
Re: How do you know if you found a key? (John Savard)
Re: Good way to one-way encrypt? (Eric Lee Green)
Re: How do you know if you found a key? (Darren New)
Re: Q: transcendental pad crypto (David Wagner)
Re: ElGamal Opinions, Please ("David")
Re: --- sci.crypt charter: read before you post (weekly notice) (chuck davis)
Re: How do you know if you found a key? (Greg)
Re: How do you know if you found a key? (Greg)
Re: How do you know if you found a key? (Greg)
Re: DES as pseudo random number generator ("Trevor Jackson, III")
----------------------------------------------------------------------------
From: amadeus @DELETE_THIS.netcomuk.co.uk (Jim)
Subject: Re: Analogue encryption
Date: Tue, 21 Dec 1999 19:18:03 GMT
Reply-To: Jim
On 20 Dec 1999 20:50:41 GMT, [EMAIL PROTECTED] (Paul Rubin) wrote:
>In article <83kkt8$[EMAIL PROTECTED]>, dls2 <[EMAIL PROTECTED]> wrote:
>><amadeus @DELETE_THIS.netcomuk.co.uk (Jim)> wrote:
>>> <[EMAIL PROTECTED]> wrote:
>>> > If a pseudo one time pad is used to generate a waveform
>>> > that overlays a voice could this ever be as percievably
>>> > secure as digital encryption?
>>>
>>> No. Which is why all serious ciphony systems are digital or
>>> at worst digitally-coded and encrypted vocoders. (And if
>>> you've ever used a secure 'phone incorporating a vocoder,
>>> you'll know why I said 'at worst' !!!)
>>
>>I've never used a secure phone incorporating a vocoder,
>>so why did you say "at worst"?
>
>You can try a software-based one from http://www.lila.com/nautilus/
>
>Hardware-based phones sound quite a bit better, though there is
>still some difference from an unencrypted phone from the slight
>delay created by the vocoder. It's similar to a digital cellular
>phone.
Thanks, but I wasn't using ciphony from home, don't need it.
Why does it use a vocoder? To keep the bandwidth down?
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Q: transcendental pad crypto
Date: Tue, 21 Dec 1999 19:15:03 GMT
In article <83m4t3$[EMAIL PROTECTED]>,
"dls2" <[EMAIL PROTECTED]> wrote:
> "John Savard" <[EMAIL PROTECTED]> wrote:
> > "dls2" <[EMAIL PROTECTED]> wrote:
> >
> > >Do transcendental numbers qualify as pseudo-random, or
> > >as truely-random, for purposes of one-time pads?
> >
> > Pseudo-random, since calculating the value of a transcendental
> > number is a deterministic process. And an inefficient one, for the
> > level of security provided.
>
> If there are an infinite number of transcendental numbers, then I fail
> to see why. If the transcendental is picked randomly,
Let me try to put an end to this nonsense before it goes any further.
(1) There are very few numbers in mathematics that are actually KNOWN
to be transcendental. One can indeed construct infinitely many
transcendentals based on Liouville's theorem or from Thue's theorem.
But such numbers are USELESS for cryptographic purposes: they have
predicatable digit patterns and they are NOT normal numbers.
(2) Since there are so few transcendentals known that would be useful
for cryptography (useful because they are normal or believed to be
normal), then using one as a basis for a one-time pad is fruitless.
If someone discerns that you might be using a transcendental as the
basis for a OTP, then it would be too easily guessed; there are not
enough of them known.
A reasonable alternative might be to use (say) 10000 digits from
an ALGEBRAIC irrational starting at its (say) 40,000'th digit. One
can specify such an irrational just by specifying the coefficients
of its minimal polynomial and some indication as to which conjugate you
are using. Assuming that the degree was large enough and that the
coefficient space was large enough, the keyspace should be large enough
that having an opponent guess your number should be very low
probability.
You do NOT want to start the pad at the first digit, because given
the first few digits, one can make a good guess at the entire number
using e.g. Ferguson/Forcade.
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Microsoft- PKI/E-comm Director Opening
Date: Tue, 21 Dec 1999 19:16:59 GMT
In response to all of you... yes, this really is from Microsoft, and
yes, we do regularly look for people in newsgroups, conferences,
membership lists etc. It seems most of the smartest most passionate
people are on-line talking about the issues that are important to them
so we try to advertise to those communities as much as possible. I know
sometimes it can seem that it is difficult to find a real person in a
company of this size--- but I assure you, if you want to contact for
security/PKI job openings here-- it is me..
You are welcome to contact me directly----
Jenna Hall
Internet Recruiting Specialist-- Microsoft
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Not All Sophie Germain Primes Are "Safe".
Date: Tue, 21 Dec 1999 19:24:47 GMT
In article <[EMAIL PROTECTED]>,
Ted Kaliszewski <[EMAIL PROTECTED]> wrote:
> 12/21/1999
> Not All Sophie Germain Primes Are "Safe".
> It is generally assumed that moduli that are constructed
> with Sophie Germain primes (SG) are "safe" in that their factoring is
> difficult. While that assumption is not unreasonable there are,
> it should be noted, certain exceptions.
<SNIP> rest deleted....
No flame intended, but the above statement is vacuously true and
has NOTHING to do with "safe primes" or Sophie Germain primes.
(the product of) two randomly chosen Sophie Germain primes will
be cryptographically secure.
What the proposer disguised is that using p1 * p2 where p2 and
p1 are ***RELATED*** is a bad thing.
i.e. using p1 = 2p0 + 1 and p2 = 2p1 + 1.
Firstly I observe that such a pair has unequal bit size and hence is
prohibited by many standards. But this is a red herring.
You NEVER want to choose choose primes q1, q2 such that q1 | q2 - 1
or vice versa. The product q1 q2 is trivially factored with
Pollard P-1. It is the fact that the two primes are not 'independent'
that makes factoring their product easy. It has nothing to do with
their being "safe primes"
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: ElGamal Opinions, Please
Date: Tue, 21 Dec 1999 19:31:58 GMT
In article <TOs74.596$pf1.1005@client>,
"David" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am charged with the task of encrypting session key using a public
key
> algorithm.
>
> We have opted away from RSA, since the still pending patent entails a
large
> cost to use.
Huh? There seems to be some confusion. The only thing "pending"
about the RSA patent is its expiration in the fall of 2000. It
certainly is NOT a "pending patent"
> Management here is now leaning towards ElGamal, which seems to
> be free to use.
>
> Can I have your opinions as to the suitability of this idea?
ElGamal with a 1024 bit key certainly possesses adequate security.
But as to whether it is actually suitable, noone can answer without
your first answering "suitable for what?". What application did
you have in mind? "encrypting session keys" is just too vague.
Is speed of encryption/decryption an issue? Is size of certs an issue?
etc. etc. You leave too much unsaid to be able to reasonably answer
your question.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Schoof's algorithm
Date: Tue, 21 Dec 1999 19:49:38 -0000
Our implementation of Schoof's algorithm for counting points on an elliptic
curve over GF(p) has been improved.
When originally announced it took 100 minutes on a 180MHz Pentium Pro to
count the points on a 160-bit curve - now it takes less than 20 minutes. It
takes about 6 hours for a 256 bit curve.
Our implementation of the always-superior Schoof-Elkies-Atkin algorithm
originally took more than 27 hours to count the points on a 512-bit curve,
now it averages about 7.5 hours. Note that the SEA algorithm is always
superior, but a little more awkward to use.
See the URL below for details.
Mike Scott
=====================
Fastest is best.
MIRACL multiprecision C/C++ library for big number cryptography
http://indigo.ie/~mscott
------------------------------
From: "Matt Timmermans" <[EMAIL PROTECTED]>
Subject: Re: Non-linear PRNGs
Date: Tue, 21 Dec 1999 14:15:10 -0500
Mok-Kong Shen wrote in message <[EMAIL PROTECTED]>...
>I have only poor knowledge of BBS, hence a question: What can be said
>of the period of BBS in general? (Would the period be dependent on
>the choice of the seed?) Thanks in advance.
>
Given an RSA modulus N, and an initial seed s, the ith output for BBS is the
least significant bit (or few) of (s^(2^i))%N. The period depends on the
seed, and is some factor of totient(some fator of totient(N)). If you know
the factorization of N and its totient, then you can choose seeds with
totient(totient(N)). If N is the product of strong primes, (2p+1)(2q+1),
you can choose seeds with period (p-1)(q-1)
------------------------------
Date: Tue, 21 Dec 1999 11:49:03 -0800
From: chuck davis <[EMAIL PROTECTED]>
Subject: unbreakable?
Hello to the group. I got an email from England this morning that really
excited me. My code (at discovervancouver.com) is beginning to stir some
interest. I'm no cryptographer, believe me, but I've developed a cipher
that has been up for more than five months with no winner yet.
The prize for cracking it goes up one cent a minute, and at the moment
it's over $2,200 Cdn. There are no gimmicks, no commercial tie-ins, just
a simple, honest challenge. The company I work for, Stratford Internet
Technologies, let me do this to humor me.
Have a look at discovervancouver.com and try to Crack the Code. The
solution is a single sentence from a well-known English-language
encyclopedia.
Absolutely no clues will be given.
Cheers,
Chuck Davis
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: unbreakable?
Date: Tue, 21 Dec 1999 13:01:02 GMT
chuck davis <[EMAIL PROTECTED]> wrote, in part:
>Hello to the group. I got an email from England this morning that really
>excited me. My code (at discovervancouver.com) is beginning to stir some
>interest. I'm no cryptographer, believe me, but I've developed a cipher
>that has been up for more than five months with no winner yet.
>The prize for cracking it goes up one cent a minute, and at the moment
>it's over $2,200 Cdn. There are no gimmicks, no commercial tie-ins, just
>a simple, honest challenge. The company I work for, Stratford Internet
>Technologies, let me do this to humor me.
Thank you for letting us know about this challenge. Someone was
already here looking for help in breaking the message.
A short enough message can be unbreakable, even if the cipher method
used wouldn't be invincible for, say, *hundreds* of messages. However,
I suspect that you'll have a winner in a little while.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: DES as pseudo random number generator
Date: Tue, 21 Dec 1999 13:07:18 -0700
"Trevor Jackson, III" wrote:
> > you wish to use DES as your PRNG, key DES from your random input and then run
> > DES in CFB/counter mode. This will give you a cycle time of 2**64, but that's
> > still better than most PRNG's.
>
> You are overstating your case here. 64 bits is small for most reasonable PRNGs.
> Marsaglia's PRNG library consists of a bunch of one-line PRNGs and I believe they are
> all much larger than 64 bits..
I think you are, in turn, overstating YOUR case. "reasonable" PRNGs are still
a rarity. I have examined the source for the rand() function that's in the
FreeBSD and Linux "C" libraries, for example, and it has a 2^31 cycle time
(not to mention only 2^32 initial states!). Similarly, the "whrand()" library
included with Python has 2^24 initial states, and a cycle time of 2^45.
I by no means believe that DES is a good choice for use in a PRNG. 3DES with
periodic re-keying, or AES with its 128-bit block size, would be preferable.
On the other hand, that wasn't the issue, the issue was how he intended to use
DES, not whether using DES was a good idea in the first place!
--
Eric Lee Green [EMAIL PROTECTED]
http://members.tripod.com/e_l_green/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: How do you know if you found a key?
Date: Tue, 21 Dec 1999 13:03:48 GMT
Greg <[EMAIL PROTECTED]> wrote, in part:
>If you take random data, and you encrypt it with DES, then
>you search for the key using any and all known attacks, how
>do you know when you found the right key?
You must either know what the plaintext is, or at least be able to
recognize it (the source data should not be random - it could be text)
to know you have the right key.
But if the random data is used for something _else_, for example, as
an OTP key later on, then you *can* tell you've found the right
key...decrypt, then XOR the result with the other message, and when
plaintext comes out of _that_ you've found the right key. So even
though it *is* impossible to crack encryption of random data, that
isn't something you can _use_ to make encryption of other information
invincible.
John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: Good way to one-way encrypt?
Date: Tue, 21 Dec 1999 13:12:16 -0700
Christoffer Lern� wrote:
> What's the best way of encrypting it?
Probably an off-the-shelf one-way cryptographically-strong hash function such
as SHA or MD5.
Note that if you're a server expecting to get this hash over a network, you
first want to transmit a random challenge string, and have the client hash
that challenge string into the already-hashed value prior to sending it over
the network. This prevents someone from capturing the already-hashed value and
replaying that sequence of packets to you later in order to break your
security.
For more security, I suggest using a public key encryption algorithm. The
client first encrypts the digest using his private key, then encrypts the
digest using the server's public key. The server then decrypts using his
private key, then decrypts using the client's public key in order to verify
that the digest was, indeed, transmitted by the client.
Eric Lee Green [EMAIL PROTECTED]
http://members.tripod.com/e_l_green
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: How do you know if you found a key?
Date: Tue, 21 Dec 1999 20:45:08 GMT
> If you encrypted a credit card number (with the checksum removed) by simple
> repeated xor of a key then the key can't be found as there is no indication
> to successful decryption.
Sure there is. Put the checksum back on and check if the credit card number
is valid (in the sense of being able to be charged).
--
Darren New / Senior Software Architect / Dai Ye
San Diego, CA, USA (PST). Cryptokeys on demand.
"Perl - The BASIC of the 90's"
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Q: transcendental pad crypto
Date: 21 Dec 1999 13:06:27 -0800
In article <83ojjk$6eb$[EMAIL PROTECTED]>, Bob Silverman <[EMAIL PROTECTED]> wrote:
> A reasonable alternative might be to use (say) 10000 digits from
> an ALGEBRAIC irrational starting at its (say) 40,000'th digit.
Are there any lattice reduction attacks on this approach?
------------------------------
From: "David" <[EMAIL PROTECTED]>
Subject: Re: ElGamal Opinions, Please
Date: Tue, 21 Dec 1999 15:08:52 -0600
Bob Silverman wrote in message <83okjf$794$[EMAIL PROTECTED]>...
>Huh? There seems to be some confusion. The only thing "pending"
>about the RSA patent is its expiration in the fall of 2000. It
>certainly is NOT a "pending patent"
Wrong word perhaps. My point: to implement it before next fall costs a lot
of money.
>ElGamal with a 1024 bit key certainly possesses adequate security.
>But as to whether it is actually suitable, noone can answer without
>your first answering "suitable for what?". What application did
>you have in mind? "encrypting session keys" is just too vague.
>Is speed of encryption/decryption an issue? Is size of certs an issue?
>etc. etc. You leave too much unsaid to be able to reasonably answer
>your question.
Basically, we want to distribute a file in an encrypted format. I believe
we want to use the "digital envelope" technique of enciphering the data with
a symmetric key, and distributing that key encrypted via PK encryption. For
that, we are looking at ElGamal.
The truth is that the main goal here may more be tamperproofing the data
file, but mgmt does not want the data sent in plaintext. Hence, signatures
are not the solution. They want it PK encrypted.
At the same time, we _don't_ have any expectation that the end user will
have any desire to make any attempt an attack. Yes, this is beginning to
sound like overkill then, but mgmt wants PK encryption.
The end user app only has to run this code upon initialization - so speed is
not critical.
I'm looking at the freeware Crypto++ package, but it is not documented well
enough for a novice to learn cryptography from :�) I do have Triple DES
working via that package, though. The ElGamal is less intuitive to me and I
am not finding any abundance of information on it. That is why I am here!
TIA for your information!
>--
>Bob Silverman
>"You can lead a horse's ass to knowledge, but you can't make him think"
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
------------------------------
Date: Tue, 21 Dec 1999 13:26:58 -0800
From: chuck davis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: --- sci.crypt charter: read before you post (weekly notice)
Dan: I hope you can take a moment to advise me. Reading your FAQ note I
realize I may have inadvertently breached site etiquette. I got an e-mail
from Paul Johnstone, in England, who had seen a code I created at
discovervancouver.com, and suggested I let other people on sci.crypt know
about it. The prize for cracking the code goes up a cent a minute, and is now
more than $2,200 Cdn.
So I put in a notice about it into sci.crypt (although I haven't seen it
appear yet!)
I want the cryptanalysis world to know about the code, but I didn't want to
intrude into a news group devoted to technical analyses or whatever.
There's no gimmicks with the code, no commercial tie-ins, just an honest
challenge. Is there somewhere I can tell code-crackers everywhere about this
thing?
Chuck Davis
"D. J. Bernstein" wrote:
> sci.crypt Different methods of data en/decryption.
> sci.crypt.research Cryptography, cryptanalysis, and related issues.
> talk.politics.crypto The relation between cryptography and government.
>
> The Cryptography FAQ is posted to sci.crypt and talk.politics.crypto
> every three weeks. You should read it before posting to either group.
>
> A common myth is that sci.crypt is USENET's catch-all crypto newsgroup.
> It is not. It is reserved for discussion of the _science_ of cryptology,
> including cryptography, cryptanalysis, and related topics such as
> one-way hash functions.
>
> Use talk.politics.crypto for the _politics_ of cryptography, including
> Clipper, Digital Telephony, NSA, RSADSI, the distribution of RC4, and
> export controls.
>
> What if you want to post an article which is neither pure science nor
> pure politics? Go for talk.politics.crypto. Political discussions are
> naturally free-ranging, and can easily include scientific articles. But
> sci.crypt is much more limited: it has no room for politics.
>
> It's appropriate to post (or at least cross-post) Clipper discussions to
> alt.privacy.clipper, which should become talk.politics.crypto.clipper at
> some point.
>
> There are now several PGP newsgroups. Try comp.security.pgp.resources if
> you want to find PGP, c.s.pgp.tech if you want to set it up and use it,
> and c.s.pgp.discuss for other PGP-related questions.
>
> Questions about microfilm and smuggling and other non-cryptographic
> ``spy stuff'' don't belong in sci.crypt. Try alt.security.
>
> Other relevant newsgroups: misc.legal.computing, comp.org.eff.talk,
> comp.org.cpsr.talk, alt.politics.org.nsa, comp.patents, sci.math,
> comp.compression, comp.security.misc.
>
> Here's the sci.crypt.research charter: ``The discussion of cryptography,
> cryptanalysis, and related issues, in a more civilised environment than
> is currently provided by sci.crypt.'' If you want to submit something to
> the moderators, try [EMAIL PROTECTED]
>
> ---Dan
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: Tue, 21 Dec 1999 21:43:58 GMT
> If you encrypted a credit card number (with the checksum removed) by
simple
> repeated xor of a key then the key can't be found as there is no
indication
> to successful decryption.
>
> However most plaintext has headers such as "dear sir" or file type
> indicators. These are present even in the streams of compressors and
can be
> picked up by an analyst.
So you would agree that given a set of bytes that have no
noticeable or distinguishable characteristics, there is no
way to determine if the key has been found?
For public key encryption, it seems that the key is found
when the math puzzle is solved, regardless of the cipher
text. But I am refering to symmetric key encryption where
any key value is possible.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: Tue, 21 Dec 1999 21:38:53 GMT
In article <83n5js$1bd$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> Greg <[EMAIL PROTECTED]> wrote:
> > If you take random data, and you encrypt it with DES, then
> > you search for the key using any and all known attacks, how
> > do you know when you found the right key?
>
> What does the random data mean? is there something else which depends
> on it which can act as a check on your decryption?
Assume that it is just random and means nothing. Really.
This is the case I am asking about. Can you know when you
found the key that produces that specific random data
if you do not know what it is you should see?
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: How do you know if you found a key?
Date: Tue, 21 Dec 1999 21:51:12 GMT
In article <83nvfu$546$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>
> > I think by random he means that the file encrypted could be any
possible
> > valid binary file that fits in the space he is encrypting. And in
such a case
> > not knowing anything else about the file. It is impossible to find
the file
> > that was encrypted since each of the 2^56 keys leads to what is as
likely
> > as any other to a possible solution.
>
> OK. I wondered if that were the case, in which case I think you're
right.
> It's just that I'm trying to figure out when such a thing might
actually
> happen.
>
> > However if the cyrpto gods confused the poor man and he was dumb
enough
> > to always run the same bad compressor as in PGP and then encrypt
the file.
> > One can easily find the so called random file (or any file) that
was encrypted
> > since it is likely only one key can lead to a file that could have
been
> > compressed by the method used.
>
> This would be one thing - also he'd have to make sure that his
encryption
> program didn't append some kind of checksum in a known position in the
> file. Because I expect the chances of having the rest of the data
> match such a checksum or hash are pretty small when the key isn't
right.
>
So then the question becomes, what if the plain text file
is encrypted, and then encrypted again? The first encryption
should produce appearant random content with no distinguishing
features to search for.
What I am wondering (to cut to the chase) is how is it that
using DES three times is not as strong as triple DES? My
understanding is that triple DES encrypts, then decrypts then
encrypts again, rather than encrypting three levels deep, and
that the reason is that it is stronger that way.
It seems that if you cannot distinguish the result from decrypting
the second or third level of encryption, then you have to
try EVERY combination of each level with every combination of
every other level to find the final plain text.
Any help understanding why this is not true would be appreciated.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 21 Dec 1999 17:10:48 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: DES as pseudo random number generator
Eric Lee Green wrote:
> "Trevor Jackson, III" wrote:
> > > you wish to use DES as your PRNG, key DES from your random input and then run
> > > DES in CFB/counter mode. This will give you a cycle time of 2**64, but that's
> > > still better than most PRNG's.
> >
> > You are overstating your case here. 64 bits is small for most reasonable PRNGs.
> > Marsaglia's PRNG library consists of a bunch of one-line PRNGs and I believe they
>are
> > all much larger than 64 bits..
>
> I think you are, in turn, overstating YOUR case. "reasonable" PRNGs are still
> a rarity. I have examined the source for the rand() function that's in the
> FreeBSD and Linux "C" libraries, for example, and it has a 2^31 cycle time
> (not to mention only 2^32 initial states!). Similarly, the "whrand()" library
> included with Python has 2^24 initial states, and a cycle time of 2^45.
Sampling error. Nobody serious uses a C-compiler's rand() function. That's a
classical
error that goes back 3-4 decades.
------------------------------
** 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
******************************
