Cryptography-Digest Digest #114, Volume #12 Tue, 27 Jun 00 06:13:00 EDT
Contents:
Enigma... ("Fortunato")
Re: TEA-wmlscript question (Boris Kazak)
Re: Idea or 3DES (Boris Kazak)
Re: Surrendering Keys, I think not. (Boris Kazak)
Re: breaking encryption - help! (Andru Luvisi)
Re: Enigma... (John Savard)
Re: Surrendering Keys, I think not. ([EMAIL PROTECTED])
Remark on practical predictability of sequences (Mok-Kong Shen)
Re: Surrendering Keys, I think not. (David Blackman)
Re: After the FIPS140-1 randomness tests for DOS (command line)... ("Sam Simpson")
News blurb about our friends in Ft. Meade MD (No User)
Re: Idea or 3DES (Mark Wooding)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: Variability of chaining modes of block ciphers (Mark Wooding)
Re: On a notation issue of Feistel ciphers (Mark Wooding)
Re: Idea or 3DES (David Blackman)
Re: Key agreement in GSM phones (Tome')
Re: Compression & Encryption in FISHYLAND (Tim Tyler)
Re: Compression and known plaintext in brute force analysis (restatements caused by
the missing info .... thread) (Tim Tyler)
Re: Compression and known plaintext in brute force analysis (restatements caused by
the missing info .... thread) (Tim Tyler)
----------------------------------------------------------------------------
From: "Fortunato" <[EMAIL PROTECTED]>
Subject: Enigma...
Date: Tue, 27 Jun 2000 03:33:36 +0200
Does anyone have got enigma's crypto scheme ?
I want to study how it works !!!
Thank you a lot
Fo
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: TEA-wmlscript question
Date: Tue, 27 Jun 2000 04:25:14 GMT
"Douglas A. Gwyn" wrote:
>
> dexMilano wrote:
> > SO I think there are some tables anywhere.
>
> There would not be "tables" of a single number. I am sure
> that one can find phi's decimal expansion to a few dozen digits
> in some table of common constants, and certainly the first
> several digits of the decimal expansion of the square root of 5
> may be found in some table.
>
=============
Try <http://antwrp.gsfc.nasa.gov/htmltest/rjn_dig.html>
aka "RJN's More Digits of Irrational Numbers Page"
Best wishes BNK
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Idea or 3DES
Date: Tue, 27 Jun 2000 04:39:33 GMT
Mark Wooding wrote:
>
> Simon Johnson <[EMAIL PROTECTED]> wrote:
> > Moreover, IDEA doesn't have any steps that might be troublesome in
> > software.
>
> Actually, IDEA's multiplication mod 2^{16} + 1 is a real nuisance in
> software, even though it's theoretically lovely.
==============================
Practically even lovelier: loading numbers into registers tests them
against =0 condition, 16-bit multiplication yields the 32-bit product,
thereafter adding together LSW, MSW and eventual carry finishes the job.
With careful planning - 5-7 register instructions (2 loads, one
branch,
one mult, one add, one adc, one unload).
>
> -- [mdw]
Best wishes BNK
------------------------------
From: Boris Kazak <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Surrendering Keys, I think not.
Date: Tue, 27 Jun 2000 04:59:54 GMT
Harvey Rook wrote:
>
> How do you convince the opponent that you are using an OTP? Because you told
> him, and you provided a sample OTP+plain text? This is security though
> obscurity. In the long run it doesn't work.
>
> Harvey Rook
> [EMAIL PROTECTED]
============================
But all you need is a short delay - some 20-50 years...
Just an eyeblink on a geological scale.
And also, opponent must convince himself that you did not use OTP.
For this there must be a distinguishing attack against the cipher used,
such that with, say, 2^40 plaintexts or ciphertexts it would be possible
to pinpoint the algorithm - DES or IDEA or SAFER or RIJNDAEL.
Are you sure that any decent opponent will engage into this futility?
Best wishes BNK
------------------------------
From: Andru Luvisi <[EMAIL PROTECTED]>
Subject: Re: breaking encryption - help!
Date: 26 Jun 2000 22:28:36 -0700
Steve Basford <[EMAIL PROTECTED]> writes:
[snip]
> Anyone any ideas how I can decode this?
[snip]
It appears to be some kind of byte wise cipher feedback. When two
strings first differ in the nth character, it appears as though the
xor of the plaintext and ciphertext of the nth characters are the same
for both of them. It could be DES or something more powerful in CFB
mode, in which case you're pretty screwed. If the output is only a
function of the previous plaintext, ciphertext, and/or output along
with some fixed key material, then it may be possible to model it
using several 16x16 sboxes.
Could you post the rest of the aXa encryptions, one for every value of
X it will allow you to put in?
I would also very much like to find two different strings XXXX and
YYYY (any length, but they have to be the same length) such that when
XXXXa and YYYYa are encrypted, the resulting strings are the same in
the last byte. Then I would like to try XXXX and YYYY with lots of
other strings, ZZZ, appended, and see if for every trial the ZZZ part
of XXXXZZZ encrypts to the same value as the ZZZ part of YYYYZZZ. It
should only take 16 trial encryptions or so to find such a pair. If
the ZZZ parts always encrypt to the same value, you can be fairly sure
it is just a function of the previous output and plaintext/ciphertext
along with some fixed key material. Otherwise, it is carrying some
larger state with it and is bound to be more difficult.
Andru
--
==========================================================================
| Andru Luvisi | http://libweb.sonoma.edu/ |
| Programmer/Analyst | Library Resources Online |
| Ruben Salazar Library |-----------------------------------------|
| Sonoma State University | http://www.belleprovence.com/ |
| [EMAIL PROTECTED] | Textile imports from Provence, France |
==========================================================================
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Enigma...
Date: Tue, 27 Jun 2000 06:48:17 GMT
On Tue, 27 Jun 2000 03:33:36 +0200, "Fortunato"
<[EMAIL PROTECTED]> wrote, in part:
>Does anyone have got enigma's crypto scheme ?
>I want to study how it works !!!
My web site describes how the Enigma works: there are many other web
sites about the Enigma specifically as well, and I have links to a few
of them.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Surrendering Keys, I think not.
Date: Tue, 27 Jun 2000 06:22:48 GMT
In article <[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> It was either here, or in one of the daily newspapers i read a
> story about the government wanting the police to be able to
> demand the encryption keys for e-mails, files etc.... If it
> where so needed in a criminal investigation.
>
> I was wondering how they would ever be able to *prove* that this
> key is correct. Since one of the requirements for the AES is
> that the output of data encryption produces cipher-text that
> cannot be told apart from random data. If some person said the
> cipher-text was a message encrypted using an OTP, then the
> police must brute-force the underlying algorithm to prove
> otherwise.
>
Isn't it easier to use a steganography system and hide the whole
message in a picture or WAV file so the police do not know its hiding a
cipher in the first place?
> Like i said, a law of this nature can do nothing except catch
> the stupid out. ( Which criminals usally are :) )
>
> Got questions? Get answers over the phone at Keen.com.
> Up to 100 minutes free!
> http://www.keen.com
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Remark on practical predictability of sequences
Date: Tue, 27 Jun 2000 09:56:04 +0200
Pseudo-random sequences, being deterministically generated,
always involve the issue of predictability. On the other
hand, a good cipher prevents the opponent to obtain the
plaintext from the ciphertext. It seems logical to conclude
that, if one feeds a pseudo-random sequence to a good cipher,
the resulting output sequence is practically unpredictable,
since he can't recover the original sequence which he needs
to do the inference in the first place.
I should appreciate comments on this view.
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: Surrendering Keys, I think not.
Date: Tue, 27 Jun 2000 17:58:24 +1000
[EMAIL PROTECTED] wrote:
>
> Isn't it easier to use a steganography system and hide the whole
> message in a picture or WAV file so the police do not know its hiding a
> cipher in the first place?
As Bruce Schneier and no doubt many others have pointed out:
steganography still requires a little care. If you have a set of
elaborate steganography programs sitting on your hard disc, the police
will suspect you might be using steganography. (And if you don't, how do
you conveniently get back your data?)
Given that suspicion, they might even be tempted to take a close look at
the low order bits in your image and sound files. If those bits look
like high quality random numbers, you will have some explaining to do.
That said, steganography is still an excellent idea for some
applications. But you need to be a bit careful, have some good
explanations ready, and probably plant a few decoys so you can say "The
message is hidden in that file, the key is XYZZY" and have something
moderately embarrasing but not criminal, subversive, or confidential, in
that file. You then say all the other odd looking files are only decoys
hiding only random noise. You should have a program that hides random
noise in files on your disc to make this plausible.
Add any other precautions that occur to you as well, most likely i've
missed a few necessary ones.
------------------------------
From: "Sam Simpson" <[EMAIL PROTECTED]>
Subject: Re: After the FIPS140-1 randomness tests for DOS (command line)...
Date: Tue, 27 Jun 2000 09:01:03 +0100
Yeah, but I needed the tests "yesterday" for a client...Sigh, I'll
get coding :)
Cheers,
--
Sam Simpson
http://www.scramdisk.clara.net/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
Mark Wooding <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Sam Simpson <[EMAIL PROTECTED]> wrote:
>
> > Anyone know a download site?
>
> You could write your own. Catacomb contains FIPS 140-1 randomness
> tests, so the hard work's done.
>
> -- [mdw]
------------------------------
Date: Tue, 27 Jun 2000 02:18:48 -0500
From: No User <[EMAIL PROTECTED]>
Subject: News blurb about our friends in Ft. Meade MD
as reported in EE Times, 6/20/2000, p49
"To Upgrade IT equipment, NSA will buy off the shelf"
The NSA will turn to private industry to develop and maintain most
of its unclassified information technology infrastructure as part of
an initiative "to refocus agency assets on core functions that
directly support its national security missions," agency officials
said.
NSA announced the decision earlier this month after completing a
15-month feasibility study called Project Groundbreaker. The study
was designed to assess whether the agency's IT infrastructure
requirements could be met by the private sector and to compare
government and industry performance in providing information
technology such as desktop computers, servers, and voice and data
networks. The agency said it will stage a "managed competition" to
purchase equipment. A single, 10-yr contract could reportedly be
worth $5 billion.
NSA officials called the decision to purchase commercial equipment a
"dramatic change to NSA's long-standing IT operations."
"In order to remain successful in our foreign signals intelligence
and information assurance missions," said Air Force Lt. Gen. Michael
Hayden, NSA director, "we must immediately begin to invest in our IT
infrastructure to secure NSA's agility and adaptibility in the
Information Age. It is critical that we have a robust and reliable
infrastructure capable of supporting our missions."
NSA was hit by a major computer failure in January that crippled its
global spy network, preventing the processing of signals intelligence
for several days. The massive failure reportedly inspired the IT
modernization effort.
The agency has traditionally developed spy technology in-house at
its Ft. Meade MD headquarters. It was instrumental in developing the
first supercomputers that were used to process signals intelligence
gathered from listening posts around the world. However, the
proliferation of encryption and fiber-optic technology has forced
the agency to reforcus its development efforts on spy technology and
to consider buying IT equipment off-the-shelf.
"Explosive growth in the global network and new technologies makes
our partnership with industry more vital to NSA's success than ever
before," Hayden said.
======> Hmmmmm, sure would like to know more about this "partnership
with industry". Where to begin: Clipper chip, key-escrow, NSAKEY built
into Microshaft's OS and thus there's a little bit of Ft. Meade in 90%
of all desktop PCs in the world. Why, it's enough to make one almost
patriotic. <======
NSA has also attempted to reach out to industry and US universities
to develop information security policies and standards. For instance,
it created the National Information Assurance Partnership in 1997
with the Commerce Department's NIST to address security testing
needs for IT equipment manufacturers and users.
======> What better way to ensure it can crack whatever manufacturers
come up with? <======
Despite these outreach efforts, critics of US restrictions on exports
of encryption technology viewed the initiatives with suspicion.
======> What a vast understatement! Really, no more needs to be
said. <======
Four areas will be covered under NSA's IT contract: distributed
computing; enterprise/security management; networks; and telephony.
The modernization effort is expected to save government as much as
$1 billion over 10 years. The agency said it would select a
contractor by the spring of 2001.
The agency's initiave builds on a 1998 pilot program to develop an
approach for outsourcing 20 legacy software systems.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Idea or 3DES
Date: 27 Jun 2000 08:25:16 GMT
Boris Kazak <[EMAIL PROTECTED]> wrote:
> Practically even lovelier: loading numbers into registers tests them
> against =0 condition,
Only on some processors: the ARM in particular doesn't do this, so
that's an extra comparison to do.
> 16-bit multiplication yields the 32-bit product, thereafter adding
> together LSW, MSW and eventual carry finishes the job. With careful
> planning - 5-7 register instructions (2 loads, one branch, one mult,
> one add, one adc, one unload).
I think it was the branch I was particularly objecting to. That's not a
pleasant thing to have to do.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Variability of chaining modes of block ciphers
Date: 27 Jun 2000 08:41:53 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Mark Wooding wrote:
> > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > > Scott Fluhrer wrote:
>
> [snip]
>
> > > You are distorting the discussion context. We are discussing the
> > > possibilities to obtain some improvements upon a given cipher with
> > > some chaining modes, not discussing using two or more ciphers.
> >
> > I think that Scott is trying to say that if you're not happy with your
> > cipher's security, you're best off preprocessing with another cipher
> > rather than playing with fancy chaining modes.
>
> That's right. Hence my answer to him.
But your answer doesn't address his point.
The point is that you're using the wrong fix. The right fix is a good
cipher. Use one.
> > I suspect that it can't exist. Indeed, I suspect that, if we know our
> > adversary's capabilities that accurately, we probably don't need
> > cryptography at all, because we can determine a communication channel
> > which is already secure against him.
>
> If you know the computer of the opponent, then you can calculate the
> time for brute forcing.
Ahhh! I see your problem. Have you learned nothing from the years
you've been reading sci.crypt? Brute force is not the only way to
attack ciphers!
> What do you mean by 'determine a communication channel'?
I mean, you can decide upon some way of communicating which is not
vulnerable to attack from your adversary, since you know his
capabilities so accurately.
> Suppose the messages are to be transmitted via certain public
> providers. What are you going to 'determine'?
That there's a better idea than using that method of communication?
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Variability of chaining modes of block ciphers
Date: 27 Jun 2000 08:49:25 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> I don't understand you. If you use brute force and there is a chaining
> value that is unknown but that is xored to the plaintext block, what
> are you going to do?
Who said anything about brute force?
> (Your first sentence seems unclear. Do you mean that you already have
> a strong enough cipher, so that any add-ons aren't necessary, or
> what?)
I mean that a good cipher, by *definition*, will resist attacks which
recover the key (or, indeed, your plaintext), and that not using a good
cipher is simply folly.
I'm getting rather bored of this argument. Unless you have something
new to add, I think I'll ignore it from now on.
-- [mdw]
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: On a notation issue of Feistel ciphers
Date: 27 Jun 2000 09:26:45 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> it seems less clear why one needs very good avalanche effect in the
> direction of decryption.
Chosen ciphertext attacks.
-- [mdw]
------------------------------
From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: Idea or 3DES
Date: Tue, 27 Jun 2000 19:34:12 +1000
Mark Wooding wrote:
>
> Boris Kazak <[EMAIL PROTECTED]> wrote:
>
> > Practically even lovelier: loading numbers into registers tests them
> > against =0 condition,
>
> Only on some processors: the ARM in particular doesn't do this, so
> that's an extra comparison to do.
>
> > 16-bit multiplication yields the 32-bit product, thereafter adding
> > together LSW, MSW and eventual carry finishes the job. With careful
> > planning - 5-7 register instructions (2 loads, one branch, one mult,
> > one add, one adc, one unload).
>
> I think it was the branch I was particularly objecting to. That's not a
> pleasant thing to have to do.
>
> -- [mdw]
Can you use a conditional move instead? Available on Pentium-2 and also
on ARM and some other RISC chips :-) Not available on older X86 chips
:-(
Conditional moves are usually as fast as other register ops and much
faster than a conditional branch.
It's still not quite as quick as multiply shift and xor, which is nearly
as nice, and probably what Mark would rather do.
------------------------------
From: [EMAIL PROTECTED] (Tome')
Subject: Re: Key agreement in GSM phones
Date: Tue, 27 Jun 2000 09:22:01 GMT
On 26 Jun 2000 20:20:10 GMT, [EMAIL PROTECTED] (Paul Rubin) wrote:
>In article <8j7rqh$92u$[EMAIL PROTECTED]>,
>David A. Wagner <[EMAIL PROTECTED]> wrote:
>>In article <[EMAIL PROTECTED]>, Gerard Tel <[EMAIL PROTECTED]> wrote:
>>> 1. What protocol is used by the two parties to agree on the
>>> 64 bit keys used?
>>
>>The base station and handset share a common key, called Ki. The base
>>station sends a random challenge to the handset. Both ends compute a
>>response SRES and a session key Kc from Ki and the challenge using a
>>symmetric `hashing' algorithm known as A3/A8. The handset sends SRES
>>back to the base station to authenticate itself. Finally, both sides
>>use Kc as their A5 key for that call.
>
>Is Ki a single key shared by the base station and ALL the handsets?!
>Followup questions left to your imagination.
The challenge response use a keyed one way hash function and is like
ISO/IEC 9798-4 , SKID2
Alice <-------- Bob random rb
Alice---------> Bob MACk(rb)
The identification is unidirectional so the network verify the 'user'
identity but the 'user' can't verify the network identity.
Make an air encrytpion so in the network the message is trasmitted
decrypted.
Ki is a unic number stored in the Sim card
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression & Encryption in FISHYLAND
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Jun 2000 09:08:59 GMT
tomstd <[EMAIL PROTECTED]> wrote:
: Here's something funnier. Some attacks actually work better
: against compressed data. The full 16r Differential Attack on DES
: for example doesn't work so well with only ASCII plaintext blocks...
Differential analysis with known plaintext is not much use against DES
anyway. You really need *chosen* plaintexts before there's any
significant advantage over using brute force on DES.
If you can choose plaintext blocks as inputs - and observe their
corresponding cyphertexts directly - compression offers no advantages
anyway - the attacker can just choose his cypher inputs, decompress
them, and send them as messages through the system.
Anyway, superficially, you might have a point - differential attacks
require large sets of known plaintext pairs - and if the range of the
inputs is reduced these will be harder to collect.
Of course, in compensation you don't /need/ to determine how the cypher
responds to all inputs in order to break it, if it's only being used
for ASCII plaintexts. For example, dictionary attacks need to maintain
smaller dictionaries before they can break the messages.
If some input differences are irrelevant because they never happen, a
differential attack can normally be judged to have succeeded - even if it
fails to recover them.
In general, only exercising part of the cyphermachinery means there's
less of it to break.
This might mean that some key bits remain "stuck" in unexercised parts of
the cypher and can't be recovered - but typically you don't /need/ to
recover them to read the messages transmitted using it.
There /might/ be cases where compression helps a particular attack.
For example, if recovering /all/ the key bits helps with breaking the
RNG responsible for key-generation, and some key bits are not spread
around in the key-schedule very much, and remain in inaccessible
parts of the cypher, a failure to compress might be of benefit.
I'd be interested to see a practical example of any such case - i.e.
where the disadvantages compensate for the loss of plaintexts due to
the compression.
However, the net effect of compression (on appropriate plaintext)
usually seems /far/ more positive than negative.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression and known plaintext in brute force analysis (restatements
caused by the missing info .... thread)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Jun 2000 09:22:54 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
:> If the compressor actually compresses, then a larger proportion of
:> cyphertexts will result in expansion to valid plaintexts (for any given
:> length of cyphertext) - so you'll typically need a larger cyphertext (as
:> well as a larger original plaintext) to reduce the number of possible
:> plaintexts to 1.
: Whether compression is keyed or not can make all the difference between
: inconvenience and added strength. Presuming that compression must be
: unkeyed is marching under a similar reasoned banner as presuming that all
: text must be ASCII.
I'm not presuming compression is unkeyed - that's simply what I'm
discussing.
There are distinct security advantages in depriving attackers of
cyphertext - these accrue irrespective of whether key material is
mixed in at the same time.
"Eventually", I suspect compression "should" be keyed. The advantage of
keying is that it generates additional confusion, without wasting cycles
or space (since the compression is occurring anyway).
There are potential disadvantages - in that there's a new way for key bits
to leak [I assume here (as one must when comparing strength of related
systems) that the overall key size remains unchanged)]. While this may
cause significant complex problems, I /suspect/ they will eventually be
largely overcome.
However, we are still in the stone age on this subject. Keying
compression seems like an added complication at this stage. It's
true that added complications can be of benefit in terms of resisting
attack - but complications can have their costs as well. For the
moment, I'd be inclined to KISS.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression and known plaintext in brute force analysis (restatements
caused by the missing info .... thread)
Reply-To: [EMAIL PROTECTED]
Date: Tue, 27 Jun 2000 09:39:54 GMT
zapzing <[EMAIL PROTECTED]> wrote:
: "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
:> zapzing wrote:
:> > And another problem: suppose a random (or already encrypted)
:> > file is encrypted. Then an amount of predictable
:> > information will be added to a file that was previously
:> > perfectly unpredicatble.
:>
:> ? That is false in general.
: A "compression" program cannot "compress" all
: files, while still maintaining the same amount
: of information. If you attempt to compress a
: random file, therefore, the resultant
: "compressed" file will actually be larger.
Say the compression program is the identity transformation with the
modification that the "peace" file maps to the "love" file - and
"love" maps to "peace".
If you pick a file "genuinely" at random (from any set containing both
these files), the chances of hitting either of them is the same.
Therefore if you pick a "random" file, the chance of it expanding
is eactly equal to the chance of it contracting - and the net
information that is added to the file is exactly zero - and no
"predictable information" would be added to the file.
: If you still disagree, I challenge you to
: present a "compression" algorithm that will
: compress *all* files without loss of information.
I think Douglas was right. He never implied anything like this was
possible. A compression program only needs to compress /some/ of its
inputs to qualify for the name - and my counter-example does this nicely.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ VIPAR GAMMA GUPPY.
------------------------------
** 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
******************************
