Cryptography-Digest Digest #469, Volume #9       Tue, 27 Apr 99 01:13:06 EDT

Contents:
  Re: choosing g in DH (Phil Howard)
  Re: function help (Jim Felling)
  Re: Common Passowrds ("Dan")
  Re: RSA-Myth (Jerry Coffin)
  Weakness Found in Alternative Signature Format (David Crick)
  Question on exponent size for DH (Ray)
  Re: function help ([EMAIL PROTECTED])
  Re: Thought question: why do public ciphers use only simple ops like shift and XOR? 
(Jerry Coffin)
  Re: function help (Jim Felling)
  Re: function help ([EMAIL PROTECTED])
  Re: Weakness Found in Alternative Signature Format (David A Molnar)
  Re: Common Passowrds ("Dan")
  Factoring breakthrough? (lcs Mixmaster Remailer)
  Re: Thought question: why do public ciphers use only simple ops like shift and XOR? 
("Trevor Jackson, III")
  Re: FSE-6 Report: Slide Attack ([EMAIL PROTECTED])

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

From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: choosing g in DH
Date: Mon, 26 Apr 1999 21:04:52 GMT

On 26 Apr 1999 14:00:13 GMT DJohn37050 ([EMAIL PROTECTED]) wrote:

| IEEE P1363 gives ways to choose g.  Also, the use of a prime order g was first
| mentioned I believe by Scott Vanstone at the first PKS.
| Don Johnson

Is this something that will explain the mathematics or assume one already knows
the math?  I'm principly looking for resources that explain the math without
having to take a full course in it.  In other words, what is "prime order"?
If there is any general resource that answers questions like this, that would
be good to know as I could consult it with my next question.  What I am wanting
to do is figure out how to take a given number, and find a good value for g that
somehow relates to that number (such as the next higher number that fits a rule).
While I realize DH does not require choosing new values for g for each session,
I want to explore some implications of doing so.

--
Phil Howard           KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]

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

From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: function help
Date: Mon, 26 Apr 1999 17:00:09 -0500

inverse in that case is

