Cryptography-Digest Digest #442, Volume #10 Sun, 24 Oct 99 17:13:03 EDT
Contents:
Re: Slide this.... (Anonymous)
Re: This compression argument must end now (SCOTT19U.ZIP_GUY)
Re: Unbiased One to One Compression (SCOTT19U.ZIP_GUY)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column ("Trevor
Jackson, III")
Re: This compression argument must end now (Tom St Denis)
Re: Slide this.... (Tom St Denis)
Re: compression and encryption (Geoffrey T. Falk)
----------------------------------------------------------------------------
Date: 24 Oct 1999 14:35:41 -0000
From: [EMAIL PROTECTED] (Anonymous)
Subject: Re: Slide this....
Correction to post =>
For i = 0 To LeapFrogRounds
SK(i, 0) = A5(SK(i, 0))
SK(i, 1) = A6(SK(i, 0))
SK(i, 2) = A7(SK(i, 0))
SK(i, 3) = A8(SK(i, 0))
Next
For i = 0 To LeapFrogRounds
SK(i, 4) = A1(SK(i, 0))
SK(i, 5) = A2(SK(i, 0))
SK(i, 6) = A3(SK(i, 0))
SK(i, 7) = A4(SK(i, 0))
Next
Should read =>
For i = 0 To LeapFrogRounds
SK(i, 0) = A5(SK(i, 0))
SK(i, 1) = A6(SK(i, 1))
SK(i, 2) = A7(SK(i, 2))
SK(i, 3) = A8(SK(i, 3))
Next
For i = 0 To LeapFrogRounds
SK(i, 4) = A1(SK(i, 4))
SK(i, 5) = A2(SK(i, 5))
SK(i, 6) = A3(SK(i, 6))
SK(i, 7) = A4(SK(i, 7))
Next
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: This compression argument must end now
Date: Sun, 24 Oct 1999 15:30:25 GMT
In article <7uv337$bmo$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>Ok the argument does 'p = compress(decompress(p))' make cryptanalysis
>has gone on too long now.
Who died and made you GOD. You are an asshole Tom. You
bitch because people don't anwser your argumanets but you fail
to learn or understand anything. You do not ask questions to learn
you don't want to learn.
>
>First off lets review the argument. The argument is if the above is
>true it will be harder to tell if a decryption is valid (via brute
>force) because any decryption is 'valid'. Second that since all
Look asshole the brute force was brought up only to illustrate
the concept from an information view point. Only an idiot like you
would use dumb brute force for a long key. The argument was to
show that with inferior compression many keys could be ruled out
because they lead to solutions that dont compress to a file which
when recompressed to the file. Thus one could even get a case
with some compression encryption schemes that if a individual
was sending a completely random file. It may be possible for the
attacker to recover the data compleltely with knowing anything
about the file. But obviously this is over your brains ability to
understand. Not many encryption systems are so weak so to
allow the attacker the possiblity of recovering a randomly encrypted
file. But a poor compressor encryption method can be.
...
>My second counter-argument. Most compression algorithms such as LZ77
>and Deflate (belongs to the LZ77 family) have no 'invalid' code words
>in the data stream. What does this mean? It means you cannot just
>look at a code and say it's invalid. No counter arguement provided.
>My counter to my own idea, is that if you have a index > your current
>position in the decompressed stream it must be invalid.
>
Well again I state an easy test which you again seem unable to
understand. I have played with many cmpression schemes. If you have
a version of LZ** that will decompress any binary file in such a way that
when you run the compression routine you get the file back you have a
winner. But your pee brain seems to think that if the obvious headers are
missing then all is well. But have you found any available compression
programs the average user can use that have this one to one property.
THere may be many compression routines that have this one ot one
property. But they are not aadvertised or discussed. I am sure it has
been thought up by the NSA. These are not stupid people. Our at least
before the dumbbing down process that the government is currently going
through I am sure that the NSA had people at one time of the intelligence
to understand this.
People like your Mr BS may actually lack such intellignce or they would
have written on it. THe main reason so little is written on this is that it
would hurt the NSA's ability to break encryption. THey love idiots like
you that can't seem to understand the basic ideas in a total system of
encryption.
I have given you the ability to test compression routines that would
gaurantee you that nothing is being added to help break the encryption.
You claim that many programs have this ability. Well advertise them
and SHOW ME. I am sure they are there just prove it instead of flapping
your jaws. Like I said they might should exist but for some strange reason
they don't exist in large numbers. I do hope you find one since they should
be there. You can even take the basics of LZ and code your own. BUt i
suspect you to dam lazy.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Unbiased One to One Compression
Date: Sun, 24 Oct 1999 15:52:22 GMT
In article <[EMAIL PROTECTED]>, "Trevor Jackson, III" <[EMAIL PROTECTED]>
wrote:
>
>
>Tim Tyler wrote:
>
>> SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>> : In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>>
>> :>Note that David's scheme doesn't *just* make all strings decompress to
>> :>valid outputs, it also has the property that distinct strings
>> :>always decompress to *different* valid outputs - the ultimate in
>> :>"equiprobability"?
>> :>
>> :>It's *easy* to make a decompressor that fails to give errors, but doesn't
>> :>have this "one-on-one" property: just take an ordinary decompressor and
>> :>instead of giving errors, make it spit out an empty string. Needless to
>> :>say, this doesn't offer any real security benefits [...]
>>
>> : Thanks Tim I have been away for a few weeks so I have not kept up
>> : with what is going on. However I doubt if you can make John understand
>> : the concept. [...]
>>
>> I have a high opinion of John Savard, based on his usenet contributions.
>>
>> However, I'm not sure I've done as well as I could have done in explaining
>> why having one - and only one - decompressed file for every compressed one
>> is potentially important to security.
>>
>> If you *don't* have this, then the compressor, when compressing, can
>> choose more than one compressed file to compress to.
>>
>> If the compressor chooses between these files at random, then there's no
>> security problem - you just wind up with fatter compressed files than you
>> need to.
>
>This is not always true. In classic Huffman compression there is a choice to
>be made when assigning subtrees to bits. One could always assign zero to the
>lighter subtree and one to the heavier subtree, yeilding a tiny amount of
>information to an attacker, or one can chosse randomly. The random choice does
>not increase the size of the file, but simply manipulates the mapping of the
>source characters onto the code bits, and thus the original text(s) onto the
>compressed text(s).
>
If one choose the one/zero assignements as random then you must supply
this method to the person recieving the message I feel this would be like
supplying a key and I don't do that. However I have a version which does
changes the one/zero assignments and that does affect the length of the
resulting file if a second huffman pass is done throught the file.
But even if one used the stand one/zero assignemnt or any other assiment
method if you assume the attacker has full access to you compression
decompression routines you are not giving extra information to the attacker.
After all we are talking about using compression as a seperate stage to be
done before encryption. If compression where not done at all the attacker
still has the plain text. And as many point out this kind of compression
does not prevent certain choossen plain text attacks.
If you can get the person to encrypt whole garbage files you can still cause
any file to actually be encrypted. However if the enemy only has access to the
encrypted messages the task is much harder for the enemy to break. In
fact only if the enemy can be given complete whole garbage files can an
attacker hope to achieve the same level of attacking that could have been done
if compression not used at all.
The beauty of one to one compression is that it does not add the other
hooks which other compression routines do. Most compression methods
leave information to help the attacker break the encryption in a way that
a system that may have been secure without using compression at all may
be broken if we can get the enemy to use cryptographically weak compression
as a preprocess.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
Date: Sun, 24 Oct 1999 10:59:23 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
A [Temporary] Dog wrote:
> >
> >"NEVER"? That statement is /so/ strong it is almost certain to be wrong.
>
> Not withstanding Mr. Ritter's comments on reinterpreting the words of
> others, always read "never" as "for the foreseeable future".
>
I don't think so. We aren't using clinton-speak. We (most) are using
English. In English never means not ever; and NEVER means
not-ever-and-I-really-mean-it!
If someone means "for the forseeable future" they might as well say "for the
forseeable future". But I doubt the submitter meant FOR THE FORSEEABLE
FUTURE, do you?
------------------------------
Date: Sun, 24 Oct 1999 11:29:12 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Mok-Kong Shen wrote:
> Trevor Jackson, III wrote:
> >
> > Mok-Kong Shen wrote:
> >
> > > Trevor Jackson, III wrote:
> > > >
> > > > What do you belive is the difference between a MUST implement feature and a MAY
> > > > implement feature?
> > >
> > > I am not sure in which sense your question is posed.
> >
> > You suggested that NIST recommend one MUST implement cipher and several MAY
>implement
> > ciphers. They you said that implementors would not have to implement the MUST
> > implement algorithm. This last statement appears to contradict the definition of
> > MUST implement. It appears that you think the MUST implement cipher you think NIST
> > should recommend is and implementation option. The MAY-implement ciphers are
> > obviously optional as well. So why did you distingush between MUST and MAY if the
> > difference makes no difference?
>
> I am quite sure that you mis-read my sentences. I am quoting my
> previous post below:
>
> But I believe one could be satisfied with a compromise.
> I guess that the possibility of NIST announcing, say, 3
> candidates to be 'the' (all entirely equivalent) standards
> is fiable. So letting one be the must and the others be may
> could be a practicable solution out of the dilema. Note that
> one must not use the MUST implementation at all. (I am aware
> that my viewpoint is critisizable. )
>
> I way saying that one (the user) must not use the MUST implementation,
> not that the implementor may omit the MUST implementation.
OK, this is the element, distinguishing between user and implementor, of context that
I did
not derive from your previous post. Thanks for the clarification.
> This
> implies that, if e.g. there are rumors that the winner were broken, he
> can simply drop that. While the analogy with standards in programming
> languages is only partly appropriate (because we are in our case
> considering a number of candidates that are functionally equivalent
> to one another, not certain features that are necessary and others
> that are not necessary in all situations) I do like to mention that
> the language COBOL has 3 levels in its standard. All implementor must
> implement the first level (without that no meaningful program can be
> written), those that also implement the higher levels can claim that
> their products provide these higher level features. So the market
> demand will determine what kind of complilers at what price category
> one will have. In our case a manufacturer that also implements the
> two MAY algorithms can claim that the user can have a random choice
> of the three available algorithms or do multiple encryption with them.
> Those users that have very have good faith in the winner can buy a
> product that only implements that at a lower price. Since all
> implementations have the MUST algorithm, all users can at least
> communicate with that and the issue of interoperability vanishes.
>
> M. K. Shen
> -----------------------
> http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: This compression argument must end now
Date: Sun, 24 Oct 1999 16:42:25 GMT
In article <7uv572$16ro$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <7uv337$bmo$[EMAIL PROTECTED]>, Tom St Denis <tomstdenis@my-
deja.com> wrote:
> Who died and made you GOD. You are an asshole Tom. You
> bitch because people don't anwser your argumanets but you fail
> to learn or understand anything. You do not ask questions to learn
> you don't want to learn.
Wow.
> Look asshole the brute force was brought up only to illustrate
> the concept from an information view point. Only an idiot like you
> would use dumb brute force for a long key. The argument was to
> show that with inferior compression many keys could be ruled out
> because they lead to solutions that dont compress to a file which
> when recompressed to the file. Thus one could even get a case
> with some compression encryption schemes that if a individual
> was sending a completely random file. It may be possible for the
> attacker to recover the data compleltely with knowing anything
> about the file. But obviously this is over your brains ability to
> understand. Not many encryption systems are so weak so to
> allow the attacker the possiblity of recovering a randomly encrypted
> file. But a poor compressor encryption method can be.
How do you rule out keys? What if I gave out 12344321 as a 8-byte
block of a message that was compressed with say DEFLATE then encrypted
with a 64-bit block cipher. Tell me how you would rule keys from
knowing the ciphertext only? Tell me your method. Take a PGP (hell
even a peekboo message) and tell me how you would rule out keys faster
then trial decryption.
It's the same for the ascii argument. I agree that some decryptions
would be invalid (1 in 256 for the 64-bit blocks) however there appear
to be no tractable way to rule out keys with only the ciphertext
**FASTER** then trying the keys. Otherwise you would have to break the
cipher.
> Well again I state an easy test which you again seem unable to
> understand. I have played with many cmpression schemes. If you have
> a version of LZ** that will decompress any binary file in such a way
that
> when you run the compression routine you get the file back you have a
> winner. But your pee brain seems to think that if the obvious headers
are
> missing then all is well. But have you found any available compression
> programs the average user can use that have this one to one property.
> THere may be many compression routines that have this one ot one
> property. But they are not aadvertised or discussed. I am sure it has
> been thought up by the NSA. These are not stupid people. Our at least
> before the dumbbing down process that the government is currently
going
> through I am sure that the NSA had people at one time of the
intelligence
> to understand this.
No, they (like me) fail to see the relevance of it.
> People like your Mr BS may actually lack such intellignce or they
would
> have written on it. THe main reason so little is written on this is
that it
> would hurt the NSA's ability to break encryption. THey love idiots
like
> you that can't seem to understand the basic ideas in a total system of
> encryption.
> I have given you the ability to test compression routines that would
> gaurantee you that nothing is being added to help break the
encryption.
> You claim that many programs have this ability. Well advertise them
> and SHOW ME. I am sure they are there just prove it instead of
flapping
> your jaws. Like I said they might should exist but for some strange
reason
> they don't exist in large numbers. I do hope you find one since they
should
> be there. You can even take the basics of LZ and code your own. BUt i
> suspect you to dam lazy.
Yak, yak yak. Believe what you want. Just shut the %$@! up.
Hey heres an idea. Build an attack against say PGP or some other
hybrid system using compression, and we will see the merit in your
ideas. Just like how they broke knapsacks. They didn't just ramble on
and on. They put there ideas down in formal papers and presented them
clearly and consisely (well I would assume this, I wasn't really alive
when knapsacks were in). Basically why don't you prove that your ideas
are worth the attention you are trying to get.
Have a nice day.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Slide this....
Date: Sun, 24 Oct 1999 16:43:45 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Anonymous) wrote:
<snip insanely stupid post>
Hey why not cryptanalyze your cipher and present it properly. Also
state the benefits (faster, more compact, simpler, etc...).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: gtf[@]cirp.org (Geoffrey T. Falk)
Subject: Re: compression and encryption
Date: Sun, 24 Oct 1999 19:30:31 GMT
In article <7uvg4e$upm$[EMAIL PROTECTED]>,
Patrick Juola <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Jerry Coffin <[EMAIL PROTECTED]> wrote:
>>In article <nJpQ3.3907$[EMAIL PROTECTED]>,
>>gtf[@]cirp.org (Geoffrey T. Falk) says...
>>
>>[ ... ]
>>
>>> Maybe, but I have taught information theory and cryptography and I've
>>> written compressors up the wazoo, so...
>>
>>[ ... ]
>>
>>> The problem you fail to neglect is that with any headerless compression
>>> scheme, you can feed in random data, and *something* will come out the
>>> output of the decompression algorithm. (What comes out may or may not
>>> make any sense, but determining that is another problem altogether.)
>>
>>If you've written so many compressors and taught information theory,
>>then how is it that you know SO little about compression and
>>decompression? Your statement is simply blatantly false. It's
>>entirely possible (and in fact pretty simple) to come up with a stream
>>that an LZSS or LZW compressor simply can't decompress.
>
>That's because standard LZSS and LZW aren't *headerless* compression
>schemes.
>
> -kitten
Precisely. I was not talking about LZ, which are far from headerless
algorithms. All flavours of Lempel-Ziv rely on pointers throughout the
message, which essentially provide header-type information that can
be used by an attacker.
An example of a headerless algorithm would be adaptive arithmetic
or Huffman coder/decoder. The output can be considered as a bit stream
with no special structure.
g.
--
I conceal nothing. It is not enough not to lie. One should strive
not to lie in a negative sense by remaining silent. ---Leo Tolstoy
ADDRESS ALTERED TO DEFLECT SPAM. UNSOLICITED E-MAIL ADS BILLED $500
Geoffrey T. Falk <gtf(@)cirp.org> http://www.cirp.org/~gtf/
------------------------------
** 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
******************************
