Cryptography-Digest Digest #503, Volume #10 Wed, 3 Nov 99 20:13:03 EST
Contents:
Re: Proposal: Inexpensive Method of "True Random Data" Generation (John Savard)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (John Savard)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Scott Nelson)
Re: An encryption proposal from a Newbie... (Johnny Bravo)
Re: Q: Removal of bias (Mok-Kong Shen)
Re: What is the deal with passwords? (John Kennedy)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Patrick Juola)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto Comments...)
(Matt Curtin)
Re: Newbie entropy question.. (John Savard)
Re: Q: Removal of bias (James Felling)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
SCHULTZE Heinrich is DEAD? ("freed lemon")
Re: SCHULTZE Heinrich is DEAD? (PCProd)
Re: What is the deal with passwords? (Dan Day)
Re: Compression: A ? for David Scott (Tom)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 03 Nov 1999 19:38:51 GMT
[EMAIL PROTECTED] (Scott Nelson) wrote, in part:
> ==> probability/pi.s <==
> No, the digits of pi are not truly random, therefore you can win
> money playing against a supercomputer that can calculate the
> digits of pi far beyond what we are currently capable of doing.
>There's more to the answer, which you can read at
>http://einstein.et.tudelft.nl/~arlet/puzzles/sol.cgi/probability/pi
>or any of the several other places the rec.puzzles archive is stored.
Now that is *very* interesting. I thought the digits of pi were
"random" in that sense, but the poster was still very wrong in
thinking they could be used in cryptography, since however
good-looking pi is, it is still dangerously easy to guess.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 03 Nov 1999 19:41:58 GMT
[EMAIL PROTECTED] (Will Ware) wrote, in part:
>You can solve your problem
>by upgrading your OS.
That which requires me to throw out my old applications is not an
"upgrade", it is a platform change. Such usage is acceptable in
comp.os.linux.advocacy, but here you might actually confuse someone.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Scott Nelson)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Reply-To: [EMAIL PROTECTED]
Date: Wed, 03 Nov 1999 20:26:41 GMT
On 3 Nov 1999 [EMAIL PROTECTED] (Patrick Juola) wrote:
[edited]
>In article <[EMAIL PROTECTED]>,
>Scott Nelson <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Patrick Juola) wrote:
>>>
>>>I believe pi has been proved "normal", which is to say that every
>>>finite-length string appears equiprobably in the extended decimal
>>>expansion. In point of fact, I think it's been proved "normal to
>>>all bases," which means the same holds in the octal, hexadecimal,
>>>binary, septal, &c. expansions.
>>>
>>
>>All the numbers might appear in the decimal expansion of PI,
>>but they aren't equiprobable. Long runs of zeros can't occur
>>early, so their probability is lower. Other repeating patterns
>>are also impossible in early positions. Thus, PI has been
>>proved to be "non-normal" although the bias is so slight
>>that only a mathematician would make the distinction.
>
>It has not, thank you.... you're confusing finite sample statistics
>with the statistics of an infinite set.
>
>If I play a (fair) roulette table once and walk away, the fact that only
>one number appeared does *NOT* make the distribution other-than-
>equiprobable.
>
After N digits, there is zero chance of 41*N zeros in a row.
This is true for all values of N.
If PI were "normal" then after N digits, there would be
a 1/10^(41*N) chance of 41*N zeros.
Therefore, PI is not "normal"
Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: An encryption proposal from a Newbie...
Date: Wed, 03 Nov 1999 16:30:29 GMT
On Wed, 03 Nov 1999 02:17:34 GMT, [EMAIL PROTECTED] (CoyoteRed) wrote:
>We will both generate new key pairs that we will use for communicating
>with each other. These pairs are shared with each other in an
>encrypted form so they are never open to the public.
If you already have a secure encrypted channel, just use that to distribute
the messages. If you are talking about a physical passing of the key on a
disk, just use a writable CD to churn out 600mb of one time pad and use that
instead. If you have semi-frequent contact or are sending very small messages,
you can just put 1.4 meg of one time pad on a floppy and use that. Use
Scramdisk to protect the contents of the pad while you are not using it.
>(A side note: to distribute this number, have one party come up with
>the number and the other generate a large key pair and send his
>partner the public key, encrypted, and the random number can be sent
>back and the public key destroyed. We would have only one message
>with that key out there.)
If you are trusting a public key system to the entire key for this new system,
why not just keep using the public key system for your messages, use a new key
for every message if you are that paranoid about it. The chain is only as
secure as the weakest link. If the public key is the weakest part, you gain
nothing by your method. If your method is the weaker of the two, then you are
better off just using the public key method. Setting up your system this way
has no benefit and very possibly extra weakness over the public key method.
Best Wishes,
Johnny Bravo
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Removal of bias
Date: Wed, 03 Nov 1999 22:47:09 +0100
Scott Nelson wrote:
>
> On Wed, 03 Nov 1999 08:40:52 +0100, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>
> >Could anyone give references to practical results of removal of
> >bias in random number/bit sequences, showing the efficiency of
> >the techniques? Thanks in advance.
> >
>
> Well, assuming independence and for simple techniques
> like XOR or CRC, it's just straight math;
.............
>
> Assuming a biased bit which is '1' .75 and '0' .25
............
> Is this the sort of thing you were looking for?
I like to know a little bit morethan that: How is the practice
in comparison to theory? Further, can we somehow check the assumption
of independence (IMHO this could be quite hard) made above?
M. K. Shen
------------------------------
From: John Kennedy <[EMAIL PROTECTED]>
Subject: Re: What is the deal with passwords?
Date: Wed, 03 Nov 1999 17:17:40 -0500
On Wed, 03 Nov 1999 13:11:16 GMT, [EMAIL PROTECTED] (Johnny Bravo)
wrote:
>On Tue, 02 Nov 1999 20:04:24 -0500, John Kennedy <[EMAIL PROTECTED]>
>wrote:
>
>>I have not spread any lies, I speculated out loud in a newsgroup. I
>>thought 41k seemed awfully small for the functionality claimed but I
>>don't have anything hard to base that on. I've done lots of DOS and
>>Widows programming but no crypto programming to speak of. I know
>>there are versions of PGP available that are only a few hundred K so
>>105K sounds more plausible.
>
> There is no requirement for crypto software to be large.
I didn't say it had to be. But 41k seemed pretty small to me for the
feature set described for this particular program.
> After all,
>you can code a complete and functional RC4 implementation in
>1k of C code, including comments. :) Strip it down to bare essentials
>and you can get by with about 650 bytes of code.
I defer to the judgement of those with experience coding crypto.
-
John Kennedy
The Wild Shall Wild Remain!
http://members.xoom.com/rational1/wild/
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 3 Nov 1999 17:10:06 -0500
In article <[EMAIL PROTECTED]>,
Scott Nelson <[EMAIL PROTECTED]> wrote:
>>It has not, thank you.... you're confusing finite sample statistics
>>with the statistics of an infinite set.
>>
>>If I play a (fair) roulette table once and walk away, the fact that only
>>one number appeared does *NOT* make the distribution other-than-
>>equiprobable.
>>
>
>After N digits, there is zero chance of 41*N zeros in a row.
>This is true for all values of N.
>
>If PI were "normal" then after N digits, there would be
>a 1/10^(41*N) chance of 41*N zeros.
That is not true. You're still confusing finite sample statistics
with infinite set statistics; the infinite tail dominates all
finite samples.
-kitten
------------------------------
Date: Wed, 03 Nov 1999 17:34:38 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> >> I see your point, but this wouldn't work with email for example. Here
> >> the choice of cipher must be made by me alone.
> >
> >How so? In a PK environment one would publish one's cipher set along
> >with one's public key. It's still the intersection of the cipher sets
> >of the two parties.
>
> Let's see: Normally, I compose the message and encrypt it off-line,
> then I connect to Internet and send all my mail in batch mode.
Good, that means you already have obtained the public keys of all of the
recipients of your messages. When you got their public keys you also got
their supported cipher list.
> Oh, I
> suppose I could encrypt it after connecting to the Internet and after
> downloading a certified set of each addressee's set of ciphers and
> choosing a cipher for each one.
Why would you want to choose? It would normally be completely automatic to
the point of transparency. All you have to do is order (sort or prioritize)
your own list.
> I suppose this can be done, but it
> looks complicated. What if none of the ciphers in one addresse's set is
> trusted by me?
Then you cannot communicate. This problem is not created by having multiple
ciphers supported at each end. This problem is created by having users
insist upon particular ciphers. Note that if you insist upon ciphers {A1,
A2, A3 } and your respondent insists upon { B1, B2 }, they you can still
communicate securely in both your opinions, by using two ciphers, one of
yours and one of his. Both of you will believe that the doubly encuphered
messages are secure.
If you _lack_ the cipher agility just described, you cannot ever convince
both participants that their messages are secure.
> What if my addressee does not have public keys?
Then, as now, you would need to obtain a secret key from him. With the
secret key comes the set of his ciphers.
> What if my addressee uses a different PK protocol?
Then you can't talk anyway.
> What if I want to send one
> message to 100 destinations?
You have to encipher multiple times anyway because using the same key for
broadcast messages creates an opportunity for attack. I'm not a protocol
expert, barely even a student. But I know there's weakness in reusing
message keys whether serially or in parallel.
> More importantly: what if the standard (or widely used) PK system
> suffers a catastrophic failure in the future?
Yeah, what if? The ensuing disturbance would have nothing to do with cipher
agility.
> This is more probable to
> happen with PK than with a symmetric cipher. Therefore it is even more
> important to be able to change PK environments.
Probably true. But AFAIK there is no reason to believe we can create "many"
PK systems, whereas there is good reason to believe that we can create
"many" symmetric ciphers.
>
>
> (...)
> >I would fear such a central repository. It adds a third party to the
> >system, and that third party is going to be vulnerable to attacks that
> >the original parties would not.
>
> A third party is not necessary if a group of people stick to a few
> ciphersuites. Then I just have to name one key exchange protocol (or
> several to be executed in parallel) and one cipher (or several to be
> executed in series). Also consider that a PK environment normally
> involves third parties too. In a networked world third parties are a
> fact of life.
Sure. As a key respository. Not as a repository for security
implementations. The two aren;t anywhere near comparable.
>
>
> Now, I don't claim that my suggestion is the best solution or that
> public servers are an indispensable component to any solution. What I
> do claim is that it is worthwhile to think about the feasibility of a
> "protocol of protocols". I want to be able in the future to dynamically
> change ciphersuites as a defense against unforeseen attacks and
> catastrophic failures. The Y2K error is so costly because so many
> programs all around the world are using one single, stupid (and de
> facto standard) data structure. We should learn from that experience
> and try to avoid a situation in the future where somebody discovers
> that a standardized cryptographic primitive that forms part of almost
> all security software is useless. In other words let us define a high
> level standard that explains how to change a low level standard.
An extremely ambitious goal.
>
>
> >I also have an aversion to downloading security code on demand. It
> >appears to me to be the inverse of a trojan. instead of an opponent
> >penetrating my firewalls, security, permissions, etc. by subterfuge. I
> >actually invite them in by regularly replacing the critical security
> components of my infrastructure from an external source.
>
> Trojan horses are a huge problem but I wonder if a few trusted central
> servers of certified code would not work *against* Trojan attacks. In
> my original message I suggested that you should be able to instruct
> your "code downloader" to only fetch code trusted by you. For example,
> you could instruct it to only download code certified by NIST or, if
> you prefer, by Schneier as well as by Shamir. Also *all* ciphersuites
> in the central servers should be in source code too - a big problem
> (but not insurmountable) for Trojan Horse designers. Finally, loading
> new code can be a fully manual process.
>
> Anyway, I see what you mean. In many cases you would never want to use
> the centralized code servers but you would be glad they are there just
> in case something extraordinary happens. For example: many applications
> will happily use the AES main winner as the only symmetric cipher
> primitive. Other more conservative applications may include code for
> both the AES-1 and the AES-2 winner (assuming NIST does choose two
> winners), just in case that something very bad happened to AES-1. Now
> you may argue that it is highly unlikely, but it is still realistically
> possible that both AES-1 and AES-2 suffer a sudden catastrophic failure
> in 50 years time. Then you will want to be able to instruct your
> application to download the new cipher X from a centralized server - or
> at least be able to introduce cipher X directly into the application.
> Let us trust in standards, but let us also be prepared.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Matt Curtin <[EMAIL PROTECTED]>
Subject: Re: Scientific Progress and the NSA (was: Bruce Schneier's Crypto
Comments...)
Date: 03 Nov 1999 17:57:15 -0500
>>>>> On Wed, 03 Nov 1999 07:23:00 GMT,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) said:
SCOTT19U> Where the HELL was the NSA when our nuclear screts were
SCOTT19U> giving to CHINA
Perhaps this is evidence that NSA does, in fact, lack omnipotence,
contrary to the claims of some who refuse to acknowledge that their
guesses about NSA's capability are just as wild as everyone else's.
--
Matt Curtin [EMAIL PROTECTED] http://www.interhack.net/people/cmcurtin/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Newbie entropy question..
Date: Wed, 03 Nov 1999 22:58:19 GMT
Mark Windmill <[EMAIL PROTECTED]> wrote, in part:
>2. Bruce then defines the rate of language as r=H(M)/N (N being the
>length of message M).
>Using the figures provided how does one get the rate(s) of language
>shown ? Surely N will always be larger than the entropy of any possibly
>known message content, giving a less than 1 result ?
Well, he gave the rate of English as 1.5 bits _per letter_. Had he
given the rate in terms of bits (of information) per _bit_
(transmitted, at 8 bits per letter, in ASCII), then the rate, as a
dimensionless constant, would indeed always be less than one (in this
case, 0.1975 (bits per bit)).
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Q: Removal of bias
Date: Wed, 03 Nov 1999 17:02:28 -0600
Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > >
> > > For x = 0 to size
> > > Ax = 0
> > > For y = nx to nx + n
> > > Ax = Ax xor By
> > > next y
> > > next x
> >
> > Please re-read my sentences to see whether you were answering
> > to that. I was questioning whether there are publically availbable
> > results of removing statistical bias from given random number/bit
> > sequences and whether the techniques involved prove to ge good
> > in practice. What has your program have to do with that at all???
>
> If you lean towards 1 or 0 (but not completely) xoring several bits
> together can 'flatten' out the bias. I read this in AC somewhere. I am
> not into the probabilities right now but I could dig em up if you want.
>
> I think it works similar to this line of thinking [i Could be wrong I
> am a bit tired now]. If you have a p(1) = 0.5 + 0.25 then xoring two
> consecutive bits gives you p'(1) = p(1)^2 or p'(1) = 0.5625 which is
> only 0.0625 from normal. (p(1)^3 is 0.4218 thus no better). Obviously
> this cannot be perfect (unless you can xor fractional bits) but can get
> better. you also have to know the bias of the bits before hand.
This method will flatten any stream.( You don't need to know what the p(1)
and the p(0) is as long as it remains constant this will gradually make the
bias as small as possible.
You sample with out replacement a stream B where B(i) = the ith bit of B,
and B(i) has probability (.5 +u) of being a 1, and probability (.5 -u) of
being 0
then B(2i) XOR B(2i +1) = C(i) will output 1 with probability (.5 - 2u^2),
and 0 with probability ( .5+ 2u^2). Repeat with C's if you want less
bias.
If the bias is of a less simple nature (even bits biaes high, odd bits low,
this method will fail miserably), but for simple uncorelated inputs this is
a near ideal bias killer.)
>
>
>
> [ this is also an order-0 algorithm... ]
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Wed, 03 Nov 1999 17:56:40 -0500
Reply-To: [EMAIL PROTECTED]
John E. Kuslich wrote:
>
> Wrong!
>
> This is a common misconception.
>
> Really GOOD random data is very hard to get.
No, it's EASY to get. I get -way- too much of it.
I looking to offload some to crypto goobers, any takers?
------------------------------
From: "freed lemon" <[EMAIL PROTECTED]>
Crossposted-To:
alt.binaries.satellite-tv,alt.satellite,alt.satellite.tv,alt.satellite.tv.crypt,alt.satellite.tv.europe,alt.satellite.tv.forsale,alt.usenet.satellite
Subject: SCHULTZE Heinrich is DEAD?
Date: Wed, 03 Nov 1999 23:10:40 GMT
This is a multi-part message in MIME format.
=======_NextPart_000_0017_01BF2650.AB8DCF60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
http://www.dcgs.org/addison/page131.htm
Look here.
He is a zombie
=======_NextPart_000_0017_01BF2650.AB8DCF60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2><A=20
href=3D"http://www.dcgs.org/addison/page131.htm">http://www.dcgs.org/addi=
son/page131.htm</A></FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>Look here.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=3D2>He is a zombie</FONT></DIV></BODY></HTML>
=======_NextPart_000_0017_01BF2650.AB8DCF60==
------------------------------
From: [EMAIL PROTECTED] (PCProd)
Crossposted-To:
alt.binaries.satellite-tv,alt.satellite,alt.satellite.tv,alt.satellite.tv.crypt,alt.satellite.tv.europe,alt.satellite.tv.forsale,alt.usenet.satellite
Subject: Re: SCHULTZE Heinrich is DEAD?
Date: Wed, 03 Nov 1999 23:16:07 GMT
Reply-To: [EMAIL PROTECTED]
On Wed, 03 Nov 1999 23:10:40 GMT, "freed lemon" <[EMAIL PROTECTED]>
wrote:
snip...
>
>Look here.
>
snip....
Hey! Are you attempting to cheer everybody up here??
If so, you've nearly succeeded. Tell me when the nails are
in the coffin and I'll open this very large magnum of Bolli
earlier than the milenium night! ;-))
OK, so I didn't remove the cross posting, but on reflection, would you
in light of such possible news? ;-) Like the MAN says.."be happy".
------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: What is the deal with passwords?
Date: Wed, 03 Nov 1999 23:23:06 GMT
On Tue, 02 Nov 1999 08:06:14 -0500, John Kennedy <[EMAIL PROTECTED]>
wrote:
>High entropy pass phrases are not as difficult to memorize as most
>people seem to think. Most people can rememeber some fairly long
>sentences.
I don't think the memorization is the biggest hurdle. I easily
memorized Lewis Carroll's nonsense poem "Jabberwocky", for example,
and can still recite it upon demand today, 15 years later.
("Twas brillig, and the slithy toves...")
However, I'll be damned if I want to type it in every time I
need to access my data, and *that's* the real hurdle to using
a sizeable high-entropy passphrase.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: [EMAIL PROTECTED] (Tom)
Subject: Re: Compression: A ? for David Scott
Date: Thu, 04 Nov 1999 03:40:28 GMT
Reply-To: [EMAIL PROTECTED]
to save space, snipping a bunch of stuff that we seem to be in
agreement on, generally....
On Wed, 3 Nov 1999 02:36:58 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>Tom <[EMAIL PROTECTED]> wrote:
>: On Sun, 31 Oct 1999 11:03:30 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>:>Tom <[EMAIL PROTECTED]> wrote:
>:>: (SCOTT19U.ZIP_GUY) wrote:
>:
>: The "so what" is that this one-one-one scheme is being touted as an
>: absolutely better way to compress than standard compression [...]
>
>I'm not touting it as such. A o-o-o compression schem that leaves the
>file unchanged may frequently be /worse/ than using a decent compressor.
>
>o-o-o *on it's own* does not necessarily offer any security.
>
What I'm begnning to wonder is if the information that's said to be
added information in non o-o-o can really be considered to be a
byproduct of the standard compression algorithm not fully compressing,
similar to that of low ratio o-o-o leaving patterning behind. DS has
claimed that the two types of information present different types of
weaknesses, but this leads me to question if it's true if the type of
plaintext file (and thus it's patterning) is known.
>: As to all the best compressors being "one-on-one", if that were true,
>: they would make some files 10 times larger! Clearly this isn't so.
>
>*All* compressors make some files larger. Your argument leaves me unmoved.
All do make some files larger, but if the assertion that "the best"
(taken to mean in compression ratio) are o-o-o, then they would indeed
greatly expand some files, more than standard compression.
>
>The proof of the original assertion is via a counting argument.
>
>Non-o-o-o compressors "waste" compressed files. These "wasted" files
>could be used to improve the compression ratio.
>
By not using the entire set of possible output files, you mean? OK.
Which could lead to the theory that the perfect compressor would
decompress anything to something. But I don't think that would
nessesary mean it would be o-o-o, and even if this could be proven to
be true, it wouldn't prove that the quality of being o-o-o itself made
a compressor more efficient in any sense.
>: This all (nearly anyway) comes back to patterning, and rather than
>: re-hash the last three dozen posts, I suggest posting some objective,
>: verifiable information before continuing to claim that this scheme
>: reduces patterning over standard compression, and is thus superior.
>
>It does not necessarily. I have mentioned an exception a moment ago.
>
>It prevents pattern that is "systematically added" by the compressor.
>This can only be a good thing.
That's what I mean. We're talking about patterning left by a low
ratio compressor vs patterning created by a compressor.
>
>: Again, if the goal of the compression program is to eliminate
>: patterning, then I still contend that you're talking about encryption,
>: not compression.
>
>Deterministic encryption rarely eliminates patterning, it /mainly/
>shuffles it around. ;-)
>
>By compressing the pattern into a smaller space, compression does
>something neither block-cyphers, nor stream cyphers ever do - that is
>increase the entropy-per-bit of the text.
That's true, and why I think compression ratio has to be looked at in
conjunction with patterning.
>
>I don't think it's unfair to analyse o-o-o as part of an encryption
>scheme. That is how it will commonly be used.
>
>: In short: Prove it's better.
>
>Analysis will eventually prove the case in practice. However some
>decent one-on-one compressors will be needed before they can be widely
>used without risk. Today the situation is not perfectly clear cut.
>
>The /main/ thing that has changed recently is that the o-o-o "framework"
>has indicated that there are potential problems with *many* compressors -
>even ones without headers, or CRC information designed to detect errors -
>and that there problems may - in principle - be eliminated.
Discussion has raised a couple of good points about compression,
especially the need for some type of compression better suited for
crypto, or at least a better system for dealing with compression in
general.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Thu, 04 Nov 1999 00:29:36 +0100
Tim Tyler wrote:
>
> : (1) Must the symbol sets that appear on both sides of a dictionary
> : be identical? (I presume not. See your own example.)
>
> Yes. If you have a dictionary entry:
>
> "ABCD" <-- "XYZ"
>
> ...you *must* also have:
>
> "XYZ" <-- "ABCD"
> : (3) MUST a dictionary have the form above or not?
>
> In your "side1", "side2" notation - yes. If it does not, the system will
> probably fail to work.
>
> : Besides the two criteria that you gave in an earlier post, namely
>
> : No string in the tables should contain another such string
> : as a substring.
> :
> : No leading symbols in any string should exactly match the
> : trailing symbols in a different string.
>
> : what else exactly must a dictionary also satisfy?
>
> These are the only conditions for the dictionary in my original format.
>
> If you use your own "side1", "side2" notation, each dictionary
> entry should be present with the sides reversed - and note that the above
> two conditions need only be applied to the entries on one side of the
> dictionary, if using your notation.
If you require what you use with <--> in the dictionary (or in
my notation what is expressed by the last sentence above) I don't
see why you need the first rule
No string in the tables should contain another such string
as a substring.
The second rule apprears to be sufficient.
M. K. Shen
------------------------------
** 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
******************************
