Cryptography-Digest Digest #889, Volume #9 Fri, 16 Jul 99 10:13:02 EDT
Contents:
Re: huffman code length ([EMAIL PROTECTED])
Re: Differences in binary-based conversions. ("User")
Numerical Base Encryption (NBE) ("User")
Re: zip or replacement (Paul Edwards)
Re: DES permutations ([EMAIL PROTECTED])
Re: What is the "real" length of a key in 3-key 3DES? (Nicol So)
Re: randomness of powerball, was something about one time pads (Richard Herring)
Re: Funny News (Rob Warnock)
Re: How Big is a Byte? (was: New Encryption Product!) ("donald tees")
Re: Funny News (Bob Silverman)
Re: Why public key in PGP (Patrick Juola)
Re: How Big is a Byte? (was: New Encryption Product!) (Patrick Juola)
Re: Funny News ([EMAIL PROTECTED])
Re: Differences in binary-based conversions. ([EMAIL PROTECTED])
Re: How to crack monoalphabetic ciphers ([EMAIL PROTECTED])
Re: Compression and security (was: Re: How to crack monoalphabetic ciphers)
([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.compression,alt.comp.compression,sci.math
Subject: Re: huffman code length
Date: Fri, 16 Jul 1999 05:48:30 GMT
At
http://www.compressconsult.com/huffman/#maxlength
I learned that the Fibonacci sequence of frequencies
gives the maximum possible code length.
length of file (# of samples)
maximum code length
2 1
3...4 2
5...7 3
8...12 4
13...20 5
21...33 6
...... ...
1597...2583 15
2584...4180 16
4181... 17
which gives a 16 bit code length
after only 2584 samples of a 17 symbol file
and a 17 bit code length
after only 4181 samples of a 18 symbol file
:-(.
It appears that Tom Lane made the same mistake I did when I figured
that if I used 15 bit counters to count the symbol frequencies, that I
could be guaranteed a minimum frequency
of 1 out of 2^15 and therefore (erroneously) the maximum symbol length
would be about 16 bits. The maximum symbol length could be far longer
than that, so I'm thinking about using the depth-limited near-Huffman
compression Tom
Lane mentioned.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "User" <[EMAIL PROTECTED]>
Subject: Re: Differences in binary-based conversions.
Date: Thu, 15 Jul 1999 23:58:01 -0700
> Just be converting a number to a different base does not omit
> redundancy. Check this out
>
> F O O F F A B E (hex)
> 15 0 0 15 15 10 11 14 (dec)
> 17 0 0 17 17 12 13 16 (oct)
>
> And you should be able to find the base by examining the output and
> seeing which chars appear more frequently. Plus how many bases are
> there that are actually usable?
Hi Tom, I see you are still confused about differences between *numeric
base
conversion* and traditional base conversion. I can see by your example
you are stuck in thinking traditionally when converting between hex, dec,
and oct.
Remember in numerical base conversion, the previous and next symbols
are related to each other... you cant just break it up into pieces like you
did
above. Here is the correct result...
F00FFABE (hex)
4027579070 (dec)
36003775276 (oct)
But this conversion is not good... for really good ones, try to pick bases
that
are unrelated to each other by a power. In your example hex and oct are
related by 2^power.
If you use the virtual calc 99 program, it allows you to easily pick a
different
power... Here are good conversions...
5aKbVO (base 60)
4gl3f6f (base 31)
gcaf1ck (base 25)
6a78bhae (base 18)
201543600014 (base 7)
Note the lack of frequency... where did FF and 00 go? Sort of
disappeared eh? How can you attack this using frequency analysis
when the encrypted symbols do not map to the plaintext symbols directly?
Remember, when using Numerical Base Conversion (NBC), or NBE
(Encryption), the whole message is used for conversion... you cant
chop off pieces of it (especially when you are converting UP a base)
But here is an important point... There is a difference between
converting UP and converting DOWN a base. In some cases, UP
is better, in others, DOWN is better. That is another topic for another
time.
The program Virtual Calc can be gotten at http://www.edepot.com/phl.html
Please use the program, as your examples indicate you can't convert
to a base other than oct, dec, bin, and hex, which does not show the true
power of NBC and NBE.
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: "User" <[EMAIL PROTECTED]>
Subject: Numerical Base Encryption (NBE)
Date: Fri, 16 Jul 1999 00:52:57 -0700
When utilizing Numerical Base Encryption (NBE) as a precursor
to a full fledged encryption algorithm (using block cyphers, or what
have you), you achieve the following...
1) A compression algorithm built in (especially when converting UP)
2) A reduction of frequency (especially when converting to a base unrelated
by power)
3) A powerful encryption mechanism built in (unknown base of plaintext given
an encrypted text) Also, the encrypted text may only be a subset of full
base
of symbols, which makes it even harder to determine base AND symbols
for encrypted text.
Examples showing this...
Plaintext:
this message will be encrypted (base 36)
Encryptedtext (converting UP):
evAazw43k8gwq6915952t7tjf6 (base 37: note reduction of frequency)
8NI9gie5AMHmL2jPLjGnpEV (base 62: note compression: less symbols)
Encryptedtext (converting DOWN):
2976030784a828956414624b7305b252341071 (base 12)
23833567420888026222355431499792166653717 (base 10)
435505063241525136245151056033265226453123406560 (base 7)
10001100000101001100010000111100010010010011010
10011001011111010001111001011110111111101111111
01110110010100001001010111000111100010101 (base 2)
All the above were done with Virtual Calc 99.
It allows single click conversion between bases.
You can download it at http://www.edepot.com/phl.html
Thank you for your attention :)
Remember, NBE is useful as an addition to existing encryption algorithms.
You can use it BEFORE you apply any other algorithms. Choosing
an unknown base deters initial stages of attacks.
Of course, if you wish to use NBE as a full fledged encryption cypher,
here are the possibilites...
add a floating point in your plaintext (especially before the first
character).
do a 1/message. a message^power message/arbitrary number
message xor randommessage.
All these operations are reversible.
And can be done easily with Virtual Calc :)
For fun, try the following encrypted message...
Try to break it first...
1.95Z3xQJKK1qf4py6BAumAwIT7dJTvg
ODPoMIgzurZ9M1vjHMKXVYxkIxT@Hs
U5ibhRCWRzSPZSfjEhjafwCzkDW0tD
ULriT1aBl@5A2@7u2TYOo
if you can't break it, download virtual calc,
select base 64... enter 1/MESSAGE
where MESSAGE is the above encrypted text.
You will then get the plaintext. (I left a message for unbelievers)
I suggest you REALLY try to break it to see how strong
this encryption method is. Note that you can use any
operator on it.. I just happen to choose the most basic...
insertion of a floating point, and an inverse (1/num) operator.
Practical applications:
Streaming cyphers: NBE practical when the bases are related by power.
http://www.edepot.com/phl.html
------------------------------
From: Paul Edwards <[EMAIL PROTECTED]>
Subject: Re: zip or replacement
Date: Fri, 16 Jul 1999 07:37:43 GMT
In article <[EMAIL PROTECTED]>,
fungus <[EMAIL PROTECTED]> wrote:
> > zip -0 -r fred c:\*.*
>
> Is this a "backup"? It won't restore any system files...
Yes, I simplified it for people who didn't know what
the "-S" option was. I assumed people would know
what the "-0" and "-9" options were. An interesting
story there - I once saw someone do a zip -1 -9 ...
I asked them what that meant, and they said they
were using the "-9" because the help (running zip
with no parameters) said that that was "compress
better", which they liked, and they used "-1"
because the help said "compress faster", which
they liked the sound of too!!!!!!!!!
As if someone would write a slow version of the
same software, and that was the default, but you
could choose a fast version if you wanted!
> > If so, can someone suggest a replacement for zip's encryption?
> > Thanks. Paul.
> >
>
> ftp://ftp.artlum.com/pub/crypt.zip (wrote it myself...)
Looks good! I'd rather have a longer password
than use other than lowercase letters. That way
I can easily make up a sentence that no-one can
guess, not even in English (or any language!).
You cited 20 characters for uncrackable forever.
Does this still apply for my sentence, or do I
need more (assuming someone knows that its
lowercase alphas)?
Also, I was a bit confused, can I use the same
password for all my files? It sounded like I could,
because although the algorithm didn't allow it, you
used random numbers to overcome the problem.
One more thing - some people here have suggested
using PGP. I don't have the PGP software, but
assuming I do, is there an advantage in using your
software? Or do I need to create a 100 character
password for PGP in order to acheive the same thing
as yours? Thanks. Paul.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES permutations
Date: Fri, 16 Jul 1999 09:08:59 GMT
In article <7mkf95$4sv$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Matthew Kwan) wrote:
> [EMAIL PROTECTED] writes:
>
> >In article <7mfoqc$n2a$[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> >> In article <7k51r0$gjr$[EMAIL PROTECTED]>,
> >> [EMAIL PROTECTED] wrote:
> >> > > >DES;
> >> > > >1 That initial permutation; is it actualy worth
> >> > anything cryptograpicaly?
> >> > >
> >> > > No. They were put there to support the hardware
> >> > implementation of DES that was popular in the mid-1970s.
> >>
> >> > I've heard and read this several times but while
> >> > being from a hardware background I cannot see how
> >> > the initial permutation could speed up the
> >> > hardware implementation. Does anyone know how it
> >> > helps the hardware?
> >>
> >> It doesn't help hardware. It doesn't take any
> >> time in hardware. (No *extra* time beyond normal wiring
> >> delays)
> >>
> >> What it *does* do is royally slow down any software implementation.
> >> *That* was the point.
>
> No, the point was to amount of chip *space* needed to implement DES.
> The IP made the wiring simpler. Software was probably not a
consideration
> at the time.
But how does it make the wiring simpler? As far as I can see it only
makes it more complicated.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: What is the "real" length of a key in 3-key 3DES?
Date: Fri, 16 Jul 1999 06:43:56 -0400
wtshaw wrote:
>
> And, in practical use, getting a few if any chosen plaintexts is not
> practical.
That depends on the application. In some applications, the adversary
can obtain a large amount of adaptively chosen plaintext-ciphertext
pairs. People who work on these applications are aware of the
possibility and they defend against the threat it poses in their designs
one way or another.
Nicol
------------------------------
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: randomness of powerball, was something about one time pads
Date: 16 Jul 1999 10:33:11 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Tony T. Warnock
([EMAIL PROTECTED]) wrote:
> No, the game as described, 1 euro for 1 die, 2 euros if it occurs twice, 3
> euros if it occurs 3 times is unfair. (of course a fair game in euros may be
> a losing proposition.) This is Chuck-a-Luck.
"Crown and Anchor" is its English name, after the special symbols
on the traditional dice.
--
Richard Herring | <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Rob Warnock)
Subject: Re: Funny News
Date: 16 Jul 1999 11:38:26 GMT
fungus <[EMAIL PROTECTED]> wrote:
+---------------
| Doug Stell wrote:
| > There is little doubt that encryption makes the job of the national
| > security and law enforcement folks more difficult.
|
| http://jya.com/ussc032699.htm
+---------------
Oh, this is a hoot!! Since not everyone will bother to go look, here's
a few of the more interesting snippets:
...probation officers in each federal district court [required] to
"concisely describe any use of encryption or scrambling technology
in the offense conduct section of the presentence report and the
relevance of the defendant's use of this technology to impede the
investigation, prosecution, or sentencing of the case, if any."
...
No cases sentenced during fiscal year 1997 using encryption
technology and receiving sentencing enhancement under U.S.S.C.
para. 3C1.1 have been identified in the U.S.S.C. monitoring datafile.
In an effort to validate this finding, staff ... searched the
Lexis-Nexis and Westlaw federal case law datasets ... search
resulted in a small number of cases, none of which were sentenced
during fiscal year 1997. Secondly, the two agents of the Federal
Bureau of Investigation who authored the attached document
"Encryption: The Impact on Law Enforcement" [PDF 141K] were
contacted. Neither were able to identify a specific case sentenced
in 1997 involving encryption.
Here's where it gets *really* funny! After all, haven't they been telling
us encryption is this terrible, terrible threat to law enforcement? But:
The finding of zero cases at this early stage is not unexpected.
The use of computer encryption to obstruct justice involves
application of an emerging technology, and as such, is likely
still very rare.
"Well, o.k., maybe so, but it'll *be* terrible, just you wait!"
-Rob
=====
Rob Warnock, 8L-855 [EMAIL PROTECTED]
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
------------------------------
From: "donald tees" <[EMAIL PROTECTED]>
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: Fri, 16 Jul 1999 08:01:39 -0400
Nothing is gender-neutral.
Peter Seebach wrote in message ...
>In article <7mlo64$h57$[EMAIL PROTECTED]>,
>donald tees <[EMAIL PROTECTED]> wrote:
>>Interesting that you were the only one to pick up on the she. The
religious
>>ones always make the pious claim that god is sexless, until someone takes
>>them at their word and figures that one adjective is the same as another
>>under the circumstances. You should hear the cries, though, when I use
>>"it". Lip service is a wonderful thing.<G>.
>
>This is partially because "he" is a gender-neutral pronoun in English,
while
>"she" isn't, and "it" is a pronoun for the inanimate. "he" is correctly
used
>both for typeless entities and for male entities.
>
>Another argument against overloading words.
>
>-s
>--
>Copyright 1999, All rights reserved. Peter Seebach / [EMAIL PROTECTED]
>C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
>Will work for interesting hardware. http://www.plethora.net/~seebs/
>Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Funny News
Date: Fri, 16 Jul 1999 12:50:13 GMT
In article <7ml1le$k8a$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7ml163$k1e$[EMAIL PROTECTED]>,
> Bob Silverman <[EMAIL PROTECTED]> wrote:
<snip>
> > Read the (joint) book by Whit Diffie and Susan Landau on the
> > politics of wiretapping.
> >
> > The basic answer is: very little if any.
> >
> > There have been ZERO documented cases where a wiretap has been
> > prevented because of encryption.
>
> Possibly because they have been hidden? What if the NSA cracked a
> message and prevented a crime (or performed an arrest).
I regret I can not reproduce the sigh of exasperation I emit when
I hear statements such as these.
(1) If indeed the NSA cracked a message, then the wiretap was NOT
prevented, was it?
(2) The statement shows gross ignorance of the NSA, what it does, and
what it is allowed to do. The NSA does NOT, repeat, NOT get involved
in domestic law enforcement. They are prohibited from doing so by law.
And there are watchdog committees who watch this quite carefully.
They are NOT allowed to do any sort of domestic surveillance of ANY
kind.
> Would they
> admit they broke the cipher? (now the spooky oooh sound starts...)
If indeed the FBI asked the NSA to break a cipher that the *FBI*
intercepted, and it was a criminal matter that came to court, then you
can be sure that the fact that the NSA broke a cipher would become
public. Trials are public in this country. And you can be sure a
defense attorney would question the validity of any purported
wiretap communication.
Why is it that all these people seem to think the NSA has magical powers
and is above the law???
Give up the paranoia. It is tiresome.
>
> > However, I think the question is, or should be, moot. I paraphrase
> > Ben Franklin:
> >
> > Those willing to give up essential liberty for a little safety are
> > deserving of neither.
>
> That's a good quote. Should staple that to Janet Renos head... Of
> course she does affect me much (unless she visits the GWN much...)
--
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/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Why public key in PGP
Date: 16 Jul 1999 09:03:02 -0400
In article <7mlv56$eg$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
><snip>
>Making new keys per conversation makes no sense whatsoever. I can
>still tap your lines of communication and then factor it later.
Is it worth it for the contents of only one conversation?
>Same
>for symmetrical schemes. The idea in PKC is that I can give you my
>public key and you can send me messages without a secure medium. I
>could publish my public key on a server (whoa neato idea) and others
>could pluck it off when they need it.
The idea, though, is that if you use a different session key for each
session, and only use the 'main' public key for key exchange, then
it may not be worth the effort to attempt to recover the session
keys. I could understand spending several hundred million dollars to
recover Phil Z.'s signing key -- I don't think that I want to spend
that much to recover a single randomly selected message and find out
that he's going to have to change the staff meeting time from 10 to
10:30 next week.
-kitten
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Crossposted-To: alt.folklore.computers
Subject: Re: How Big is a Byte? (was: New Encryption Product!)
Date: 16 Jul 1999 09:16:38 -0400
In article <7mn6o7$cqs$[EMAIL PROTECTED]>,
donald tees <[EMAIL PROTECTED]> wrote:
>Nothing is gender-neutral.
*Everything* is gender-neutral in itself; the gender you choose to
project onto a concept is your own problem.
-kitten
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Funny News
Date: Fri, 16 Jul 1999 13:13:51 GMT
In article <7mn9q1$ea8$[EMAIL PROTECTED]>,
Bob Silverman <[EMAIL PROTECTED]> wrote:
> Why is it that all these people seem to think the NSA has magical
powers
> and is above the law???
>
> Give up the paranoia. It is tiresome.
No way man, you're one of them (hahahahaha)
I think it's because of some things a) movies, b) I ain't in the states
and c) movies.
Even in the X-Files series they got the NSA involved with some stuff a
couple of times. This paranoia is unwarranted i feel because well they
are human too. I don't think they can jump on things (like Dave Scott
says) with unhuman speed and power (i.e factor 200 digit numbers).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Differences in binary-based conversions.
Date: Fri, 16 Jul 1999 12:38:36 GMT
<snip>
NBE is not a good idea and this is why. Most algorithms and protocals
work on a fixed sized input. If your output is a different size I
could guess at what it was. Remember that the output must have the
same number of bits as the input. It doesn't matter how you print it
on the screen!!!
i.e
12341234 (dec)
57047762 (oct)
101111000100111111110010 (bin)
Note that the octal version looks more 'random'. But the binary
representation will never change!!!
Just because I don't know your base doesn't mean I can't get access to
the binary version of the message. It's always there.
I don't see this as a good idea. Even if you only send me the ascii
conversion there are not alot of bases to try before I get the
message. You can't for example use a base larger then the message or
it won't change it. You can't use a base that's too small either...
Tom
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: How to crack monoalphabetic ciphers
Date: Fri, 16 Jul 1999 12:40:33 GMT
In article <7ml6tb$mfq$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <7ml5ks$lud$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
> > If it was compressed, I would perhaps try digram and trigram
frequency
> > analysis. Digrams are two-letter combinations, trigrams are three
> > letter combinations. Since compression works by substituting single
> > characters for digrams, trigrams, and higher, this might work.
>
> So this would be compression algorithm dependant? Most symbols in
> compressed files are not well distributed (although their occurences
> are) so I think that might prove as a somewhat usefull avenue...
>
Yes, I would suppose so since each compression algorithm works
differently.
> >
> > > Would a PRNG passed thru a non-linear (say SAFER style) sbox be
> secure
> > > (if the sbox were private)?
> >
> > Yes, you could do frequency analysis on this also, unless I severely
> > misinterpreted this. However, it would now be a polyalphabetic
> cipher,
> > like vigenere. Granted, it would be a pain to crack, but it is
> > possible. The PRNG has a period which can be determined, though I
> > forget the name of the algorithm to do it. The sbox will not hide
> this
> > fact, so if you XOR the output of the PRNG fed through the sbox and
> the
> > plaintext, you have a complex, though still trivial, XOR cipher.
>
> I meant something like
>
> O = sbox[RNG]
>
> Where the sbox is keyed somehow (you could just perform 256 random
> swaps)..
>
> What you are talking about is
>
> C = S[P xor RNG]
>
> right? This would be just as effective as
>
> C = S[RNG] xor P
>
This is what I thought you were talking about<above>. Since a PRNG has
a period, it will eventually repeat and then it can be analyzed and
broken. This of course assumes you have enough ciphertext. If the PRNG
only repeats itself 5 time, for example, when applied to a plaintext
message, you won't get a good enough analysis. If it repeats 100 times
when applied to a message, you will get a good analysis of the cipher.
> if RNG were truly random (and S is a function). possibly even
>
> C = S[P] xor RNG
>
> if S were unknown you would not learn much about RNG acept
>
> C xor C' = RNG xor RNG'
>
> (Where P = P').
>
> Any other thoughts?
>
> Tom
> --
> PGP key is at:
> 'http://mypage.goplay.com/tomstdenis/key.pgp'.
> Free PRNG C++ lib:
> 'http://mypage.goplay.com/tomstdenis/prng.html'.
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Compression and security (was: Re: How to crack monoalphabetic ciphers)
Date: Fri, 16 Jul 1999 12:40:23 GMT
In article <7mmgdc$ps0$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> If you compress a plain ascii message the average entropy per bit
> goes up so that the when the compressed file is encrypted you should
> have more security then when just encypting the plain ascii message.
> However most encryption methods like PKZIP have header information
> that leak data and make it easier to break. For example a PKZIP
> compressed file has the ascii bytes "PK" as the first two bytes of the
> file. Also most compressed files have other attributes that leak
information.
> So that if an analysist would be able to rule out many keys from the
> solution if it is known that a compressed file is used. If one used an
> encryption method like scott19u.zip since every byte of the file
affects
> output you still gain some security even if you used pkzip. However
> if one used short block AES types of codes you should use a headerless
> compression scheme as described on my web page.
Just because the entropy per byte goes up doesn't mean the entropy per
bit goes up. I think that's what his point was (and he's right).
Tom
--
PGP key is at:
'http://mypage.goplay.com/tomstdenis/key.pgp'.
Free PRNG C++ lib:
'http://mypage.goplay.com/tomstdenis/prng.html'.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
** 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
******************************