A=((A' xor D)-C) xor B

[EMAIL PROTECTED] wrote:

> > Your question is confusing!
> > If you're mapping 4 bits into 1, then of course that's noninvertible.
> > If you're mapping 4 bits into 4 bits, then what are the other 3 rules
> > (for B', C', D')?
> > If you don't actually mean, inverse function, then what *do* you
> > mean?
> > Is "xor" supposed to have precedence over "+", or vice-versa, or
> > are the operators evaluated left-to-right, or right-to-left?
> > Why do you say "without changing A, B, C, or D" -- why would we
> > think they are not constant?
>
> Sorry I meant to write
>
> ((A xor B) + C) xor D)
>
> Tom
> --
> PGP public keys.  SPARE key is for daily work, WORK key is for
> published work.  The spare is at
> 'http://members.tripod.com/~tomstdenis/key_s.pgp'.  Work key is at
> 'http://members.tripod.com/~tomstdenis/key.pgp'.  Try SPARE first!
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


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

From: "Dan" <[EMAIL PROTECTED]>
Subject: Re: Common Passowrds
Date: Mon, 26 Apr 1999 18:14:49 -0400

How do you attack RC4 with a 40 bit key directly?

Dan [EMAIL PROTECTED]

Paul Rubin wrote in message ...

<SNIP>
>
>Word 97 uses RC4 encryption with a 40 bit key.  You're probably better
>off attacking that directly.
>



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

From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: RSA-Myth
Date: Mon, 26 Apr 1999 15:58:35 -0600

In article <[EMAIL PROTECTED]>, 
[EMAIL PROTECTED] says...
> Mahlzeit
> 
> 
> Anonymous ([EMAIL PROTECTED]) wrote:
> 
> > PGP are such that generator with source code and send that the public
> > will never with out code and an RSA PGP.  Think. 
> 
> > But this is RSA approach?  How many times send that the public primes
> > it is RSA approach?  At baud, even the weaknesses that generator with
> > a probability, that the Spooks may have to think just because the same
> > algorithms is RSA PGP cannot! 
> 
> > ...
> 
> Are non-English/US people supposed to understand this?

...or even English speaking US natives?  No, I don't think so.  I 
think somebody basically just took the previous messages in the 
thread, jumbled them semi-randomly (but surely not _truly_ randomly 
<G>) and figured the result made about as much sense as other messages 
in the thread, so they posted it.  The worst part is that they appear 
to be correct.

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

Date: Mon, 26 Apr 1999 20:14:16 +0100
From: David Crick <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.misc,comp.security.pgp.discuss
Subject: Weakness Found in Alternative Signature Format

Full details of an attack against a certain type of RSA signature at

         http://www.rsa.com/rsalabs/html/sigforge_qa.html

I wonder if this applies to PGP RSA signatures?

   David.

-- 
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/~vidcad/ |
| Damon Hill WC96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
| PGP Public Keys: 2048-bit RSA: 0x22D5C7A9 4096-DH/DSS: 0x87C46DE1 |
+-------------------------------------------------------------------+

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

From: [EMAIL PROTECTED] (Ray)
Subject: Question on exponent size for DH
Date: Mon, 26 Apr 1999 15:38:32 -0500

I understand that you need to have a large prime for security in
Diffie-Hellman.  RSA recommends at least 768 bits.

But what about the size of the exponent (i.e., the "secret private"
value)?  From what I read it must be shorter than the prime, but is there
any reason for it to have a particular number of bits?   Does making it
significantly smaller than the prime have any security implication?

In some timing test I ran with a 768 bit prime, an exponent of 568 bits
was much faster than an exponent of 760 bits.

Thanks.

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

From: [EMAIL PROTECTED]
Subject: Re: function help
Date: Mon, 26 Apr 1999 21:56:04 GMT


> A' =( (A+B)  xor C) + D       inverse is ((A' - D) xor C) - B
> A'= (A+B) xor (C+D)           inverse is  (A' xor (C+D)) -B
> A' = A +(B xor C) +D           inverse is  A' -( (B xor C) +D)
> A'= A + ( B xor (C+D))        inverse is A' -( B xor (C+D))

I thought the blowfish F function (the first) had no inverse, or did I read it
wrong?

Tom

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Thought question: why do public ciphers use only simple ops like shift 
and XOR?
Date: Mon, 26 Apr 1999 15:58:37 -0600

In article <7g0u3r$j1h$[EMAIL PROTECTED]>, [EMAIL PROTECTED] 
says...

[ ... ] 

>     Let us design two possible future worlds and then pick the one
>     that is more secure:
> 
>     In the first the AES is used for almost all encryption.
> 
>     In the second world we define a set of several interesting
>     ciphers, preferably ciphers that are different in some fundamental
>     ways. We put in there the AES, some more ciphers that have been
>     extensively analyzed, some ciphers that follow different design
>     methodologies (for example variable ciphers such as Frog, ciphers
>     designed specifically for making analysis very difficult, ciphers
>     using novel primitives or structures, etc.). Now add to all
>     encrypted data or make implicit in all security applications the
>     following information: the subset of the ciphers that must be used
>     and at which "depth", i.e. how many ciphers out of this subset are
>     cascaded in series. Finally extend the secret key with a
>     sufficient number of bits that define the sequence of the ciphers.
>     (I don't want to discuss here how the individual ciphers' keys are
>     defined - I know it is not optimal but as a first approximation
>     let us suppose all individual keys are identical.) Now observe
>     that if you want to use the AES, you just define a subset that
>     includes only the AES and a depth of one. But you can also include
>     the entire set and a depth of one hundred.

The first is more secure, or at least more dependably secure.  The 
problem is, when you combine two algorithms, you're basically 
designing a new cypher.  If you're lucky, it'll combine the strengths 
of both the base cyphers, while negating some of the weaknesses of 
each.

Unfortunately, in cryptology luck tends to be of the bad kind -- you 
might combine two cyphers that end up negating each other's good 
points, and nearly eliminating each other strengths.

