Cryptography-Digest Digest #554
Cryptography-Digest Digest #554, Volume #13 Fri, 26 Jan 01 07:13:00 EST
Contents:
Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: What do you do with broken crypto hardware? (Nicol So)
Re: Durstenfeld Transpositions ARC4 (Benjamin Goldberg)
Re: Durstenfeld Transpositions ARC4 (Mok-Kong Shen)
Decode Algorythim ("Yeah")
Re: Some Enigma Questions ("Yeah")
Re: Steak Stream Cipher ([EMAIL PROTECTED])
Re: Durstenfeld Transpositions ARC4 (Mok-Kong Shen)
Paranoia (Simon Jenkins)
From: Anthony Stephen Szopa [EMAIL PROTECTED]
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Why Microsoft's Product Activation Stinks
Date: Fri, 26 Jan 2001 00:10:54 -0800
Splaat23 wrote:
He doesn't consider XORing two files together to be significant. That's
easy! He considers XORing two files together, one of which happens to
be generated by a PRNG to be significant. Innovation, what a sight! I
wish I had his foresight to create a slow, unwieldy stream cipher that
has no market to acquire and no use.
He was not stupid for showing it to Microsoft. He's stupid for
believing that not a soul could think it up independently! I love his
lack of understanding of the laws of causation: "I sent my [simple,
bad] program [that could be thought up by any 9-year old reading _AC_]
to Microsoft, and years later they come out with something remotely
similiar, therefore they are liars and thieves!"
Note, I think Microsoft's patenting of this, if that's what they really
intend to do, is silly, like most tech patents, but that's OT.
Enough bashing of Mr. Szopa. From his past posting history (which I had
the urge to view and regret my stupidity), Mr. Szopa will disregard
anything we say here and continue to believe his own superiority over
us mere mortals.
- Andrew
In article [EMAIL PROTECTED],
Richard Heathfield [EMAIL PROTECTED] wrote:
[Sorry to reply to Joe's post when I'm really addressing the issues
raised by Mr Szopa. Mr Szopa's article hasn't hit my newsfeed yet and
may not do so for some time...]
"Anthony Stephen Szopa" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Richard Heathfield wrote:
Anthony Stephen Szopa wrote:
snip over 200 lines
So that's all I have to say for a while.
Is that a promise?
Here is a guy who spits on the souls of anyone for no damned
reason.
I guess it wasn't a promise after all. (sigh)
I told you that I am the inventor that will save people tens or
hundreds of billions of dollars in lost revenue and you verbally
shit on me with your sarcasm.
You do a good line in invective. Perhaps you should switch from crypto
to politics.
Did you develope an anti-piracy computer software module that will
prevent perhaps half at a minimum of the illegal copying of
computer software in the world?
Certainly not. I wouldn't dream of writing such a pointless program.
Do you know how important a contribution this is?
It's completely insignificant to those who have already realised that
MS
has, for years, been using the very best copy protection of all - i.e.
products that don't work, products that corrupt files, products that
hang the machine... Why would anyone with the slightest semblance of
common sense *want* to copy programs like that?
I can prove that I did this. And if I eventually do prove it
publicly everyone will know you are a fool. But most importantly
you will know. I think you probably already know you are a fool.
If you really were conned by MS, I sympathise (like Joe), but am
stunned
by your naivete.
1) Copy protection doesn't work. sci.crypt already knows this. Why
don't
you?
2) Microsoft is well-known for exploiting anything it can exploit.
I am certainly one of a very very few and perhaps the only person
in
the world who can prove that they did it before MS.
You're the guy with the proprietary no-source-code-provided technique
for XORing two files together, yes? The one with the front end that
looks like something the cat dragged in? The one you said was so
innovative?
I am not going
to divulge my thought processes here or my plans or my actions
regarding the implications of this situation at this time, as I
have
said.
Excellent.
I am actively pursuing my interests.
I think I read that there is about $50 billion dollars worth of
computer software piracy going on every year.
Well, people will play those games, I suppose.
If you don't want people to steal your software, give it away. It's
that
simple.
You must be a real high achiever to top this. Tell your friends
what a proud soul you are and give
Cryptography-Digest Digest #555
Cryptography-Digest Digest #555, Volume #13 Fri, 26 Jan 01 09:13:01 EST Contents: Re: William's P+1 (Bob Silverman) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) Re: William's P+1 ([EMAIL PROTECTED]) Re: What do you do with broken crypto hardware? (John Veldhuis) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) Re: What do you do with broken crypto hardware? (Paul Rubin) Re: Paranoia ([EMAIL PROTECTED]) Re: Cryptographic Camouflage (Mok-Kong Shen) Re: Dynamic Transposition Revisited (long) (Rob Warnock) Re: Fitting Dynamic Transposition into a Binary World (Rob Warnock) Re: What do you do with broken crypto hardware? (John Veldhuis) Re: Why Microsoft's Product Activation Stinks (Richard Heathfield) Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition (Rob Warnock) From: Bob Silverman [EMAIL PROTECTED] Subject: Re: William's P+1 Date: Fri, 26 Jan 2001 12:39:25 GMT In article 94n6eq$lhj$[EMAIL PROTECTED], "The Death" [EMAIL PROTECTED] wrote: I saw several websites, and they all mentioned this algorithm but didn't have any info about it. Can any1 give me information about this algorithm? It finds a factor p dividing n if p+1 only has small prime factors. It only works 1/2 the time even when p has the required property. (you choose a Lucas sequence. It succeeeds iff the discriminant is a non-residue mod p) It is obsolete. What more would you like? -- 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/ -- From: Mok-Kong Shen [EMAIL PROTECTED] Subject: Re: Dynamic Transposition Revisited (long) Date: Fri, 26 Jan 2001 13:56:11 +0100 Mok-Kong Shen wrote: Terry Ritter wrote: [snip] My knowledge is too meager to enable me to offer more points than I have already done. However, it is my impression that your arguments todate somehow (I have no definite idea of that) need strenthening, if DT is to be accepted as on a par with the theoretical OTP (which seems to be your goal), in particular by the academics, assuming DT has in fact that property. (Apology, if my open words are inappropriate in some way.) After some re-thinking, I do like to elaborate a little a previous point of mine concerning the question of perfectness of DT. Suppose we have block size of n and we agree not to use the non-balanced groups of bits but only the balanced ones to transmit informations (in other words, we have an 'alphabet' of a certain size m that is less than n). This serves to separate out the issue of bit balancing in order to simpify the argumentation below. Now what we have is the following: Given an information block, we do permutations of its bits to produce an enciphered block with the help of a PRNG. A PRNG never provides a perfect bit sequence in the sense used in the context of the theoretical OTP. How can it be that this imperfectness does not manifest itself in some form (possibly in certain very much reduced, practically entirely negligible, intensity) AT ALL in our encryption result? Let's order all the distinct balanced bit groups into a sequence S and feed repetitions of S into our algorithm. This input is evidently perfectly predictable. Can the output be perfectly unpredictable? It certainly cannot. For the PRNG has a finite period and hence the ciphertext must cycle ultimately. This shows that, while DT could be practically very secure (an issue that certainly merits careful study before its being used in practice), it cannot offer perfect security that pertains to the theoretical OTP. M. K. Shen === http://home.t-online.de/home/mok-kong.shen -- From: [EMAIL PROTECTED] Subject: Re: William's P+1 Date: Fri, 26 Jan 2001 12:45:54 GMT In article 94n6eq$lhj$[EMAIL PROTECTED], "The Death" [EMAIL PROTECTED] wrote: I saw several websites, and they all mentioned this algorithm but didn't have any info about it. Can any1 give me information about this algorithm? There's a description in "A Survey of Modern Integer Factorization Algorithms" CWI Quarterly, v.7 (4), 1994, pp. 337 - 365, by Peter Montgomery which is available here: http://ftp.cwi.nl/ftp/CWIQuarterly/1994/7.4/Montgomery.ps.Z Chris Sent via Deja.com http://www.deja.com/ -- From: John Veldhuis [EMAIL PROTECTED] Subject: Re: What do you do with broken crypto hardware? Date: Fri, 26 Jan 2001 13:01:33 GMT Paul Rubin wrote: = I'm wondering if anyone else here is using crypto hardware modules for key management. What do you do if one malfunctions? Throw it into a blast furnace? Send it back to the manufacturer for warranty repair/replacement, with your secret keys inside? I just send it back to the manufacturer. The moment it is tampered with (eg. removed from a
Cryptography-Digest Digest #556
Cryptography-Digest Digest #556, Volume #13 Fri, 26 Jan 01 12:13:01 EST
Contents:
Re: Windows encryption: API and file system ("Ben Newman")
Re: Some Enigma Questions (Jim Reeds)
Weak DES keys/Weak Plaintexts ([EMAIL PROTECTED])
Re: Why Microsoft's Product Activation Stinks (Lord Running Clam)
Re: Barrett modular reduction ([EMAIL PROTECTED])
Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition (John
Savard)
History Question: signatures in nuclear test ban verification? (Gerard Tel)
Re: Fitting Dynamic Transposition into a Binary World (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Paranoia (JCA)
Re: Why Microsoft's Product Activation Stinks (Richard Heathfield)
ICCIT2001 (CFP) ([EMAIL PROTECTED])
Re: What do you do with broken crypto hardware? (John Savard)
Re: What do you do with broken crypto hardware? (John Savard)
Re: Dynamic Transposition Revisited (long) ("Paul Pires")
From: "Ben Newman" [EMAIL PROTECTED]
Subject: Re: Windows encryption: API and file system
Date: Fri, 26 Jan 2001 14:41:34 GMT
Good point. I do think that they should at least zero out the sectors on
disk that contain the temporary file.
Isn't it more a question of what kinds of attacks this encryption is
supposed to defend against? Surely if the user's login record / password /
whatever is used to encrypt the files, and no passphrase is needed for
accessing an encrypted file, stealing the disk will give you all the
information you need to decrypt the encrypted files anyway, yes?
What kinds of attacks does Microsoft think this defends against? Theft of
backup materials, maybe? Reading of files by administrators?
--
From: [EMAIL PROTECTED] (Jim Reeds)
Subject: Re: Some Enigma Questions
Date: Fri, 26 Jan 2001 14:52:52 GMT
In article [EMAIL PROTECTED], "Yeah" [EMAIL PROTECTED] writes:
| Didn't the British Government invent the worlds first programmable computer
| to crak the enigma code. (Suck that America, IBM more precisely)
| I think i once heard the lead designer on TV commenting that it too about 5
| minutes to crack the code on their computer and that he once got the paper
| reel spinning at 3 times the RPM of usual before it broke.
No.
You are thinking of the "Colossus", an electronic special
purpose calculator designed by Tommy Flowers of the British
Post Office labs to break a different German cipher. Colossus
used vacuum tubes and high speed (5,000 characters per
second) punched tape, but it was not programmable in the modern
sense of the word. (One had to set switches and plug plugboards
to change the parameters of a run.) It was definitely the
most technologically advanced instance of use of digital logic,
large-scale use of vacuum tubes, etc, at its time, but was (I
think) matched in conception by several contemporary computing
projects in America and Germany.
I suspect, but have no evidence, that the special purpose
number theoretical calculators built by D. H. Lehmer in the
1930s in California were a kind of mental jumping off point
for the Colossus team. The team that used Colossus, and
which commissioned Flowers to design and build it,
was full of pure mathematicians, who would have known of
Lehmer's machines.
--
Jim Reeds, ATT Labs - Research
Shannon Laboratory, Room C229, Building 103
180 Park Avenue, Florham Park, NJ 07932-0971, USA
[EMAIL PROTECTED], phone: +1 973 360 8414, fax: +1 973 360 8178
--
From: [EMAIL PROTECTED]
Subject: Weak DES keys/Weak Plaintexts
Date: Fri, 26 Jan 2001 10:01:12 -0500
I know that DES has some weak keys that make plaintext recovery easy.
Q. Are there weak DES plaintext that make key recovery easier?
Example: I control the plaintext, someone else does a single
des_ecb_encrypt(), and I receive the cyphertext. Is there a
particularly weak plaintext I could select to be encrypted to make the
unknown key be recovered eaiser?
Thanks for the help.
Please Reply or CC' me if possible, since I have limited newsgroup
access.
- Aaron
==
Disclaimer:
The views and opinions are soley mine and not my companies.
--
Date: Fri, 26 Jan 2001 09:25:33 -0600
From: Lord Running Clam Use-Author-Address-Header@[127.1]
Subject: Re: Why Microsoft's Product Activation Stinks
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
=BEGIN PGP SIGNED MESSAGE=
On Fri, 26 Jan 2001, Richard Heathfield [EMAIL PROTECTED] wrote:
Anthony Stephen Szopa wrote:
Pointless program where to stop software piracy could increase
revenues by tens of billions of dollars each year? Pointless?
Pretty much, yes. It's like trying to protect Pythagoras' Theorem.
Counter-productive.
Excuse me, but is this little piece from alt.security.pgp relevant to your
flamewar?
Cryptography-Digest Digest #558
Cryptography-Digest Digest #558, Volume #13 Fri, 26 Jan 01 15:13:01 EST Contents: Re: Windows encryption: API and file system (Ray Dillinger) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) Re: Dynamic Transposition Revisited (long) (AllanW) Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa) Re: Dynamic Transposition Revisited (long) (AllanW) Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa) Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen) From: Ray Dillinger [EMAIL PROTECTED] Subject: Re: Windows encryption: API and file system Date: Fri, 26 Jan 2001 19:13:22 GMT It's not merely sloppy engineering... Think about it. It would have been just as easy to create the temporary file as an encrypted file in the first place, then copy it back over the file being encrypted, and *then* delete it. To call this "sloppy" is to believe that the engineer selected these operations and then didn't think *at all* about what order to apply them in. Which, I guess, you may believe if you care to, but I don't think anyone that flatout stupid can be an engineer in the first place. I don't think Microsoft is in the security business at all. I think that they are in the business of providing the *illusion* of security while still selling out ^H^H^H^H^H^H^H^H uh, "providing for the legitimate needs of law enforcement and data theives". Real security scares the bejabbers out of them and they're fighting it every step of the way. Bear Ben Newman [EMAIL PROTECTED] wrote: : This is an excellent start. I was hoping for a more detailed discussion of : how an OS can secure files, and how Windows has implemented their encryption : protocol. : This bug is just plain sloppy engineering! : --ben : "Bryan Mongeau" [EMAIL PROTECTED] wrote in message : news:VUYb6.6219$[EMAIL PROTECTED]... : Ben Newman wrote: : : I'd like to learn more about criticisms of the Windows cryptography : implementation. In response to an earlier post, someone characterized it : as "practically useless." This seems like a particularly important issue : given the amount of knowledge your average Windows user has about : crypto. : : --ben : : : : I don't know if this what you mean but I saw this on Bugtraq : a few days ago: : : -- : BugTraq: EFS Win 2000 flaw : From: Rickard Berglind [EMAIL PROTECTED] : To: [EMAIL PROTECTED] : Date: Fri, 19 Jan 2001 12:29:50 +0100 : : : I have found a major problem with the encrypted filesystem : ( EFS ) in Windows 2000 which shows that encrypted files : are still very available for a thief or attacker. : : : The problem comes from how EFS works when the encryption : is done. When a user marks a file for encryption a : backup-file, called efs0.tmp, will be created. When : the copy is in place the orginal file will be deleted : and then recreated, now encrypted, from the efs0.tmp- : file. : And finally, when the new encrypted file is succesfully : created, the temporary-file ( which will never be shown : in the user interface ) will be deleted as well. : : So far, so good. The only file remaining is the one : which is encrypted. : : : But the flaw is this: the temporary-file is deleted : in the same way any other file is "deleted" - i.e. : the entry in the $mft is marked as empty and the clusters : where the file was stored will be marked in the $Bitmap : as available, but the psysical file and the information it : contains will NOT be deleted. The information in the : file which the user have encrypted will be left in the backup : file efs0.tmp in total plaintext on the surface of the disk. : : When new files are added to the partition will they : gradually overwrite the secret information, but if : the encrypted file was large - the information could : be left for months. : : So how can this be exploited ? If someone steals : a laptop or have psysical access to the disk it will : be easy to use any low level disk editor to search : for the information. For example, the Microsoft : Support Tool "dskprobe.exe" works fine for locating : old efs0.tmp-files and read information, in plain-text, : that the user thought was safe. : : In my opinion there should be a function in the EFS : which physically overwrites the efs0.tmp at least once : to make it a lot harder for an attacker to gain control : over secret information. : : : : Here is a description how to test this : : : Use any version of Windows 2000. : Install the Support Tools from the Win2000 CD. : : For demonstrating purposes - create a new partition with : the size of 7 MB. : Choose to format with NTFS. : Create a new small file ( easier to find ) with Notepad : and put some text in it. Save this file in the root of the : new partition. : : Do not encrypt it yet. : : Let us look at the file through DiskProbe before
Cryptography-Digest Digest #559
Cryptography-Digest Digest #559, Volume #13 Fri, 26 Jan 01 15:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: Snake Oil (SCOTT19U.ZIP_GUY)
Re: Knots, knots, and more knots (Matthew Montchalin)
Re: Decode Algorythim ("Joseph Ashwood")
Re: Steak Stream Cipher ("Joseph Ashwood")
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks) ("Joseph
Ashwood")
Re: Why Microsoft's Product Activation Stinks (Anthony Stephen Szopa)
Encryption Program (Benjamin)
Re: What do you do with broken crypto hardware? (Bill Unruh)
Q: File Extension .$#! - Which Encryption Program?!? (Thomas Propst)
From: AllanW [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 19:33:06 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote:
On Tue, 23 Jan 2001 08:29:16 -0800, in
[EMAIL PROTECTED], in sci.crypt "John A. Malley"
[EMAIL PROTECTED] wrote:
Terry Ritter wrote:
[snip]
This may be a good place to continue the cryptanalysis of the
strength
of the DT cipher. A PRNG with N! states to make every
permutation of
the bits in an N bit block can only generate some of the possible
sequences of permutations. There are (N!)! possible sequences of
permutations.
There are (N!)**S possible sequences of permutations, of sequence
length S.
Please help - where did I go wrong in calculating the total number of
possible sequences of the N! total possible permutations?
Here's my reasoning -
Given N bits there are N! different, unique ways to permute those
bits -
the N! unique permutations. They make a set P.
I number the permutations in the set from 1 to N!. How many
different
ways can I sequence the members of the set of permutations? Or in
other
words, how many different ways can I write down (list) the elements
of
P? Let the number of elements in P be M, so
M = N!. The number of unique listing sequences of the M elements is
the
number of permutations of the M elements of P, which is M!. Since M =
N!, then M = (N!)!.
So that's how I derived the number of ways the individual elements of
the set of permutations of an N bit block can be listed out as a
sequence.
OK, I had no idea what you were doing. Of course, I still have no
idea where you are going. Do you have any idea how big (N!)! is?
Even 128! is 3.85620482e+215, and the factorial of that is some number
which is about 2.75610295e+218 bits long. (From
http://www.io.com/~ritter/JAVASCRP/PERMCOMB.HTM#Factorials
).
Surely, there is no reason to imagine that permutations must all occur
before repeating. In fact, that would be a weakness.
The design goal is to allow the very same permutation to occur on the
next block, and then rely on the almost infinitesimal probability of
any particular permutation occurring to be assured that it will almost
never happen. The goal is to make the permutation selection for each
and every block independent, with equal probabilities.
We can see the selected permutation as a "value," in a sequence of
values, exactly the same way we get random values from an RNG, or the
way we think of sequences as some number of symbols, each one chosen
from a set. It is a weakness for a random generator to produce a
value which will not then re-occur until the generator recycles.
AFAIK it's safe to say the PRNG generates N! sequences
(assuming the set of seed values is equal to the set of possible
outputs
of the PRNG, both sets are of order N!.) Only N!/ (N!)! of the
sequences
can ever be seen.
??
There are M! ways to list the M values from 1 - M.
These are called permutations.
A PRNG outputs lists
(sequences) of the values between 1-M.
Some RNG's are like that. Don't do that.
The PRNG starts from a seed
value s and makes a list of the M values. Each list is different.
The
PRNG can only make as many unique lists of the M values are there are
unique seeds s. Let the order of the set S of seed values be K.
Then
the PRNG can only make K out of M! listings (sequences) of the M
values
from 1 - M. So the PRNG only produces a fraction K / M! of the total
possible sequences of the M values.
Internally, there is some concept of a huge cycle which is shuffled by
an RNG -- the internal state -- but that concept is not necessarily
the output value. Surely, when we have a huge internal state, we do
not imagine that we must take the whole amount of that state as the
RNG result. When we do not, any particular value can re-occur on the
very next RNG step.
The Additive RNG is discussed in Knuth II. And even though those are
tiny, it should be clear that, in an Additive RNG, values can and do
repeat. The intent is to make the probability of that immeasurably
close to independent selection.
Let the set S be the set of M output values of the PRNG. The order
of
the set M is M. Then the
Cryptography-Digest Digest #560
Cryptography-Digest Digest #560, Volume #13 Fri, 26 Jan 01 16:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: What do you do with broken crypto hardware? (David Schwartz)
Re: What do you do with broken crypto hardware? (David Schwartz)
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: Paranoia (William Hugh Murray)
Re: Encryption Program (Richard Heathfield)
Re: Q: File Extension .$#! - Which Encryption Program?!? (Jim Gillogly)
Re: History Question: signatures in nuclear test ban verification? (Doug Stell)
Re: Dynamic Transposition Revisited (long) (Richard Heathfield)
Re: Encryption Program ("Joseph Ashwood")
Re: Steak Stream Cipher ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Random stream testing. (long) ("Paul Pires")
Re: Q: File Extension .$#! - Which Encryption Program?!? (Thomas Propst)
From: AllanW [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:04:24 GMT
"Matt Timmermans" [EMAIL PROTECTED] wrote:
In all likelyhood, that would be a very practical generator for OTP
keys,
and it would be reasonably easy to purposely underestimate the amount
of
entropy you're getting. If you want proof, though, you should do
something
different. For instance:
Generate a photon, and polarize it vertically. Then measure its
polarization at 45 degrees from the vertical. Repeat.
By measuring the transparency of your optics, the sensitivity of your
photomultipliers, and the orientation of your polarizers, you can
place a
very confident lower bound on the rate of real randomness.
I think I missed one of my classes when I learned programming.
Could you please show me the code corresponding to "generate a
photon?" Use any well-known computer language -- ADA, APL,
BASIC, C, C++, COBOL, FORTRAN, PASCAL -- whatever you feel
comfortable with. I just need to see the basic algorithm for
"generate a photon."
Wait, I think I see a photon now -- no, it's gone. I probably
just imagined it.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
--
From: David Schwartz [EMAIL PROTECTED]
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 12:19:48 -0800
Nicol So wrote:
I'm not familiar with your application, but it sounds dangerous if the
application host is completely insecure. Besides preventing someone from
extracting secrets from the security module, don't you want to control
how the module's functions are exercised, and who can exercise it? I
suspect that you need to provide some level of security to the host
anyway.
I think you're missing the entire point of having a secure module. The
point of the module is to isolate failures. That is, with a secure
module, the worst case scenario for a compromised host is supposed to be
that they can perform encryptions and decryptions for as long as the
host is compromised. If the keys themselves are accessible through a
compromised host, then a compromised host equals a compromised key. That
defeats the purpose of having the module.
Let's assume that the encrypted keys are fairly well protected so that
there's a low but non-zero probability that an adversary can get to it,
but without physical access it is impossible to extract the secrets from
the security module. For adversaries coming in from a network, their
lives are not made easier. For insiders such as bad admins, their
attacks are not made harder, but not easier either. For the module
manufacturer as an adversary, who's best positioned to defeat/bypass the
module's physical security, they now have an additional barrier to
overcome. That may be an improvement.
That's a big step down in security from what the module is supposed to
provide.
DS
--
From: David Schwartz [EMAIL PROTECTED]
Subject: Re: What do you do with broken crypto hardware?
Date: Fri, 26 Jan 2001 12:17:11 -0800
Paul Rubin wrote:
This doesn't make sense--the whole point of the tamper resistant
module is to securely store keys internally. Any keys stored outside
the module are vulnerable to copying and therefore must be encrypted;
but then in order to load them into the module, the decryption key
must be stored inside the module. So if the module is sent back to
the manufacturer, all the keys are potentially compromised.
Yes, you can't have it both ways. If the module can decrypt the keys,
then you're not safe from anyone who has both the module and the
encrypted keys. If you are assuming that you can store the encrypted
Cryptography-Digest Digest #561
Cryptography-Digest Digest #561, Volume #13 Fri, 26 Jan 01 17:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (AllanW)
Re: Dynamic Transposition Revisited (long) ("Tony T. Warnock")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Some Enigma Questions (JimD)
Re: Echelon in Asia. (JimD)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Fitting Dynamic Transposition into a Binary World (Terry Ritter)
From: AllanW [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 20:49:45 GMT
AllanW [EMAIL PROTECTED] wrote:
As I understood the filler bits to work, the data would
look like this before the transposition begins: if the
data had more 0-bits than 1-bits, it would take the form
XXXX 00..00 11..11
where X bits represent the data, and then there are 1-8
0-bits followed by 1 or more 1-bits.
I see now that I should have said, 1-7 0-bits and then
1 or more 1-bits.
If the data has
more 1-bits than 0-bits, simply reverse the filler:
XXXX 11..11 00..00
this time using 1-8 1-bits and then 1 or more 0-bits.
And here I should have said: 1-7 1-bits and then 1 or
more 0-bits.
[EMAIL PROTECTED] (Terry Ritter) wrote:
That does not seem to be the way I did it.
That's what I got out of it. Not word-for-word, of course.
I don't understand having both 0's and 1's balancing bytes.
Surely you do...? It is so that we can always remove the balancing
bytes without removing any meaningful data.
What if the block has 16 more 0-bits than 1-bits, but the last byte
of plaintext is 0x0F? You could balance the block by adding 2 more
bytes of 0xFF, but then after decryption we could not identify the
first byte of filler (as you say below: the mixed byte must be
mixed to be a flag).
If we have an excess of 0's, we want any full balancing bytes to
be all 1's, with the mixed byte being what it needs to be. Since
the mixed byte must be mixed to be a flag, it cannot balance a
full 8 bits, but at most 6 (1000 is an excess of 6 0's).
Yes, exactly. And then following this, we have bytes with all
1-bits.
I suppose that what I wrote above (1-7 0-bits, followed by 1 or more
1-bits) was stronger than absolutely needed. The mixed byte could be
randomly mixed as well, so instead of using 1000- we could just
as easily have used 0001-. Is there any reason to do this
randomly? If not, then my description fits the same pattern but is
easier to describe.
Another way to say this is to show what the filler
would look like for various imbalances. Here I'll
assume that the data has more 0-bits than 1-bits; use
the complement if the opposite is true.
If there are B more 0-bits than 1-bits, then the
filler looks like (in hex):
B=0 0F
B=2 1F
B=4 3F
B=6 7F
B=8 0FFF
B=10. 1FFF
B=12. 3FFF
B=14. 7FFF
B=16. 0F
B=18. 1F
B=20. 3F
B=22. 7F
B=24. 0FFF
...and so on.
Looks right.
Good, because in every case the first balance byte starts
with 1-4 0-bits followed by 1-7 1-bits.
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
--
From: "Tony T. Warnock" [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 14:08:19 -0700
Reply-To: [EMAIL PROTECTED]
The efficiency of the balanced pre-substitutions can be improved by
taking more bits. Of course a table-lookup gets too big rather quickly.
Output Input
Size Length Expansion
6 450.0%
8 6 33.3%
10 7 42.9%
12 9 33.3%
14 11 27.3%
16 13 23.1%
18 15 20.0%
20 17 17.6%
22 19 15.8%
24 21 14.3%
26 23 13.0%
28 25 12.0%
30 27 11.1%
32 29 10.3%
64 60 6.7%
128 124 3.2%
256 251 2.0%
512 507 1.0%
1024 1018
Cryptography-Digest Digest #562
Cryptography-Digest Digest #562, Volume #13 Fri, 26 Jan 01 19:13:01 EST
Contents:
Re: Producing "bit-balanced" strings efficiently for Dynamic ("Tony T. Warnock")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
Encoded serial number:Help! (Giannikol)
Q: solving simultaneous equations in modulo arithmetic (G. Ralph Kuntz, MD)
Re: Some Enigma Questions (Neil Sluman)
Re: Random stream testing. (long) ("Joseph Ashwood")
Re: Some Enigma Questions (John Savard)
Re: Some Enigma Questions (John Savard)
Re: Producing "bit-balanced" strings efficiently for Dynamic Transposition (Terry
Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Why Microsoft's Product Activation Stinks (Lord Running Clam)
Re: Dynamic Transposition Revisited (long) ("Paul Pires")
From: "Tony T. Warnock" [EMAIL PROTECTED]
Subject: Re: Producing "bit-balanced" strings efficiently for Dynamic
Date: Fri, 26 Jan 2001 15:19:06 -0700
Reply-To: [EMAIL PROTECTED]
Arbitrary 37 bit strings will fit into 40 bits. 2**37 is just larger
than 40!/20!**2. I didn't check to see if the suggested algorithm would
actually work.
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 22:21:52 GMT
On Fri, 26 Jan 2001 09:07:03 -0800, in
[EMAIL PROTECTED], in sci.crypt "Paul Pires"
[EMAIL PROTECTED] wrote:
[...]
I also am not clear on the goal. Yes there needs to be bit balancing so that
a bias in the input is not recognizable in the output but by doing this
hiding,
don't you sacrafice another valuable property? Seems like the output would
fail a taylored randomness test. You are going to get data that has a
prefect
distribution of zero's and ones within a block and something else if the
block
reference is displaced. Right?
It is not necessary for strength or security that a cipher to produce
random-like output. Most ciphers do so, but such is not necessary.
Here I think the possible output codes do appear with equal
probability.
This is a characteristic which represents the inefficiency of balanced
coding. But since that is a plaintext coding, and is known by both
designer and opponent, it does not seem particularly worrisome.
Seems like what you'd want would be a method where the transposition
works on a pile that is "Probably" balanced but where the deviation from
perfect is not correlated to the input or output. I could be screwy here.
I have mentioned the possibility of a statistical or "almost" balance,
which could be very effective. But it seems like that analysis would
be much more complicated. We would have to talk about the
distribution of balance, and how strength changes accordingly, which
seems beyond what can now be done.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 22:25:04 GMT
On Fri, 26 Jan 2001 12:07:40 -0700, in
[EMAIL PROTECTED], in sci.crypt "Tony T. Warnock"
[EMAIL PROTECTED] wrote:
I have a suggestion for the initial statistical-balance step (to reduce
the later balance extensions.) XOR the input with a DeBruijn sequence.
For example a simple method would be to XOR the sequence 0101010101
Better would be 001100110011 and even better 0001011100010111 In
the latter case, the XORing sequence is one byte long so one might
improve things by rotating this sequence between bytes. Longer
sequences are possible 10011010 could be used on pairs of
bytes--with rotation.
If we are going to process plaintext with a known sequence, why should
any particular balanced sequence be better than any other? It seems
like there will always be some plaintext that will not be helped, or
would in fact be made worse.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
--
From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 23:26:55 +0100
Terry Ritter wrote:
Mok-Kong Shen[EMAIL PROTECTED] wrote:
After some re-thinking, I do like to elaborate a little
a previous point of mine concerning the question of
perfectness of DT.
Suppose we have block size of n and we agree not to use
the non-balanced groups of bits but only the balanced
ones to transmit informations (in other words, we have
an 'alphabet' of a certain size m that is less than n). This
serves to separate out the issue of bit balancing in order to
simpify the
Cryptography-Digest Digest #563
Cryptography-Digest Digest #563, Volume #13 Fri, 26 Jan 01 20:13:01 EST
Contents:
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: What do you do with broken crypto hardware? (Paul Rubin)
Re: Cryptographic Camouflage (Thomas Wu)
Re: What do you do with broken crypto hardware? (David Schwartz)
Re: Why Microsoft's Product Activation Stinks (Splaat23)
RSA Source code ("Adam Smith")
Re: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks) (Alan
Mackenzie)
Re: Why Microsoft's Product Activation Stinks (Splaat23)
Re: Why Microsoft's Product Activation Stinks (Splaat23)
Re: RSA Source code (Paul Rubin)
Re: RSA Source code ("Joseph Ashwood")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Fri, 26 Jan 2001 23:30:36 GMT
On Fri, 26 Jan 2001 21:48:40 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
The DES keyspace is 56 bits, a value 2 bits long.
Let's see: A value 10**21 bits long compared to a value 2 bits long.
Yeah, I'd say "some" were impossible to reach.
Actually, 56 is a 6-bit-long binary number. And DES doesn't have 56
different keys, it has 2^56 different keys, as noted below.
The DES keyspace is such a tiny fragment of the potential keyspace
that there is no assurance at all that it retains the smooth
theoretical properties of distribution for which we might hope.
quoting me:
Well, by shuffling, I can't reach a total overall pairing of bit
balanced inputs to bit balanced outputs such that
-
and
00101011 -
Why not? What does that mean? Are you criticizing the balancing
algorithm? Fine, use another.
This has nothing to do with the balancing algorithm.
This is about Dynamic Transposition itself.
All possible N! transpositions of an N-bit block may be effected.
However, 16! is also a tiny fraction of 12870!, just as 2^56 (not 56)
is a tiny fraction of (2^64)!.
If our PRTG - pseudorandom transposition generator - generates the
transposition
9 12 14 16 15 11 10 13 3 5 1 2 7 6 4 8
then if the plaintext was
the ciphertext will be
000
and if the plaintext was
00101011
the ciphertext would be instead
11011000
note that just as we have switched two bits in our plaintext, we have
switched two bits in our ciphertext.
A substitution cannot be reached by means of any transposition that
will at the same time take
to
and take
00101011
to
since we are inverting a different number of bits in the plaintext and
the ciphertext.
Thus, as with DES, some total overall mappings, considering the whole
ensemble of (plaintext, ciphertext) pairs generated at a single point
in the process, are unreachable.
This is not so much a criticism of Dynamic Transposition itself as of
your claim that it is vastly superior to DES with
stream-cipher-generated subkeys.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: Paul Rubin [EMAIL PROTECTED]
Subject: Re: What do you do with broken crypto hardware?
Date: 26 Jan 2001 15:48:42 -0800
Nicol So [EMAIL PROTECTED] writes:
Maybe I'm overly paranoid but the encrypted external keys are in disk
files on the application host, and I'm going by the assumption that
the online application host is completely insecure.
I'm not familiar with your application, but it sounds dangerous if the
application host is completely insecure.
To clarify: we do all the usual things to make the host secure, but
despite this I assume there's a chance it can be compromised, and
that's what the module is supposed to protect against.
--
From: Thomas Wu [EMAIL PROTECTED]
Subject: Re: Cryptographic Camouflage
Date: 26 Jan 2001 15:50:23 -0800
Mok-Kong Shen [EMAIL PROTECTED] writes:
Thomas Wu wrote:
Mok-Kong Shen [EMAIL PROTECTED] writes:
Darren New wrote:
I.e., it looks like it's protecting against offline searches of passwords
you can only truely verify online.
Of course, that's just my interpretation. Read the actual patent for what
they're actually covering.
Thank you very much. For, trusting that you are right, I don't
think I would spend time to study the detailed document.
So it seems that it is virtually the 'employment' of a checksum
that gets patented. When I was in school, solving some systems
Huh? It's just the opposite. Having a checksum (MAC, etc.) that
validates a password guess is exactly what camouflage avoids.
By removing this checksum, and doing some other cleverness, you
get a blob of data that leaks no information about the PIN that
unlocks it. Yet when the right guy comes along with the right
PIN, the
Cryptography-Digest Digest #564
Cryptography-Digest Digest #564, Volume #13 Fri, 26 Jan 01 21:13:00 EST
Contents:
Last revision ("lemaymd")
Re: solving simultaneous equations in modulo arithmetic ("Matt Timmermans")
Re: RSA Source code ("Adam Smith")
Re: Decode Algorythim ("Yeah")
Re: Steak Stream Cipher (Bryan Olson)
Random Number Generator ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Paranoia ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Random Number Generator ("Douglas A. Gwyn")
Re: Dynamic Transposition Revisited (long) ("Douglas A. Gwyn")
From: "lemaymd" [EMAIL PROTECTED]
Subject: Last revision
Date: Fri, 26 Jan 2001 18:31:18 -0600
Thanks for those final pieces of advice! I've modified my algorithm for
hopefully the last time using your suggestion and Joseph Ashwood's. He said
as I understand it that having eight encryption rounds doesn't do much
except slow my algorithm down. So without further ado, here it is:(an
excerpt from my documentation)
3. Description of algorithm
a. Key mutation
Encryption using the Bermuda Triangle 2.1 algorithm consists of several
steps consisting of XOR, rotate and addition operations, involving three key
derived values. It operates with 32768-bit plaintext and ciphertext blocks
controlled by a 32768-bit key, referred to as K0. The principal advantage
of this algorithm is the requirement that the entire key be known before any
decipherment can take place. This is insured by two key mutations,
described here.
The first key derivative is created by loading the first byte of K0, storing
it in a register and to memory, loading the next byte and XORing it against
the register containing the first byte, storing the register contents to the
next memory location and loading each subsequent byte in this manner, XORing
it against this register and storing it to memory. This key derivative is
referred to as K1. The original key, once again, is referred to as K0.
To form the second key derivative the entire key is loaded one byte at a
time from the end of the key to its beginning, stored to a register, XORed
and stored to a memory location as for K1. Note: the last byte in this
memory area will always equal the original key data. This key is referred
to as K2. These keys are now ready to be used in the encryption and
decryption processes.
b. Encryption
The actual encryption process involves one round of twelve XOR, addition and
bitwise rotation operations involving the three key mutations described
earlier and the original plaintext. The identification tag described in
section 2 is placed in the first twelve bytes of this file.
The steps involved are illustrated in this pseudocode segment:
Variables:
C Ciphertext
Kx Key "x"
P Plaintext
X Current byte position
Y Current key offset
Z General purpose register
C[x] = ( ( ( ( ( ( ( ( ( ( ( (
^ K2[y] ) + K1[y] ) K0[y] )
^ K1[y] ) + K2[y] ) K1[y] )
P[x] ^ Z ) + Z ) Z{5lsbits} )
^ K0[y] ) + K0[y] ) K2[y] )
Z = (Z^P[x])
Legend:
^ XOR
+ addition
rotate left
rotate right
"Scott Fluhrer" [EMAIL PROTECTED] wrote in message
news:94lo0p$j71$[EMAIL PROTECTED]...
lemaymd [EMAIL PROTECTED] wrote in message
news:94l9ds$k2m$[EMAIL PROTECTED]...
Poncho,
From what you've written, it's looks as though simplicity is not
this
cipher's weakness. What path would you suggest to strengthen it? I
don't
truly understand how you would retrieve a completely random key (which
of
course it's not, but for simplicity let's say it is) when you have only
the
ciphertext. Theoretically, as is the case with the true stream cipher,
one
XOR operation between the key and data should be sufficient to make an
entirely impossible to crack piece of ciphertext. Because of the huge
size
of the key utilized by this algorithm, it almost qualifies as a stream
cipher itself. Thanks for your valuable input! : - )
If an attacker had only one block of unknown plaintext, that would likely
be
the case. It would appear to be difficult to retrieve either the key or
the
plaintext, and it would obviously be totally impossible for an XOR
operation. However, if the attacker has multiple blocks encrypted under
the
same key, that changes radically. If you look at my suggested attack, you
use one block to guess key bits, and another block (or more likely,
several
blocks) to verify the guess.
As for what this cipher's weakness, it would appear to me caused by
several
things:
- Lack of diffusion between plaintext bits -- the value of one byte never
affects the value of another byte. This means (for example) if the
attacker
leaves that a plaintext "W" at offset 27 encrypts into the byte 0xf3, then
he knows that, for any other block, a ciphertext byte 0xf3 at offset 27
implies that the plaintext had a "W" there as well
- Lack of diffusion between key bits.
Cryptography-Digest Digest #565
Cryptography-Digest Digest #565, Volume #13 Sat, 27 Jan 01 02:13:00 EST
Contents:
Re: Between Silk and Cyanide ([EMAIL PROTECTED])
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: Dynamic Transposition Revisited (long) ("Matt Timmermans")
Re: Steak Stream Cipher ([EMAIL PROTECTED])
32768-bit cryptography, updated ("lemaymd")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: 32768-bit cryptography, updated ("Scott Fluhrer")
Re: Dynamic Transposition Revisited (long) (Terry Ritter)
Re: Dynamic Transposition Revisited (long) (John Savard)
Re: 32768-bit cryptography, updated ("Matt Timmermans")
no joke (adam)
From: [EMAIL PROTECTED]
Subject: Re: Between Silk and Cyanide
Date: Sat, 27 Jan 2001 02:11:56 GMT
In article _Kic6.67331$[EMAIL PROTECTED],
"Roger Peniston-Bird" [EMAIL PROTECTED] wrote:
For instance, what happened to Giskes, who captured so many agents
sent to the Netherlands? Did he survive the war?
Giskes not only survived the war, he wrote a book about the whole
affair. An English translation was published in 1953 by British Book
Centre, Inc. and by William Kimber and Co, in London. It was reprinted
in paperback by Bantam Books in 1982 under the title, London Calling
North Pole.
I found it odd that Marks never mentions Giskes' book. There was an
investigation in the Netherlands after the war, which seems to have
drawn considerable publicity in both the Netherlands and England, and I
suspect that the publication of Giskes' book was due entirely to the
controversy stirred up by this investigation, yet Marks takes no notice
of this in his book.
-- Jeff Hill
Sent via Deja.com
http://www.deja.com/
--
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 02:11:54 GMT
On Sat, 27 Jan 2001 01:20:23 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
There is simply no hope of being able to reach every possible
conventional block cipher substitution "table" in the same way that
Dynamic Transposition can reach every possible permutation.
Absolutely! I agree with that 100%.
But what I'm on about is that that's a comparison between apples and
oranges.
Two rounds of DES with independent subkeys can produce 2^32 different
substitutions which will take any plaintext block P to any ciphertext
block C.
Similarly, "every possible permutation" can produce, for every N-bit
balanced block P, every possible N-bit balanced block C, in
(N/2)!(N/2)! different ways.
However, DES cannot produce every possible overall substitution, every
possible table C(0),C(1),C(2^64-1) of output ciphertext blocks
from input plaintext blocks.
And transposition, period, also cannot produce every possible overall
substitution, every possible table C()
C() where the 12870 possible balanced 16-bit blocks,
(for N=16) are assigned, as ciphertext outputs, to the 12870 possible
balanced 16-bit blocks as inputs.
Transposition of balanced blocks is "better than XOR", because there
is more than one way to get from a particular P to a particular C, but
it does not have the sort of exhaustiveness that you are demanding a
substitution-based polyalphabetic block cipher have in order to be
comparable to Dynamic Transposition. The exhaustiveness it does have,
"all possible transpositions", is not equivalent.
Maybe it seems so because 'transposition' is treated as a class of
encipherment in itself, comparable to 'substitution'; this isn't a
semantic problem, it's a conceptual problem; I think you may be a
victim of the Whorf hypothesis, that language limits how we can think.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
--
From: "Matt Timmermans" [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Sat, 27 Jan 2001 02:28:25 GMT
"AllanW" [EMAIL PROTECTED] wrote in message
news:94sl80$alu$[EMAIL PROTECTED]...
I think I missed one of my classes when I learned programming.
Could you please show me the code corresponding to "generate a
photon?" Use any well-known computer language -- ADA, APL,
BASIC, C, C++, COBOL, FORTRAN, PASCAL -- whatever you feel
comfortable with. I just need to see the basic algorithm for
"generate a photon."
It sounds more like you missed the drunken argument in the college bar about
the feasibility of strong AI, the limits of simulation, the possibility that
that nature can support useful modes of super-Turing computation, who that
girl in the corner is _really_ checking out, and whether or not Bob tries to
coerce his partners into cheating at Euchre.
--
From: [EMAIL PROTECTED]
Subject: Re: Steak Stream Cipher
Date: Sat, 27 Jan 2001 02:33:08 GMT
In article 94t6g3$qai$[EMAIL PROTECTED],
