Cryptography-Digest Digest #633, Volume #14 Sun, 17 Jun 01 06:13:00 EDT
Contents:
Re: IV (David Wagner)
Re: Is ECB truly more secure than CBC? (David Wagner)
Re: Is ECB truly more secure than CBC? (David Wagner)
Re: Tom's base64 code (was Re: CipherText E-mail encryption) ("Tom St Denis")
Re: Order of encryption and authentication (David Hopwood)
Re: Tom's base64 code (was Re: CipherText E-mail encryption) (David Hopwood)
Re: Is ECB truly more secure than CBC? (SCOTT19U.ZIP_GUY)
Re: Tell me could this one-way function be somewhat secure (wtshaw)
Re: Tom's base64 code (was Re: CipherText E-mail encryption) (SCOTT19U.ZIP_GUY)
Re: IV (SCOTT19U.ZIP_GUY)
Re: Is ECB truly more secure than CBC? (SCOTT19U.ZIP_GUY)
Re: integration question (Roger Fleming)
Re: Order of encryption and authentication (lcs Mixmaster Remailer)
Re: Is ECB truly more secure than CBC? (Tim Tyler)
Re: Uniciyt distance and compression for AES ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: IV
Date: Sun, 17 Jun 2001 02:15:48 +0000 (UTC)
Tim Tyler wrote:
>I think your summary says something different to the theorem - something
>that is stronger - and is not actually supported by the theorem at all.
Quite possibly! It _is_ a summary, after all, so it is impossible
to include all the nuances. It's a judgement call which nuances are
important enough to mention and which ones aren't.
While I agree that there might be some rare cases where CTR mode is less
secure than CBC mode, I claim that (1) these are rare and unimportant,
(2) the difference between the two modes will still be quite small,
and (3) in such scenarios even CBC mode is unlikely to be completely
satisfactory anyway.
There are plenty of other examples, too. For instance, you could note
that "taking the last block of the ciphertext" forms a somewhat better
MAC if you use CBC mode than if you use CTR mode. Does this mean that
we should consider CBC mode significantly more secure than CTR mode?
No, I don't think so.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Is ECB truly more secure than CBC?
Date: Sun, 17 Jun 2001 02:19:10 +0000 (UTC)
lcs Mixmaster Remailer wrote:
>It appears that none of the classical chaining modes provide non-
>malleability. [...] Nevertheless it is an important
>property, as the recent Czech attack on PGP showed. [...]
>The usual way of achieving effective non-malleability is with another
>layer of protection, either a signature or a MAC. I believe the
>XML encryption standard does include the option of using a MAC,
>although it is not required.
Right. In my opinion, anywhere that you use encryption, you should always
include a MAC, too, as a matter of good design. There are many subtle
ways that systems have been broken when they did not follow this rule of
thumb (see Bellovin's cut-and-paste attacks on IPSEC, or reaction attacks
on WEP, or ...).
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Is ECB truly more secure than CBC?
Date: Sun, 17 Jun 2001 02:20:56 +0000 (UTC)
Actually, CTR mode is a little _harder_ to use correctly than CBC mode,
because the consequences of inadvertently reusing an IV in CTR mode are
much more severe than the consequences of reusing an IV in CBC mode. I
would argue that it is an interesting open problem how to design modes
of operation that have the desirable features of CTR mode (parallelizable,
extremely simple) yet have better robustness.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Tom's base64 code (was Re: CipherText E-mail encryption)
Date: Sun, 17 Jun 2001 02:24:13 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (David Hopwood) wrote in
> <[EMAIL PROTECTED]>:
>
> >-----BEGIN PGP SIGNED MESSAGE-----
> >
> >Tom St Denis wrote:
> >> /* Does base64 encoding decoding */
> >[snip]
> >
> >No it doesn't. "base64" is the name of the algorithm in RFC 2045:
> > - you use a different character set from base64,
> > - base64 handles arbitrary length inputs; your code does zero-padding
> > of the input,
> > - base64 specifies that the output is padded to a multiple of 4 octets
> > with '=' characters; your code does not,
> > - base64 is consistently big-endian; you read the input into y in
> > big-endian order, and then write it out in little-endian order.
>
> Dave its a trival matter to clean "base64" up. So that it could
> really be base64. Why do they add the "=" symbol. It kind of takes
> away the beauty of it. It not that hard to convert from any binary
> file to "true base64" if one likes one could easy convert any binary
> file to a "true base64 with a fixed line length". It would be a
> hell of a lot cleaner. And if people have a heart on for 64 plus
> the "=" symbol why not go to base65.
Because 65 does not divide a power of two.
And I agree that the output should be a fixed line length mainly to avoid
truncation etc.
Of course my routines will skip over white space so if you get aaz3 as the
"base64" output you could send it "a a z 3" and get the correct
output from the decoder. Therefore it doesn't matter with my routines if
the programs wrap lines or add spaces, etc. As long as they don't add or
remove base64 chars.
Tom
------------------------------
Date: Sun, 17 Jun 2001 03:26:32 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Order of encryption and authentication
=====BEGIN PGP SIGNED MESSAGE=====
I wrote:
> Here's an interesting protocol design puzzle:
I misstated it slightly. This is the corrected version (the difference
between versions is a big clue):
> Alice has a public encryption key PKB for Bob, with fingerprint FB.
Alice's own public verification key is PKA, with fingerprint FA.
> Enc is an IND-CCA2-secure encryption scheme and Sign is an EUF-CMA-secure
> signature scheme with appendix. Alice sends a signed and encrypted
> message with plaintext M to Bob, as:
>
> FB, Enc_PKB(FA, M, Sign_PKA(FB, M))
>
> Exercise: why is each of the fingerprints there, and what do they stop an
> attacker from doing?
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOywVJjkCAxeYt5gVAQGUgAf6A5iunE3nAP0/pd5EoJWW6CDa5h+DPXey
MPG/JAF0UpZNSa/ZfIcxlBHn8rxOwEV4jX9gXcLzEllc04yu8ESQq/qugttZbWcP
ybz67avDxzTGbEFqSmD1KGWXAJZ3mRgAraEBI8oG3m5O7nJr7wWI9CjbMNPjEOUO
eoPuqc9wOlJDf4uRrA2kaq/VOJzjVSAmMrRhlc2guMrbA9CS15prllXNynOQRae2
9k3NnA2kgQrby2W4iuRnpohROWoEIOrijAi7w/rJg7+kgiNLsPINKkY+yyys9Lkw
y23wbBDpc8+upFjVcwh7cabJXwfGLmEN8hXWfm+HtheGF2RfNZf2TQ==
=/501
=====END PGP SIGNATURE=====
------------------------------
Date: Sun, 17 Jun 2001 02:59:22 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Subject: Re: Tom's base64 code (was Re: CipherText E-mail encryption)
=====BEGIN PGP SIGNED MESSAGE=====
"SCOTT19U.ZIP_GUY" wrote:
> Why do they add the "=" symbol [in base64].
That's a good question. I don't see any reason for the "=" padding
(the length of the input is unambiguous even without it). Still,
there's no point in changing the algorithm over such a small quibble.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOywOiTkCAxeYt5gVAQEpnwgAxP+fIoJ6zMW+fLTDAcQzXhAekwvGMq3z
aCNwp5Lef4E/jsOrgdPC8y8saIJ8IsmtFwjf7JZu0EpoCe600h8eTBlzT1/yRDWH
aI5jsRSJZJZf1nMa1w1QwC2rnkaX9GyX7lJpN/RA3paC38svHhX45JEgG79um0I2
yTVIHuvhhP0RFKVEB/L9PBD4puC8EDnrtAauqvCyCZ/8TAcOb0LGQqUlHtzL9FmS
nlt3EjOqr725h1agGG7VkUdpZElLf3AlVIDo+cA1lDsChJ6jKFnksX5vJ/wXKvjB
6opHJVkDyPaIbludfjvrqwPFBPVbiZ7AHHHpy2k5ZfCyEAX/BcqSRg==
=9IJZ
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is ECB truly more secure than CBC?
Date: 17 Jun 2001 03:37:10 GMT
[EMAIL PROTECTED] (David Wagner) wrote in
<9gh3fh$26hd$[EMAIL PROTECTED]>:
>
>I still dispute whether there is a scenario (even an unlikely one)
>where ECB mode would be preferred over a proper use of more standard
>modes of operation, and I think I gave strong evidence that his claimed
>"counterexample" was not valid. Maybe others will prove me wrong;
>who knows.
>
>But even if we assume that such a rare scenario exists, I still think it
>might be bad engineering practice to retain ECB mode---it is too easy to
>inadvertently screw yourself over by using ECB mode when you shouldn't
>be, and the consequences of doing so are very bad. Systems must be
>secure not just when used as intended by the designer, but when used by
>humans who do all sorts of unexpected things (like use ECB mode when
>they shouldn't).
Maybe your argument should also apply to CTR mode since humans do
all sorts of unexpected things. (such as using CTR mode when they
shouldn't) And CTR mode will easily become the most commonly used.
Since people will be fooled into belivening its as safe or better
than CBC.
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] (wtshaw)
Subject: Re: Tell me could this one-way function be somewhat secure
Date: Sat, 16 Jun 2001 21:40:55 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> wtshaw <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> :> Well, you *will* if you hash material with more entropy that the width of
> :> the combined hash. A scarcity of source material appears to be why
> :> Marko's example failed to demonstrate this.
>
> : But, anyone should know that brief input that is extrapolated into a
> : longer so-called hash is merely an exercise in super-redundancy and low if
> : not marginal security.
>
> Does anyone "know" that?
By definition.
>
> : I suggest that two less intelligent hashes can do wonders if combined, one
> : which closely tracks the size of the input in output, and some wildly
> : different hash, perhaps more of a digest, to cut effective collisions way
> : down.
>
> It sounds like you would create collisions in the former by considering
> plaintexts of the same size. Then you only have the latter "less
> intelligent" hash to deal with.
A hash should produce a little less output state than input to guarantee
collision or it is not a true hash. A hash can be trivial and combine
with others to do wonderous things.
>
> I think I'd rather take an ordinary hash of their combined size.
Different uses, different ways of doing things, the more the merrier.
What I look for are easy ways to get complex results. Of course, complex
ways to do simple things are available if that is what turns you on.
The original thought of this thread is on the right track.
--
In trying to get meaning from the TmV-OK saga, remember that
those who do not learn from history are apt to repeat it.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tom's base64 code (was Re: CipherText E-mail encryption)
Date: 17 Jun 2001 03:54:30 GMT
[EMAIL PROTECTED] (David Hopwood) wrote in
<[EMAIL PROTECTED]>:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>"SCOTT19U.ZIP_GUY" wrote:
>> Why do they add the "=" symbol [in base64].
>
>That's a good question. I don't see any reason for the "=" padding
>(the length of the input is unambiguous even without it). Still,
>there's no point in changing the algorithm over such a small quibble.
>
Actaully since computers do the same crap over and over with
millions of messages. This little quibble can add up. There really
is no reason not to fix it. Also if your sending base64 data over
the net. The odd occurance of the "=" symbol can throw the compressor
off if the stream is compressed. I am glad you see its not really
needed. But the use not only implies waste it makes it look like
idoits designed the specification and maybe there were not smart
enough to realize it didn't have to be there.
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: IV
Date: 17 Jun 2001 03:47:57 GMT
[EMAIL PROTECTED] (David Wagner) wrote in
<9gh3sk$26hd$[EMAIL PROTECTED]>:
>Tim Tyler wrote:
>>I think your summary says something different to the theorem - something
>>that is stronger - and is not actually supported by the theorem at all.
>
>Quite possibly! It _is_ a summary, after all, so it is impossible
>to include all the nuances. It's a judgement call which nuances are
>important enough to mention and which ones aren't.
>
>While I agree that there might be some rare cases where CTR mode is less
>secure than CBC mode, I claim that (1) these are rare and unimportant,
>(2) the difference between the two modes will still be quite small,
>and (3) in such scenarios even CBC mode is unlikely to be completely
>satisfactory anyway.
I realize you really are one to treat weakness as rare and unimportant.
I also realizse as you put it CTR mode is less secure than CBC mode. The
question is. Is there really any practical cases where CTR is more secure
than CBC mode. I see it may be fast and paralleazble. And one does not
have to use padding. But if one uses CBC mode you don't have to use
the weak nonbijective padding that the government approved with DES.
Again you can use it if your don't care about possible weaknesses.
But whats more important using it securely or trying to weaken the
underlying cipher and make it faster.
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: Is ECB truly more secure than CBC?
Date: 17 Jun 2001 03:40:34 GMT
[EMAIL PROTECTED] (David Wagner) wrote in
<9gh468$26hd$[EMAIL PROTECTED]>:
>Actually, CTR mode is a little _harder_ to use correctly than CBC mode,
>because the consequences of inadvertently reusing an IV in CTR mode are
>much more severe than the consequences of reusing an IV in CBC mode. I
>would argue that it is an interesting open problem how to design modes
>of operation that have the desirable features of CTR mode (parallelizable,
>extremely simple) yet have better robustness.
Strange do I see cracks in your armour. Are you honestly starting
to admit CTR may not be the mode of choice. Or are you starting to
realize it will be poorly implemetned in most cases.
I don't think it an open problem. Speed and highly parallelizable
encryption that is extrememly simple most likely can't be secure.
especailly with zero error propagation as in CTR mode.
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] (Roger Fleming)
Subject: Re: integration question
Date: Sun, 17 Jun 2001 07:24:53 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
[...]
>in school education between Canada and US. Douglas Gwyn
>just told us he was able to read most of Principia
>Mathematica in high school.
Wow. Doug, do all US high schools do Latin? 8^)
------------------------------
Date: 17 Jun 2001 09:20:01 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Order of encryption and authentication
David Hopwood writes:
> Alice has a public encryption key PKB for Bob, with fingerprint FB.
> Alice's own public verification key is PKA, with fingerprint FA.
> Enc is an IND-CCA2-secure encryption scheme and Sign is an EUF-CMA-secure
> signature scheme with appendix. Alice sends a signed and encrypted
> message with plaintext M to Bob, as:
>
> FB, Enc_PKB(FA, M, Sign_PKA(FB, M))
The interesting one is the FB inside the signature. This seems to serve
as a sort of "Dear Bob" within the signed portion of Alice's message,
so that it is clear that she meant to send it to Bob.
There was a debate about a similar issue in the early days of the XML
encryption effort. What happened was that first the group worked on
XML digital signatures. This was higher priority since an important use
of XML was in business documents and it was thought that being able to
certify/validate these documents would facilitate ecommerce.
Once the XMLDSig effort got pretty well done, they started working on
XML encryption. This was essentially an independent effort. There was
a requirement that XML encryption coexist with XML signatures, in that
you could encrypt a signed document and then when it was decrypted the
signatures should still validate. Or you could sign an encrypted document
and it shouldn't prevent decryption (although that would probably break
the signature).
It was argued, though, that it was not right to try to separate encryption
from signature like this. What was really needed (at least as an option)
was a combined signature and encryption transform. The reasoning was
essentially that shown by David's example above. If you just sign and
then encrypt, it is as if the inner "FB" doesn't exist. Then Bob can
decrypt the data and re-encrypt it for someone else. They then receive a
message encrypted to them and signed by Alice, and they might be misled
into thinking that Alice intended to send it to them. Maybe if there
were some instructions in the message they might think Alice intended
for them to be followed. Much mischief could result.
In the end the group decided not to try to support a combined mode like
this. Partially it was for organizational reasons; due to the structure
of the working group it would not be practical to go back and change
the charter of the DSIG group to incorporate features for encryption.
But it was also argued that the mistake above was simply a matter of not
understanding the semantics of public key signatures. Only the signed
portion is authenticated. The fact that it is wrapped in an encryption
envelope for someone tells nothing about the intentions of the signer.
Signers need to make sure they include all the relevant data within the
portion that they sign.
Because of the structure of XML, the general problem of unauthenticated
data crops up in other contexts. For example there are ways to set
up abbreviations for words or phrases, which then get automatically
expanded when an XML document is displayed. If you sign a portion of
the document that includes abbreviations but not the part where they
are defined, then an attacker can change the apparent meaning of the
signed portion by manipulating other parts of the document. So the
XML signature document has many caveats warning users to be careful and
complete in what they sign.
Given that this general type of problem already existed, it was decided
that the problem of changing the apparent target of a document by
re-encrypting for a new recipient was not serious enough to warrant
resetting the digital signature effort. If you want to say who a document
is meant for, you should put it in the signed portion.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Is ECB truly more secure than CBC?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Jun 2001 09:21:09 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:>However, perhaps the argument is stronger if the same key is
:>used. You've just transmitted an important short message in CBC
:>mode. You can't change key - and now want to transmit a long (but
:>not-very-important) message. Do you use ECB mode or CBC mode?
: It seems to me that the correct answer to this question is to
: unask the question. Why can't you change the key? In particular,
: let k be the shared key, let k' = prf_k(0), k'' = prf_k(1), and
: use k' for the important short message and k'' for the unimportant
: long message. Is there any reason this won't be possible?
Once can certainly think of cases where it might present problems:
* Protocol can't cope with it - e.g.:
Multiple recipients, with new keys from a pad at midnight every night.
* Recipient or sender is an embedded device - with no PRF handy.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Uniciyt distance and compression for AES
Date: Sun, 17 Jun 2001 00:42:25 -0800
Tim Tyler wrote:
>
> [EMAIL PROTECTED] wrote:
> :> : 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.
>
> Not in your example. You already used up all the probabilities available.
I used up the probabilities in the compressed message space. That
doesn't
mean I can't transmit "file" instead of "file.gz". If the file doesn't
compress it doesn't belong in the compressed message space.
[snip]
> You refuse to even consider the cases that is of interest - instead you
> stick with your message distorter.
>
> If you distort the messages, goodness knows what happens to the entropy in
> the resulting system. Goodness knows what happens to the unicity distance.
> Had any bets been made, they would definitely be off.
I really don't understand why you say the messages are distorted since
I can recover all compressed messages and I can encrypt and transmit
messages that won't compress "as is". I think you would probably claim
that I am distorting the probabilities in the message space. Is this
what
you mean?
[snip]
> : Why bother specifying the base? ;>
>
> It's there in the definition of entropy of a message.
Actually you're wrong here. Shannon, who originally defined it, didn't
specify
a base. He used an arbitrary constant K "which merely amounts to a
choice
of unit of measure" which is the same thing that choosing a base for the
logarithm
does. *Typically* it is log2 . Forgive me for mentioning it as it is
quite
picky, and besides I was jokingly referring to the fact that
log2(0)=log3(0)=log4(0)=log5(0)=...
>
> :> The last time you asked this question I replied:
> :>
> :> ``That is not how compression programs function.''
> : Do you think that's a good reply?
>
> It should have given you a clue that your model was up the creek - in
> conjunction with all my other explanations.
>
> : A good reply would be to explain how they (compressors in general, not
> : specific algos) function.
>
> I don't see my function here as being teaching you - I'm mainly trying to
> prevent misinformation being spread around on the subject - because
> there's enough of it out there already, without people spreading it
> further.
For the record, I haven't asked you to teach me and unless you're
a professor who teaches grad level math/sci/engr. courses you aren't
qualified to teach me anyway.
For the benefit of those that you wish to guard against misinformation
on Usenet, do you expect them to concur with your statements without
question (statements like (paraphrased) "There really aren't *that* many
atoms
in the entire universe."). I think any reader who didn't know the
answer already would want an explanation too.
[snip]
> No - that's NOT what I'm saying! You are one of the most frustrating
> individuals I've discussed matters with recently :-|
I feel the same way! I can sum up this entire thread from start to
finish:
"Does so"
"Does not"
"Does so"!
"Does not"!!
"YES IT DOES"!!!
"NO IT DOES NOT"!!!
etc.
Which is really frustrating to me because either compression increases
unicity distance or it does not and with the expertise in this group
it should be fairly easy for someone to explain it definitively
so that there would be no question on any side. Unfortunately, no one
has done that. There has been plenty of disagreement (and not just by
me) on this tread over what should be a simple issue.
> :> 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.
Did yours?
(previous posts to this thread. TSD= Tom St. Denis, TT=Tim Tyler)
=================================================================================
TT:> So what are you going to do if the compression is so good that
*all* the
TT:> messages appear to be in English?
TSD: How is that possible? [...]
TT Like this (for example):
TT 0 <-> It is raining in Spain.
TT 1 <-> All quiet on the western front.
TT 2 <-> Red sky at night.
TT 3 <-> Looks like snow tomorrow.
TT ...
TT 65532 <-> Rainingly solidly.
TT 65533 <-> Hailstorm arriving.
TT 65534 <-> No hope of remission for the patient.
TT 65535 <-> Burn everything as soon as possible.
TT Messages are restricted to a set of 65536 possible ones. A subset
of the
TT English language - but enough for weather reports, status reports,
etc.
TSD : That form of compression would not be practical. [...]
TT Well, the example of all possible English text messages is not
TT really the subject of this discussion. We are talking about whether
TT compression before encryption increases the unicity distance
TT of the resulting system. The existence of "perfect" text compressors
TT is neither here nor there - all that matters is that some reasonable
TT compressors exist.
[...]
TSD: This is wholly impractical. Its not very versatile and requires me
to lug
TSD: around a dictionary...
TT This was an /example/ - designed to demonstrate your error as clearly
and
TT concisely as possible, to assist you in understanding the issue.
TT To object that the result is not very useful misses the point.
=============================================================================
Can we just go ahead and call this a dead thread that has turned into a
catfight?
Go ahead and take the parting shot - I'm not going to reply to this
thread again.
------------------------------
** 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
******************************