Ultimately, when somebody designs something like DES, IDEA or 
Blowfish, they're combining a number of more primitive operations into 
a single, complete cypher.

In your scenario, essentially the same thing is happening, EXCEPT that 
instead of an expert in cryptography studying the individual 
primitives in detail to ensure that they produce a good output, in the 
typical scenario somebody who knows nothing about cryptography is 
going to combine things with little or no chance to study them at all.  
The result may be quite secure, but it may also be EXTREMELY insecure.  
Without doing a fairly intensive study of the exact combination used, 
it's nearly impossible to say which.
 
>     In fact, the original set of ciphers need not be fixed. Allow
>     anybody to add his or her code to the lot in a public Internet
>     server in an environment where everybody can "Amazon-like" comment
>     on all present ciphers, where the experts' opinion is expressively
>     stated and where statistics are held about which products include
>     which ciphers in their "standard" set of ciphers.

This gets worse and worse.  Rather than having a small set of 
primitives that you _might_ be able to study in detail, you're now 
combining an unknown number of primitives in completely unknown ways.  
There's simply no way that anybody can keep up with all the possible 
combinations and figure out which of them produce dangerously poorly 
encrypted output.

>     So which world do you think is more secure: the AES-centric one,
>     or the "organized chaos" one? It seems to me the latter, because
>     the attacker will have a more complex task and less information to
>     work with.

It seems to me the former.  Ultimately, you're designing a single 
cypher that'll be used to do the job.  You're simply taking the design 
of the cypher away from people who study for years about how to do it 
as well as possible, and instead putting it in the hands of (mostly) 
people who haven't a clue of how to design a cypher.
 
>     One can ask if all this is really necessary.

One _should_ start by asking whether it's really useful.  Since the 
answer is "only rarely, if ever", it's pointless to deal with costs, 
necessity, etc. 

>     It is still possible that somebody will publish a provable secure
>     cipher that is practical to implement. Meanwhile a variable cipher
>     protocol similar to the one described above would fulfil almost
>     everybody's requirements for symmetric encryption. This would leave
>     many other problems to worry about such as key management and
>     public key systems, Trojan horses, the appropriate use of encryption
>     technology, etc.

First of all, to a limited degree, variable protocols such as you 
describe are already available -- for example, different versions of 
PGP support triple-DES either or IDEA for the encryption, and RSA or 
Diffie-Hellman for key exchange.  Secure email-protocols support 
relatively open-ended descriptions of the encryption used in a 
particular message, though (thankfully) only a few forms of encryption 
are presently supported.

Second, the variable protocol you propose would be likely to fulfill 
people's needs under only two possible sets of circumstances: either 
1) everybody becomes an expert in designing encryption before they use 
it, or 2) they really don't need much security in the first place.

DES, AES, etc., are all about one basic idea: since most people 
neither know, nor want to know how to design secure encryption, the 
people who do know and care design something that nearly anybody can 
use, and derive real usefulness from it.  If you take a number of 
components of poorly understood design, and leave it to a total 
amateur to pick a combination that'll work well, chances are all too 
high that the final result will be catastrophically awful.

In short: if you intend to combine cyphers and get a secure result, 
you need to put in quite a bit of study to know how they may interact.  
Just for example, most people take for granted that triple-DES is more 
secure than DES, simply because you have three times as large of a 
key.  In fact, in the case of DES, it IS true, because it's been 
proven that DES does not form a group.

By contrast, assume somebody has the mistaken assumption that it all 
really comes down to key-size (quite a common misconception).  He 
notices that the "XOR stream encryption" module will allow him to 
enter MUCH larger keys than any of the others, so he decides to do a 
"triple XOR stream encryption" with three different 40-byte (320-bit) 
keys.

Now, it happens that a simple XOR stream encryption DOES form a group, 
so first of all, doing it three times with three different keys hasn't 
really accomplished a thing -- you've still basically got only a 40-
byte key.  As I'm sure you're well aware, a simple XOR encryption with 
a 40-byte key is _pathetically_ easy to break, even for a rank amateur 
at cryptanalysis.

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

