Cryptography-Digest Digest #720, Volume #9       Mon, 14 Jun 99 19:13:08 EDT

Contents:
  Followup: OTP is it really ugly to use or not? (Cyba Nonymous)
  Re: Cracking DES ([EMAIL PROTECTED])
  Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (John Savard)
  Re: Generating Large Primes for ElGamal (Wei Dai)
  Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (James Pate Williams, Jr.)
  Re: TEA vs Blowfish (Peter Gunn)
  Re: huffman code length (Andras Erdei)
  Book Usefulness Question (consalus)
  Re: sbox design (Medical Electronics Lab)
  Re: TEA vs Blowfish (David Wagner)
  Re: OTP is it really ugly to use or not? ([EMAIL PROTECTED])
  Re: IDEA in "aplied cryptography" BRUCE SCHNEIER (John Savard)
  Re: OTP is it really ugly to use or not? ([EMAIL PROTECTED])
  Re: Book Usefulness Question ("Steven Alexander")
  Re: Followup: OTP is it really ugly to use or not? (Jim Gillogly)
  Re: Is there a short digest for short messages? (Jerry Coffin)
  Re: DES and BPANN (James Pate Williams, Jr.)
  Re: Cracking DES ([EMAIL PROTECTED])
  Re: Generating Large Primes for ElGamal ([EMAIL PROTECTED])

----------------------------------------------------------------------------

Date: 14 Jun 1999 16:38:48 -0000
From: Cyba Nonymous <[EMAIL PROTECTED]>
Subject: Followup: OTP is it really ugly to use or not?

Jim,

Thanks for taking the time to give me the benefit
of your knowledge.

I understand most of what you said but still can't
see how re-using bits in a random pad provided they
have been re-scrambled into another random pad
compromises the security  of an OTP. In other words,
does the method I proposed really reuse "the pad"
or not?

That is the question. I don't think so. At least not
in the sense or in a way in which it can be used to
compromise the OTP. I maintain that all the derived
pads are different even though they are derived from
the same CD of random numbers.
No?

Let's say I have a CD with the following random
numbers:

E7 05 87 12 A1 63 BC 29 9A 32 ...

I want to encode the following message #1:

HELLO (48 45 4C 4C 4F)

I use codeword "A" to select bytes from the pad
using a formula based program and it gives me
offsets:

05 02 07 06 09

which yields a pad of:
(that for purposes of discussion is also random)

A1 05 BC 63 9A

I use this pad to encrypt "HELLO" using xor to:

E9 40 F0 2F D5

Now I want to encode a second message #2 which is:

GOODBYE (47 4F 4F 44 42 59 45)

I use codeword "B" to select bytes from the CD
with the program and it gives offsets:

06 01 08 0A 03 05 01

which yields a pad of:

63 E7 29 32 87 A1 E7

I use this pad to encrypt "GOODBYE" using xor to:

24 A8 66 76 E5 F8 A2

Ok now let's assume that the "source" instead of
being 10 numbers like in this example is a CD
full or better yet a DVD full, 8/16 GIG's worth,
and the selection program grabs a calculated mixed
subset of these bytes for the new pad that is
guaranteed to be randomly different for every
unique codeword.

I fail to see then how the security of either message
is compromised simply because I reused bytes from
the CD/DVD? It is not as if I reused the pad or even
a sequence from the pad but in essence what I did
was to generate another unique pad from an existing
pool of random numbers on the CD/DVD right?

Are these messages not secure as long as the codeword
is secure? I will even give you tha pad and the
formula and I bet you can't break it without the
codeword. Or, I'll give you the codeword but you
still can't break it without the pad and the formula.

Is it not true that the encrypted message

24 A8 66 76 E5 F8 A2

can be xor'd back to every possible 7 letter
phrase with some pad? It is obvious to me that
this is so. I can derive a pad to turn those
7 bytes into any message I want so how can anyone
ever know they have got the right answer? Just
because they get a plausible message does not mean
it is the correct message and I don't see how they
can learn anything unless a significant sequence
from the original pad is reused and that can be
prevented by the selection program.

Even granting the "theoretical" it must be's to
be an "absolute" unbreakable OTP in the math sense
which this method may not satisfy isn't this method
still extremely strong? I can't see how it can be
broken. It can't be brute forced, it can't be
factored and even if somehow a part of a message or
even an entire message became known it does not
compromise any other message. I think that is pretty
good.

