Cryptography-Digest Digest #594, Volume #11 Fri, 21 Apr 00 13:13:01 EDT
Contents:
Net::SSLeay local install ([EMAIL PROTECTED])
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Will Dickson)
Re: Requested: update on aes contest (DJohn37050)
Re: Stop User Impersonation with Encryption ("C. Prichard")
Can a password be to long? (John)
Primality Test-how many iterations suffice for n digit number ? ([EMAIL PROTECTED])
Re: Q: complementation priority of DES (John Savard)
Re: Stop User Impersonation with Encryption (Tom St Denis)
Re: new Echelon article ([EMAIL PROTECTED])
Re: Can a password be to long? (Joe Durusau)
Re: Can a password be to long? (Tom St Denis)
Re: The Illusion of Security (Mike Kent)
Re: The Illusion of Security ("Douglas A. Gwyn")
Re: Requested: update on aes contest ("Douglas A. Gwyn")
Re: Problems with OAP-L3 ("Douglas A. Gwyn")
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: Primality Test-how many iterations suffice for n digit number ? (Tom St Denis)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: The Illusion of Security (Tom St Denis)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Net::SSLeay local install
Date: Fri, 21 Apr 2000 12:02:36 GMT
Hi,
Does anyone know if Net::SSLeay can be installed in a local directory on
a host such as /home/domain/www/cgi-bin/Net
or maybe I should try using something else besides Net::SSLeay for
https_post?
Can you help?
Thanks,
Wes
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Will Dickson)
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 12:39:41 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
>> You asked me to write a paper. Guess what? There are probably
>> a dozen papers already written on OAP-L3. One is at NSA, another
>> at MI 6, one is in Moscow, another in Tokyo, ... But don't hold
>> your breath waiting for one of these to be published.
Clearly his understanding of government agencies is equalled only by
his grasp of cryptography. MI6 (UK) do not do cryptanalysis and
signals intelligence (assuming that's even what they call themselves -
opinion is divided and they have no comment to make on the subject, as
with everything else!). That's GCHQ's job. My suspicion is that
they're actually _funding_ him. Doubtless many others have had this
thought too :-)
>
>Lastly, what is with this '100,000 bit key' thingy you state on your
>page. That's an obvious sign of snake oil.
Yep, got to be GCHQ or the London zoo reptile house - apparently
they've got a outbreak of dry skin over there, and need all the
unguents they can get hold of...
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Requested: update on aes contest
Date: 21 Apr 2000 13:43:35 GMT
Everyone interested should submit comments to NIST. They MIGHT read them here,
but they WILL read them there.
Don Johnson
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Crossposted-To:
alt.ecommerce,alt.internet.commerce,alt.invest.technical-analysis.omega,alt.perl
Subject: Re: Stop User Impersonation with Encryption
Date: Fri, 21 Apr 2000 15:26:39 GMT
Its possible to track different keys for each frame and refresh each =
frame's tags key when the frame is updated.
This will make it possible to achieve site security in the sense that =
all logged users will be allowed to use only links presented to them.
The system is subject to a timeout condition that can be made relatively =
short to reduce the possibility that the necessary "impersonation =
information" can be transferred to another user.
If a user does begin to accurately impersonate another user, the =
original user will lose the correct frame-key and begin to contend for =
it with his impersonator. Errors will result with each response that has =
the wrong tagkey. Considering this performance, the system could be =
considered acceptable for disbursement of "paid-for" information and =
entertainment.
This makes for a highly secure website without tracking cookie =
information on the client side. Server-side information retains a user's =
identity and password and group status. The password is his =
authentication, and there is nothing else to program to maintain each =
user's unique system identity. The uniquely encrypted tags assure that =
no more than one other user can ever successfully contend for the same =
user identity, and they also ensure that such contention would most =
likely be a result of willful collaboration between both users to permit =
such impersonation.
-Charles Prichard
www.greentv.com
------------------------------
Subject: Can a password be to long?
From: John <[EMAIL PROTECTED]>
Date: Fri, 21 Apr 2000 08:31:01 -0700
I know passwords can be to shrot, but I recall reading
somewhere, a long time ago, about being to long. Is this true.
http://www.aasp.net/~speechfb
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: [EMAIL PROTECTED]
Subject: Primality Test-how many iterations suffice for n digit number ?
Date: Fri, 21 Apr 2000 15:28:19 GMT
Hi all,
As a part of the project, I implement prime-number tests
Division by small primes - Lucas - Lehmann - Miller& Rabin ... etc
(Frobenius Primality Test sounds ok but finite field knowledge is
necessary. )
Then number of parameters become important.
I know that when I implement MilRob for one base - prob that i will fail
0.25, in Lehman(Euler) 0.5; Lucas 5/16, Frobenius 1/7710
R.G.E.Pinch suggests that I should take n bases for n digit number.
Any other suggestions, reccomendations ?
If I implement Lucas & Miller-Robin together how many iterations
suffice?
any reference ?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Q: complementation priority of DES
Date: Fri, 21 Apr 2000 15:36:41 GMT
On Fri, 21 Apr 2000 00:29:14 -0500, J <[EMAIL PROTECTED]> wrote:
>Can you explain to me how I prove it ?
It's really very simple. Each round of DES operates like this:
L <- L xor f( R xor K )
and then L and R are swapped. The subkeys are made by picking bits out
of the key. So, if both the block and the key are complemented, so
that L' = not L, R' = not R, and K' = not K, then, since not R xor not
K equals R xor K, the f-function produces the same output, having had
the same input.
If you XOR not L with the same thing as you XORed L, then you are
inverting the same bits, so the result is also the NOT of the previous
result. So the condition L' = not L, R' = not R, and K' = not K is
preserved from round to round.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To:
alt.ecommerce,alt.internet.commerce,alt.invest.technical-analysis.omega,alt.perl
Subject: Re: Stop User Impersonation with Encryption
Date: Fri, 21 Apr 2000 16:01:03 GMT
Stop posting the same garbage...
Tom
"C. Prichard" wrote:
>
> Its possible to track different keys for each frame and refresh each frame's tags
>key when the frame is updated.
>
> This will make it possible to achieve site security in the sense that all logged
>users will be allowed to use only links presented to them.
>
> The system is subject to a timeout condition that can be made relatively short to
>reduce the possibility that the necessary "impersonation information" can be
>transferred to another user.
>
> If a user does begin to accurately impersonate another user, the original user will
>lose the correct frame-key and begin to contend for it with his impersonator. Errors
>will result with each response that has the wrong tagkey. Considering this
>performance, the system could be considered acceptable for disbursement of "paid-for"
>information and entertainment.
>
> This makes for a highly secure website without tracking cookie information on the
>client side. Server-side information retains a user's identity and password and group
>status. The password is his authentication, and there is nothing else to program to
>maintain each user's unique system identity. The uniquely encrypted tags assure that
>no more than one other user can ever successfully contend for the same user identity,
>and they also ensure that such contention would most likely be a result of willful
>collaboration between both users to permit such impersonation.
>
> -Charles Prichard
> www.greentv.com
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: [EMAIL PROTECTED]
Date: Fri, 21 Apr 2000 15:31:53 GMT
On Wed, 15 Mar 2000 06:22:08 GMT, jungle <[EMAIL PROTECTED]> wrote:
>the correct link is
>http://www.wired.com/news/politics/0,1283,34932,00.html
Another one:
"We need to act now to minimize the risk to national security and
public safety, cut short the widespread use of encryption that is
inaccessible to law enforcement, spur the development of key recovery,
and assure that U.S. products retain their market dominance
worldwide."
-- John Deutch, CIA, Memorandum for the President and Vice President,
September 11, 1996
Selected pertinent paragraph from:
http://cryptome.org/cia-gak.htm
What U.S. products from what specific U.S. companies do you refer to
Mr. Deutch???
------------------------------
From: Joe Durusau <[EMAIL PROTECTED]>
Subject: Re: Can a password be to long?
Date: Fri, 21 Apr 2000 12:09:02 -0400
It tends to be a religious issue with admins, but the most
common problems are that with long passwords, users will:
1)Use some easily remembered or guessed sentence, or
2)write them down somewhere they can be easily found, or
3) Something equally intilligent.
If you are dealing with unix-like systems, many of them
will ignore more than some small number of characters in the
password anyway, so makeing them longer doesn't help.
If you have a huge password and all of it is used,
another problem might be that many crypto systems suffer if
you encode a lot in a single key. Many systems have fallen
in the past because they used a single key for a very long
time and eventually, enough data was accumulated to allow them
to be broken.
IMHO, the problem cited in # 2 above is the real
killer.
Speaking only for myself,
Joe Durusau
John wrote:
>
> I know passwords can be to shrot, but I recall reading
> somewhere, a long time ago, about being to long. Is this true.
>
> http://www.aasp.net/~speechfb
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Can a password be to long?
Date: Fri, 21 Apr 2000 16:11:09 GMT
John wrote:
>
> I know passwords can be to shrot, but I recall reading
> somewhere, a long time ago, about being to long. Is this true.
>
> http://www.aasp.net/~speechfb
>
> * Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
> The fastest and easiest way to search and participate in Usenet - Free!
Well most systems only allow a password of maximum length, for example
unix (does it still?) has a 8 char limit on the password. Technically
speaking a password can't be 'too long' but it may become difficult to
remember.
Tom
------------------------------
From: Mike Kent <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: The Illusion of Security
Date: Fri, 21 Apr 2000 16:24:04 GMT
Tom St Denis wrote:
> UBCHI2 wrote:
...
> > Intractable math problem are only in the eye of the beholder. How many of you
> > would have thought that the enigma could be broken?
>
> This is amazingly false.
Hmmm, it's _very probably_ amazingly false.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Fri, 21 Apr 2000 14:10:54 GMT
UBCHI2 wrote:
> He's probably right for the wrong reasons. Nothing but the one
> time pad has ever worked in cryptography for any length of time.
Wrong on several counts!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Fri, 21 Apr 2000 14:13:54 GMT
lcs Mixmaster Remailer wrote:
> This whole AES process has been a sad, embarrassing revelation of
> the personal weaknesses and flaws of the leaders of the field.
I don't think the motivation and salesmanship has been as bad as
one usually sees in this sort of competition.
But as a scientific process it is indeed pretty sad.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Problems with OAP-L3
Date: Fri, 21 Apr 2000 14:21:46 GMT
Tom St Denis wrote:
> 3) Why perms of 0-9? You waste alot of space that way, why not 0-16 or
> 0-255?
Yes, that is an obvious question that deserves an answer.
I have my own theory as to the *real* answer to that,
but let's use this question as a "litmus test" to see
whether OAP-L3's author sincerely wants us to understand
his system.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 09:36:50 -0700
Tom St Denis wrote:
>
> Anthony Stephen Szopa wrote:
> > You still don't know what you are talking about.
>
> I am going on what I read in the ng.
>
> > You are not drawing random digits / numbers from the bottle of
> > numbered beans, you are drawing random number sequences of the
> > numbers 1 - 14.
> >
> > You say you are in high school?
> >
> > Is it a high school for morons?
>
> Why yes it is. I saw you graduated from here in 88'. Impressive.
>
> > You apparently still have not read the Help Files and certainly
> > not retained the most basic facts given in them, you think you know
> > something yet consistently prove you know nothing.
>
> Present your ideas in the ng, where you appear to be flaming everyone.
>
> > Then you have the nerve to critique my Help Files as being
> > inadequate, and you have the ridiculous audacity to tell me to
> > make them more presentable and mature while you are a blithering
> > knuckle head.
>
> replace help file with technically correct paper. Present your ideas
> properly. Have you ever even read a technical paper?
>
> > You have never offered any factual support for even one of your
> > positions. You can't even write a coherent paragraph. You might
> > as well forget about going to a university.
> 7
> It does require alot of memory.
>
> > You are now in the permanent kill file.
>
> Along with common sense I will jump in your kill file.
>
> > You couldn't give any positive feed back if your life depended on it.
> >
> > Who in their right mind would waste anymore of their time with such
> > a jerk?
>
> Because I asked questions about your method and you don't respond.
>
> Tom
Wait until I sink my teeth into you later today.
Then hopefully you will leave this news group with your tail / tale
between your legs.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Primality Test-how many iterations suffice for n digit number ?
Date: Fri, 21 Apr 2000 16:39:53 GMT
[EMAIL PROTECTED] wrote:
>
> Hi all,
>
> As a part of the project, I implement prime-number tests
>
> Division by small primes - Lucas - Lehmann - Miller& Rabin ... etc
> (Frobenius Primality Test sounds ok but finite field knowledge is
> necessary. )
>
> Then number of parameters become important.
> I know that when I implement MilRob for one base - prob that i will fail
> 0.25, in Lehman(Euler) 0.5; Lucas 5/16, Frobenius 1/7710
>
> R.G.E.Pinch suggests that I should take n bases for n digit number.
>
> Any other suggestions, reccomendations ?
>
> If I implement Lucas & Miller-Robin together how many iterations
> suffice?
>
> any reference ?
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
Normally to make large random primes you can use this pseudo code:
1. Large random no, set the lsb and msb
2. Test for easy division of primes upto 1000
3. Do six rounds of miller-rabin
Should be cool, of course you can change the 'six' to lower/higher as
paranoia requires.
Of course you can always 'prove' that it's prime by factoring the
order... i.e p = random no, factor (p - 1). Try to find a primitive
generator. If you can then p is prime, otherwise it is not.... hehehe
Tom
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 09:38:41 -0700
James Felling wrote:
>
> > <giant snip>
> >
> > I will prove you do not know what you are talking about by you
> > simply answering this question:
> >
> > The OAP-L3 encryption software uses a random number generator.
> > Now which of the following is the most correct and most
> > comprehensive description of this random number generator that
> > it uses: which is the description that results in the random
> > numbers used in the encryption process?
>
> >
> > 1) The process that outputs the random digits from the MixFiles,
or
> >
> > 2) the process that results in the OTP files?
>
> Well the best way to answer that is "neither"( or "both" -- depends
upon how I look at it). I
> agree that the stream data is generated primarially by process #2.
However it still uses
> data from process #1 to produce the mix files which are then used by
process #2. If one
> examines the crypto literature you will find many algorithims that
have comentaries by skilled
> people along the line of "this section of the algorithim is weak --
it does not do X properly
> -- I have found no attack to exploit this property" and this is
enough to withdraw the
> algorithim from serious consideration. Why should your program be
judged upon a different
> standard?
>
> >
> >
> > Now define precisely what your supposed flaws are and what is the
> > exact nature of these "artifacts" you allege?
>
> Ok since you have obviously not done even a textbook analisys of your
mix file generation
> process I will.
> I am using your own names for the subprocesses.(P.S. this is not an
exhaustive list of what I
> have found, but it is simply the result of a half hour of simple
kindergarten cryptoanalisys)
>
> We start with a file F of all possible 1 to 10 sequences.I shall
number them F(1),F(2),
> ....,F(10!)
>
> 1) Scramble -- since all other mixing ops are external( they affect
the order in which the
> F(i)'s are presented) Scramble is effectively orthogonal to all other
MixFile creation
> steps.This means we can effectivly treat all other steps as modifying
the set S=
> Scramble(F(1)), Scramble(F(2)), ....., Scramble(F(10!))
>
> 2) Mix -- The "Mix" operation doesn't do a very good job of it. M(i)=
the ith sequence of
> Mix(S) has the following properties M(j+105*n)= S(j+105*n) with
probability . (n>=0, and j=
> first mix value). Since there are further steps this is less bad than
it seems.
>
> 3) Redistribute -- This creates 14 files I will denote them as T(1)
to T(14), and then T(k,m)
> = themth member of Tfilek.
> This is aparently accomplished as follows T(k,m)= M( (k-1)*259200 + m
).
>
> 4) Shuffle. This Permutes the Tfiles, then data are taken from them
in the permuted order to
> generate the mixfile.call this permutation p(x).
>
> Attack vs mix file generation.
>
> Sincej>=1, T(1,1)= Scramble(F(1)) , and T(8,1)=Scramble(F(1814401))
this meand that within
> the first 14 sequences in the Mix files we have two sequences that
are known, this will occur
> regularly within the mix file where within 14 digits at easily
computable points in the file 2
> sequences (Scrambled) with known chjaracter exist. Because of this we
have very good odds of
> recovering both scramble, and some very good information on P(x) in
addition. Further, if
> j>1 we will easily recover scramble as T(1,2) will occur 14 spots
later in the file and will
> be a single rearangement swap different from T(1,1)
> .
>
> As you can see the Mixfile.otp has a significant amount of
exploitable structure -- enough to
> allow recovery of its generating keys in comparitively short order.
Since this is the case,
> it seems likely to me that at least some of this structure could be
exploited by an analyst
> working the whole key backward.
>
> >
> >
> > Let me end with this:
> >
> > The accepted test of the security of an encryption process is not
> > what Mr. Huuskonen has asked for. The accepted test is that it is
> > assumed that the cracker knows every thing there is to know about
> > the algorithm, and that the cracker has a substantial amount of
> > plain text and the corresponding encrypted text. From this
> > it is demanded that the cracker use this information and knowledge
> > to crack the software. This is hardly what Mr. Huuskonen is asking
> > for: he is essentially asking for the key once removed.
>
> Yes, to a degree he is. But the same structures that allow him to
attack your mix file will
> exist, to a lesser degree in the final output. My guess is that the
Mix files provide about
> 20-30 bits of randomness per each(assuming my attack cannot be
refined). This puts the
> randomness of your code somewhere in the neigborhood of a 90 to 100
bits( tops) when you
> factor it all in. I will be generous and say you are as secure as
3DES(112 bits). Why should
> we use your code in prefrence to 3DES?
This is nothing but BS and I think you know it.
Let's keep it simple then build from there.
Let's say we start with the original encryption data file: the
3,628,800 ten-digit permutations consisting of the digits 0 - 9
with no repeats. In this original encryption file the permutations
are arranged in ascending order.
Let's just run the Shuffle process once. The first 259,200 arrays
are read from the original encryption data file and written to
TFile1. The next 259,200 arrays are read and written to TFile2.
The next 259,200 arrays are read and written to TFile3, etc. until
there are TFile1 - TFile14.
The user then inputs a true random 14 number sequence of the
numbers 1 - 14 with no repeats. For your information there are
14! = over 87 billion possible unique sequences of the numbers
1 - 14.
Then these 14 TFiles are interleaved one array at a time according
to this 14 number sequence.
The resulting output file, we'll call it, MixFile1, is one of over
87 billion possible.
You say it will be easy to guess the order of the permutations in
this MixFile1? How will you do it? There is only one way to do
it: trial and error by using all the 87 billion 14 number
sequences. (Because the input was true random you cannot get around
this by any other means.)
So, after you have produced each of these over 87 billion possible
MixFile1's you store them confident that you have certainly produced
the correct MixFile1 among the over 87 billion you have generated and
stored.
Okay.
Now let us run the Shuffle process again on MixFile1 using another
true random 14 number sequence of the numbers 1 - 14 with no repeats
and call the output again, MixFile1. As above, there are over 87
billion possible sequences.
But there are now over (87E9)^2 possible 28 number sequences of two
sequences of 14 numbers 1 - 14 in a row.
So now you have to produce and store over (87E9)^2 MixFile1's but
you can still be certain that at least one of these (87E9)^2
MixFile1's is the correct one.
Let's say I repeat the process 50 times in total. This means that I
have shuffled the original encryption data file 50 times using one
of over 87 billion 14 number sequences with each shuffle. Thus the
total user input is 50 true random 14 number sequences of the numbers
1 - 14.
This means that there are over (87E9)^50 possible 50 true random 14
number sequence sequences in a row and that the actual input used is
only one of these over (87E9)^50 sequences.
For you to determine the final MixFile array sequence after 50 runs
of the Shuffle process with absolute certainty that at least one of
the MixFiles is the actual one, you will have to produce over
(87E9)^50 MixFiles, and store them.
Let's see, if each MixFile is over 18MB you will need enough storage
for 18E6 * (87E9)^50 = 1.5E459 bytes.
But you can at least be sure you have the right sequence somewhere
among them all.
Your problem now is: which one is it?
Let's say you need three such MixFiles and that the user uses their
last MixFile1 after 50 Shuffle runs to begin 50 more shuffle
processes to produce a MixFile2, then run 50 more processes on this
last MixFile2 to produce a MixFile3.
Similarly as shown in the Theory and Processes Help Files, the odds
of duplicating MixFile1 with certainty is one in (87E9)^50.
But for duplicating MixFile2 it is one in ((87E9)^50)^2 = (87E9)^100.
For duplicating MixFile3 it is one in ((87E9)^50)^3) = (87E9)^150.
And finally, to guess with certainty, all three MixFiles it would be
(87E9)^50 * (87E9)^100 * (87E9)^150 = (87E9)^300.
Tell us how you are going to guess the one chance in (87E9)^300 of
getting the correct three exact MixFiles? (Not to mention store all
of them.)
We really want to know?
Give up?
Give up.
And we haven't even considered subsequent processing of the random
binary number files produced from the MixFiles.
Now, what is it you don't understand about unbreakable?
(I bet you would you like me to sneak you the key right about
now, eh?)
See, how plain it is in layman's terms. This is why I say that the
entire software package is understandable by anyone with average
intelligence.
Now what exactly don't you understand?
(And whatever it is you'd like to say can you say it in laymen's terms
so everyone can understand you?)
Thank you.
(All of this is just as simply explained in the Help Files at
http://www.ciphile.com)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Fri, 21 Apr 2000 16:41:57 GMT
Mike Kent wrote:
>
> Tom St Denis wrote:
>
> > UBCHI2 wrote:
> ...
> > > Intractable math problem are only in the eye of the beholder. How many of you
> > > would have thought that the enigma could be broken?
> >
> > This is amazingly false.
>
> Hmmm, it's _very probably_ amazingly false.
I would like to think all the math-wizards know what they are doing.
Ciphers along the same idea as DES (i.e feistel) have been around for a
while.
Of course it's entirely possible that all AES ciphers and pre-aes
ciphers get broken tommorow. However, that is as likely as monkeys
learning speech and taking over the world while we are asleep.
Both could happend, but neither will. Of course having a monkey as a
master isn't a big change for alot of people... hehehe
------------------------------
** 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
******************************
