Cryptography-Digest Digest #536, Volume #10 Wed, 10 Nov 99 02:13:03 EST
Contents:
Modified Feistel network ("Adam Durana")
Re: Modified Feistel network ("Adam Durana")
Re: The story of a small boy --- sealed envelops --- encryption technologies
([EMAIL PROTECTED])
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Modified Feistel network (David Wagner)
Re: Can the SETI@home client be protected? ("ME")
Re: The story of a small boy --- sealed envelops --- encryption technologies (Markku
J. Saarelainen)
Re: How protect HDisk against Customs when entering Great Britain (Albert P. Belle
Isle)
Re: What's gpg? (Jose Castejon-Amenedo)
Re: The story of a small boy --- sealed envelops --- encryption technologies (Markku
J. Saarelainen)
Re: Bracking RSA Encryption. Is it possible. (Jose Castejon-Amenedo)
Re: Build your own one-on-one compressor (Don Taylor)
Re: Modified Feistel network
Re: Modified Feistel network
Re: What's gpg? <PHILOSOPHY 101> (Dennis Ritchie)
Re: Modified Feistel network (Tom St Denis)
Re: What sort of noise should encrypted stuff look like? (Tom St Denis)
Re: What sort of noise should encrypted stuff look like? (Tom St Denis)
Re: Signals From Intelligent Space Aliens? Forget About It. ("Trevor Jackson, III")
Re: The story of a small boy --- sealed envelops --- encryption technologies (Markku
J. Saarelainen)
Re: Can the SETI@home client be protected? ("Trevor Jackson, III")
Re: Modified Feistel network (David Wagner)
----------------------------------------------------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Modified Feistel network
Date: Tue, 9 Nov 1999 18:48:28 -0500
Break input into 3 pieces (L, M, R)
Li = Ri-1 xor F(Mi-1, K1)
Mi = Li-1 xor K2
Ri = Mi-1 ^ F(Li-1, K3)
Recombine the 3 pieces to get output.
After 4 rounds all pieces are influenced by the other pieces and the keys.
The influence is not even though, some pieces are influenced more by another
piece. Is this a problem? Or does anyone see any problems with this
method? Any comments would be greatly appreciated.
-- Adam
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: Modified Feistel network
Date: Tue, 9 Nov 1999 18:53:16 -0500
> Ri = Mi-1 ^ F(Li-1, K3)
That ^ is xor
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,alt.math,soc.culture.russian
Subject: Re: The story of a small boy --- sealed envelops --- encryption technologies
Date: Tue, 09 Nov 1999 22:58:08 GMT
On Tue, 09 Nov 1999 05:34:34 GMT, Markku J. Saarelainen
<[EMAIL PROTECTED]> wrote:
>was this young
>child just smarter than many today's executives?
No. He now thinks this garbage is (i) worth reading, and (ii)
something to do with alt.math.
Dan.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Wed, 10 Nov 1999 00:50:27 +0100
Tim Tyler wrote:
>
> I suspect the *main* problem is finding a dictionary that actually
> compresses text at all.
>
> I assert than English text simply doesn't have anything like 65536 symbol
> strings which are longer than two bytes, and which occur with approximately
> equal frequency ;-(
If each word of the sentence above (where each character as ASCII
occuppies 1 byte) is replaced by 2 bytes, is that a small
compression ratio? That's bigger than one can normally achieve
when compressing the ASCII file with Huffman. Note that in the
replacing with 2 byte numbers we don't care about the frequencies
of the words.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Modified Feistel network
Date: 9 Nov 1999 16:29:12 -0800
In article <1o2W3.24$[EMAIL PROTECTED]>,
Adam Durana <[EMAIL PROTECTED]> wrote:
> Break input into 3 pieces (L, M, R)
>
> Li = Ri-1 xor F(Mi-1, K1)
> Mi = Li-1 xor K2
> Ri = Mi-1 ^ F(Li-1, K3)
>
> Recombine the 3 pieces to get output.
Why treat Mi so differently?
That's an obvious place where I'd start to look for attacks.
Note that you always want independent subkeys in every round,
or at least round subkeys that are different.
Maybe the following is better. Alternate the following two steps:
1. L := L xor F(R, K_i)
2. (L,M,R) := (M,R,L)
This seems like a reasonable enough way to build a cipher, _except_
that encryption and decryption are no longer symmetric. So you probably
want to do the above process for about 6 rounds, then do the reverse
process for another 6 rounds.
------------------------------
From: "ME" <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: Wed, 10 Nov 1999 11:44:15 +1100
I'm not sure IP address is that useful, as some users will be dial-up, and
hence could have different IPs assigned.
Email addresses are more static.
Having multiple copies of a single client is not a problem, as long as you
can profile the different number of clients per S/N - but I personally don't
know how to do that well enough.
Either distribute the client pre-serialised, or supply a set-up tool that
obtains S/N from your server as each client is set-up or used the first
time.
Lyal
>Interesting ideas! Does it help to know that the server knows the IP
>address (so it can send work units) and the email address (so it can
>credit the right person)? Right now those are both created upon
>installation of legit or hacked versions. Right now I can download the
>client and install it on multiple PCs. Maybe SETI should make the
>software so that it only installs from the SETI@home server, serializes
>the client, and makes it hard to get results credited to an email
>address other than the one entered during the install... Just kicking
>ideas around...
>
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,alt.math,soc.culture.russian
Subject: Re: The story of a small boy --- sealed envelops --- encryption technologies
Date: Wed, 10 Nov 1999 01:14:57 GMT
Hey .. you just gave some information to the world that anybody whould
be able to access just in few moments on the internet with a right
search engine. Of course, your query data and user ID (as well as your
originating ISP access location) shall be recorded for the future
commercial purposes. Yes, sure .. it is all about the information.
Lovely ... lovely ... and lovely ...
But other than that, if you can find out details details of one specific
embassy worker who had sent a message from the embassy's common email
address in two minutes, then you are the master. And then you say what
the information is ?
But other than that ... have fun !
Cheers !
In article <80a9qc$mmh$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Anyone wanting to visit this little boy MARKKU can try the following:
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Tue, 09 Nov 1999 20:18:04 -0500
Reply-To: [EMAIL PROTECTED]
On 9 Nov 1999 01:45:29 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>
>No. US law prevents you from taking any encryption, no matter where you
>got it, out of the US without a license.
Except for the automatic "personal use exemption" to which every "US
person" is entitled with no prior arrangements, of course.
(Or the "temporary use" exemptions for "product demonstration"
purposes, or the exemption for employees of "US person" corporations
with overseas dividions, or ...... See the BXA web-site.)
In other words, people (like us) who sell strong crypto can't; but
people who lawfully _have_ strong crypto can, indeed, use it outside
the US under a variety of scenarios without having to "wire Moscow for
instructions."
As long as you have the right, USE IT.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: Jose Castejon-Amenedo <[EMAIL PROTECTED]>
Subject: Re: What's gpg?
Date: Tue, 09 Nov 1999 17:11:58 -0800
Joe Smulowicz wrote:
> I just picked up the fact that there's a GNU version of PGP out, called
> GPG or GNUPG.
>
> I found the web page www.gnupg.org, and it makes claims that no
> patented algorithms are used.
>
> From this claim I would assume that GPG is not as secure as PGP.
How's that? In principle, anyone can come up with a unique, but more or
less, moronic algorithm, and patent it. This wouldn't turn it into a secure
algorithm.
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,alt.math,soc.culture.russian
Subject: Re: The story of a small boy --- sealed envelops --- encryption technologies
Date: Wed, 10 Nov 1999 01:17:27 GMT
"After a battle a Cossack warrior was badly wounded and it looked like
he was about to die. Other Cossacks stood around the wounded one in a
circle (krug) and began singing about their battles and warrior's life.
The energy of the ritual was so strong, that the dying Cossack got up
and joined his brothers-in-arms in their singing."
http://artiom.home.mindspring.com/cossacks/kazpesni.htm
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jose Castejon-Amenedo <[EMAIL PROTECTED]>
Subject: Re: Bracking RSA Encryption. Is it possible.
Date: Tue, 09 Nov 1999 17:24:45 -0800
[EMAIL PROTECTED] wrote:
> I have a big problem. I have a lap top sniffer on a small unix LAN and
> have managed to read packages. The packages are in RSA Encryption. I
> have timed the time it takes to encrypted the e mials. To try to get an
> idea as what the private key is . Brute force attacks on the code off
> line are impossible to brake. Have come to the conclusion that RSA
> encryption is unbrakable and it is a waiste of time using sniffer as I
> cannot brake encryption. Putting the crimminality of it asside the
> question is can RSA code be broken.
With the exception of one-time pads, all encryption algorithms can
theoretically be broken by brute force, and sometimes by more refined
methods. Whether brute force attacks are practical or not is one of the
issues that determines the useability of a given algorithm. This, in turn,
usually depends on key length.
Thus, as of today 256-bit RSA can easily be broken, whereas 1024-bit
one cannot. Additionally, a hypothetical mathematical breakthrough on
integer factoring might render RSA unusable, just as quantum computers
would (integer factoring is a P problem in the quantum computer world.)
------------------------------
From: Don Taylor <[EMAIL PROTECTED]>
Subject: Re: Build your own one-on-one compressor
Crossposted-To: comp.compression
Date: 9 Nov 1999 21:30:48 -0600
In comp.compression Tim Tyler <[EMAIL PROTECTED]> wrote:
> : The main trouble with a scheme like that is to have the general
> : public accept a standard (or defecto standard) of numerical coding.
> : On the other hand, the Unicode gives coding of Chinese 'words' in
> : two bytes. So there is already a precedence case.
> I suspect the *main* problem is finding a dictionary that actually
> compresses text at all.
I am not being critical here or questioning the position that anyone
is taking.
But if someone would like to point at a modest sized collection
of words that they think would be representative of the content
of messages that would be sent, preferably with some estimated
frequencies, particularly for the short words, then I would be
willing to try to produce an algorithm using that dictionary
that I think would have acceptable compression.
If people are particularly concerned about plural forms of words
and are concerned about the compression of words that would not
appear in this dictionary then they should include some frequency
data for those cases.
Given that information I think that given a bit of time to work
on this I can deliver such a compressor. I would need to see
the information first, but my guess is that the resulting
compressor would be very competitive with any of the general
compressors available today, when used on the agreed upon
general style and form and frequwncy of text messages.
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
======== Over 73,000 Newsgroups = Including Dedicated Binaries Servers =======
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Modified Feistel network
Date: 10 Nov 99 04:09:51 GMT
David Wagner ([EMAIL PROTECTED]) wrote:
: In article <1o2W3.24$[EMAIL PROTECTED]>,
: Adam Durana <[EMAIL PROTECTED]> wrote:
: > Break input into 3 pieces (L, M, R)
: >
: > Li = Ri-1 xor F(Mi-1, K1)
: > Mi = Li-1 xor K2
: > Ri = Mi-1 ^ F(Li-1, K3)
: >
: > Recombine the 3 pieces to get output.
: Why treat Mi so differently?
: That's an obvious place where I'd start to look for attacks.
Actually, he *must* treat Mi differently; just as in a round of DES, the
right half is treated differently...Li = Ri-1 without encryption.
If a round of DES were to simultaneously XOR *both* halves of the block
with an f-function of the other half, one would have a hash function, but
not a block cipher. A similar objection applies here.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Modified Feistel network
Date: 10 Nov 99 04:07:39 GMT
Adam Durana ([EMAIL PROTECTED]) wrote:
: Break input into 3 pieces (L, M, R)
: Li = Ri-1 xor F(Mi-1, K1)
: Mi = Li-1 xor K2
: Ri = Mi-1 ^ F(Li-1, K3)
: Recombine the 3 pieces to get output.
: After 4 rounds all pieces are influenced by the other pieces and the keys.
: The influence is not even though, some pieces are influenced more by another
: piece. Is this a problem? Or does anyone see any problems with this
: method? Any comments would be greatly appreciated.
Since ^ stands for xor in C, did you mean to use two different operations
or not? Your round structure is invertible, so it works.
Usually, though, a step like Mi = Li-1 xor K2 is not bothered with. And
the final step from the viewpoint of decryption,
Li = Ri-1 xor F(Mi-1, K3);
since Li-1 is known to the decryptor when this is reversed, it would seem
to me that the whole benefit of splitting the block into three, rather
than four parts (making the F-function operate on a smaller piece, in
itself, _decreases_ security, because it is smaller and therefore simpler)
is to allow the step to, instead, be
Li = Ri-1 xor G(Mi-1, Li-1, K3)
where the second f-function, G, is more complicated than the first, and
depends on Li-1 in a different way than on Mi-1.
Of course, that is just how _I_ would do this sort of thing; there are
other ways to improve as well.
John Savard
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: Dennis Ritchie <[EMAIL PROTECTED]>
Subject: Re: What's gpg? <PHILOSOPHY 101>
Date: Wed, 10 Nov 1999 04:44:45 +0000
Reply-To: [EMAIL PROTECTED]
John Savard wrote (first quoting):
> > .... As the class came to an end, the student woke up and copied the
> >problems from the board, thinking they were his weekend homework assignment.
> >He labored away and when he returned to class the beginning of the next
> >week, he had the solution to one of them. 1 out of 3 ain't bad. If you
> >believe it's impossible to accomplish something- guess what- you're right.
>
> Yes, this really happened; it's not an urban legend. That was Paul
> Cohen, and his proof that the negation of the Axiom of Choice was
> compatible with set theory, wasn't it?
Well, the independence of AC and GCH, and the forcing method,
are Cohen's most memorable contributions that I know of, but
he neglected to mention the waking-up business in his 1966 monograph
and in the 1965 course at Harvard in which he discussed
the then-new (1963) result. I'd want to see some direct testimony
before believing this particular story.
Dennis
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Modified Feistel network
Date: Wed, 10 Nov 1999 04:27:26 GMT
In article <1o2W3.24$[EMAIL PROTECTED]>,
"Adam Durana" <[EMAIL PROTECTED]> wrote:
> Break input into 3 pieces (L, M, R)
>
> Li = Ri-1 xor F(Mi-1, K1)
> Mi = Li-1 xor K2
> Ri = Mi-1 ^ F(Li-1, K3)
>
> Recombine the 3 pieces to get output.
>
> After 4 rounds all pieces are influenced by the other pieces and the
keys.
> The influence is not even though, some pieces are influenced more by
another
> piece. Is this a problem? Or does anyone see any problems with this
> method? Any comments would be greatly appreciated.
Why not just break it up into parts (A, B, C)
for i = 1 to rounds
A = A xor F(B, C, Ki)
(B, C, A) = (A, B, C)
next i
Which is conceptually simpler and has a mixing rate of 1/3. Ideally
you would want to make a SPN cipher and have a rate of 1 (like in
SAFER).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What sort of noise should encrypted stuff look like?
Date: Wed, 10 Nov 1999 04:31:02 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I have the impression most encrypted material look like white noise.
>
> Why not some other noise? e.g. pink noise and so on.
>
> Of course if there is precompression then we should make it follow the
> compressed stuff.
What is pink noise?
Technically encrypted data should not resemble anything, mechanically
though we can think of it as white noise [although white noise is not
actually white, so why do they call it white noise?].
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What sort of noise should encrypted stuff look like?
Date: Wed, 10 Nov 1999 04:30:32 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> I have the impression most encrypted material look like white noise.
>
> Why not some other noise? e.g. pink noise and so on.
>
> Of course if there is precompression then we should make it follow the
> compressed stuff.
What is pink noise?
Technically encrypted data should not resemble anything, mechanically
though we can think of it as white noise [although white noise is not
actually white, so why do they call it white noise?].
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Tue, 09 Nov 1999 23:59:27 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Douglas A. Gwyn wrote:
> John Kennedy wrote:
> > Do you have an engineering solution to deliver an acceleration of G
> > for the time required?
>
> (Note that G turns out to be not much more more than 1, to
> maximize distance traveled in one human lifetime, for any
> reasonable assumption about the effect of G on longevity.)
>
> The point of the exercise was to find an upper bound.
> If the technology is inadequate, that merely reduces the
> achievable distance.
>
> I'm not a spaceship engineer, but I'm aware of some ideas
> along those lines. One that I remember involved gathering
> interstellar protons and fusing them.
That's a Bussard Ramjet. The magnetics make make it useful only for
probes because chordates may not survive the field intensity.
Dr. Forward of JPL (used to be anyway; may still be) has proven that the
optimim mass ratio for a reaction engine using an antimatter energy
source is 2/3rds reaction mass, 1/3 frame & payload. According to his
method the distance/time/acceleration profile influences only the amount
of AM you need to power the thing. I'm not sure he accounted for
relativitistic effects, but as a ball park it may be a useful benchmark
for the nearer stars.
------------------------------
From: Markku J. Saarelainen <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,alt.math,soc.culture.russian
Subject: Re: The story of a small boy --- sealed envelops --- encryption technologies
Date: Wed, 10 Nov 1999 05:13:18 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> No. He now thinks this garbage is (i) worth reading, and (ii)
> something to do with alt.math.
>
> Dan.
>
>
Well, everybody knows that cryptography is all about mathematics. Was
this why I got 10 in math ......
:)
But other than that ... now you know ..
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Wed, 10 Nov 1999 00:26:47 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
You will probably get lots of advice in answer to your question about
validating client software. I'll address a slight tanget that may allow
you to limit the size of the problem without solving the essentially
impossible task of provided an authenticated client.
The key concept is to deny hackers the information they need to crack your
system. Not the client software, your entire server-comm-client
architecture. I've used this approach with good results in several
contexts, including protecting highly priced game software.
The key to the hacker's ability to masquerade as valid client software is
their ability to determine what works and what does not. You provide this
feedback by reacting to the detection of an invalid client. You can deny
this feedback by _not_ detectably reacting to a bad client. Simply react
invisibly
All aspects of the client's behavior is visible to the hackers. There is
_nothing_ you can do in the client that a hacker cannot emulate. You do
however, control two invisble aspects of the system at the server end:
selection of data sets and recording of results. When you detect a bad
client, continue to send data sets indistinguishable from real ones.
Continue to accept results. Perform the detection of a bad client at the
server end, and simply mark the results received from bad clients as bad.
But otherwise do not react to the behavior of the clients.
If your handling of bad clients is invisible to hackers you can use weaker
detection mechisms, such as Verisign, simple test data sets, etc. If you
react detectably to a babd client the hackers can detect the behavioral
criteria that you use to validate the clients, and emulate the validated
behavior.
Consider it an evolutionary mechanism a la genertic algorithms. If you
deny the hackers a fitness function, they will not evolve. If you provide
any detectable fitness function the hacker population will quickly converge
on what works.
Note that "knowing" a clients IP address or other such identifier is
literally meaningless. For instance, the IP address of the node at which I
am typing is unroutable. You cannot possibly reach it because every router
will simply drop your packets on the floor. The local firewall remaps the
IP addresses of the machines behind it to its public, routable IP address.
This on top of the fact that the public IP address mine is remapped to
belongs to a pool owned by an ISP, and will change the next time I dial
in. This ignores the opportunity to go through proxies, anonymizers, etc.
Anything you think you can count on the hackers can change. Anything you
set as fixed they can emulate.
Guy Macon wrote:
> Over in the sci.astro.seti newsgroup there has been some discussion
> whether or not it is possible to protect certain software.
>
> Here is the situation:
>
> SETI@home [ http://setiathome.ssl.berkeley.edu/ ] is a scientific
> experiment that involves millions of Internet-connected computers
> in the Search for Extraterrestrial Intelligence (SETI). Participants
> run a program that downloads and analyzes radio telescope data from
> a server at Berkeley.
>
> Certain people have created unauthorized patches that speed up the
> client program. The scientists at the SETI project have asked that
> only the autorized client be run, but the patchers will not comply.
> This threatens the science behind the project by injecting possibly
> corrupt data into the mix.
>
> The scientists are working on a new version of both the client
> software that you can download and the server software at Berkeley.
> In the newsgroup some folks (not the SETI scientists) have opined
> that it is impossible to protect the client software from such
> patches, and that any such protection can be broken without breaking
> the actual encryption. Is this true?
>
> Note that those who run the patched versions want to do so, so
> something like Verisign which mearly advises of modified software
> isn't good enough.
>
> Also, if a patched client gives a false positive, it will be caught
> by double checking the calvulation at SETI, but if a patched client
> misses ET, then the false negative will be like a needle in a haystack.
>
> There is no need to actually prevent patched clients from running -
> if the server can detect that the client is patched, it can stop
> sending work to be processed, thus shutting the client down.
>
> Is this an intractable problem?
>
> --
> Need a good EE? My resume is at http://users.deltanet.com/~guymacon
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Modified Feistel network
Date: 9 Nov 1999 21:34:22 -0800
In article <yx6W3.370$[EMAIL PROTECTED]>,
Adam Durana <[EMAIL PROTECTED]> wrote:
> What do you mean by symmetric? Do you mean that the encryption and
> decryption processes are not the same? e.g., decryption is not just
> encryption with the keys applied in reverse order. If thats what you mean
> then you are right the method to decrypt is different.
Exactly, you got it.
One practical disadvantage with asymmetric ciphers is they are slightly
more expensive to implement (in hardware), since often one must separately
implement both a decryption and encryption engine.
But probably a much more important disadvantage with asymmetric ciphers
is based on security concerns. If the cipher is symmetric, it is obvious
that chosen-ciphertext attacks are no easier (or harder) than chosen-plaintext
attacks. If the cipher is asymmetric, one cannot make this argument, and
thus one has to start worrying about whether you can do better with chosen
ciphertexts than chosen plaintexts (or vice versa). In practice, it seems
quite common to find that asymmetric ciphers exhibit poorer diffusion in
one of the two directions, and then it seems likely that a smart attacker
might try to exploit this property to his advantage.
------------------------------
** 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
******************************