Or, am I all wet? Come to think of it can't the
selection program be seen as a rng in its own right?
But one that produces numbers that can never be
reproduced by anyone not having the original CD?
Is that another way of looking at this perhaps?

If so then this can be quite useful in that from
say a 16 GIG DVD used as a source you can get perhaps
a lifetime of unique pads and only ever have to deliver
the  "source" pad once.

I hope I am not being to simple or stupid and that
I make some sense here in asking these questions.

I appreciate your patience.

------------------------------

Date: Mon, 14 Jun 1999 04:52:51 -0400
From: [EMAIL PROTECTED]
Subject: Re: Cracking DES

Terry Ritter wrote:
> 
> On 11 Jun 1999 12:46:28 -0700, in
> <7jrp2k$7hn$[EMAIL PROTECTED]>, in sci.crypt
> [EMAIL PROTECTED] (David Wagner) wrote:
> 
> >In article <[EMAIL PROTECTED]>, Terry Ritter <[EMAIL PROTECTED]> wrote:
> >> >Two other points indicate the assumptions are false.  First,
> >> >the reward is proportional to the intelligence value of the
> >> >recovered plaintext and not the volume of plaintext.  Five
> >> >percent of the traffic carries much more than five percent
> >> >of the value, since real traffic is redundant.
> >>
> >> Where does this come from?  Cite please.  Under what assumptions?
> >>
> >> The next time you want to read a 200-page book, rip it apart and
> >> reconstruct the writing from any random 10 pages.  So now "reading a
> >> book" takes only 5% of the time it did.  That should be a boon for
> >> busy executives everywhere!
> 
> >[...]
> >I claim that any five consecutive pages from Biham and Shamir's classic
> >book on differential cryptanalysis would probably be enough to reproduce
> >most of the ideas, with a bit of work.  (Any one of their umpteen pictures
> >of differential characteristics would likely be enough to give away the
> >whole game.)
> 
> *If* we *assume* that an entire book is concerned with a single
> secret, such that any page can reveal it, *then* we will find, to our
> great surprise, that any page can reveal it.  Now let's try making
> more realistic assumptions.
> 
> For example, what percentage of all books fall into such a category?
> What percentage of all crypto message traffic fall into such a
> category?
> 
> And if 5% of the traffic can expose everything, why is it that anyone
> ever bothers to send the other 95%?
> 
> >[...]
> >I don't think this is a particularly contrived example.  Is this what
> >you were asking for?
> 
> I asked for a citation to the literature where somebody has made such
> a statement, identified their assumptions, explained their reasoning,
> and backed it up with evidence.
> 
> Anybody can handwave that only 5% of the traffic is essentially as
> good as 100%, but that does not make it true.  In special cases it may
> be true.  For the most part, I doubt it is.  To imply that it is true
> is to some extent implying that everyone else (!!!) in the world
> operates in a haze, repeating everything they say 20 times.

I recall some experiements in psycho linguistics where people were
required to reconstruct a paragraph of text with a fraction of the
letter/words/sentences.  The results were interesting in that missing
letters did little damage to the reonstructions up to a point where a
sudden collapse of reconstructabiliy was found.

Missing words tended to blur things more, but a long "paragraph" (more
like a page really) could be rebuilt at 50% missing, an some good
results found at 67% missing.

Missing sentences tended to trigger the whisper line effect whereby the
reconstructor invented replacements.  I suspect this is because a
sentence is a complete thought, and if it's missing it's missing.  The
redundancy of sentences is low.  The redundancy of words is pretty high.

I wish I could find those references.  Got to look that up again.

OTOH, looking at modern email systems in which multiply quoted replies
dominate the traffic, intercepting a single message would, in effect,
give away an entire conversation.  I can easily believe that kind of
email is 95% redundant.

<sparks> how redundant were Knaeur's "randomness" threads in sci.crypt?
</sparks>

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Mon, 14 Jun 1999 20:44:06 GMT

[EMAIL PROTECTED] (James Pate Williams, Jr.) wrote, in part:

>if you are a citizen of the United
>States of America currently residing in the U.S.

Not to keep criticizing you for being helpful, but I doubt the United
States has annexed Germany any time lately...

John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm

------------------------------

From: [EMAIL PROTECTED] (Wei Dai)
Subject: Re: Generating Large Primes for ElGamal
Date: Mon, 14 Jun 1999 13:10:59 -0700

In article <7k32ne$plv$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> I'm interested in implementing ElGamal public key encryption.  Is there
> any public source available ( C++ would be great ) for generating large
> primes used in public key encryption?

