Cryptography-Digest Digest #610, Volume #14 Thu, 14 Jun 01 13:13:01 EDT
Contents:
Re: National Security Nightmare? (Derek Bell)
Re: Alice and Bob Speak MooJoo ("Robert J. Kolker")
Re: RSA's new Factoring Challenges: $200,000 prize. (Chris Card)
Re: When the signer is trusted do birthdays matter? (Phil Carmody)
Re: help non-elephant encryption (Nicholas Sheppard)
Re: Knapsack security??? Ah....huh ("Jakob Jonsson")
Re: Yarrow PRNG (Mark Wooding)
Re: Alice and Bob Speak MooJoo ([EMAIL PROTECTED])
Re: The 94 cycle 64-bit block cipher :-) (Mark Wooding)
ENCRYPTION TYPE - UNKNOWN! :( ("Total Annihilation")
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY (Mok-Kong Shen)
Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
([EMAIL PROTECTED])
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
Re: Alice and Bob Speak MooJoo ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: Derek Bell <[EMAIL PROTECTED]>
Subject: Re: National Security Nightmare?
Date: 14 Jun 2001 13:24:35 +0100
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
: Another example of French Academy meddling was allowing
: the use of "pipeline" but requiring a change in its
: pronunciation to "pee-pleen". This was an embarrassment
: to French pipeliners.
IIRC, Monsieur Alain Toubon was a minister who
supported this kind of nonsense - his opponents nicknamed
him "Mister Allgood" in response.
Derek
--
Derek Bell [EMAIL PROTECTED] |"Usenet is a strange place."
WWW: http://www.maths.tcd.ie/~dbell/index.html| - Dennis M Ritchie,
PGP: http://www.maths.tcd.ie/~dbell/key.asc | 29 July 1999.
|
------------------------------
From: "Robert J. Kolker" <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Thu, 14 Jun 2001 08:56:03 -0400
"John A. Malley" wrote:
>
> What Eve gets is not _noise_ in the electrical
> engineering/communications systems point of view, though. Eve detects
> correlations between portions of the stream of signal over time. She'll
> detect similar or identical modulations of signal characteristics
> (amplitudes of frequencies, phases of frequencies ) in different
> portions of the stream of signal over time. Time-varying modulation of
> signal characteristics is indicative of communication between
> intelligent creatures.
>
> Eve can learn a lot about the "meaning" of the signal from their
> responses with respect to the context dictated by events common to
> Alice, Bob and her. She can correlate events, the signal patterns
> following immediately after the events and any observable actions of
> Alice or Bob and assign a rough "meaning" to the patterns.
There are no observable actions of Alice and Bob other than the
communications. In the absence of a shared referrent, Eve is up
the creek. Now let us assume, Eve does something like the
chosen plaintext attack. Eve creates events which she * hopes *
Alice and Bob will referrence in their communications. Let us
assume, arguendo, that Alice and Bob oblige Eve in this regard.
The best Eve can come up with is some good guesses pertaining
to nouns, the names of thing things and events. Is this is enough
to understand the communication? No. What about adjectives
and adverbs. How does one convey to a child, the concept of
"pretty" or "bad" except by ostention (initially anyway)? In the absence
of the Pointing Finger no human child can learn his first language.
The only possible crib that Eve has with regard to MooJoo is a
shared cultural experience. If Alice and Bob had totally foreign
cultural outlooks and artificats, Eve would not have a chance to
figuare out what A/B are saying to each other.
Let me give you a homely example. You are on a bus, train or
plane and there is a Japanese coupule sitting nearby having a
conversation in Japanese. Assuming you are not a nihonophone,
how could you possible decode the conversation by passive
listening? Answer. You can't. To learn Japanese you must
* interact * some how with Japanese speaks to get the basic
referrents (things and their names).
What is wrong with the following scenario found in just about
any sci fi movie made in the 1950-s.
"We learned your Earth Languages from your * radio *
broadcasts"..
Bob Kolker
------------------------------
From: [EMAIL PROTECTED] (Chris Card)
Subject: Re: RSA's new Factoring Challenges: $200,000 prize.
Date: 14 Jun 2001 06:11:36 -0700
Peter Trei <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> RSA Security, has revamped its Factoring Challenges.
>
> Prizes now start at US$10,000 (factorization of a 576 bit modulus)
I've been running a polynomial selection for RSA576, and I've got quite a good
one - anyone got a spare Cray big enough to do the matrix reduction step? I don't see
any point starting sieving if the matrix is likely to be too big to handle.
Chris
------------------------------
From: Phil Carmody <[EMAIL PROTECTED]>
Subject: Re: When the signer is trusted do birthdays matter?
Date: Thu, 14 Jun 2001 13:15:30 GMT
Jakob Jonsson wrote:
>
> Here is an outline of a possible attack. An adversary wants to forge a
> signature of a message M. To succeed, she takes another message N that she
> knows that the legitimate signer will accept and sign. If the messages are
In the situation I proposed, the _signer_ does not _accept_, he
_authors_.
So this analysis doesn't apply.
> This construction is included in some paper, but I don't remember where.
It is mentioned in AC, 2nd Ed., Ch 18 p.430, and is accompanied by the
reference Gideon Yuval [1635] = "How To Swinde Rabin", Cryptologia, v.3
n.3 July 1979, pp187-190.
Phil
------------------------------
Date: Thu, 14 Jun 2001 16:43:07 +1000
From: Nicholas Sheppard <[EMAIL PROTECTED]>
Subject: Re: help non-elephant encryption
On 13 Jun 2001 [EMAIL PROTECTED] wrote:
> Nicholas Sheppard <[EMAIL PROTECTED]> writes:
> >
> > Perhaps it works by having the communicating devices measuring some common
> > source of randomness available on the network...
>
> In that case, it can't work. Passive observers on the network can observe
> the same random source, and can deduce the key.
That would certainly be true in the most straightforward implementation of
the system, that is, to just use the common random source as a one-time
pad. I don't know the details of Rabin's system (it is unpublished, so
far as I know), but it apparently used the random source in some more
sophisticated way and was reported to be "provably secure". It seemed
impractical (to me, at least) because the amount of random information
mentioned in the article was absurd.
There is an earlier system of this type by Cachin and Maurer in Crypto 97
that is apparently perfectly secure against an enemy with limited memory
capacity, though if memory serves me it is also impractical.
--
Nicholas Sheppard | Ph: +61 2 4221 5290
Research Fellow | Fax: +61 2 4221 4170
School of Information Technology & Computer Science | E-mail: [EMAIL PROTECTED]
The University of Wollongong, Australia | WWW: www.uow.edu.au/~nps
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: Knapsack security??? Ah....huh
Date: Thu, 14 Jun 2001 15:46:51 +0200
"John Bailey" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> >This scheme doesn't look terribly secure to me.
> It isn't. If I didn't say so in the immediate context of what you
> read, I say it in several other places--cryptographically this is
> about as secure as hiding your door key under a flower pot. Its only
> possible value is as a demonstration of a public key like system which
> exhibits superficially the process of using a public key and private
> key to conceal information. In the context of this thread--the
> important think is that it IS EASILY reversed. If you believe there
> is a formal equivalence to the NTRU system, the question then becomes
> whether there is something else that makes a system using a more
> elaborate and less well known basis secure?
I believe that there is an important difference between the schemes. In the
scheme that you present the moduli p and q are secret, whereas in NTRU two
elements f and g such that f*h = g are secret (p and q are public).
Yet, NTRU is based on the hard problem of finding a small vector in a
lattice, so NTRU can be viewed as a variant of a knapsack system. What makes
NTRU arguably superior to earlier proposals is the polynomial ring
construction, which makes the dimension of the lattice linear in the size of
the key pair -- as opposed to some earlier proposals, where the lattice
dimension was proportional to the square root of the size of the key pair.
Instead of having key pairs with hundreds of thousands of bits, we now need
just a few thousand bits.
Jakob
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Yarrow PRNG
Date: 14 Jun 2001 14:01:35 GMT
Tim Tyler <[EMAIL PROTECTED]> wrote:
> Then there's the use of MD5 - which is no longer regarded as a good
> one-way hash function, because of the techniques for finding collisions
> in it.
Linux /dev/random hasn't used MD5 for ages. It switched to SHA1
somewhere in the 2.0 series (or earlier).
-- [mdw]
------------------------------
Subject: Re: Alice and Bob Speak MooJoo
From: [EMAIL PROTECTED]
Date: 14 Jun 2001 10:04:47 -0400
"Robert J. Kolker" <[EMAIL PROTECTED]> writes:
>
> There are no observable actions of Alice and Bob other than the
> communications.
Then who cares what they're talking about? (Hint: If Bob and Alice are
my enemies, then they *do* perform observable actions in response to their
communications.)
Anyway, the weakness of language codes lies mainly in the potential for a
dictionary--whether paper, electronic or human--to be stolen.
Len.
--
Frugal Tip #40:
Instead of commuting to work every day, consider tending to your job
duties by mental telepathy.
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: The 94 cycle 64-bit block cipher :-)
Date: 14 Jun 2001 14:46:03 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> CRC's typically are only 32-bits wide. A collision can be found with
> 2^16 CRCs
Much fewer than that. Collisions and second preimages are trivial to
find in CRCs because they're completely linear.
-- [mdw]
------------------------------
From: "Total Annihilation" <[EMAIL PROTECTED]>
Subject: ENCRYPTION TYPE - UNKNOWN! :(
Date: Thu, 14 Jun 2001 16:43:40 +0100
Been trying to figure this encryption type out for ages now. I originally
though it was xbtoa encryption but I now know that it uses a keyword to
encode/decode it so I thought it could possibly be Babel or something
similar. Only problem is the only Babel tools I can find are for the Palm
Tops :(
Anyone here think they now what this is??? The keyword I have been given is
fr3quenter
BV!B-F-LR+K-IJ-YY-UX!I+NE!^E=EDF^DY-XU-TX+I+JRT=M!XU!B=W.YF-JF^LSO+TFC!D^SUY
=RN^
M-P=VFJ=JJ.EE=MM.R=Q=CO=CRI^H^PM+J^UY+H.WB-F+II+JR!BF+C.!FXV!ZTL=IM^L+VM^M^E
XZ-T
.Y.XU=X-.D.V-G!LBO=R.Z.TME^KI=QGI..O+HB.=.FK-TEO=VF.X!CFZ^I^FL!SOT!F!CD^N=EH
H-R!
KM.EL!NXS.-CBN-GR-S-K^I=B=YG!ML-RY^J!KW!O+R=KH+FBE=.J.BI.EX+W.FSC!O^^IR=R!PE
.P+Y
Y=U^MC!FMI!D-Z+JU.M^E+.CTW!J^BFH=X^+EH.M!SDF.K.Y!WE^YE=C.XJE!U=LE+GXH-RY^KX+
Y^F+
R-Z+ME+SZD^A!S=SX^E.T=M+UQ-S-^WB-TR.PU+RIM^A!B!KH.PT-L^X+UZR^B=WF-SC^OA.SBW^
^JFW
=!K-MYR!GR.J^F-ZI!XI!YE-L-MK-Z^J=UM!X^UX-J+L-ST+J+C+SA^-S(^H+RD+FV=NL+R.FS!E
Y-Y.
)!M=BIE!X^D=(O+)N=J^TY-GVF^EC^UC=QW-IF^L=IMJ.EJ+BV.BNK^Y^X=Z.NN+IRG-SW-!WV.Y
GE=A
G!D.VYR+!V^O=RPM^MFS+=.=Z=JI=RYR+!E.CQF^M^M!TE+X+GZ^X-V!T!C+KVM-W-RX!J-KGM^A
=ZX-
Y^FK.VCJ=R!MC!I!JGU=N!MG.B-ZV+QFE=JW^BY.-E+U!N=X-YN!QRT+R.J-N+K-I-JVR-VM!JJ-
!^LI
-CRT=ML.RY.G-Q-MWJ^H^VU.XY!EO!P=QL!LLY!=U+EQ=R-GA+I=DF-T!X=CRR!!T.W=WT=IM^BC
=LH+
YI!^X!YKN!XVG^K^Z-Y=UE+QR=V.W.SE=YB^D.IA.V=F.N^L-XK+JB+IZ.BW^V+WRR=F=I=Y-BXK
!Q.V
^.JY^GU^BI==NM+FF.L+S+TKE!DR=VT^NL.V!L^X!YNE.W+^C+X^=F!I=VFG+RRF!C^N=ZS!FI^K
+X=C
.R=T^M!LRY-Z.C=F^IN+O+M!E+L..K.XY+GB!NR=K!WP=YH!N.H-LX-R.KVM^X=E-LL!==.=.EGU
.V.D
X=IQ!=B!=NL-XK^-E-P!IE.AI=R^W+U!I=IQ!RML!Z=S!X!V=L-SZ+HRV+TW.JB!I=-RG.KZS!V.
U^L!
W=+V-M=WV+J^D!IN=L+RR!E.I.J!T-XUR-T^BRX=.YY!UU!PTH.VZ=YY!C-ZS.EM-LV-.JMU!H!H
.NRW
=.ZY!JU!Y!QF^MLV=D.+R+HY-YF^BRX.HF!C^J^PR.M+I-GWV-SCW.VH^RE^T=N=^MBM=P-AM^NT
!LBX
^E+FLY!DJ+N^EOP=Q-M-EB+JR.D-ORT=HH=CD.RCI^Y.AM-SW^H=GK!!NMZ!X=^EG!URH^Y!RG^E
C=KM
!V^O+BE.I.X!W=F.RV!DYA.^NE^SXW.ZJ+BQ.G!AI.P=WV=J+U.PXB^R=X+FS^E.OX!UN!KV+KC+
EU!X
VG.K!GTZ-DNW-C=B^XF+YY-Y!L=X.L=-MA+F+IV+SCQ!NE+TCF.TU=M.IHE.II^!FE-TV-I=E^G.
SLQ=
CY.!M+XVE-P-K.M-VI!U=QR-WIT.ND=QF^TY!TG+VX+RI^NL-R.DI!P.NK-IY.I+ZL=.M-C=Q^KH
^SX+
BE+SX^F^J^C+O+GU.TW^Z^HR=DV.ISH^VV=QV^QPM.AZ.^
If you now what it is then point me in the name of some information on it
coz I would like to crack this on my own really :) Email and other contact
info is below :)
==========================
Message sent by ToTaL
ICQ: 30193162
Email: [EMAIL PROTECTED]
MSN: [EMAIL PROTECTED]
Web: http://montos.virtualave.net
==========================
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
Date: Thu, 14 Jun 2001 17:46:55 +0200
[EMAIL PROTECTED] wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> > [EMAIL PROTECTED] wrote:
> >>
> > [snip]
> >> No. In an information-theoretic sense, the plaintext you hand me is
> >> useless. I am forced to consider the possibility that you are lying...
> >
> > I think that I misunderstood you. I am confused. Could
> > you please give a description of a scenario (a sequence
> > of events) such that an opponent could absolutely prove
> > that I am not lying in ANY sense?
>
> Who said anything about ``ANY'' sense? If you say, ``Here's my OTP,''
> then I'm generally forced to believe that you are lying. If your secretary
> says, ``Here's Mok's OTP, honey!'' then I must consider the possibility
> that you planted a OTP for her to find.
>
> If somebody says, ``Here's Mok's private key,'' then I can be 100% positive
> that it's the one that goes with your public key. There's no way you can be
> lying about that. And since your public key is ``public'', there is likely
> to be evidence connecting you to it--including a large body of messages I've
> been itching to decrypt. You *can't* lie about that.
>
> But in ``ANY'' sense? Maybe you've been lying to everyone, all your
> life. Maybe everything you ever said was a lie, and getting your
> private key simply allows me to read more of your lies. Sure.
>
> But there's one thing you can't lie about, period: the question ``Does this
> private key go with that public key?'' You can't fool me, because I can
> verify (i.e., ``absolutely prove'') it for myself.
Isn't it that the existence of the so-called trust centers
is because of the need of proving whether a public key
actually belongs to me? If you consider that the
trustworthiness of a trust center in fact needs itself a
proof, you get what I meant.
M. K. Shen
------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic) - VERY
From: [EMAIL PROTECTED]
Date: 14 Jun 2001 12:07:37 -0400
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>>
>> ...there's one thing you can't lie about, period: the question
>> ``Does this private key go with that public key?'' You can't fool me,
>> because I can verify (i.e., ``absolutely prove'') it for myself.
>
> Isn't it that the existence of the so-called trust centers is because
> of the need of proving whether a public key actually belongs to me?
But you keep changing the subject. Knowing that I'm dealing with *you*
and not with Dr. Evil is separate from the cryptanalysis of your
messages. In practical situations I know who I'm dealing with; I've
spied on the Mokkian diplomats; I've subverted the parlourmaid of Mok,
the King of all Mokkia; I've located your transmitters deep in the heart
of Mok-Kongs-burg, the capital city; and I've found copies of your public
key in radio rooms on captured Mokkian subs.
So denying your identity isn't going to fool me. The only interesting
question is, ``Do I now have the private key which unlocks the messages
we've intercepted?'' An absolute proof, one way or the other, is not
hard.
BTW, establishing identity only connects an individual to a body of
messages. The body of messages have an ``identity'' of their own; they
were all produced with one public key. And the private key can be
verified with certainty. So the only missing puzzle piece is the owner
of the key. If I can pin any single message on you, then I can pin all
of them on you--unless you can convince a jury that your private key was
stolen before the messages were written.
The same applies to guns used in multiple crimes, fingerprints left by
an unknown suspect, or--in the case of Timothy McVeigh--a prepaid phone
card.
Len.
--
Frugal Tip #38:
Don't buy mustache wax. It's much cheaper to let the handlebars droop.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Uniciyt distance and compression for AES
Date: Thu, 14 Jun 2001 07:25:55 -0800
Tim Tyler wrote:
>
> [EMAIL PROTECTED] wrote:
> : Tim Tyler wrote:
> :> [EMAIL PROTECTED] wrote:
> :> : Tim Tyler wrote:
>
> :> :> Here is the model I think you should have adopted:
> :> :>
> :> :> Alice -> [encrypt] -> ...eve... -> [decrypt] -> Bob
> :> :>
> :> :> Unicity distance is as measured by Eve.
> :> :>
> :> :> We are interested in the effect of replacing [encrypt] and [decrypt]
> :> :> by [compress encrypt] and [decrypt decompress] respectively.
> :> :>
> :> :> What you have done is not /just/ make changes to the stages represented
> :> :> inside square brackets.
> :>
> :> :> You have made fundamental changes to the set of messages which are sent
> :> :> and their probabilities.
> :>
> :> : How is this avoidable if messages are compressed from n=4 to n=3?
> :> : There are 16 possible messages before compression and 8 possible after
> :> : compression.
> :>
> :> That is not how compression programs function. I'm talking about
> :> conventional compression programs, like zip, huffman, arithmetic, etc.
> :> These allow you to compress a file, decompress it again and wind up with
> :> the same result.
>
> : You misunderstood my example.
>
> I very much doubt it. Was my sentence above less than 100% accurate?
> : The example compressor *encodes* 0000 as 000, 0001 as 001, etc. It
> : doesn't just throw away the leading zero.
>
> I'm well aware of that.
>
> : The decoder would reverse the mapping so that 000 would decode into
> : 0000, etc. So, all values that compress would decompress into exactly
> : the same value.
>
> Yes - but compress "1111" - and then decompress - and what do you get?
Any values that don't compress, like "1111" are expanded. If "1111"
didn't
compress, I wouldn't try to "decompress" it in the first place.
> In any orthodox compressor that behaviour would be regarded as severely
> broken. If you tried to seel such a program it would soon garner a
> reputation as a file mangler, not a file compressor.
>
> : Anyway, I'm not trying to understand specific compressor algorithms at
> : this point.
>
> A good job.
Likewise on your assertions instead of explanations.
> : I'm trying to understand the fundamentals of what *any* compressor
> : does.
>
> By examining a compressor that isn't even reversible, and mangles the
> user's data. Not a good start IMO.
>
> : Compressors map m-bit values into n-bit values where n < m.
>
> That's a bad description of what compressors do. They do that for
> particular files - not for *all* files.
>
> :> :> Your system after the compressor is added can't even transmit some
> :> :> messages that were transmitted before - and *all* the probabilities of
> :> :> the messages occurring are changed!
> :>
> :> : This isn't surprising. [...]
> :>
> :> It was suprising to me. How you could think comparing the resulting
> :> systems had any meaning was most puzzling.
> :>
> :> : Can *any* compressor compress *all* possible messages in the original
> :> : message space?
> :>
> :> Of course not - but that is not how compressors operate either. They
> :> compress some files, and expand others.
>
> : My example allows for the expansion of the values that don't compress.
>
> No - you did *not* include these files or their probabilities. If you
> add in any more files, your probabilities will need reworking so that they
> still add up to one.
So you want me to include the probability of a value that expanded in
the compressed message space? Sorry bud, if it expands from n=4 then it
doesn't
belong in the n=3 message space. BTW, if a value expands instead of
compresses, don't you think I'd just transmit the original value?
> : In fact, they don't affect the results in any way because I only
> : considered the compressed message space.
>
> Nonsense. Add those files in, leave all the probabilities alone and your
> thesis collapses. Remember what H(m) = -log2(0) is?
Why bother specifying the base? ;>
Show me how to add a n=4 value that expands into an n=3 message space
and
I'll be glad to start thinking about how to deal with the probabilities.
> :> :> Why should putting in a compressor affect the frequency of the messages
> :> :> being sent? It should not.
> :> :>
> :> :> If you /must/ use a lossy compressor at least set the probability of
> :> :> messages it can't handle to be 0 initially, or you are comparing different
> :> :> systems with different message spaces.
> :>
> :> : Again, doesn't one *have* to compare different message spaces since the
> :> : value of n is different after compression??
> :>
> :> No, you should be comparing the same message spaces, otherwise the
> :> comparison is completely nonsensical.
>
> : How can the message spaces be the same when there are 2^m values in the
> : original message space and 2^n values in the compressed message space?
>
> The last time you asked this question I replied:
>
> ``That is not how compression programs function.''
Do you think that's a good reply? A good reply would be to explain how
they (compressors in general, not specific algos) function.
> :> :> Also, do not change the probabilities of the messages occurring, or else
> :> :> you are comparing entropies in very different systems - and it is no
> :> :> suprise that your unicity distances are all over the map.
> :>
> :> : The probabilities in the original message space are what they are. If
> :> : they are non-zero then assigning them zero probability isn't an option;
> :> : *that* would be altering the message space.
> :>
> :> Of course. But *don't* apply a compressor that can't accept these
> :> messages as inputs and pretend that nothing has changed.
>
> : How can a compressor accept all inputs if it is mapping values from
> : a larger message space into a smaller message space?
>
> It can't - but your premise is wrong.
Maybe, but you don't seem to be able to explain why. Plenty of
assertions though...
> :> : All the probabilities in my compressed message spaces sum to one [...]
> :>
> :> No they don't. Add up the probabilities in your second column, and you
> :> will find they exceed one. A minor arithmetic error on your part.
> :> I ignored it until now because there were other far more important errors
> :> to address.
>
> : The point is that they are supposed to sum to one, and since the
> : compressed message space is smaller than the original message space the
> : original message probabilities can't be used because then they don't
> : sum to one.
>
> The compressed message space should not be smaller than the original
> message space.
>
> Think about what you are saying. Why should introducing a compressor into
> the system affect the frequency with which Alice wants to send messages to
> Bob? A compressor should not make any difference to them. It should
> be transparent in operation. The only person affected is Eve - who
> has a harder time of it.
Thing about what *you* are saying. A message compresses, i.e. fewer
bits, but
the message space still remains the same even though fewer bits means
fewer
possible values???
Again, the compressor doesn't restrict the choice of messages that I can
send. It restricts the number of *compressed* messages that I can send.
If whatever compressor I'm using doesn't compress the message, I'll send
it uncompressed - it's not like I'm unable to send that message at all.
> :> : Propose other probabilities.
> :>
> :> Leave the probabilities completely alone, you you are not comparing
> :> equivalent systems.
>
> : The message spaces can't be equivalent since n < m.
>
> You are barking up completely the wrong tree. You don't seem to
> grasp that your model has nothing to do with what compression programs
> actually do.
>
> If you deal with "compression" programs that distort messages as they are
> sent, don't allow the original messages to be reconstructed, and you
> change all the probabilities of the messages in your system after adding
> compression you are not comparing like with like.
1.) My compression example doesn't distort any messages. It just doesn't
compress some, which isn't that unusual.
2.) My example allows any compressed message to be completely
reconstructed.
3.) If you have a compressor that can encode only two messages, and
those
two messages have arbitrary but equal probabilities in the uncompressed
message space, and only compressed messages can be transmitted, what is
the probability that the transmitted message is 1 and what is the
probability
that the transmitted message is 0 ? You are saying that the probabilties
won't change?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Alice and Bob Speak MooJoo
Date: Thu, 14 Jun 2001 16:00:17 GMT
Tom St Denis wrote:
> Question. If "dumb means mute" and dumb also has the meaning [perhaps
> unofficial] as stupid, why not just say "mute".?
Because "dumb" means "unable to speak" while "mute" means
"not speaking". It's a matter of using the correct word.
------------------------------
** 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
******************************