From: Jim Felling <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: function help
Date: Mon, 26 Apr 1999 17:46:40 -0500



[EMAIL PROTECTED] wrote:

> > A' =( (A+B)  xor C) + D       inverse is ((A' - D) xor C) - B
> > A'= (A+B) xor (C+D)           inverse is  (A' xor (C+D)) -B
> > A' = A +(B xor C) +D           inverse is  A' -( (B xor C) +D)
> > A'= A + ( B xor (C+D))        inverse is A' -( B xor (C+D))
>
> I thought the blowfish F function (the first) had no inverse, or did I read it
> wrong?
>
> Tom
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own

All of these are invertable. They are all 1-1 functions, and onto. Thus they are
all bijections given known  B,C,D



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

From: [EMAIL PROTECTED]
Subject: Re: function help
Date: Mon, 26 Apr 1999 22:51:23 GMT

In article <7g2ndi$7s3$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
>
> > A' =( (A+B)  xor C) + D       inverse is ((A' - D) xor C) - B
> > A'= (A+B) xor (C+D)           inverse is  (A' xor (C+D)) -B
> > A' = A +(B xor C) +D           inverse is  A' -( (B xor C) +D)
> > A'= A + ( B xor (C+D))        inverse is A' -( B xor (C+D))
>
> I thought the blowfish F function (the first) had no inverse, or did I read it
> wrong?
>

You're comment is correct, but you're asking the wrong question.
The F function in question uses 8x32 S-boxes which are indexed using
various parts of the input to the F function. The results are then combined
to create the output.

> Tom
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
>

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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

From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.misc,comp.security.pgp.discuss
Subject: Re: Weakness Found in Alternative Signature Format
Date: 26 Apr 1999 23:07:37 GMT

In sci.crypt David Crick <[EMAIL PROTECTED]> wrote:
> Full details of an attack against a certain type of RSA signature at

>          http://www.rsa.com/rsalabs/html/sigforge_qa.html

> I wonder if this applies to PGP RSA signatures?

 The note says that ISO 9796-2, which is the standard affected, does not
 include a hash function. Rather, the message is padded with something or
 other and then signed directly(1). If I'm not mistaken, PGP hashes the 
 message before signing it, so the two formats are different. Therefore
 it may not apply, especially if the attack uses some special property
 of the signed text which may not survive a hash function. 

 (can you say "correlation intractable?" ha)

 Come to think of it, though, 
 I am not sure if PGP uses the PKCS #1 v2.0 standard which uses OAEP or
 PKCS #1 v1.0 or something else ( I remember seeing a "Use PKCS#1 Signatures
in my copy of MacPGP 2.3a way back when). 

 Anyway, the specs for PGP are at 

 http://www.pgpi.com/doc/specs/

 including the signature format. The paper isn't on Stern's web page yet, nor
 at Gemplus R&D. Maybe they'll post it in a few days. Then we can have a look-see
 for ourselves.
 
 -David Molnar

 (1) - I want to say that signing a message directly, even with padding, is a 
 staggeringly bad idea, but maybe the ISO had a good reason for it. Anyone know what?


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

From: "Dan" <[EMAIL PROTECTED]>
Subject: Re: Common Passowrds
Date: Mon, 26 Apr 1999 19:57:14 -0400

=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
That sounds doable. Unlike some of the newer stuff.
Dan [EMAIL PROTECTED]

Nathan Kennedy wrote in message <[EMAIL PROTECTED]>...
>Dan wrote:
>>
>> How do you attack RC4 with a 40 bit key directly?
>>
>
>Try all 2^40 keys, until you get something that looks correct.  RC4
>crackers aren't hard to write, on the other hand *I* wouldn't want to
>reverse engineer a data format like Word.  Maybe there's a
free/commercial
>program out there that does that.  In any event, cracking a 40-bit
RC4 key
>could take anywhere from a couple days to a month directly proportion
to
>the speed of the computer times the speed of the implementation.
>
>Nate
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.0 for non-commercial use <http://www.pgp.com>
iQA/AwUBNyT9V3czPNMGhkSQEQLjAACgoX3x3mqi2nKpPaez9bgjkvD/CdoAnRnC
9B3NHMRpyiyGU4srpfHU+DNi
=SuG0
=====END PGP SIGNATURE=====




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

