Cryptography-Digest Digest #177, Volume #13 Fri, 17 Nov 00 12:13:01 EST
Contents:
Re: DES question: Has this ever been proven before? (Zulfikar Ramzan)
Re: help on user authentication protocol (Edward Keyes)
Re: Hitachi - on what grounds ?? (John Savard)
Re: Big-block cipher, perhaps a new cipher family? (Paul Crowley)
Re: DES question: Has this ever been proven before? (Paul Crowley)
Re: Big-block cipher, perhaps a new cipher family? (Manuel Pancorbo)
Re: Hitachi - on what grounds ?? (Terry Ritter)
Re: My new book "Exploring RANDOMNESS" ("Douglas A. Gwyn")
Re: My new book "Exploring RANDOMNESS" ("Douglas A. Gwyn")
Re: [Question] XOR encryption ("Douglas A. Gwyn")
Re: DES question: Has this ever been proven before? ("Douglas A. Gwyn")
Re: MUST READ IN ORDER TO UNDERSTAND ASTROLOGICAL ORIGINS ("Douglas A. Gwyn")
Re: MUST READ IN ORDER TO UNDERSTAND ASTROLOGICAL ORIGINS (Volker Hetzer)
Re: Big-block cipher, perhaps a new cipher family? (Terry Ritter)
Re: DES question: Has this ever been proven before? (Tom St Denis)
Re: Big-block cipher, perhaps a new cipher family? (Tom St Denis)
Re: Q: fast block ciphers ("Douglas A. Gwyn")
Re: About blowfish... (Cory C. Albrecht)
Re: [Question] Generation of random keys (Alan Rouse)
Re: help on user authentication protocol ([EMAIL PROTECTED])
Re: Silly idea to prevent decrypt (Alan Rouse)
----------------------------------------------------------------------------
Date: Fri, 17 Nov 2000 08:19:00 -0500
From: Zulfikar Ramzan <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
> It seems almost certain that there must exist *some* (K, X, Y) such that
>
> X XOR Y = DES_k(X) XOR DES_k(Y)
>
> though I think searching for one such tuple would be slightly slower
> than breaking DES keys by brute force
So it seems to me that this task may not be so intractable. For example, if the
key k is the all 0 key, then I believe DES is an involution. That is, DES(DES(m))
= m. This follows since all the round keys will be all 0's regardless of the
order in which they are placed. (and DES decryption is DES encryption with the
round keys placed in reverse order)
So, if we pick any X, and set Y = DES(X) -- then the input differential will be:
X \xor Y = X \xor DES(X)
The output differential will be:
DES(X) \xor DES(Y)
= DES(X) \xor DES(DES(X))
= DES(X) \xor X.
This last quantity is the same as the input differential.
The same thing works, I believe, for the all 1's key.
I believe this idea (or some variation of it) should work.
-- Zulfikar Ramzan
>
> However, the probability of events of the form
>
> P(DES'_k(X) XOR DES'_k(Y) = A | X XOR Y = B)
>
> for some A, B and where DES' is some subrange of the DES rounds, is
> *extremely* well studied, in DES more than any other cipher, since this
> is the basis of differential cryptanalysis. If the event you're
> describing had more than non-trivial probability, we would certainly
> know about it by now.
> --
> __
> \/ o\ [EMAIL PROTECTED]
> /\__/ http://www.cluefactory.org.uk/paul/
--
--Zully
=======
Zulfikar Ramzan (AKA Zully)
Laboratory for Computer Science, MIT
NE43-311, (617) 253-2345
http://theory.lcs.mit.edu/~zulfikar/homepage.html
------------------------------
From: [EMAIL PROTECTED] (Edward Keyes)
Subject: Re: help on user authentication protocol
Date: 17 Nov 2000 14:12:45 GMT
In article <8v2ldh$t6k$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> To run this protocol:
> 1. A sends its id
> 2. B finds A's hashed password by A's id. B then uses A's hashed
> password to encrypt a random number and send the result to A.
> 3. A decrypts the random number with its hashed password, then uses the
> random number to encrypt A's hashed password and send the result to B.
> 4. B will then be able to verify if this is A because B knows the random
> number and A's hashed password.
Note that A does not know at the end whether he is really talking to
B or to a fake server which just sent him a few random bytes. The
protocol would have to be extended to do two-way authentication.
+------------ Edward Keyes, [EMAIL PROTECTED] -------------+
|................ http://web.mit.edu/eakeyes/www/ ................|
|.... DaggerWare: "small, sharp, and with a heck of a point!" ....|
+- "A little inaccuracy saves a world of explanation." C.E.Ayres -+
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Hitachi - on what grounds ??
Date: Fri, 17 Nov 2000 14:36:54 GMT
On Fri, 17 Nov 2000 00:55:21 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>http://www.io.com/~ritter/PATS/VSBCPAT.HTM
Although this appears to be a patent on a particular means of
achieving a variable block size, it seems to cover one particular
technique which I would tend to call the "lazy man's cipher".
Suppose a programmer is faced with the problem of encrypting a string
to another string of the same length, using another string as the key.
But the programmer knows that Vigenere is insecure. (He may be writing
the subroutine to replace one that uses Vigenere in an existing
programming environment!)
An obvious technique would be the following:
Use the key string as an S-box. (essentially, repeat it to fill a
255-character, or 95-character, or whatever, table - but use a mod
function instead)...
Let N be the length of the string to be enciphered.
Pass 1:
For I from 2 to N, replace plain(I) by plain(I) + S( plain(I-1) ).
Pass 2:
For I from N-1 to 1, step -1, replace plain(I) by plain(I) + S(
plain(I+1) )
with various elaborations, such as subtracting instead of adding
during some passes, or going from 3 to N and N-2 to 1, and including
plain(I +/- 2), perhaps without the S-box, having more passes, say
four or even six, and throwing in a Vigenere pass at some point.
At one point, a description of Scott16 suggested to me that it was
based on something similar.
This sort of technique, I suspect, is very commonly used when a
programmer wants a quick-and-dirty scrambling routine in an
application where genuine security isn't considered to be required.
Since it works like a Feistel round, there is no need to construct an
invertible substitution table, which is what makes it very simple to
do.
But I'm not sure if the patent relates to what Rijndael does to
achieve its variable block size; that depends, though, on the claims,
which I didn't notice when I glanced at it.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 15:16:19 GMT
Manuel Pancorbo wrote:
> Really interesting. I didn't realize that huge-block ciphers were
> matter of discussion in sci.crypt in the past.
See also http://www.cluefactory.org.uk/paul/mercy/ for the block cipher
I presented at FSE2000 this year, including a discussion of some
weaknesses special to block ciphers and some informatoin about disk
sector encryption.
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Fri, 17 Nov 2000 15:21:46 GMT
Zulfikar Ramzan wrote:
> So it seems to me that this task may not be so intractable. For example, if the
> key k is the all 0 key, then I believe DES is an involution. That is, DES(DES(m))
> = m. This follows since all the round keys will be all 0's regardless of the
> order in which they are placed. (and DES decryption is DES encryption with the
> round keys placed in reverse order)
>
> So, if we pick any X, and set Y = DES(X) -- then the input differential will be:
> X \xor Y = X \xor DES(X)
Yes, it looks to me as though this will work for any of the DES weak
keys
0000000 0000000
0000000 FFFFFFF
FFFFFFF 0000000
FFFFFFF FFFFFFF
Nice!
--
__
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
------------------------------
From: Manuel Pancorbo <[EMAIL PROTECTED]>
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 15:20:18 GMT
In article <8v13r3$jrl$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> By replacing the keys the period of this "cipher" would probably be
> much lower then you would think.
Do you mean that ciphering homogeneous plaintext will reveal short
periodicity on the ciphertext? As much as I know the algorithm this is
quite difficult to occur.
> Also attacks such as chosen-plaintext
> could be damaging.
>
Yes, in the last units of the placket. This is why a previous partial
backward encryption is performed.
> What exactly are these F/G functions anyways? The security of this
> scheme will have to take those into account.
OK, I will show you how they are. Anyway I will post soon the whole
code.
===== Encryption of single unit =========
o = F(i; s0, s1) where
F(i; s0, s1) = s1 ^ SubsBox2(SubsBox1(i ^ s0) <<< 4)
s1 <- G(i, o) where
G(i, o) = SubsBox_1 (i ^ o) >>> 4
=========================================
SubsBox1 is a 4-byte-word substitution consisting in 4 indivual byte
substitution. The S-Boxes used are Rijndael and inverse Rijndael ones
in the following manner {R, R_1, R, R_1}
SubsBox2 is other 4-byte-word substitution with other combination of
Rijndael S-Boxes, namely {R_1, R_1, R, R}. Further, a full byte shift
to the left is performed (<<< 8).
SubsBox_1 is the inverse of SubsBox1.
Remember that G refreshes the S[1] vector state element and, in the
following step, S[1] acts as S[0] (and S[2] as S[1]) and so on. This is
how a single bit change in P[0] propagates through the packet. Remember
also that, at the end, state is reset (S <- K) and a backwad encryption
is performed. So, this single bit change in P[0], although imperfectly
diffused in P'[0], is fully diffused in C[0] (and C[1], C[2]... C[N-1]).
As a quick performance test. To encrypt a 32-bit word is needed:
2x (3 four-byte-word substitutions)
2x (3 XOR bitwise)
2x (2 cyclic rotations)
6 fbws + 6 XOR + 4 cr
To encrypt 128 bits of plaintext:
4x(6 fbws + 6 XOR + 4 cr) = 24 fbws + 24 XOR + 16 cr
As matter of comparison Rijndael block cipher needs, for the same
amount of data and using full 32-bit optimizations:
10x (16 fbws + 16 XOR + 12 arithmetics) = 160 fbws + 160 XOR + 120
arithmetics
--
____________________________________________________________________
Manuel Pancorbo
[EMAIL PROTECTED] (Apply ROT13)
____________________________________________________________________
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Hitachi - on what grounds ??
Date: Fri, 17 Nov 2000 16:07:28 GMT
On Fri, 17 Nov 2000 11:54:52 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Terry Ritter wrote:
>>
>> Mok-Kong Shen<[EMAIL PROTECTED]> wrote:
>> >
>> >Lest Hitachi comes onto further ideas of patenting based
>> >on variability, let's note that variable block sizes,
>>
>> http://www.io.com/~ritter/PATS/VSBCPAT.HTM
>
>Just as a matter of interest in the way of general handling
>by patent offices, did you have to present related materials
>such as those in your
>
> http://www.io.com/~ritter/NEWS/HUGEBLK.HTM
That would have required time-travel, a capability which I have
decided not to reveal:
United States Patent 5,727,062
Filed: Jul. 6, 1995
First HugeBlock Message:
Subject: Ciphers with *Huge* Block Size ?
Date: 22 Aug 1996 17:18:35 GMT
However, the References Cited section does include:
"Gutmann 1974 Excerpt from 400KB Secum File System Documentation.
Moyes, Rubin, Murray, Johnson, Scott, Schneier Messages from Sci.
Crypt (Internet Messages from Jan. 1995)."
>and argue that your idea was novel? Thanks.
The novelty argument is made throughout the patent body, but some
appropriate sections would be:
No Literature on Variable Size Block Ciphers
No Literature on Variable Size Layers
No Literature on Dedicated Diffusion Layers
No Known Literature on Effective Block Ciphers with Few Rounds
No literature on Use of New Combiners in Block Ciphers
Literature Reports Difficulty in Doubling Fixed Block Size
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
Crossposted-To: sci.math,sci.logic
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: My new book "Exploring RANDOMNESS"
Date: Fri, 17 Nov 2000 15:15:29 GMT
Greggy wrote:
> Have you considered making parts of it free for all of us to study,
> such as the algorithms?
Why didn't you look at the referenced Web site?
It has links for both the source code and executable applets.
------------------------------
Crossposted-To: sci.math,sci.logic
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: My new book "Exploring RANDOMNESS"
Date: Fri, 17 Nov 2000 15:17:29 GMT
Niek Sprakel wrote:
> It doesn't matter who wrote the book. If it's not published online it
> can safely be ignored.
Safely?
Practically none of the all-time classic textbooks on
technical subjects are published on line. I guess that
means that you will have to remain ignorant about nearly
everything.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: [Question] XOR encryption
Date: Fri, 17 Nov 2000 15:21:23 GMT
Shri Desai wrote:
> If my key is equal or larger then the input text then can simple XOR
> of input text with key give me a good enough encryption?
Not necessarily. If the key has much structure then this
system is unsafe. If the key was generated by an unbiased
genuinely random process then the system is safe except for
concerns about key exchange. (The intended decipherer has
to get a copy of the key somehow.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Fri, 17 Nov 2000 15:25:44 GMT
Raphael Phan wrote:
> Hmm... John, you are positively sure that a certain DES plaintext XOR
> would not cause the same ciphertext XOR? Are there any references
> (papers, reports...) where it has been explicitly stated that such a
> situation won't happpen?
It doesn't happen for arbitrary inputs. You don't need a reference;
just take two inputs and try it.
Of course, for fixed key and *identical* inputs, the input XOR
equals the output XOR (equals all 0 bits), but that says nothing
about DES other than that it is deterministic.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: MUST READ IN ORDER TO UNDERSTAND ASTROLOGICAL ORIGINS
Date: Fri, 17 Nov 2000 15:28:21 GMT
Numerology and Velikovsky's absurd theories have no place in
*any* sci.* newsgroup, let alone one concerned with cryptology.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: MUST READ IN ORDER TO UNDERSTAND ASTROLOGICAL ORIGINS
Date: Fri, 17 Nov 2000 17:29:29 +0100
"Douglas A. Gwyn" wrote:
>
> Numerology and Velikovsky's absurd theories
Perhaps they are encrypted? :-)
Greetings!
Volker
--
The early bird gets the worm. If you want something else for
breakfast, get up later.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 16:30:10 GMT
On Fri, 17 Nov 2000 12:41:21 GMT, in <8v391g$bo2$[EMAIL PROTECTED]>, in
sci.crypt Manuel Pancorbo <[EMAIL PROTECTED]> wrote:
>[...]
>Really interesting. I didn't realize that huge-block ciphers were
>matter of discussion in sci.crypt in the past. But the question stands
>up: this can be a new formal family of ciphers worthy of deep(er)
>analysis.
>
>Well I conject, from a glance reading of your material, that you are
>familiar to this kind of ciphers. So I invite you reading my original
>post and answer this questions:
>
>1) What's your opinion of this particular huge-block cipher mode? I.e.
>a kernel feedback stream cipher that passes twice -forward and backward-
I have not looked at your cipher per se, but a real look would
probably require implementation and experiment: just "looking" is
rarely enough.
In my experience from actual measurement of diffusion (see, for
example:
http://www.io.com/~ritter/VSBC.HTM#Diffusion
), I have found two passes insufficient.
>2) You mention the concept "avalanche distance" that I correspond
>to "safe distance" in my original post. IMHO, in this scheme the last
>units of the packet (huge-block) are vulnerable up to this "avalanche
>distance" and a previous backward encryption that covers only this
>distance is enough to prevent chosen ciphertext attacks, am I right?
I do talk about distant avalanche, and with this I mean avalanche at
bit positions far removed from the initial change. This is a
measurable quantity.
I don't know if you are right or not.
I do note that *nothing* can prevent known plaintext attacks, and
having a proof that no such attack could succeed would be equivalent
to an overall proof of strength, which seems unlikely.
>3) I mention the possibility that this particular scheme would be weak
>in small packets. How can I measure the safe minimum size of a packet?
It is not possible to measure strength per se. We can measure
particular weaknesses, but we cannot imagine all possible weaknesses,
and so cannot run all possible tests for weakness, nor would we have
time to do so in any case.
We can, however, measure things like diffusion and Boolean function
nonlinearity, to get a handle on some ciphering characteristics.
>Thanks for your attention.
You are welcome.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: DES question: Has this ever been proven before?
Date: Fri, 17 Nov 2000 16:25:37 GMT
In article <[EMAIL PROTECTED]>,
Paul Crowley <[EMAIL PROTECTED]> wrote:
> Zulfikar Ramzan wrote:
> > So it seems to me that this task may not be so intractable. For
example, if the
> > key k is the all 0 key, then I believe DES is an involution. That
is, DES(DES(m))
> > = m. This follows since all the round keys will be all 0's
regardless of the
> > order in which they are placed. (and DES decryption is DES
encryption with the
> > round keys placed in reverse order)
> >
> > So, if we pick any X, and set Y = DES(X) -- then the input
differential will be:
> > X \xor Y = X \xor DES(X)
>
> Yes, it looks to me as though this will work for any of the DES weak
> keys
> 0000000 0000000
> 0000000 FFFFFFF
> FFFFFFF 0000000
> FFFFFFF FFFFFFF
>
> Nice!
As nice and non-origional as that may be, differential attacks are done
when the key is not known. I.e assuming that the above differential
will hold over all keys is not likely, therefore not an attack.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 16:28:34 GMT
In article <8v3ib9$jo2$[EMAIL PROTECTED]>,
Manuel Pancorbo <[EMAIL PROTECTED]> wrote:
> What exactly are these F/G functions anyways? The security of this
> > scheme will have to take those into account.
>
> OK, I will show you how they are. Anyway I will post soon the whole
> code.
>
> ----- Encryption of single unit ---------
> o = F(i; s0, s1) where
> F(i; s0, s1) = s1 ^ SubsBox2(SubsBox1(i ^ s0) <<< 4)
>
> s1 <- G(i, o) where
> G(i, o) = SubsBox_1 (i ^ o) >>> 4
> -----------------------------------------
>
> SubsBox1 is a 4-byte-word substitution consisting in 4 indivual byte
> substitution. The S-Boxes used are Rijndael and inverse Rijndael ones
> in the following manner {R, R_1, R, R_1}
> SubsBox2 is other 4-byte-word substitution with other combination of
> Rijndael S-Boxes, namely {R_1, R_1, R, R}. Further, a full byte shift
> to the left is performed (<<< 8).
> SubsBox_1 is the inverse of SubsBox1.
Double application of an sbox is *only* usefull when there are keys
applied (i.e xor, addition, etc..) to the input of the substitution.
So doing S0[S1[x]] is no better then S3[x] where S3 = S0 o S1.
The rotation left by four bits promotes weak diffusion in one direction
only. I.e a change of one bit could result in only one active sbox
after the S0[S1[x ^ k] <<< 4] layers.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: fast block ciphers
Date: Fri, 17 Nov 2000 15:36:01 GMT
Pranke wrote:
> I never have heared of the idea to use a stream cipher as a block
> cipher, and I really would like to know how THAT should work ?
> While using a block cipher as stream cipher is indeed trivial.
To the contrary, a block cipher requires that PT be encrypted
in chunks rather than a single character at a time; if you
pervert a block cipher into a key generator, then yes the key
can be used in a stream cipher, albeit one subject to
exploitation, because that is not using the block cipher in
its designed enciphering role.
A stream cipher *is* conceptually a block cipher, if you merely
consider the PT as occurring in chunks. A really good stream
cipher (not a mere key generator) will in fact convolve several
characters with, in effect, a sliding window, which differs
from the usual block cipher only in that the latter does not
have overlapping windows.
------------------------------
From: [EMAIL PROTECTED] (Cory C. Albrecht)
Subject: Re: About blowfish...
Date: Fri, 17 Nov 2000 16:58:30 GMT
In article <8ufdb9$of9$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>My memory is too foggy, but Schneier may have defined a
>higher-round-count version. The 16-round version (which needs 18 values
>in the P-table, since you use an extra P value at the start and end..)
>is the common one, don't worry about more rounds.
So the choice of 20 rounds in SSLeay is just some non-standard artifact add=
ed=20
by Eric Young?
--
Cory C. Albrecht
http://members.home.com/cory.albrecht/
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: [Question] Generation of random keys
Date: Fri, 17 Nov 2000 16:45:51 GMT
You will have no trouble finding a good pseudo-random number
generator. One good example is Yarrow at
http://www.counterpane.com/yarrow.html.
The difficult part is obtaining enough entropy for a random seed. That
requires sampling from physical sources which is hardware specific.
And it requires good and conservative estimation of how much entropy is
in your sample. You won't be able to solve that problem with source
code alone. (If you do, please let me know!)
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: help on user authentication protocol
Date: Fri, 17 Nov 2000 16:46:39 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Edward Keyes) wrote:
> In article <8v2ldh$t6k$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> > To run this protocol:
> > 1. A sends its id
> > 2. B finds A's hashed password by A's id. B then uses A's hashed
> > password to encrypt a random number and send the result to A.
> > 3. A decrypts the random number with its hashed password, then uses
the
> > random number to encrypt A's hashed password and send the result to
B.
> > 4. B will then be able to verify if this is A because B knows the
random
> > number and A's hashed password.
>
> Note that A does not know at the end whether he is really talking to
> B or to a fake server which just sent him a few random bytes. The
> protocol would have to be extended to do two-way authentication.
>
But if, for example, C is trying to pretend to be B. The C, however,
will not have A's hashed password. So A will not able to decrypt the
fake data sent from C. Then A will know C is faking? Am I right?
c6ap
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Alan Rouse <[EMAIL PROTECTED]>
Subject: Re: Silly idea to prevent decrypt
Date: Fri, 17 Nov 2000 16:54:31 GMT
Here's how it would be broken:
1) By bribery, burglary, armed robbery, or genius, the algorithm is
discovered.
2) The pseudo-random-number generator is studied for weaknesses. Also
the seed algorithm is attacked. Weaknesses in these reduce the brute
force search field substantially. The key is eventually found and the
message decoded.
BTW there is practically zero chance that your algorithm is stronger
than conventionally accepted crypto algorithms. The best you can hope
for is an equally strong algorithm so that an attacker cannot do better
than brute force attack on the random seed / key. In all likelihood
there exist much easier attacks than brute force.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
