Cryptography-Digest Digest #365, Volume #9 Sat, 10 Apr 99 00:13:03 EDT
Contents:
Re: Security of LFSR on noisy channel. ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: Announce - ScramDisk v2.02h (Boris Kazak)
Re: Announce - ScramDisk v2.02h (Boris Kazak)
Re: Wanted: Why not PKzip? ([EMAIL PROTECTED])
Re: More Diffie-Hellman musings... ("Lyal Collins")
Re: Encrypting Fields in Microsoft Access Database (wtshaw)
Re: a question about time and DES cracking (Solar Designer)
Re: chosen-plaintext attack (wtshaw)
Re: Encrypting Fields in Microsoft Access Database (wtshaw)
Re: Test vector repository--specifically, help with a broken Blowfish (Nathan
Kennedy)
New Hash Function (improved) ([EMAIL PROTECTED])
Re: Is a repeated Vigenere cipher decipherable? (wtshaw)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Security of LFSR on noisy channel.
Date: Fri, 09 Apr 1999 23:56:03 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Now, take 10000 S bits, XOR with 1 D bit, and transmit over a radio
> > channel, at very low power.
> > The intended reciever simply generates 10000 S bits, XORS them with
> > the incoming signal, and adds up the result, if it's over a
> > threshold it's called a 1, if it's under, it's called a 0.
>
> You could do that, but a similar effect can be achieved through
> appropriate coding (e.g. convolutional) with much better throughput.
> It would be better to use those 10000 S bits as key for a good
> conventional encipherment *within* the channel.
Not really, at least with near-term hardware.
I don't think convolutional decoders exist that will pick the data
out of a stream that's 99.9% noise, at 100mbits/second.
If they do, they wouldn't be easy or cheap.
This is basically spread spectrum transmission, but replacing the spreading
code (which can be easily determined) with a psuedo-random sequence, that
is very hard-nigh impossible to crack.
This could be done with a similar CPU to that in some palmpads, with
extra hardware to talk to the radio.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Sat, 10 Apr 1999 01:27:30 GMT
Reply-To: [EMAIL PROTECTED]
On Fri, 9 Apr 1999 17:02:10 -0600, [EMAIL PROTECTED] (Jerry Coffin)
wrote:
>> FIPS-140 has a Long Run Test that uses 20,000 bits:
>Perhaps attaching some hard numbers to things will help the discussion
>in general.
>
>> The Long Run Test
>>
>> 1.A long run is defined to be a run of length 34 or more (of either
>> zeros or ones).
>
>Okay, the chances of creating one of these is obviously 1/2^^34. The
>chance of creating either is therefore 1/2^^33.
>
>> 2.On the sample of 20,000 bits, the test is passed if there are NO
>> long runs.
>
>In 20,000 consecutive bits, there should be 19,967 possible runs of 34
>bits each. Therefore, the chances of failure by a random input is
>19,967/2^33, or approximately 0.000232 percent. IOW, we'd expect a
>random generator to fail approximately once in every 430,206 tests.
The Long Runs Test was the only test for which acknowledged Expert
Mario Trivola was willing to stick his neck out in his book, at least
the 4th edition, which is woefully dated. Ol' Mario is already up to
the 7th edition.
NB: Houston is the center of excellence in oil and gas technology for
the entire world, but it has some catching up to do with its library
system. We're working on it, so keep on pumping and help us out.
Bob Knauer
"I am making this trip to Africa because Washington is an international
city, just like Tokyo, Nigeria or Israel. As mayor, I am an international
symbol. Can you deny that to Africa?"
- Marion Barry, Mayor of Washington DC
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 09 Apr 1999 18:06:51 -0400
Reply-To: [EMAIL PROTECTED]
Patrick Juola wrote:
>
> In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> >But
> >if the ciphers are dynamically selected by keying, or just dynamically
> >selected frequently by communications under cipher, the attacker does
> >*not* know "which systems you're using." Kerckhoff's maxim does not
> >apply.
>
> Unfortunately, this isn't the case.
>
> If the system is dynamically selected by keying, then the exact
> selection becomes part of the key. If you are taking a set of cyphers
> and reordering them, Kerchoff's maxim suggests that you have to assume
> that the attacker knows the set of cyphers and just doesn't know
> the order.
>
> -kitten
=====================
It all depends on the numbers in question.
If there are 2,3,10, even 100 ciphers, you can afford an exhaustive
search, but what if there are 2^16 ciphers (or 2^16 variations of the
base cipher), what then?
Essentially you are adding together the key space and the ciphers
space, with the corresponding increase of problems for an attacker.
Best wishes BNK
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Subject: Re: Announce - ScramDisk v2.02h
Date: Fri, 09 Apr 1999 18:28:10 -0400
Reply-To: [EMAIL PROTECTED]
Terry Ritter wrote:
> .................
> >Of course, your attacker must now analyze the compound cipher, which
> >is almost certainly harder to do than than attacking a single cipher.
>
> Yes. Even if each cipher used has known weaknesses, those may not be
> exploitable in the multi-ciphering case.
>
> ---
> Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
> Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
=================
A practical suggestion: what if we would initialize BLOWFISH not
with the digits of 'pi', but with some other constant - e, sqrt(2),
sin(1)...? How many different ciphers can we generate from the same
base algorithm, and how big will be the additional effort to break
them all? Especially if dynamically selected...
Best wishes BNK
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Wanted: Why not PKzip?
Crossposted-To: comp.security.misc
Date: 10 Apr 99 02:47:31 GMT
In sci.crypt Sundial Services <[EMAIL PROTECTED]> wrote:
> Arthur N. Klassen wrote:
>>
>> [EMAIL PROTECTED] wrote:
>>
>> > Because its encryption is incredibly weak (known plaintext).
>>
>> I've been thinking about this one... Isn't this mainly a concern for
>> people trying to protect Zip-encrypted install-sets from pirates (as
>> spamless' example at the end of that post suggested)?
There are many other examples where known plaintext is available.
Example: You want to decrypt the information in zip files you intercept
from a lawyer to his client.
Become a client of the lawyer.
Wait until, some day, he includes in an encrypted ZIP archive to you a
note: "we have a new associate who will be joining us..."
You have it in the ZIP file he sent you and if it is sent to all clients,
you have the plain text.
Example: On your portable computer you use ZIP to encrypt all your
documents. You use the same password. You are careful always to erase and
wipe the disk when you encrypt a business document. However, you didn't
erase the last letter you sent to your wife that is also zip encrypted
(same password).
Example: You get a password protected archive including an ad for
something. You pass the ad around. Any coworker who gets the ad, has plain
text to decrypt the file on your disk.
There are many other ways to get known plaintext. ZIP's encryption is
terribly weak against known plaintext attacks.
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: More Diffie-Hellman musings...
Date: Sat, 10 Apr 1999 12:38:39 +1000
Why do you need DH when the hash of a shared secret and a counter serves the
same purpose ?
Lyal
Peter Gunn wrote in message <[EMAIL PROTECTED]>...
>Noone has commented on my proposal to avoid the man-in-the middle
>by simply creating a key by hashing a secret shared between the
>client & server with the DH value...
>
>A->B: y1=(2^x1)%p
>B->A: y2=(2^x2)%p
>A: key=H(secret,(y2^x1)%p)
>B: key=H(secret,(y1^x2)%p)
>
>thinking on this a bit more, and wanting to use a user specific secret,
>how about the following...
>
>x1 is a random number
>x2 is a random number
>A is the Client.
>B is the Server.
>H() is a one way crypto hash function (SHA or similar)
>p a large safe prime
>key is the key used for the symmetric block cipher
>U is the userid (perhaps just the user's name??)
>
>A->B: y1=(2^x1)%p, H(U)
>B->A: y2=(2^x2)%p, H(U,y2)
>A: key=H(U,(y2^x1)%p)
>B: key=H(U,(y1^x2)%p)
>
>So, what happens is...
>
>1) The client generates a random number (x1), works out
>y1=(2^x1)%p and sends it along with SHA(userid) to
>the server.
>
>2) Server looks up list of users keyed by SHA(userid)...
>disconnects client if it is not recognised, otherwise
>generates a random number (x2) and returns y2=(2^x2)%p
>to the client, along with SHA(userid,y2). Server works out key for
>block cipher using SHA(userid,(y1^x2)%p).
>
>3) Client calculates SHA(userid,y2) and disconnects if
>the value is wrong. Client works out key for block cipher
>from SHA(userid,(y2^x1)%p)
>
>Then the server and client encrypts all the traffic using their
>shared key. If this works, its possible to have a secure
>client/server network connection that avoids the man in
>the middle based simply on userid, which the server needs
>to keep a list of anyway.
>
>If the user list needs to be public, then a short password
>could be associated with the user, and "userid+password"
>could be used in place of userid (U) above.
>
>Comments please :-)
>
>ttfn
>
>PG.
>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting Fields in Microsoft Access Database
Date: Fri, 09 Apr 1999 20:55:24 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Derek Lyons) wrote:
> [EMAIL PROTECTED] wrote:
>
> >If you want to do encryption, you will need to use C. VB lacks powerful
> >bit-bashing operators (AFAIK it doesn't have bit shifting) and forces
> >you to use signed operators.
>
> You can bit bash in BASIC.... You XOR with 1,2,4,8,16,255 etc to pull
> each bit out and make an 8 byte string, manipulating the string, then
> XOR from the string back into the byte.
>
> It's a b---h and a hack, and slow as dirt, but it works.
>
You can do lots more than the above; remember that binary cannot include
some functions that are most applicable in other number systems. And,
stock bit-based stuff in themselves are merely a starting point for
sophistocated manipulations in binary.
I agree that for exploratory work, speed is not a factor. Delving into
the unknown is not to be forbidden for want of optimal tools; they may
come later as needed their proper design is better defined.
--
Too much of a good thing can be much worse than none.
------------------------------
From: Solar Designer <[EMAIL PROTECTED]>
Subject: Re: a question about time and DES cracking
Date: 10 Apr 1999 01:05:35 GMT
Pete <[EMAIL PROTECTED]> wrote:
> i'm running john the ripper DES cracker on my home linux password file.
> i have to say that i'm extremely surprised to see how slowly the
> incremental cracker works. it's been working for weeks, and i've only
> obtained about 10 cracked passwords.
Its purpose is to detect weak passwords. If all passwords would be
easily crackable, then why use such a password scheme at all.
> does anybody know any order of magnitude estimates on unix password hacking
> and time on a typical pentium II/300? are we talking decades, years or
> months?
Thousands of years, actually (assuming that you're talking about the
time it'd take to get a password for sure).
I am not sure this discussion belongs in here, but as it has already
started, here's a quote from john-1.6/doc/MODES that you should have
read: "it is assumed that cracking with this mode will never terminate
because of the number of combinations being too large (actually, it
will terminate if you set a low password length limit, or make it use
a small charset), and you'll have to interrupt it earlier. That's why
this mode deals with character frequency tables, to get as many
passwords as possible within a limited time."
--
/sd
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: chosen-plaintext attack
Date: Fri, 09 Apr 1999 21:17:27 -0600
In article <[EMAIL PROTECTED]>, Thirteen <[EMAIL PROTECTED]> wrote:
> news.compassnet.com wrote:
> >
> > Hi, thanks for reading this post!
> >
> > Why are public-key systems vulnerable to chosen-plaintext attacks?
>
> One attack is for the attacker to choose a plaintext and have it
> encrypted using the secret key. This may be considered to be a
> signature.
If a type of symmetry is involved, 1 plaintext / 1 key / 1 ciphertext,
such a signature in indistinguishable from encryption, which a signature
should not be. However, it the above relationship is not true for an
algorithm, a far classier signature can be made available by decrypting
either the ciphertext or the plaintext with a different key that that
which would be used for encryption.
.....
>
> >How does it help since public keys are known to everyone.
>
> A cyclic attack can be tried in which the public key is used
> millions of times encrypting each previous ciphertext. After some
> number of such recursive cycles, the plaintext may appear.
This is a restatement of the epicyclic tendencies of block ciphers in
which the amount of I/O information, plaintext/ciphertext, is unitary.
The effective hack can be shorter than expected, depending on the nature
of the algorithm. There are still other ways that such ciphers can go
wrong with such recursive cycles. Full analysis of block ciphers should
include these possible flaws and/or limits.
Consider that a wrong key in some systems might actually be used in a
recursive attack if the algorithm is overly perfect, symmetric in a
sense. Extensive studies of keystructures can have some unwanted
surprises, perhaps showing that a selected key may be in fact a sort of
skeleton key, or at lease partly disable the lock which was thought to be
carefully constructed.
>
> > Why are symmetric cryptosystems not vulnerable to this attack?
>
> Well designed ciphers are not vulnerable because they have enough
> rounds. Poorly designed ciphers are vulnerable to chosen plaintext
> attacks.
Just adding rounds may feed into the attack mentioned above. It may be
that a cipher has some critical range of rounds to be useful. A better
design would not fall apart with increased rounds, or more of some sort of
stages, be they not really rounds in a classic sense.
And, proper chaining, compounding algorithms, can do more than just adding
rounds. Certainly, such would perhaps allow increased key space as a
fringe benefit.
--
Too much of a good thing can be much worse than none.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Encrypting Fields in Microsoft Access Database
Date: Fri, 09 Apr 1999 20:47:37 -0600
In article <N1XN2.379$[EMAIL PROTECTED]>, "David Starr"
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote in message ...
> >In article <7e3kms$svl$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >
> >> If you want to do encryption, you will need to use C. VB lacks powerful
> >> bit-bashing operators (AFAIK it doesn't have bit shifting) and forces
> >> you to use signed operators.
> >>
> >BASIC has very powerful string functions. Rotations are no problem either,
> >merely concatenate a string with itself and use MID$ to select the
> >starting point and original length in the doubled string. This works
> >well, use it all the time.
>
> Am I missing something?
> Bit ops and string ops are not the same thing at all.
>
It appears that you are.
Information can be expressed via various units, bits, trits, digits, etc.,
characters in a set of any base size. String operations allow you to
manipulate any of the multitude of possibilities, certainly bits as well.
Now, I deal with many of the various units, sometimes even bits. Some bit
operations are available in the BASIC I like to use, but string versions,
useful in all number systems, can be in fact more flexible than pure
bit-oriented ones, granted that speed may be compromized; but, for
demonstrating theory as reasonable, speed is one of the lesser concerns of
the moment.
Bit-oriented functions do have their place, and I have been known to use
them. If you confine your operations to those which are bit-convenient,
you severely limit yourself, even in what you might do purely with bits;
to do some higher things, you must in fact paste-up more complicated
mechanisms, some of which are really string function equivalents. I favor
a more genealized approach to handling information, which certainly has
the ability to do the various bit-tricks as a subset.
--
Too much of a good thing can be much worse than none.
------------------------------
From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Test vector repository--specifically, help with a broken Blowfish
Date: Sat, 10 Apr 1999 11:20:15 +0800
Boris Kazak wrote:
> Dear friend, in 99.9% of all C compilers "int" are 16 bit wide.
> You better declare your P,S,L,R and other goodies as "unsigned long",
> then only you might get a slim chance of your program working.
> Also in "printf" you'd better declare the format as %lx, then it
> will print 8 hex places.
What did I say? Hmmm, perhaps I said:
> Enclosed is my implementation of Blowfish. probably not very portable
> across architectures but I'm trying to get it to work right first.
Now, maybe broken PC compilers only have 16 bit ints, but I have about 0
interest in portability to them. Cockroaches outnumber humans more than
100 to one, but I'm not interested them either. I highly debate your 99%
figure anyway.
Right now, I'm just trying to get a working, test vector-passing Blowfish.
Then I'll make a pretty one that will compile on x86 GNU/Linux, Sparcs,
Alphas, Suns, and Crays. But not PC's running Borlando Turbo C++ for DOSO.
Nate
------------------------------
From: [EMAIL PROTECTED]
Subject: New Hash Function (improved)
Date: 10 Apr 1999 04:08:20 GMT
Changes:
(a) I've made some improvements to my hash function (improving
avalanche effect, etc.)
(b) I've run tests for bit biases. I get numbers in the range of
49.9697 to 51.11211. I think that's okay.
(c) I fixed some very stupid coding errors.
Notes:
(a) Utilizing the BIRTHDAY PARADOX, this can be broken in 2^96
operations. That should be enough for now.
(b) I am trying to provide a hash function with the following
features:
It is easy to compute H(m) = h
It is hard to compute H(m`) = H(m)
It is impossible to compute h = m
(c) This was based originally on a block cipher.
(d) This is quite slow, (85 kbps on a 486/66 w/ Linux, small
system load, unoptimized gcc code). This can be good
(if you're hasing small messages and need to prevent
brute force attacks) and bad (if you aren't hashing
small messages). If someone could test this on a modern
machine running DOS (Windows-in-DOS-mode,etc), I would
be much obliged.
(e) This may actually be good as a block cipher. Change
K to the user's 128-bit key. However, this is not
the purpouse of this program. Beware.
You can also fetch this from ftp://146.115.234.58/~noahp/hash.c.
Thanks for your time.
---BEGIN CODE---
#include <stdio.h>
#include <string.h>
int hashround( unsigned long b[6] )
{
int i,j,x;
unsigned long k[4] = {
0xABCDEF98, /* magic numbers */
0x98FEDCBA,
0x12345678,
0x87654321
};
for( j = 0; j < 4; j++ )
{
/* Spread and obfustucate bits. */
for( x = 0; x < 4; x++ )
{
/* you'll see the + ^ - construct a lot in this
* hash function. i like it.
*/
k[x] += b[x] ^ k[0] + k[3] - k[0];
k[x] ^= b[6-x] ^ k[1] + k[2] - k[1];
k[x] -= b[x] ^ k[2] + k[1] - k[2];
k[x] |= ((b[x]^~b[6-x])^b[4-x]) ^ k[3] + k[0] - k[3];
}
/* XOR Spread (Primary Spread): Distribute bits.
*/
b[5] ^= b[4] ^= b[3] ^=
b[2] ^= b[1] ^= b[0] ^=
(((k[j%4]^((k[j%4]^k[1]%16)^(k[(j+1)%4]^k[0]%k[1]))) ^
(k[(j-1)%4]))^((((k[0]|k[1])&k[2])+k[3])));
/* Obfusticative Spread:
* Spread among all words and change bits about.
*/
for( i = 0; i < 6; i++ )
{
b[i] += (k[0]^(k[3]^(~k[2])))-k[1];
b[(i+1)%6] -= (k[3]^(k[2]^(~k[1])))+k[0];
b[0] ^= ~(((k[3]^(k[0]+k[1])))^~(k[2]));
b[(i+1)%6] ^= ~(((k[2]^(k[1]+k[0])))^(~k[3]));
}
/* Additive/XOR Spread */
for( x = 0; x < 4; x++ )
{
/* Simple, repetative spread, but quite effective. */
b[0] ^= k[x];
b[0] += k[3-x];
b[0] -= k[x];
b[0] ^= ~k[x];
b[1] ^= ~k[x];
b[1] += ~k[3-x];
b[1] -= ~k[x];
b[0] ^= ~k[x];
b[2] += (k[x]|(~k[3-x]));
b[2] += ~(k[x]|(~k[3-x]));
k[2] ^= k[x]|k[3-x];
b[2] -= ((k[x]|(~k[3-x])));
b[3] ^= k[3-x];
b[3] -= k[3-x];
b[3] += ~k[x];
b[3] += k[x];
b[3] += k[3-x];
b[4] ^= k[x];
b[4] += k[3-x];
b[4] -= k[x];
b[4] ^= ~k[x];
b[5] ^= ~k[x];
b[5] += ~k[3-x];
b[5] -= ~k[x];
b[4] ^= ~k[x] ^ (k[3-x]|k[x]&k[2-x]);
}
/* Final Spread -- Some spreading & obfustucation */
for( i = 0; i < 6; i++ )
{
b[i] ^= k[i%4];
b[i] ^= k[(3-(i%4))];
b[i] ^= ~k[i%4];
b[i] += k[i];
b[i] ^= (b[i+1]%6^k[i%4]^k[3-(i%4)]);
}
}
}
int main( int argc, char **argv )
{
int i;
unsigned long b2[6];
FILE *f;
/* These magic numbers are derived from e(1) + pi
*
* unix:~$ echo "scale=96;e(1)+(4*a(1))" | bc -l
*/
unsigned long b[] = {
58598744,
82048838,
47382293,
8546321,
65381954,
41649307
};
unsigned long bt[] = {
50653959,
41912220,
3189303,
66397565,
93199417,
386728
};
if( argc == 1 )
{
f = stdin;
}
else
{
f = fopen(argv[1],"r");
if(!f)
{
perror(argv[1]);
exit(1);
}
}
while(!feof(f))
{
for(i=0;i<6;i++)
{
/* Preliminary Obfustucation and spread:
* Obfustucate bits according to what was
* already in the bit registers (the hash
* round of the previous 160 bits)
*/
b[i] = 0x00000000 ^ b[i+1%6] ^ 0xAAAAAAAA
^ b[i+2%6] ^
0xFFFFFFFF ^ b[i+3%6] ^ 0xF0F0F0F0
^ b[i+4%6] ^
0x0F0F0F0F ^ b[i+5%6]
^ (b[i]^(b[i+1%6]|b[i]));
}
fread(&b2,4,6,f);
/* very simple masking of previous hash value
* and current hash value.
*/
for(i=0;i<6;i++)
{
b[i] ^= b2[i];
}
hashround(b); /* hash it! */
for(i=0;i<6;i++)
{
/* Simple +^- construct for obfustucation & spreading */
bt[i] += ~b[i];
bt[i] ^= b[i];
bt[i] -= ~b[i];
bt[i] += (b[i]|(~b[i+1%6]));
/* Create an avalanche */
bt[i] += b[i+1%6]; bt[i] ^= b[i+1%6]; bt[i] -= b[i+1%6];
bt[i] += b[i+2%6]; bt[i] ^= b[i+2%6]; bt[i] -= b[i+2%6];
bt[i] += b[i+3%6]; bt[i] ^= b[i+3%6]; bt[i] -= b[i+3%6];
bt[i] += b[i+4%6]; bt[i] ^= b[i+4%6]; bt[i] -= b[i+4%6];
bt[i] += b[i+5%6]; bt[i] ^= b[i+5%6]; bt[i] -= b[i+5%6];
}
}
printf("%.8x%.8x%.8x%.8x%.8x%.8x\n",
bt[0],bt[1],bt[2],bt[3],bt[4],bt[5]);
}
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Is a repeated Vigenere cipher decipherable?
Date: Fri, 09 Apr 1999 21:54:16 -0600
In article <[EMAIL PROTECTED]>, Jim Gillogly <[EMAIL PROTECTED]> wrote:
> Chris Corcoran wrote:
> > I know the answer to the subject question is probably yes, but if one
>
> Yes.
>
> > were to apply a Vigenere cipher to some plaintext, and then apply
> > another key to the encrypted text, and repeat this several times, how
> > would someone go about decrytpting this?
>
> We tried a challenge like this in sci.crypt a few years ago.
> The straightforward way is a known plaintext attack; you can
> express the known plaintext as a set of linear equations, one
> for each ciphertext letter. The strength of the cipher is no
> better than proportional to the sum of the key-lengths of
> each of the passes, not the product of the key-lengths as a
> beginner might suspect.
>
If three passes used three different words, RED, WHITE, and BLUE, you
could condense the keys into a single key of the product of their lengths,
60 characters, but it is obvious that a pattern exists in far fewer
characters, such that the complete 60 character perfect key could be
projected from far fewer characters; Jim's formula says that it would be
only 12 characters.
I, in my imperfect way, would probably still like to have more than that,
efficiency not being natural to exposure, nor inadequate experience.
--
Too much of a good thing can be much worse than none.
------------------------------
** 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
******************************