>From Crypto++ (see http://www.eskimo.com/~weidai/cryptlib.html, 
nbtheory.cpp in the distribution archive):

// generate a random prime p of the form 2*q+delta, where delta is 1 or 
// -1 and q is also prime
// use delta=1 for DH/ElGamal, and delta=-1 for LUCDIF/LUCELG
PrimeAndGenerator::PrimeAndGenerator(signed int delta, 
RandomNumberGenerator &rng, unsigned int pbits)
{
        // no prime exists for delta = -1 and pbits = 5
        assert(pbits > 5);

        Integer minP = Integer::Power2(pbits-1);
        Integer maxP = Integer::Power2(pbits) - 1;
        bool success = false;

        while (!success)
        {
                p.Randomize(rng, minP, maxP, Integer::ANY, 6+5*delta, 12);
                PrimeSieve sieve(p, STDMIN(p+PrimeSearchInterval(maxP)*12, 
maxP), 12, delta);

                while (sieve.NextCandidate(p))
                {
                        assert(IsSmallPrime(p) || SmallDivisorsTest(p));
                        q = (p-delta) >> 1;
                        assert(IsSmallPrime(q) || SmallDivisorsTest(q));
                        if (FastProbablePrimeTest(q) && 
FastProbablePrimeTest(p) && IsPrime(q) && IsPrime(p))
                        {
                                success = true;
                                break;
                        }
                }
        }

        if (delta == 1)
        {
                // find g such that g is a quadratic residue mod p, then g 
                // has order q
                // g=4 always works, but this way we get the smallest 
                // quadratic residue (other than 1)
                for (g=2; Jacobi(g, p) != 1; ++g);
        }
        else
        {
                assert(delta == -1);
                // find g such that g*g-4 is a quadratic non-residue, 
                // and such that g has order q
                for (g=3; ; ++g)
                        if (Jacobi(g*g-4, p)==-1 && Lucas(q, g, p)==2)
                                break;
        }
}

------------------------------

From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Mon, 14 Jun 1999 21:10:29 GMT

On Mon, 14 Jun 1999 20:44:06 GMT, [EMAIL PROTECTED]
(John Savard) wrote:

>[EMAIL PROTECTED] (James Pate Williams, Jr.) wrote, in part:
>
>>if you are a citizen of the United
>>States of America currently residing in the U.S.
>
>Not to keep criticizing you for being helpful, but I doubt the United
>States has annexed Germany any time lately...
>
>John Savard ( teneerf<- )
>http://members.xoom.com/quadibloc/crypto.htm

The response is intended for a wider audience that the original
poster. I hope you are being facetious at my expense.

==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate


------------------------------

From: Peter Gunn <[EMAIL PROTECTED]>
Subject: Re: TEA vs Blowfish
Date: Mon, 14 Jun 1999 17:22:24 +0100

Dave Hazelwood wrote:

> Is there a clear cut advantage in speed for one over the other?
> If so how much.

I suppose it all depends on the implementations and the platform you're
aiming at. An 18 round Blowfish takes about the same time as a
16 round TEA to encrypt/decrypt a block according to my code.
Key set up (expansion) on Blowfish is quite expsensive, but might
not be important if you're only doing it once.

Going by the recommended number of rounds... 18 for Blowfish,
and 32 for TEA (or XTEA), Blowfish is ~twice as fast.

But then again you can code TEA or XTEA in a couple of
minutes :-)

>
> Is there a clear cut advantage in security for one over the other?
> If so why?

TEA apparently has some known weaknesses (broken with 2^32
known plaintexts etc), but XTEA looks ok and is unbroken as far
as I know (Mr Wagner might know better :-)


tata

PG.



------------------------------

From: [EMAIL PROTECTED] (Andras Erdei)
Crossposted-To: comp.compression,alt.comp.compression,sci.math
Subject: Re: huffman code length
Date: Mon, 14 Jun 1999 16:34:04 GMT

"Mr. X" <[EMAIL PROTECTED]> wrote:

>Huffman lengths fit:
>
>1 <= L(1) <= L(2) <= L(3) ... <= L(n) <= (TotalNumberOfSymbols-1)
>
>Huffman frequencies fit:
>
>1 >= F(1) >= F(2) >= F(3) ... >= F(n) >= (1/TotalLengthOfSource)

If you meant that from (i) follows (ii), then counterexample:
L(1) = L(2) = 1 ; F(1) = 0.01 ; F(2)= 0.99 ;