Date: 27 Apr 1999 00:20:09 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Factoring breakthrough?

Rumor has it Adi Shamir will announce factoring breakthrough soon.
Increasing efficiency by orders of magnitude and breaking keys 100-200
bits longer than current state of the art.

Anybody confirm/deny?


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

Date: Tue, 27 Apr 1999 09:25:50 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Thought question: why do public ciphers use only simple ops like shift 
and XOR?

Jerry Coffin wrote:
> 
> In article <7g0u3r$j1h$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> says...
> 
> [ ... ]
> 
> >     Let us design two possible future worlds and then pick the one
> >     that is more secure:
> >
> >     In the first the AES is used for almost all encryption.
> >
> >     In the second world we define a set of several interesting
> >     ciphers, preferably ciphers that are different in some fundamental
> >     ways. We put in there the AES, some more ciphers that have been
> >     extensively analyzed, some ciphers that follow different design
> >     methodologies (for example variable ciphers such as Frog, ciphers
> >     designed specifically for making analysis very difficult, ciphers
> >     using novel primitives or structures, etc.). Now add to all
> >     encrypted data or make implicit in all security applications the
> >     following information: the subset of the ciphers that must be used
> >     and at which "depth", i.e. how many ciphers out of this subset are
> >     cascaded in series. Finally extend the secret key with a
> >     sufficient number of bits that define the sequence of the ciphers.
> >     (I don't want to discuss here how the individual ciphers' keys are
> >     defined - I know it is not optimal but as a first approximation
> >     let us suppose all individual keys are identical.) Now observe
> >     that if you want to use the AES, you just define a subset that
> >     includes only the AES and a depth of one. But you can also include
> >     the entire set and a depth of one hundred.
> 
> The first is more secure, or at least more dependably secure.  The
> problem is, when you combine two algorithms, you're basically
> designing a new cypher.  If you're lucky, it'll combine the strengths
> of both the base cyphers, while negating some of the weaknesses of
> each.
> 
> Unfortunately, in cryptology luck tends to be of the bad kind -- you
> might combine two cyphers that end up negating each other's good
> points, and nearly eliminating each other strengths.
> 
> Ultimately, when somebody designs something like DES, IDEA or
> Blowfish, they're combining a number of more primitive operations into
> a single, complete cypher.
> 
> In your scenario, essentially the same thing is happening, EXCEPT that
> instead of an expert in cryptography studying the individual
> primitives in detail to ensure that they produce a good output, in the
> typical scenario somebody who knows nothing about cryptography is
> going to combine things with little or no chance to study them at all.
> The result may be quite secure, but it may also be EXTREMELY insecure.
> Without doing a fairly intensive study of the exact combination used,
> it's nearly impossible to say which.
> 
> >     In fact, the original set of ciphers need not be fixed. Allow
> >     anybody to add his or her code to the lot in a public Internet
> >     server in an environment where everybody can "Amazon-like" comment
> >     on all present ciphers, where the experts' opinion is expressively
> >     stated and where statistics are held about which products include
> >     which ciphers in their "standard" set of ciphers.
> 
> This gets worse and worse.  Rather than having a small set of
> primitives that you _might_ be able to study in detail, you're now
> combining an unknown number of primitives in completely unknown ways.
> There's simply no way that anybody can keep up with all the possible
> combinations and figure out which of them produce dangerously poorly
> encrypted output.
> 
> >     So which world do you think is more secure: the AES-centric one,
> >     or the "organized chaos" one? It seems to me the latter, because
> >     the attacker will have a more complex task and less information to
> >     work with.
> 
> It seems to me the former.  Ultimately, you're designing a single
> cypher that'll be used to do the job.  You're simply taking the design
> of the cypher away from people who study for years about how to do it
> as well as possible, and instead putting it in the hands of (mostly)
> people who haven't a clue of how to design a cypher.
> 
> >     One can ask if all this is really necessary.
> 
> One _should_ start by asking whether it's really useful.  Since the
> answer is "only rarely, if ever", it's pointless to deal with costs,
> necessity, etc.
> 
> >     It is still possible that somebody will publish a provable secure
> >     cipher that is practical to implement. Meanwhile a variable cipher
> >     protocol similar to the one described above would fulfil almost
> >     everybody's requirements for symmetric encryption. This would leave
> >     many other problems to worry about such as key management and
> >     public key systems, Trojan horses, the appropriate use of encryption
> >     technology, etc.
> 
> First of all, to a limited degree, variable protocols such as you
> describe are already available -- for example, different versions of
> PGP support triple-DES either or IDEA for the encryption, and RSA or
> Diffie-Hellman for key exchange.  Secure email-protocols support
> relatively open-ended descriptions of the encryption used in a
> particular message, though (thankfully) only a few forms of encryption
> are presently supported.
> 
> Second, the variable protocol you propose would be likely to fulfill
> people's needs under only two possible sets of circumstances: either
> 1) everybody becomes an expert in designing encryption before they use
> it, or 2) they really don't need much security in the first place.
> 
> DES, AES, etc., are all about one basic idea: since most people
> neither know, nor want to know how to design secure encryption, the
> people who do know and care design something that nearly anybody can
> use, and derive real usefulness from it.  If you take a number of
> components of poorly understood design, and leave it to a total
> amateur to pick a combination that'll work well, chances are all too
> high that the final result will be catastrophically awful.
> 
> In short: if you intend to combine cyphers and get a secure result,
> you need to put in quite a bit of study to know how they may interact.
> Just for example, most people take for granted that triple-DES is more
> secure than DES, simply because you have three times as large of a
> key.  In fact, in the case of DES, it IS true, because it's been
> proven that DES does not form a group.
> 
> By contrast, assume somebody has the mistaken assumption that it all
> really comes down to key-size (quite a common misconception).  He
> notices that the "XOR stream encryption" module will allow him to
> enter MUCH larger keys than any of the others, so he decides to do a
> "triple XOR stream encryption" with three different 40-byte (320-bit)
> keys.
> 
> Now, it happens that a simple XOR stream encryption DOES form a group,
> so first of all, doing it three times with three different keys hasn't
> really accomplished a thing -- you've still basically got only a 40-
> byte key.  As I'm sure you're well aware, a simple XOR encryption with
> a 40-byte key is _pathetically_ easy to break, even for a rank amateur
> at cryptanalysis.

