Cryptography-Digest Digest #492, Volume #10 Tue, 2 Nov 99 03:13:03 EST
Contents:
Re: Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: Kerberos Question
Re: Doesn't Bruce Schneier practice what he preaches? (Jerry Coffin)
Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: Long Signatures (was Re: Doesn't Bruce Schneier practice what he preaches?)
(wtshaw)
Re: Kerberos Question
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Re: Compression: A ? for David Scott
Date: Tue, 02 Nov 1999 04:15:14 GMT
In article <[EMAIL PROTECTED]>, this news group unless otherwise
instructed! wrote:
>On Mon, 1 Nov 1999 15:15:59 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>
>>: If we can seed a random file from a key then both problems
>>: of message size and left over artifacts could be eliminated.
>>
>>If you do this, you rest the strength of your system on the strength of
>>the PRNG.
>
>Okay, I see your point.
>
>>: As to the question about getting the random file to my buddy (if I
>>: were to XOR the plaintext first) wouldn't it be easy to send the file
>>: encrypted because how would the analyst ever know he has a properly
>>: decrypted file?
>>
>>By analysing it in conjunction with the message later encrypted by
>>XORing with it.
>
>True. Like I said, there are probably things that I've overlooked.
>
>So, if we go back to David's argument about one-to-one versus
>non-one-to-one compression.
>
>One argument presented was if we used one-to-one and the aggressor
>attempted a key and decompressed, what's to stop him from looking at
>the compression ratio to determine if it expanded out. (It was
>mentioned something about output of /random data in/ (an unsuccessful
>decryption) would be /random data out/ which, in turn, doesn't
>compress well.) One of the answers that I saw was not all files are
>compressible, but if the file is very small and if the aggressor is
>looking for a text file then we would assume that the file /was/
>compressible. Plus, if it /did/ expand out then we would almost
>certainly have a /hit/ and a target for further analysis.
>
That was an old thread. True a random file tends not to compress.
Bad a random file also decompresses to a very large file with my
method. Find Clintons last message.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Kerberos Question
Date: 2 Nov 99 03:17:33 GMT
John Savard ([EMAIL PROTECTED]) wrote:
: [EMAIL PROTECTED] (David Wagner) wrote, in part:
: >I'm sure I'm missing something, but can't you trivially mount a
: >dictionary attack with the following technique?
: >Pick a random 64-bit xor mask M. Encrypt it with the server's public
: >key (pretending to be the legitimate client; remember, there is no
: >authentication yet). Capture the server's response, which will be
: >encrypted with K xor M. Now do a dictionary search for K using trial
: >decryption (which is easy, since you know M).
: You're quite right: even in the case that seems the most secure,
: encrypting the random mask with the user's secret key, the dictionary
: attack is trivial. Hence, more complicated protocols such as EKE and
: SPEKE.
I did see in the documentation on Kerberos I found over the web that
another proposal for modifying Kerberos was to have the user send an
authenticator for his own secret key with the first message. If that
authenticator as well as a session key for use with the Kerberos server
were sent, encrypted with the Kerberos server's public key, _then_ one has
protected against dictionary attacks (I think) without having to use the
unconventional - and proprietary - privacy-amplification methods such as
EKE and SPEKE.
I think this method - unlike my mistake - has been proposed before by
someone, and that again is something I'm looking for as I extend the web
page. I also think, now, that I will mention EKE and SPEKE, and I will put
them in the final conclusions part, as being among the things Kerberos and
similar protocols have inspired people to come up with, by pointing out
the need for them.
John Savard
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Crossposted-To: alt.security.scramdisk
Subject: Re: Doesn't Bruce Schneier practice what he preaches?
Date: Mon, 1 Nov 1999 21:16:18 -0700
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> I just find it puzzling, odd, inconsistent, by which I do not mean to
> imply fishy.
...as opposed to the algorithm itself, which clearly IS fishy --
almost too-fishy, you might say (sorry, I just couldn't resist).
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression: A ? for David Scott
Date: Tue, 02 Nov 1999 05:22:01 GMT
This is getting to long so I chopped the bottom half. We
are stating to over and over old stuff. You obviosuly think
it is not worth it. Then you don't have to use it. If your happy
with a high compression ratio using a method where the only
possible valid key is the key to the encyrption you used fine.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>On Sun, 31 Oct 1999 11:34:34 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>
>>Tom <[EMAIL PROTECTED]> wrote:
>>: On Sat, 30 Oct 1999 17:29:55 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>>:>Tom <[EMAIL PROTECTED]> wrote:
>>
>>:>: Measuring by compression ratio is objective. You're definition of
>>:>: adding information sounds subjective. [...]
>>:>
>>:>No - it could be measured precisely using entropic measures on both
>>:>pre- and post- compressed texts.
>>
>>: Has this been done?
>>
>>I doubt it. Measuring entropy accurately is very difficult in general.
>>
>>One-on-one compressors have only just been invented. I don't know if
>>people have been very interested in quantifying how bad non-one-on-one
>>compressors are before now.
>
>If "one-on-one" (symmetric compression) was better at reducing
>patterning, the files would be smaller! The objective, quantitative
>measurement of compression algorithms is compression ratio. It's very
>simple. To claim a "better" way to rate compression algorithms,
>without being able to measure or prove it is interesting, but can't
>IMHO be taken very seriously.
>
OK i am not hot with abbrviation what is IMHO. Look I have showed with
the only version now available the difference between my adaptive huffman
compression and the standard one. But the point is you can get any file out.
Take a new super version of one-one that works on jpegs ( I made this up
as an example no code write) Take what you call a bad file lots of patterens
then decompress it with the new hot shot program. Know when you compress
this file you have the patterning. So what?
If you can't understand the fact that most so called good compression
programs could be made better my changiing them to one to one like I did the
adaptive huffman code then I am sorry I can't help you. Go ahead use something
else.
Here is another attempt to make you understadnd Suppose I have a hot shit
compresser that decompresses a class of files that are one megbyte in
length to exacatly 64 bytes of file. What do you know from this well for
one thing it compresses pretty dam good.
But lets look at the example a bit more. It really means that the number of
files of the type you have you compressor tuned for is no more than if you
had just represented the data in a file of a different type but limited to
64 bytes.
Know lets suppose you try to decompress random files of 64 bytes in length
using the reverse of the compression method but only 1 in every 256
random file of this length are decompressable.
I state that even though you have a hot shit compressor you could still
compress it more since you have not really used the 64 bytes very wisely.
If you converted this hot shit method to one to one you would save space.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compression: A ? for David Scott
Date: Tue, 02 Nov 1999 05:35:43 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>On Mon, 1 Nov 1999 10:13:53 -0600, "Tim Wood" <[EMAIL PROTECTED]>
>wrote:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>
>>Tom wrote in message <[EMAIL PROTECTED]>...
>>>On Sat, 30 Oct 1999 13:27:48 GMT, [EMAIL PROTECTED]
>>>(SCOTT19U.ZIP_GUY) wrote:
>>>
>>>> By one to one I mean for any file X Compress( Decompress (X)) =
>>X
>>>>while most only consider for any file Y Decompress( Compress (Y)) =
>>Y
>>>>most only consider the second but with encryption you need to
>>consider
>>>>both.
>>>>..
>>>That means that in some cases you'll be reducing patterns, and in
>>>other cases creating them.
>>>
>>>Worse than that - this scheme makes the implementation of a chosen
>>>plaintext attack trivial, where using standard compression makes some
>>>forms of chosen plaintext attack completely impossible.
>>
>>This is not true. Assuming that the attaker can _choose_ the plaintext
>>it makes no difference what compression is used. The plaintext chossen
>>is the binary string *after* compression.
>
>Afraid it is.
>
>A chosen plaintext attack is just that - the person attempting to
>decrypt has the ability to insert data into the system before the
>encryption process. If the one-on-one system were implemented as part
>of a businesses data communication system, it doesn't sound too far
>fetched to be able to sneak additional information into the system to
>be encrypted. In any event, this is the definition of a chosen
>plaintext attack. To consider the compression as part of the system
>only makes sense, as it is being presented as being suited for use
>with encryption.
>
To do a chosen plaintest attack against a crypto system that uses
a one to one compression. You don't get someone to just add the information
in the file. You have to have them use a totally specailly consturcted file.
so that at the point of encryption you know what the file is that is being
encrypted.
Note this does not show the system is weaker then if compression is not
used. Since the compression added no information. But if you are using
non one to one compression this does not prevent chossen plain text attacks
it just means you have to find a file that decompresses before you give it to
the person to encrypt. IN many systems if the person is using a bad
compression you don't need to give plain text at all. The fact that a weak
compression is used my make a ciphertext only attack possible. This is
far worse than if no compression is used at all. Also if one is using a weak
compression since not all files exisit the attacker may need to only break
the system for the subset of files that the compressor creates. If you think
the NSA is fill of dummys that don't think of these things fine use what you
want.
you do
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Long Signatures (was Re: Doesn't Bruce Schneier practice what he
preaches?)
Date: Mon, 01 Nov 1999 23:45:15 -0600
In article <ZsqT3.63$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
> In sci.crypt SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
>
> > David A. Scott
> > --
>
> > SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
> > http://www.jim.com/jamesd/Kong/scott19u.zip
> >
> > Scott famous encryption website NOT FOR WIMPS
> > http://members.xoom.com/ecil/index.htm
>
> > Scott rejected paper for the ACM
> > http://members.xoom.com/ecil/dspaper.htm
>
> > Scott famous Compression Page WIMPS allowed
> > http://members.xoom.com/ecil/compress.htm
>
> > **NOTE EMAIL address is for SPAMERS***
>
> Is there some sort of compelling reason for this moronic signature,
> or are you just unable to put all these useless urls on a single
> page?
Certain of this information is useful/entertaining. Compare its length
with the standard details we usually bypass.
--
Geo. W. never met a dollar he did not like.
As for people, he likes their dollars.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Kerberos Question
Date: 2 Nov 99 05:42:43 GMT
David Wagner ([EMAIL PROTECTED]) wrote:
: I'm sure I'm missing something, but can't you trivially mount a
: dictionary attack with the following technique?
: Pick a random 64-bit xor mask M. Encrypt it with the server's public
: key (pretending to be the legitimate client; remember, there is no
: authentication yet). Capture the server's response, which will be
: encrypted with K xor M. Now do a dictionary search for K using trial
: decryption (which is easy, since you know M).
The server's response, though, is a *random session key* encrypted with K
xor M. Nothing more. The attacker was able, in the case of ordinary
Kerberos, to do a dictionary search because in the next message, the
legitimate user used the session key to encrypt public data - the current
time and the user's name.
Of course, this depends on the format of the messages. If the random
session key had correct DES odd parity, there would be an opening for this
attack.
John Savard
------------------------------
** 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
******************************