L(i) <= L(j) gives *no* hint on the relation of F(i) and F(j).

OTOH from L(i) < L(j) follows that F(i) >= F(j).

>And:
>
>F(2) + F(3) ... + F(n) = 1-(1/TotalNumberOfSymbols)

No. e.g F(1) = F(2) = 50 / 100 and F(2)  != 1 - 1/100.

> the actual original
>frequencies can not be calculated from the tree alone.

True.


------------------------------

From: consalus <[EMAIL PROTECTED]>
Subject: Book Usefulness Question
Date: Mon, 14 Jun 1999 16:55:56 -0500

Alright.
I decided I want to learn about cryptography.
I got Applied Cryptography and read it.
I've been reading papers on simple ciphers.
Just recently, I found what seems to be a really
great paper on Tom St. Denis's site on cryptoanalysis.
Now, I'm finding myself with a sudden excess of cash, and
so I was looking at Handbook of Applied Cryptography
by Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone
(ISBN: 0-8493-8523-7).  I imagine somebody in here has read it
once or twice, and so I just thought I should ask: It is worth getting?

Thanks,

Kyle Consalus


------------------------------

From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: sbox design
Date: Mon, 14 Jun 1999 12:27:02 -0500

[EMAIL PROTECTED] wrote:
> 
> I have been peering at the sboxes from CAST-128 (I used them in my
> second simple cipher).  And I would like to know about the criterion
> used to make them.  This is what I know.
> 
> 1.  They used bent functions on the inputs
> 2.  There are four 8x32 sboxes
> 3.  When used like in CAST it forms a 32x32 sbox
> 4.  They are resitant to differential and linear analysis.
> 
> My questions are.
> 
> 1.  What is a bent function?
> 2.  How is it resistant to the attacks?
> 
> I have seen a site a long time ago where Charlse talks about them, but
> I lost the link.  I would appreciate any links,urls,etc...

Here's where Entrust has the CAST papers:
http://www.entrust.com/downloads/whitepapers.htm

A "bent" function is a nonlinear boolean function of several
inputs and outputs.  You need to get hold of Carlile's paper
"Good S-boxes are hard to find", it describes everything you
want to know in lots of detail.  If you can't find it in your
library, I'll snail mail a copy to you.

Patience, persistence, truth,
Dr. mike

------------------------------

From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: TEA vs Blowfish
Date: 14 Jun 1999 11:07:40 -0700

In article <[EMAIL PROTECTED]>,
Peter Gunn  <[EMAIL PROTECTED]> wrote:
> TEA apparently has some known weaknesses (broken with 2^32
> known plaintexts etc), but XTEA looks ok and is unbroken as far
> as I know (Mr Wagner might know better :-)

The only weaknesses I know of in TEA are weaknesses in the key
schedule, and probably won't be a problem in many (or most)
applications.

Still, that doesn't mean that TEA is the more prudent choice.
I think TEA has seen less analysis than Blowfish, and Blowfish
less analysis than Triple-DES, which to me indicates something
about the assurance level we can assume from those ciphers.

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: OTP is it really ugly to use or not?
Date: Mon, 14 Jun 1999 17:22:26 GMT

[EMAIL PROTECTED] wrote:

> If it repeats it is not a OTP.  for example 'abcabcabcabcabc' is
> predictable thus not random.  Random doesn't always equal random as
> random numbers do not exist.  If you cannot predict it with any means
> faster then guessing it (brute force) then it's considered random.

What a mess.  Speed of prediction is irrelevent, which is a
good thing since "guessing it" is fast.

--Bryan


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: IDEA in "aplied cryptography" BRUCE SCHNEIER
Date: Mon, 14 Jun 1999 22:16:43 GMT

[EMAIL PROTECTED] (James Pate Williams, Jr.) wrote, in part:

>The response is intended for a wider audience that the original
>poster. I hope you are being facetious at my expense.

It's just that that sort of response _to_ the original poster - on a
systematic basis, yet - will tend to be regarded as discouraging, or
even taunting.

I wish I had the Garbo URL handy...

John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: OTP is it really ugly to use or not?
Date: Mon, 14 Jun 1999 17:26:30 GMT

[EMAIL PROTECTED] wrote:

> You cannot crack a OTP because all plaintexts are equal probable.

Wrong.  The conditional probability of each plaintext given
the ciphertext is the same as the unconditional probability
of the plaintext.  That certainly doesn't mean they're equal.

--Bryan


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------