You've made some strong claims here, and demolished a trivial example. 
Can you show a real example?  Are there _any_ known weaknesses in
combining any pair of the following:  Blowfish, IDEA, 3DES?  An easier
question would be to ask whther there are any weaknesses known in
combining one of the previously mentioned list with any other cipher.

Are there real facts behind your claims or are you expressing a
subjective judgement?

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

From: [EMAIL PROTECTED]
Subject: Re: FSE-6 Report: Slide Attack
Date: Tue, 27 Apr 1999 00:44:42 GMT


> You may be thinking of the Battle of Midway, possibly the most
> decisive chosen-plaintext attack ever perpetrated. It's featured in
> the movie, but according to Kahn, it really did happen. The
> cryptographers in the Pacific believed the code word was Midway
> Island; those in Washington were convinced that Hawaii would be the
> Japanese primary target. The Americans arranged to have a message sent
> from Midway stating that one of the water purifiers had broken down,
> using a code that they knew the Japanese had broken. When they
> subsequently intercepted a message stating that location "AF" was
> suffering a shortage of fresh water, they knew that "AF" was the
> target and were able to concentrate their naval forces there.

Cool, no offence, but heres an interesting question.  How does this apply to
normal file, or communication links of today?  I really would like to know.

Tom
--
PGP public keys.  SPARE key is for daily work, WORK key is for
published work.  The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'.  Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'.  Try SPARE first!

============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

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


** 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