Cryptography-Digest Digest #454, Volume #10 Tue, 26 Oct 99 21:13:03 EDT
Contents:
Re: compression and encryption (Tim Tyler)
Re: Unbiased One to One Compression (Tim Tyler)
Re: This compression argument must end now (SCOTT19U.ZIP_GUY)
Re: Unbiased One to One Compression (Tim Tyler)
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E ("Trevor Jackson, III")
Re: This compression argument must end now (Tim Tyler)
Re: This compression argument must end now (Tom St Denis)
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E (Tom St Denis)
Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E (Tom St Denis)
Re: This compression argument must end now (SCOTT19U.ZIP_GUY)
Re: Q: Optimal diffusion ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: compression and encryption
Reply-To: [EMAIL PROTECTED]
Date: Tue, 26 Oct 1999 20:45:26 GMT
Geoffrey T. Falk <gtf[@]cirp.org> wrote:
: SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
:> (Geoffrey T. Falk) wrote:
:>>David's "1-1" criterion is not mathematically necessary. All that is
:>>necessary is to ensure that every file is a valid input file to the
:>>decompressor. [...]
We don't agree about this. You need to make sure Comp(Decomp(X)) = X.
:>>If the algorithm is not "1-1" then some input files may produce
:>>infinite-length output files.
Not 1-1 does /not/ mean that infinite files may be produced. You /said/
you had a proof that you were right about this - but I have yet to see it.
:>> But this does not help the attacker, because determining this is
:>> equivalent to the halting problem.
:>
:> I think you are lost. If one is decompressing a file and it does not
:>stop uncompressing due to your method using an infinite loop. Then
:>you have a bad file and the key was wrong.
: You missed my point. Detecting loops can be a hard problem.
Nope. I feel I /have/ to restrict the discussion to practical compression
routines. If you're proposing that your compressor be used for
/practical/ encryption purposes it has to spit out it's decompressed files
reasonably quickly. If it fails to do so for real messages, it is
simply not very useful.
Consequently if a decompression fails to terminate, an attacker
can simply terminate it - as it can't practically be a real file.
He doesn't need to analyse the cypher, or solve the halting problem.
: One can detect certain kinds of loops easily, but in general the
: problem of showing that the output of an arbitrary Turing machine
: is infinite is intractable. This leads me to believe that your strict
: "1-1" criterion is not necessary. There are non-bijective
: compression algorithms which will give you the same thing.
These either fail to decompress real messages in a bounded time, or
simply do not have the property you are claiming. Your scheme
consequently appears to be not of any practical utility.
: You also want to make sure that for a given X, either
: Comp(Decomp(X)) = X, or Decomp(X) is infinite. Otherwise the attacker
: can try Comp(Decomp(X)) and if it does not equal X, he knows he has
: the wrong key. But if Decomp(X) is infinite, he can't even do this.
: And if you design your algorithm well, he will have a hard time
: even detecting this possibility: Your file might have a trillion zeros
: in a row--how can he prove it doesn't?!
I suspect Occam's rasor would be sufficient for him. If you find that
a shipping broadcast has a million zeros in a row, your decryption has
failed.
: I am not missing that at all. The only thing that is different in my
: scenario is the possibility of getting infinite-length files when
: decompressing. But even if that happens, the attacker cannot be
: guaranteed to detect it. He can only do it if he knows an upper
: bound on the size of your plaintext. So, in a strictly theoretical
: sense, this may not help him at all. That is all I am saying.
Your "strictly theoretical sense" is all very well. However attackers
can happily discard any billion-digit files the come across under most
circumstances.
Your approach /would/ work if /absolutely/ nothing was known about the
length of the files the enemy might be expected to be sending, or the
time their operators would allow for decryption - but these assumptions
are simply not true in any practical cypher application known to man.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The faster you go, the shorter you are - Einstein.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Unbiased One to One Compression
Reply-To: [EMAIL PROTECTED]
Date: Tue, 26 Oct 1999 21:02:52 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: Tim why do you think others seem not to realize the bennefits of a
: compression that does not give information to an attacker trying to
: break an encryption scheme.
I don't know ;-|
*Some* people are too busy to deal with the issue.
*Some* people think their cyphers are strong enough already.
*Some* people are too unintelligent ;-(
*Some* people are cusing other kinks of compression - and /hate/
to be told that any part of their system represents a potential
security leak.
*Perhaps* somes people appear to dislike the compression due to its
association with you.
*Perhaps* some people are jealous! ;-)
*Perhaps* once people understand what we are talking about they no longer
contribute to the argument.
It should be granted that the *only* existing one-on-one compression
program so far is /not/ suitable for all types of data - and thus has
some security problems of its own. Trying lots of slightly varying
compression programs, and choosing the best is not the best possible
solution.
People seem to think one-on-one compression has no benefits, though ;-(
This notion appears to be to be incorrect.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The rat race is over. The rats won.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: This compression argument must end now
Date: Tue, 26 Oct 1999 21:57:03 GMT
In article <7v45p6$sl8$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] wrote:
>> In a word: "cryptanalysis". Look at how cyphers have been broken
>> historically. Brute-force search of the keyspace is *not* the only
>> technique available to cypher-breakers.
>
>But most popular ciphers are 'as-of-yet' unbroken in any cannocal sense.
>
>> Um yes, you have to break the cypher. If it is known on a-priori
>> grounds that you can't break the cypher, no quantity of lack of
>> compression is likely to change this.
>
>Oh my gosh, was that my original point?
>
>> Unfortunatly, only with OTPs (and perhaps some obscure, monstrous
>> systems) is it /known/ that the cypher is invulnerable to any attack
>> faster than brute force.
>
>Ahh, but most popular ciphers... or more specifically: rc4, rc5, rc6,
>cast, cast-128, blowfish, 3des, idea, twofish, [any aes] have yet to
>be broken.
>
>> I've personally explained the matter a number of times now. If you
>don't
>> understand, perhaps try asking specific questions to highlight where
>your
>> problems lie. Or perhaps use a service like "deja".
>
>No you have speculated that 'weak' compression (which is ironic because
>deflate is better then huffman any day.) makes strong crypto weak. You
>guys have never actually cited one example where this is true.
>
>> So far my impression is that you've made very little effort to
>understand
>> the issue. If fact, you don't even seem to consider the /possibility/
>> that modern cyphers can be broken by analytic attacks *at all*!
>
>I understand the issue is that you guys don't have a clue. If you have
>a good compression ratio, each bit of plaintext will contain more
>information then if you had a low compression ratio. This means it's
>harder to find biases in the input [albeit not impossible]. Just
>because p = compress(decompress(p)) is true doesn't mean the
>cryptosystem is secure.
>
>Btw for any lossless deterministic compression algorithm the above is
>ALWAYS true. If it weren't it would not be deterministic. It might
>not be possible todo so with PKZIP but just use the deflate (with all
>error checking removed) and it's just as easy. Heck code your own LZ77
>compressor around it :)
Tom your so full of shit. Have you actually tested any of these other
lossless deterministic compression methods or are you just continuing to
blow smoke out your ass. I have test mine but you speak like you know
something. I don't really have the time to repeatedly correct you mistakes
if you to fucking lazy to actually do something. Is the compression you
claim your using in peekboo one to one or not? Have you ever tested it?
Do you even know how to test it? You claim that all good ones automatically
meet p = compress(decompress(p)). Have you actaully tried this or is it your
usually rambling bullshit lies of someone trying to pretend he knows
something.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Unbiased One to One Compression
Reply-To: [EMAIL PROTECTED]
Date: Tue, 26 Oct 1999 21:10:14 GMT
Geoffrey T. Falk <gtf[@]cirp.org> wrote:
: A compressor can be "one-on-one," but if it has a poor predictive
: model, it will not yield good compression ratios and may leave plenty
: of redundancy in the file.
That's certainly true.
: Improving the predictive model is more important than
: "one-on-one," if good output properties are what you are aiming for.
IYO. It seems quite possible that non-1-1 compression could introduce
regularities of the type that can be easily exploited by an analyst,
while mere poor compression did not.
It depends of a whole raft of factors. You /can't/ just make the type of
generalisation you've just made.
If the quantity of information added by the routine not being one-on-one,
is greater than that that would be obtained by optimal compression your
conclusion may be reversed.
Similarly if the former information is more accessible to the analyst than
the latter for some reason.
It depends on the types of files expected to be sent. Non 1-1 compression
may introduce the /same/ sort of irregularity into /every/ file that is
sent. It /might/ be a complete cryptographic disaster.
If the files to be compressed are largely random data, poor compression
will not just be worse than good compression - it may be worse than no
compression at all.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
The more you sit on the cat, the flatter it gets.
------------------------------
Date: Tue, 26 Oct 1999 17:29:05 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Anthony Stephen Szopa wrote:
> "Trevor Jackson, III" wrote:
>
> > [EMAIL PROTECTED] wrote:
> >
> > > They are looking for
> > > encryption that is many times more secure than anything they can crack
> > > themselves, so not being able to crack a code is not sufficient to prove
> > > it is adequately secure.
> >
> > Interesting and very succinct statement. It probably applies to organizations
> > as well as individuals. The inequality re ability and desires reminds of eyes
> > bigger than stomach, and all the important projects that have failed due to
> > lack of unobtainium.
> >
> > Perhaps this is the reason that crypto is so fertile in regards to
> > charlatans. People buy the promises.
>
> You don't have to buy anything to evaluate the software: it is
> shareware.
>
> Anyone who is a crypto consultant worth his / her salt should keep
> abreast of
> all developments in the field of crypto.
>
> OAP-L3 is a significant contribution to the field.
I did evaluate the software. I used your own testimony to perform the evaluation.
It is obvious by inspection that no further evaluation is useful.
I'm no crypto-consultant. I'm not even an amateur like Savard or St Denis. I'm a
layman. But even I have a BS detector.
OAP-L3 is a significant contribution to the field of MARKETING crypto software. It
follows in the great tradition of Bill Gates who pioneered the sale of Really Bad
Software. May you make a billion dollars giving it away free.
Now please go market it somewhere else.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: This compression argument must end now
Reply-To: [EMAIL PROTECTED]
Date: Tue, 26 Oct 1999 21:52:37 GMT
Geoffrey T. Falk <gtf[@]cirp.org> wrote:
: In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Geoffrey T. Falk <gtf[@]cirp.org> wrote:
:>: For example, here is my favourite compression algorithm: Copy the input
:>: file to the output file. This algorithm is "one-on-one." But it is
:>: worthless for cryptography.
:>
:>In what sense is this a "compression" program. It totally fails to
:>compress all possible target sets.
: It is a compression program. It is even the best possible compression
: program under some circumstances. What more do you want? :-)
Well, some compression might be nice! ;-)
: Hint: Go back and look up the definition of entropy.
Why do people keep telling me to look up the definition of entropy?
I didn't even mentioned entropy above.
Is this the sci.crypt stock insult for the intelligence of those whose
views you don't agree with?
:>The *lack* of the one-on-one property introduces new security problems
:>which were not present in the plaintext. One-on-one compression /always/
:>eliminates these, so yes by itself it can be helpful compared to other
:>types of compression.
: As far as I can see, in general it only eliminates the possibility
: of comparing Comp(Decomp(X)) with X. But first you need to guess
: X completely.
This is only as far as you can see. If there is information added to the
file by the compressor, information not present in the plaintext, then
this may be capable of being used by cryptanalytic attacks which target
the patterns in that information.
You do *NOT* necessarilt need to know X completely to do this.
: That is not the most efficient way to do cryptanalysis!
Indeed not. That is why I am not suggesting it.
:>Iy you're saying it may not necessarily help secure the data, it will
:>probably do so approximately to the extent it compresses.
: ??
??
The more you compress the fewer clues you leave about the structure of
the plaintext for the attacker to exploit.
I can't claim a perfect linear relationship, but as a rule of thumb better
compression probably means better security.
:>: The quality of the compression makes vastly more difference to the
:>: difficulty of attacking the system.
:>
:>Given that attacks based on plaintext regularity and attacks based
:>on regularities introduced by bad compression both seem quite possible,
:>I wonder how you might go about saying one characteristic is more
:>important that the other.
: I was not saying that.
What does "The quality of the compression makes vastly more difference
to the difficulty of attacking the system." refer to, then if not 1-1
compression. It seems to me that you /were/ saying that. What other
interpretation is there?
:>Poor compression is likely to introduce the same regularities regardless
:>of whether you're compressing executable, object-based drawings, or
:>plaintext. If a range of filetypes are being sent, poor compression
:>may be expected to be more insecure than no compression al all.
: Coming up with good predictive models is the heart of compression theory.
: Eliminating predictability is also exactly what the cryptographer wants
: to achieve. Unfortunately, this is a hard problem. No model will work
: well on every kind of data. You need to tailor it. If you don't focus on
: this area, the fact that your algorithm is strictly 1-1 will not matter
: one bit! It will just give you a false sense of security while they
: are breaking it some other way.
1-1 and high compression are both security concerns of potential
importance. If you focus on getting high compression and /ignore/
the one-on-one property, you may go just as badly astray.
:>Given this I don't see how it can be claimed that huffman compression
:>is worse than using a good compressor - and not just worse, "vastly" so.
: It is worse because it uses an inadequate predictive model.
Compared to being worse by leaking information another way? How is this
worse? Try to quantify the two types of security leak before you claim
to be able to compare them.
:>The security problems introduced are different. Which is more important
:>depends on factors like what is being sent.
: See above.
You disagree? You think which is of greater import is independent of
your data types???
:>: This is because the attacker must decrypt the entire message anyways
:>: before he can test if it is a valid compressed file.
:>
:>Nope. Not necessarily. I /keep/ saying that there are other security
:>problems that apply when you have only a tiny fragment of a file.
: For specific algorithms. However, in general the attacker must
: decrypt the entire message.
What is this "in general"? Attackers only /ever/ face specific
algorithms.
Can you /prove/ for any particular non-1-1 compression algorithm that
it stores the information in a manner which is /totally/ unobtainable
until the last byte is read?
If not, what is the point of your objection?
You /must/ assume the worst - that the information is available to the
attacker - when you are evaluating security of an algorithm - unless there
is good reason to do otherwise.
:>A non-one-on-one compressor introduces information systematically
:>into the compressed file. This regularity can potentially be targetted
:>by cryptanalysts.
:>
:>Despite my drumming on this point, others /continue/ to talk as though the
:>*only* attack prevented is one where you try to decompress an unencrypted
:>file. This is false - the poor compression *will* introduce other
:>regularities - unless it is attached to a hardware source of random
:>numbers.
: Sure. But this has nothing to do with 1-1 compression.
: You are confusing "poor compression" with "non 1-1 compression,"
: when in fact these are mutually independent of each other.
Well, I was using "poor" compression as a /synonym/ for "non-1-1
compression", in this instance.
Substitute "non-1-1 compression" if it helps you see the /actual/ point
I'm trying to raise in the above paragraphs, rather than nit-picking ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I just got a dog for my girlfriend - what a trade!
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: This compression argument must end now
Date: Tue, 26 Oct 1999 22:26:35 GMT
In article <7v50k6$dkg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <c1mR3.7280$[EMAIL PROTECTED]>, gtf[@]
cirp.org (Geoffrey T. Falk) wrote:
> >In article <[EMAIL PROTECTED]>, Tim Tyler <[EMAIL PROTECTED]>
wrote:
> >>Geoffrey T. Falk <gtf[@]cirp.org> wrote:
> >>: For example, here is my favourite compression algorithm: Copy the
input
> >>: file to the output file. This algorithm is "one-on-one." But it is
> >>: worthless for cryptography.
> >>
> >>In what sense is this a "compression" program. It totally fails to
> >>compress all possible target sets.
> >
> >It is a compression program. It is even the best possible compression
> >program under some circumstances. What more do you want? :-)
>
> I agree that it is better than the other methods which are non 1-1
> and add information which help break a system. But this does nothing
> to show that if one wants real compression that one should not use a
> one to one compressor. If you don't like my current version the
concept
> is not that difficlut. You can easily if you have any brains that is.
Come up
> with some useful one to one compression method for other techniques.
> And since it does not add any information as Tim as repeatedly tried
to
> tell you it is what most compression methods should have been striving
> for in the first place but for some very strange reason have not.
> What you fail to see either because of you up bringing or lack of
> intelligence is that one should never add something to a crypto system
> that helps to break it. Compression is commonly added as suggested in
> even MR BS's book which I don't recommend any one buying but the
> added compression is not one to one and actually weakens the over
> all system. That is what this thread is about. And as I have
repeatedly
> asked is are there any other common compression system in use that
> actaully concern themselves with the cryptographical considerations
> as to there use and why does PGP not use a one to one compression
routine
> other than to make it easer for the NSA to break.
What info does LZ77 add to the compressed stream that makes it so easy
to cryptanalyze? You guys alaways say 'add info for the attacker' WHAT
INFO ARE YOU TALKING ABOUT?
Another thing, say you can guess a block with prob of 1.0, that means
the block contained no message. So even if it were given out you would
not give the message. The minute one block of plaintext contains
message your chances of guessing it fall below 1.0.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Date: Tue, 26 Oct 1999 22:29:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> "I am not even done highschool."
>
> Is that a fact? Then how do you explain the following quote from an
> email you sent me. You are a researcher? etc.?
>
> "What am I suppose to do with software? I am a researcher not a know
> nothing tool. You should document your algorithm because it will
> make it look like you know what you are doing. No offense man but
> that's the truth (note: I started just like you in crypto and I too
> hated this line...)
>
> Tom"
>
> What kind of flame-baiter are you? You have never once supported your
> position trashing OAP-L3 with concrete examples using the theory or
> operation of OAP-L3. You have not even demonstrated that you even
have
> the software as you claimed.
>
> For the umpteenth time, documentation for the entire software package
> is included with the software in the extensive Help files.
>
> For your own sake I would suggest you come clean right here in this
> news group. You know exactly why you have said everything you have
> said about OAP-L3. Let US know your true motivation.
>
> It is your reputation; it is your credibility. Again, I suggest you
> come clean right here and now.
>
> "No offense man but that's the truth ..."
Last time I checked YOUR credentials were on the line, not mine.
Face it your site is just a bunch of snake oil. Ok answer this
question. Why do you use keys for symmetric style ciphers > 128 bits?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: How Do You Spell S-H-A-R-E-W-A-R-E
Date: Tue, 26 Oct 1999 22:31:09 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> You don't have to buy anything to evaluate the software: it is
> shareware.
>
> Anyone who is a crypto consultant worth his / her salt should keep
> abreast of
> all developments in the field of crypto.
And would know selling crypto to the masses is a worthless pursuit...
>
> OAP-L3 is a significant contribution to the field.
>
Why?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: This compression argument must end now
Date: Tue, 26 Oct 1999 23:29:34 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Tom St Denis <[EMAIL PROTECTED]> wrote:
>: [EMAIL PROTECTED] wrote:
>
>:> That is /one/ aspect of the argument.
>:>
>:> I observe you have somehow failed to mention that the opponents get
>:> less cyphertext to base their attacks on, and what they do get has
>:> had it's entropy-per-bit increased to the point where cryptanalysis
>:> is made much harder.
>
>: You jerk, you stupid jerk.
>
>This is not helping the discussion.
>
>: That was my point from the beginning. That if you used a better
>: compression algorithm you would have more info per bit of plaintext.
>: Obviously you don't read my posts that carefully? That's why I said
>: compression should be used to make the message smaller (i.e use
>: something other then huffman coding)
>
>You appear to understand the benefit of eliminating regularities from the
>source statistics of the file - but don't appear to be considering the
>fact that pretty much all non-one-on-one compressors must be adding
>information to the file in a systematic manner.
>
>Yes, making the compressed files smaller helps. However making
>compression one-on-one *also* helps.
>
>If you had to choose between them you would have to decide between
>one (hard to quantify) security risk, and another qualatatively
>different (and also hard-to-quantify) security risk.
>
>As you point out the only compressor currently available is not
>suitable for all data types.
>
>Consequently at the moment, people have to make this choice.
>
>However, the relevance of the "one-on-one" compressor to cryptography has
>only recently been established publicly. I'm certain that more one-on-one
>compressors will appear. Part of the beauty of the idea is that all the
>most efficient compressors are /also/ one-on one.
>
>Eventually, people will not have to choose between two potential security
>risks.
>
>:> It is not a good argument against compression in the first place.
>:> It doesn't even address the issues above. Cryptanalysis based on
>:> regulariries in the file does not rely on brute forcing the
>:> keyspace, nor on having the whole message decrypted. You've been told
>:> this before - it makes me wonder if you're paying attention ;-(
>
>: For the most part however you don't get enough ciphertext to make this
>: usefull. [...]
>
>Really? How much cyphertext is "enough". If your cyphertext is longer
>than your key then proving that there's no risk becomes tricky.
>
>:> What??? LZ77 is one-on-one? I very much doubt it. To see if a code
>:> has resulted from an actual compression, simply decompress it and
>:> compress it again. If you get a different file, you know that it has
>:> not been made with the specified (deterministic) compression
>:> program. If you /never/ get such a file, the compressor is "one-on-one".
>:>
>:> LZ isn't one-on-one - there's obviously more than one way to encode
>: the
>:> same file. LZ compression works by crudely identifying repeated
>: strings.
>:> I believe XXXXXXXX can be represented both as 8 x X and 5 x X + 3 x X
>:> as far as the decompressor is concerned. No way is this compression
>:> "one-on-one".
You have showed this point to Tom more than once. Either he is incapable
of understanding the above point or he is a phony. One would think if this
concept was over his head he would ask questions or even run simple tests.
But this guy does not. If any one on this Use group is a plant to try to bore
people to death it is Tom. Since he occasionaly strings together enough
big words to almost make sense. But his continued attack that compression
which adds info to a file should be of no concern to anyone makes me
wonder about him and I think we should just ignore him since anwsering his
posts seems to be a waste of time.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Q: Optimal diffusion
Date: Tue, 26 Oct 1999 20:57:17 GMT
Mok-Kong Shen wrote:
> Is there a mapping of n bits to n bits that gives the best diffusion?
How do you measure "best"?
For some situations, the answer would be: use a bent function.
------------------------------
** 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
******************************