From: "Steven Alexander" <[EMAIL PROTECTED]>
Subject: Re: Book Usefulness Question
Date: Mon, 14 Jun 1999 15:18:38 -0700


I bought the book a couple of months ago and I've found it quite useful.
However, the book is much more technical than AC and shouldn't be considered
light reading.

-steven



------------------------------

From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Followup: OTP is it really ugly to use or not?
Date: Mon, 14 Jun 1999 15:17:20 -0700

Cyba Nonymous wrote:
> I ... still can't see how re-using bits in a random pad
> provided they have been re-scrambled into another random
> pad compromises the security  of an OTP.

The re-scrambling part is the dicey bit.  If the re-scrambling
is done randomly and the table is very large and equi-distributed,
then that's not effectively different from doing a OTP.  You need
as many random bits to scramble it as you have in your table, of
course, and you then have to find a way to get all those bits to
the recipient.  You could use parts of the CD that you haven't
already touched for a message, which means you'll run through the
CD that much faster.  No free lunch, I'm afraid.  However, you
were talking about doing the re-scrambling under control of a
pseudo-random number generator, not with truly random bits.  A
known or chosen plaintext attack may then be equivalent to
cracking the pseudo-random number generator.  If it's
cryptographically strong, then you have a pretty strong system.
Not a OTP, of course.  If the PRNG is weak, you have a weak
system.

> I maintain that all the derived
> pads are different even though they are derived from
> the same CD of random numbers.
> No?

They may all be different, but they are related, and the
relationship is a function of your PRNG.

> I use codeword "A" to select bytes from the pad
> using a formula based program and it gives me
> offsets:

The strength of your system depends on the "formula based program"
and not on the quality of random numbers in the original pad.
 
> and the selection program grabs a calculated mixed
> subset of these bytes for the new pad that is
> guaranteed to be randomly different for every
> unique codeword.

You mean <really> randomly?  Then you need to send the random
bits you used for the mixing.  You mean with a PRNG?  Then
that's where the strength of the system lives.

> Even granting the "theoretical" it must be's to
> be an "absolute" unbreakable OTP in the math sense
> which this method may not satisfy isn't this method
> still extremely strong?

Depends on the mixing.  If the PRNG is cryptographically
strong, it's quite possible that you'll end up with a system
that's good enough to protect the secrets you need to protect
against an enemy who's willing to pay a certain amount to get
them.  However, if it's cryptographically strong you can
probably build an adequate cryptosystem out of it without
even touching the CD-ROM.

> I can't see how it can be
> broken. It can't be brute forced, it can't be
> factored and even if somehow a part of a message or
> even an entire message became known it does not
> compromise any other message. I think that is pretty
> good.

Consider a range of pseudo-random tranformations of a
smaller table against chosen-plaintext attacks, and you
should get a feeling for how much effort will get you the
result you need.

-- 
        Jim Gillogly
        Highday, 24 Forelithe S.R. 1999, 22:01
        12.19.6.4.19, 3 Cauac 7 Zotz, Ninth Lord of Night

------------------------------

From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Is there a short digest for short messages?
Date: Mon, 14 Jun 1999 16:24:10 -0600

