Cryptography-Digest Digest #586, Volume #14 Mon, 11 Jun 01 11:13:01 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY LONG
(SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY LONG (Tim
Tyler)
Re: differential cryptanalysis with a new twist? (Mika R S Kojo)
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: Def'n of bijection (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY ("John A.
Malley")
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY LONG (Tim
Tyler)
Re: Def'n of bijection ([EMAIL PROTECTED])
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
(SCOTT19U.ZIP_GUY)
Re: Brute-forcing RC4 (Trei Family)
Re: Best, Strongest Algorithm (gone from any reasonable topic) (Phil Carmody)
Re: Uniciyt distance and compression for AES (Tim Tyler)
Re: Def'n of bijection (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY LONG
Date: 11 Jun 2001 12:58:48 GMT
[EMAIL PROTECTED] (Mok-Kong Shen) wrote in
<[EMAIL PROTECTED]>:
>May I repeat: Does Shannon's writing (alone) has established
>(fully) the perfect security of the conventional OTP? My
>interpretation of what you wrote would be 'no'. Is that
>the case? If yes, we need a complete rigorous formal proof
>(perhaps based on Shannon's work) to establish the prefect
>security of the conventional OTP or else a similarly
>rigorous formal proof for the opposite case.
>
>Thanks.
>
I don't know why I try. Again look at my "yes" "No"
Example and attempt to use your brain. If you use the
convention OTP in the way TOMMY DUNGERHEAN veiws it that
he got from some BS crypto Book. It fails some of Shannons
tests. That is if you use the OTP to sends 2 character
for all 2 chacter messages then you have eliminated the
possible 3 character messages. In short the "yes" can
not map to two characters by the rules you want to see.
If you can't see that 2 is not 3 then I don't give a shit
and you are as hopless as TOMMY.
Next does all cipher text have to have the same length
no. That is not a requirement. But what is. Is that any
ciphertext has to map back to all possuble input messeage
of your set. Does that mean that all cipher text messages
could not be put in a form for a finite set of messages
so that the cipher texts are eqaul. Yes I think that
is obvious, use padding. or if that to complicated
use Savards thing of having length if front of file and pad
to make all the same length. Then use the OTP. Is this
to complicated for you. What of the above is still over your
head.
Note I am not saying it the only way but a way. The
critical point. "is that any intcepted cipher text could
hace come from any of the possible input messages" and
thats the whole point. You pick the set and since you
lack the common sense to understand write back and Tim
or I will tell you if its perfect or not.
>M. K. Shen
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY LONG
Reply-To: [EMAIL PROTECTED]
Date: Mon, 11 Jun 2001 13:18:37 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler wrote:
:> :> John A. Malley <[EMAIL PROTECTED]> wrote:
:> :> : Just a comment - the messages in a finite set do NOT need to be of the
:> :> : same length for the cipher to achieve perfect secrecy. [...]
:> :>
:> :> ...but they *do* if one is using an OTP to encrypt them.
:> :>
:> :> Apologies if the fact that an OTP was intended was not clear from the
:> :> context.
:>
:> : Opinions seem to differ here. So let me once again ask:
:> : Has Shannon proved the perfect security of the conventional
:> : OTP (for messages of finite but varying length) or not?
:>
:> I thought John Malley at least was fairly clear and unambiguous in writing:
:>
:> ``3) WHY ENCIPHERING A FINITE SET OF MESSAGES BY XORING RANDOM BINARY
:> STRINGS AS LONG AS THE MESSAGES DOES *NOT* GUARANTEE PERFECT SECRECY''
:>
:> ...though maybe a qualification abot there not being 2^n messages all of
:> the same length needs to be tacked onto that headline.
:>
:> It appears that Shannon only mentioned the OTP while dealing with
:> the case of infinite streams of data.
:>
:> You say "opinions seem to differ here". Who disagrees at this stage?
: No. In the quote above John Malley wrote: '....set do NOT
: need ....' but you wrote: '....but they *do* ....'. That's
: why I wrote that opinions seem to differ.
Both statements are correct. John was referring to a general
cryptosystem - and I was referring to an OTP.
JM: ``the messages in a finite set do NOT need to be of the
same length for the cipher to achieve perfect secrecy.''
TT: ``...but they *do* if one is using an OTP to encrypt them.''
: May I repeat: Does Shannon's writing (alone) has established
: (fully) the perfect security of the conventional OTP? My
: interpretation of what you wrote would be 'no'. Is that
: the case?
Yes. The OTP has perfect secrecy if transmitted messages don't
have proper ends, or if they are all the same length - and not
in the case where plaintext length varies and cyphertext length
is equal to plaintext length.
: If yes, we need a complete rigorous formal proof
: (perhaps based on Shannon's work) to establish the prefect
: security of the conventional OTP or else a similarly
: rigorous formal proof for the opposite case.
If you like. I'm happy with a cyphertext of length L making
plaintexts with length != L impossible, contradicting the
condition that knowledge of the cyphertext supplies no
information about the identity of the plaintext.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Mika R S Kojo <[EMAIL PROTECTED]>
Subject: Re: differential cryptanalysis with a new twist?
Date: 11 Jun 2001 16:31:51 +0300
"Tom St Denis" <[EMAIL PROTECTED]> writes:
>
> Interesting note. I think this isn't new but I've never seen it done
> before.
>
> Instead of using pairs constructed by (A,B) where B = F(x) - F(x - A) with
> some prob > 0 why not use triplets (to higher order).
Hmm, perhaps they are "higher order" differentials. :)
> For example, in TC5 I said the best pair has a DPmax of 8/256. This is
> true, however the best triplet has a prob of 9/256 which exceeds this bound.
> (You can get TC5 off my website under the misc.src section).
>
> In TC5 the difference 125 = F(x) - F(x - 59) - F(x - 94) occurs with a prob
> of 9/256. (- is XOR)
>
> My question. Does this work like regular diff analysis? I.e find a triplet
> that has the right input and output difference and use linear analysis to
> figure out what the key could have been?
The standard higher-order differential cryptanalysis is slightly
different. It is ultimately about similar sums as your triples, but
based on a bit more elaborate theory. Namely, finding the non-linear
degree of a boolean function (e.g. a block cipher under a fixed
key).
However, if you find such triplets as you above wish for you can do
key search in the natural way. The triples would then just be a
distinguisher just like usual differentials or linear relations. I
don't see why you need to use linear (crypt)analysis at all, but you
can do that also (often called differential-linear cryptanalysis then,
but perhaps here triple-differential-linear?).
Mika
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 11 Jun 2001 09:39:43 -0400
Phil Carmody <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>>
>> 1. Number of plausible messages in the space of all messages of
>> size 2510 bytes or less. This can be estimated...at 2^5 000...the
>> space of all binary files up to 2510 bytes has size around 2^20 000,
>> the probability of a random file up to 2510 bytes being a plausibly
>> mistaken for an English message is something like 1 in 2^15 000,
>> or effectively zero.
>>
>> (If you can even prove, for random files of size 1024 bytes or less, that
>> plausible BICOM preimages are likelier than 1 in 2^1 000, then I'll keep
>> you in beer for the next six months.)
>
> Hand-waving heuristics seem to say to me that if the mean compression of
> plausible plaintext when processed by BICOM is 15, then then density
> would increase from 1 in 2^15000 to 1 in 2^1000.
Where did you get a compression factor of 93% from? BICOM can be expected
to compress real email messages by about 50%. With 99% confidence, the
compression ratio will fall between about 23% and 73%. Which is good,
BTW, and slightly better than ``gzip -9''.
At 73% compression ratio, crude estimates suggest that the number of
compressed plausible messages is no larger than 2^12100. Out of 2^20000
binary messages, that still means that the chance of a false decrypt is
around 1 in 2^7 900. Recall that for false decrypts to happen enough to
matter, they should be more common than 1 in 2^20.
> If you are so sure that the density decreases...
Decreases? I said clearly that it most certainly *increases*, but by too
little to make any practical difference. See above.
--
Frugal Tip #16:
Dry clean your wax paper for reuse.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Def'n of bijection
Date: 11 Jun 2001 13:46:03 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>
>Furthermore:
>
>(1) If the (compressed) messages are larger than the key, this purported
>``benefit'' of compression falls off exponentially. Once messages reach
>the size of normal emails (or usenet posts), the ``shorter unicity
>distance'' has no practical effect whatsoever.
>
Can you prove this. OF COURSE NOT
>(2) The above-cited benefit for small messages has nothing to do with
>bijectivity, and everything to do with compression. The benefit is
>maximized by choosing the best compression algorithm available, without
>any regard to bijectivity.
>
Can you prove this. OF COURSE NOT
I don't think you understand the effects of bijectivity at all.
>Which is why I said, ``For 'large' messages--where 'large' is no bigger
>than 1KB or so--the only benefit of bijective compression is increased
>work for trial decryption.''
>
Can you prove this. OF COURSE NOT
>>> No need for hard feelings. You can't prove that normal messages are
>>> any more likely to yield false decrypts after being compressed with
>>> BICOM...
>>
>> Can you prove it makes things worse? Can you prove it leaves things
>> unchanged?
>
>Please do not shift the burden of proof. The guy who says, ``BICOM
>improves security because X'' is obligated to prove it. Nobody is
>obligated to disprove it. The burden of proof rests with the claimant.
>
>However, I gave extremely strong arguments *suggesting* that the
>situation is virtually unchanged by using BICOM for normal-sized
>messages. They are fairly convincing, and could probably be converted
>into a proof without much trouble. (At issue is the definition of
>``plausible'' messages. Which is context dependent: in the case of
>diplomatic or military messages, the space of ``plausible'' messages
>is vanishingly tiny compared to the space of ``English'' messages.)
>
Can you prove this. OF COURSE NOT
I also suspect your not capable of understanding a proof if
Shannon showed you one. If he was alive to day you would be
making the same dumb arguments.
>> Claiming someone else's statement is false because he hasn't yet proved
>> it is a hollow argument.
>
I see the kettle calling the pot black. At least TIM arguments
based on solid theory. Yours is just handwaving.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: 11 Jun 2001 13:52:19 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>Where did you get a compression factor of 93% from? BICOM can be
>expected to compress real email messages by about 50%. With 99%
>confidence, the compression ratio will fall between about 23% and 73%.
>Which is good, BTW, and slightly better than ``gzip -9''.
If you don't even know what BICOM is how can you say
its 23 to 73% I see this as just handwaving. The same sort
of thing you acuse your opponents of.
>
>At 73% compression ratio, crude estimates suggest that the number of
>compressed plausible messages is no larger than 2^12100. Out of 2^20000
>binary messages, that still means that the chance of a false decrypt is
>around 1 in 2^7 900. Recall that for false decrypts to happen enough to
>matter, they should be more common than 1 in 2^20.
Recall from where. I have seen no prood requiring something of
1 out of 2**20 being needed for security reasons. I think you might
be on a LSD trip or something similar.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
Date: Mon, 11 Jun 2001 06:57:09 -0700
JPeschel wrote:
>
> "John A. Malley" [EMAIL PROTECTED] writes, in part:
>
> >Joe Peschel posted he'd heard The Bell System Technical Journal planned
> >to post an electronic copy of Shannon's paper on-line.
>
> Fran Grimes told me in early March that the paper would be posted
> in about a week.
>
> >I just checked The Bell System Technical Journal web site and didn't
> >find it posted yet. :-(
>
> Yeah, I know. I wrote to her again in late March, but I still haven't received
>
> an answer. Maybe The Journal changed it's mind; maybe Fran forgot;
> maybe more of us should write to her.
>
Agreed! More of us should express our desire to see Shannon's paper on
secrecy systems on-line for all.
I'll send email today.
John A. Malley
[EMAIL PROTECTED]
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 11 Jun 2001 10:04:26 -0400
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
> [EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>
>> With 99% confidence, the compression ratio will fall between about 23%
>> and 73%. Which is good, BTW, and slightly better than ``gzip -9''.
>
> ...how can you say its 23 to 73% I see this as just handwaving.
Hint: notice the phrase ``with 99% confidence''. That's an unmistakable
clue that I (or someone) has performed some sort of statistical test. If
you consult any basic text on statistics, you can find out what the
statement means.
Len.
--
You're deluding yourself if you think that these anti-reliability
features actually affect the spammers.
-- Dan Bernstein
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY LONG
Reply-To: [EMAIL PROTECTED]
Date: Mon, 11 Jun 2001 14:00:11 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote, in part:
:>Getting random numbers in that range from the pad by using a sophisticated
:>procedure that is not guaranteed to terminate...? ;-)
: I'm assuming one's pad _contains_ random numbers in that range.
Ah yes - very sensible of you.
I was considering the case where the pad was generated before the range
of possible messages was known.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
Subject: Re: Def'n of bijection
From: [EMAIL PROTECTED]
Date: 11 Jun 2001 10:10:02 -0400
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
> [EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>>
>> (1) If the (compressed) messages are larger than the key, this purported
>> ``benefit'' of compression falls off exponentially. Once messages reach
>> the size of normal emails (or usenet posts), the ``shorter unicity
>> distance'' has no practical effect whatsoever.
>
> Can you prove this. OF COURSE NOT
Actually, a ``convincing argument'' can be produced with ease. But that's
irrelevant: I am not required to prove anything. The people who claim a
benefit from BICOM are required to prove it. Their say-so has no value
whatsoever--whether ``they'' means you, Tim, Schneier or the Apostle
Paul.
> Can you prove this. OF COURSE NOT
> Can you prove this. OF COURSE NOT
Look up ``shifting the burden of proof''. I can demonstrate that the
statement is reasonable--but I don't have to. You *must* prove that BICOM
does something, before you can claim it does.
>>> Claiming someone else's statement is false because he hasn't yet proved
>>> it is a hollow argument.
>
> I see the kettle calling the pot black.
Count the wedges, boy. Those are somebody else's words, and I explained
why he's wrong: he was shifting the burden of proof. Just like you are
doing. (Just like snake-oil salesmen always do: ``Dear sir, can you PROVE
that my elixir doesn't do wonders for the health of women everywhere?'')
Len.
--
When you actually try this out, let me know how many users yell at
you.
-- Dan Bernstein, author of qmail
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
Date: 11 Jun 2001 14:07:31 GMT
[EMAIL PROTECTED] (John A. Malley) wrote in
<[EMAIL PROTECTED]>:
>
>JPeschel wrote:
>>
>> "John A. Malley" [EMAIL PROTECTED] writes, in part:
>>
>> >Joe Peschel posted he'd heard The Bell System Technical Journal
>> >planned to post an electronic copy of Shannon's paper on-line.
>>
>> Fran Grimes told me in early March that the paper would be posted
>> in about a week.
>>
>> >I just checked The Bell System Technical Journal web site and didn't
>> >find it posted yet. :-(
>>
>> Yeah, I know. I wrote to her again in late March, but I still haven't
>> received
>>
>> an answer. Maybe The Journal changed it's mind; maybe Fran forgot;
>> maybe more of us should write to her.
>>
>
>Agreed! More of us should express our desire to see Shannon's paper on
>secrecy systems on-line for all.
>
>I'll send email today.
>
>John A. Malley
>[EMAIL PROTECTED]
>
Since so many are confused or purposely mislead. It may
be the kind of knowledge that the NSA doesn't want to be so
wide spread. Maybe thats the reason Wagner and company could
not be honest about the topic. Maybe they only wish to misled
people. Well its a possible reason. Or it would have been cleared
up in the BS book on crypto. You have to admit Shannon had
very poverful ideas that seem to be lost on the so called
modern crypto people. Who would rather not have people aware
of such concepts.
So maybe it won't get put on the internet. But I bet
there is a Russian copy or some such thing out there somewhere.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Trei Family <[EMAIL PROTECTED]>
Subject: Re: Brute-forcing RC4
Date: Mon, 11 Jun 2001 13:17:05 GMT
It sounds like this this guy wants to brute force the old 'export' strength SSL.
This was done several times quite a few years ago, back in the mid-90s.
The fastest crack was under 30 hours, using about 300 PCs, mostly in the
~90MHz range.
This was the first of the publicity attacks demonstrating the ludicrous nature
of the US export regulations.
Peter Trei
===================
Joseph Ashwood wrote:
> There was a mention a year and a half ago on this group of using a small
> beowolf cluster of overclocked celerons (at the time this would bring it to
> approximately the 500MHz mark), and being able to brute force RC4-40 in a
> few days for $1200, with proper optimization I think it could be lowered.
>
> Let's see
> Load takes L1 clocks
> Store takes S1 clocks
>
> In each iteration of the key schedule there are 3 loads, and 2 stores. the 2
> of the 3 loads can be done simultaneously, and parellelized highly, so the
> throughput there can be reduced to say 1.5 cache clocks per value. The
> stores are fully async on modern cpus, so those will take only 1 clock each.
>
> You've got about 6.5 clocks for each iteration of the RC4 key schedule.
> There are 256 iterations for the entire key schedule so that's 1664 clocks
> for initialization. RC4 can generate a byte in 4 clocks so we'll just assume
> that, the likelihood of having to go beyond 2 bytes is negligible and
> certainly doesn't compare to the key setup, so we'll pretend we only have to
> generate 2 bytes, that's 8 clocks. The value for comparison can be stored in
> a register so we don't have to load it, RC4 output will be to a register, so
> we simply compare them, that's an additional 1 clock. So we've got a total
> of 1664+8+1 clocks for each key. That's 1673 clocks, or 299,000/sec, 3.6
> million seconds per key (worst case), that's 42 days. Normally it would
> finish in 21 days, 3 systems could be parrelellized on this to finish in a
> week on average. This is assuming a very carefully optimized RC4
> implementation by someone who is exceptionally good at writing assembly,
> with a reasonable assembly coder, you're looking at twice as long, minimum,
> and a compiler using pure C would probably offer better results.
> Joe
>
> "S Degen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > Howmuch time would it take to brute-force a 40 bit RC4 key? (Ofcourse
> > depending on the processor-speed, but lets say a PIII 500)
> >
> > This is the case:
> > You have a 128 bit (ASCII) text, and the encyphered version of it. This
> > version is encyphered with a 64 bit secret key, but of those 64 bits, 24
> > bits are known. (Leaving 40 unkown bits)
> >
> > I would like to know how long it would approximately take to calculate
> > the 40 bit secret key.
> >
> > (Worst case scenario)
> >
> >
> > Thank you if you can help me.
------------------------------
From: Phil Carmody <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Mon, 11 Jun 2001 14:17:52 GMT
Tom St Denis wrote:
> So was the word "parallel" that doesn't mean it can't be used as a tool of
> masterbation by some stupid PR person...
>
> Hence "unparallel e-commerce super-scalable e-solution". Cipher just
> conjures up confusion and misleading ideas.
>
> Tom
This sounds brilliant, let me have your pay-pal id, and I'll get enough
money for 5 of these things to you as soon as I can. I hear your
competitors have something similar with a large number at the end of
it's name, this leads me to believe you're about to become obsolete -
when will the next version be out, and how big will the number at the
end of the name be?
:-)
Phil
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Uniciyt distance and compression for AES
Reply-To: [EMAIL PROTECTED]
Date: Mon, 11 Jun 2001 14:11:21 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : Tim Tyler wrote:
:> :> Tom St Denis <[EMAIL PROTECTED]> wrote:
:> :> : This is not true. In fact it's just the opposite. Any good
:> :> : codec makes a few files smaller.
:> :>
:> :> You err. Most codecs make an infinite set of files smaller.
:>
:> : A compressor appropriate for a given application should
:> : compress the files of that application on the average
:> : to a smaller sizes. One certainly needn't care files
:> : that don't belong to the application.
:>
:> Most codecs can deal with unboundedly long inputs.
: In all practical cases there can be given a safe upper
: bound of the input length. Whether infinite input could be
: treated isn't of any practical significance, I suppose.
If we were to restrict the discussion to consider practical cases - rather
than the capabilities of the codec - in practice we're dealing with sets
like the set of all existing JPEGs, the set of all text files written to
date, the set of all current MP3s - i.e. sets with only a "few" files in.
A bit like the way the universe only has a few hydrogen atoms in really.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Def'n of bijection
Date: 11 Jun 2001 14:20:19 GMT
[EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>> [EMAIL PROTECTED] wrote in <[EMAIL PROTECTED]>:
>>>
>>> (1) If the (compressed) messages are larger than the key, this
>>> purported ``benefit'' of compression falls off exponentially. Once
>>> messages reach the size of normal emails (or usenet posts), the
>>> ``shorter unicity distance'' has no practical effect whatsoever.
>>
>> Can you prove this. OF COURSE NOT
>
>Actually, a ``convincing argument'' can be produced with ease. But
>that's irrelevant: I am not required to prove anything. The people who
>claim a benefit from BICOM are required to prove it. Their say-so has no
>value whatsoever--whether ``they'' means you, Tim, Schneier or the
>Apostle Paul.
>
>
I'm sure you know nothing about BICOM and I am sure you could
not make a "convincing argument" to me about how it works.
However to someone of low mathematical ability like TOMMY. Since
you string words together in a professional looking matter. You
could most likely convince him of anything with ease. I truely
belive you could. Wheather something is true seems to make little
difference to him. Its the quality and amount of email volumm that
makes the difference. It probalbly still belives his poor use of
a OTP is secrue for varible length messages. That is proof of how
misguided he is. But if Wagner or Mr BS would ever tell the truth
about the topic he would instantly act like he know the truth all
along.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