In article <7k3ep0$ukc$[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
says...

[ ... ] 

[ Boris Kazak said: ] 

> > > Whatever the algorithm, if the possible values of your "digest"
> > > are in the range (0 - 10^6), you will most probably have a
> > > collision after digesting ~10^3 messages (birthday paradox).
> > >  - Collision means that two messages have the same digest value -

[ and Tom St. Denis replied: ] 

> > After ~10^3 *RANDOM* messages.  It will still take on average (10^7)/2
> > or about 500,000 messages before you find a real message and a RANDOM
> > message that collide.

[ and Bryan Olson replied: ] 
 
> No, Bkazak got it right.  There's no property of real messages
> that tends to keep them from colliding.  To get a collision
> with a specific message requires an expected (10^6)/2 tries.

Just to clarify and summarize: 

If you have a hash with 10^6 different possible values, you can hash 
approximately 10^3 different messages, and expect to see a collision 
between some pair out of them.

If you start with a predetermined message, you need to plan on hashing 
about (10^6)/2 different random messages before you find one that 
collides with it.

500,000 is the same as (10^6)/2.

------------------------------

From: [EMAIL PROTECTED] (James Pate Williams, Jr.)
Subject: Re: DES and BPANN
Date: Mon, 14 Jun 1999 19:57:39 GMT

Does anyone know of the usage of a backpropagation with momentum
artificial neural network (BPANN) to learn the DES function given a
few training examples that consist of known plaintext - ciphertext
pairs. Suppose you have 64 training examples then by the old rule of
thumb you would need (64 + 64) / 2 + sqrt(64) = 72 hidden units. This
would make the network 64 by 72 by 64. If you would like to have
a copy of C++ BPANN with momentum  source code to learn the simple
exclusive or (XOR) function then email at the following address
requesting test.cpp.

==Pate Williams==
[EMAIL PROTECTED]
http://www.mindspring.com/~pate


------------------------------

Date: Mon, 14 Jun 1999 06:35:51 -0400
From: [EMAIL PROTECTED]
Subject: Re: Cracking DES

[EMAIL PROTECTED] wrote:
> 
> In article <[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED] wrote:
> >(...)
> > Note that algorithmic weaknesses scale linearly.  I.e. if you double
> the
> > number of algorithms you double the amout of work for an adversary
> > (Ritter and others have suggested that this may not be true, for this
> > topic it is true.)
> >
> > Key weakness does not scale linearly.  If you double the key size
> (which
> > is the usual technique for 3DES) you do much more than double the
> > adversary's workload.  "Just running it three times" does not increase
> > the security by a factor of three.  It increses it by a factor of
> 2^56.
> > So if you buy a super-duper one minute DES cracker, you need 2^56
> > minutes to crack 3DES with it.
> 
> There is a big difference between combining ciphers in parallel or in
> series. If you combine them in series then security grows much faster
> than linearly. Resistance against most known attacks grows
> exponentially if you add rounds to a cipher.

No.

Consider the slide attack.  You don't even get polynomial strength
increases.

In general I agree that there are synergistic effects that may give
increased security when you use multiple cipher layered properly. 
However, I suspect that since we cannot measure the strength of the
individual ciphers that algebraic manipulation of the unknowns will not
increase the cipher strength or our knowledge thereof.

If you can solve F(?) = X, I want to see it.

 If you combine different
> ciphers it is possible that an attack will not work at all. For
> example, if you like DES but need a larger key then your are probably
> better off combining different algorithms, say DES-IDEA-DES rather then
> simply 3DES.
> 
> Using different ciphers in parallel, i.e. choosing one cipher for
> encrypting some messages and another to encrypt other messages, doesn't
> seem to be a good idea as Bryan Olson has exhaustively explained. It is
> rather odd though that this is precisely what the government does: I
> understand they use many different ciphers. Wouldn't it be better to
> use only one? Well, maybe these different ciphers are optimized for
> different operational environments or, maybe, in this way it is easier
> to keep them secret.
> 
> If it were possible to produce a *huge* number of cryptanalytically
> unrelated ciphers, then the attacker could not study them all, choose
> the weakest and attack it recovering part of the information.
> 
> A similar idea is to use a huge number of permutations and choose one
> depending on the key. In a previous post I described "heavy DES", a
> slowish cipher that encrypts 64 bit blocks with a 140 bit secret key by
> executing 10 DES encryptions in series. First define and publish 16K
> random DES keys. Observe that you need 14 bits to index one DES key.
> Next, take the secret key, divide it into 10 indexes and encrypt the
> plaintext by sequentially chaining the 10 indexed DES functions. DES is
> not a group, therefore each instance of the 140 bits long key results
> in a different permutation.
> 
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Generating Large Primes for ElGamal
Date: Mon, 14 Jun 1999 21:07:10 GMT



Thanks Pate,

I tried to get FreeLIP from your link, but the ftp site didn't seem to
like anonymous as user and my email as the password.  Do you know if
it's still 'free' and if so how I can get it?

Thanks,

Ron


> I have implemented ElGamal public-key encryption using Arjen K.
> Lenstra's FreeLIP (Free Large Integer Package). See my home
> page for a hyperlink to FreeLIP. If you are a citizen of the U. S.
> currently residing in the U. S. and you would like to have a copy
> of a C implementation using FreeLIP of 8.18 Algorithm ElGamal
> public-key encryption from _Handbook of Applied Cryptography_
> by Alfred J. Menezes et al. page 295 then send me an email
> at the address shown below requesting elgamal.c.
>
> ==Pate Williams==
> [EMAIL PROTECTED]
> http://www.mindspring.com/~pate
>
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and sci.crypt) via:

    Internet: [EMAIL PROTECTED]

End of Cryptography-Digest Digest
******************************

Reply via email to