Cryptography-Digest Digest #467, Volume #10 Fri, 29 Oct 99 20:13:02 EDT
Contents:
Re: Preventing a User from Extracting information from an Executable (jerome)
Re: Unbiased One to One Compression (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: the ACM full of Dolts? (jerome)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Bruce Schneier's Crypto Comments on Slashdot (Omar Y. Inkle)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: Preventing a User from Extracting information from an Executable
Reply-To: [EMAIL PROTECTED]
Date: Fri, 29 Oct 1999 20:54:04 GMT
On 29 Oct 1999 13:14:23 -0700, Chad Hurwitz wrote:
>
>Is there a proven way that makes it difficult for a user to see what is stored
>with in an executable they are running?
No way to do it (proven or not) on a system like unix. Somebody
can modify the OS to interrupt your executable and read the key.
The only way to do it would be to prevent the OS from handling
interruptions(IRQ timer, hd etc...) when your process is in
the critical section. By the way, you obviously can't do any
system call in this section. This critical section can't
be too long, some devices don't like to have 'interruptions
in the air'.
Doing that is likely to trigger some 'strange' behaviours
if the OS hasn't been designed to handle this kind of
situation.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Unbiased One to One Compression
Date: Fri, 29 Oct 1999 22:08:39 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> No one does not assume the opponent ususally knows the size of the
> message.
>
>But if not knowing the size of the message is essential to the system's
>security, it is a serious flaw, because there are only a relatively
>small
>number of likely sizes in many (communications-oriented) contexts,
>so the attacker can simply try them all (in parallel, perhaps).
Tha is why when I encrypt to my son during encryption we add a varible
random length block to the encrypted message but it is not really part of
the compression. Also I don't use the random block in tests of the strengh
when trying to break it. But it may be a good practice to at least have that
option when encyrpting.
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)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 29 Oct 1999 22:04:59 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>Mok-Kong Shen wrote:
>>
>>
>> If I understand correctly, you are now on compression not operating
>> on groups of 8 bits but on group of bytes. That certainly removes
>> the remaining bits problem at the last byte of file on decompression
>> of an arbitrary file which is a factor giving rise to the original
>> one-to-one problem. However: (1) the frequency counts of such group
>> of bytes takes much larger work and the Huffman tree is much much
>> larger, (2) due to the larger granularity the compression ratio is
>> likely to be poor, I believe.
>
>Addendum: I am afraid that you don't even solve the original one-to-one
>problem at all but simply have shifted that from the bits level to
>bytes level. For on decompressing an 'arbitrary' sequence of bytes,
>there is a chance that at the end of the file there will be a number
>of bytes which do not consititute a valid code symbol (analog to the
>original case where there are a few bits remaining that don't
>consitute a valid Huffman code).
>
>M. K. Shen
>--------------------------
>http://home.t-online.de/home/mok-kong.shen
Are you trying to say that you don't think my adaptive huffman compressior
actaully compress and decompress each file in a one to one way. What are you
attempting to say?
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: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 29 Oct 1999 23:12:13 +0200
SCOTT19U.ZIP_GUY wrote:
>
> >> >> TIm I did a quick look at it and yes I feel it would work. I have been
> >> >> thinking of a more complicated version but yours is more straight forward.
> >> >> I hope to is clear to users that as you search the long strings are
> >> >> replaced by the short one and that if a short string is found it is
> > replaced
> >> >> by the long one.
> >> >>
> >> >> The weird way I was thinking of doing it was things like "th" replace
> > with
> >> >> "q" if "th" not followed by "u" this way since q is usually followed by
> > u
> >> >> then it would not be replaced and since th seldom has a u after it it
> > would
> >> >> generally be replaced by a q
> >> >> So you can see mine would be messier.
> >> >>
> >> >> An alternate approoach is to allow for more than 256 symbols. You can
> > expand
> >> >> from 8 bits to 9 bits with leading bit a zero for common stuff that way
> >> >> ( note the 9 bit or even 16 bit is a temporary file to allow for more than
> >> >> 256 leaves at start mabye only 267 leaves in huffman tree)
> >> >> "th" could be replaced by a new symbol when at the compression stage
> > since I
> >> >> can easily allow 512 symbols with a slight mod to the current compressor.
> >> > Know
> >> >> on decompression if a "th" not there as a special symbol. It would be
> > count
> >> > as
> >> >> a repeat of "th" where combinations of "th" and specail new symbol would
> >> >> represent the repeat count. This is what I am playing with lately.
> >> >>
> >> >> Keep up the good work
> >> >
> >> >If I understand correctly, you are now on compression not operating
> >> >on groups of 8 bits but on group of bytes. That certainly removes
> >> >the remaining bits problem at the last byte of file on decompression
> >> >of an arbitrary file which is a factor giving rise to the original
> >> >one-to-one problem. However: (1) the frequency counts of such group
> >> >of bytes takes much larger work and the Huffman tree is much much
> >> >larger, (2) due to the larger granularity the compression ratio is
> >> >likely to be poor, I believe.
> >> >
> >> >M. K. Shen
> >> You lost me Mok. I was using groups of 8 bits to mean bytes. Some
> >> people don't use the common defination of byte to mean 8 bits. There
> >> was no change. To clarify
> >> "8bits==byte"
> >
> >Did I ever deviate from the common naming convention of bytes??
> >Note also the arguments of mine in an addendum given in a follow-up
> >posted some hours later. No comments to any argument are yet seen.
> >
> Then reask your question so I know what your asking. You have be
> confused since "on groups of 8 bits but on group of bytes" seems to
> me to mean you don't think 8bits is a typical byte.
'Groups of 8 bits' means a number of groups, each of which has 8 bits.
'Group of bytes' means a group, which contains a number of bytes. Well,
natural language has the disadvantage of sometimes incurring
ambiguities, particularly on quick reading. Let me say it hence more
clearly: In one case one compresses a string ABCDE... where each A, B,
etc. is a seperate unit having 8 bits (each unit is a group of
8 bits -- commonly also called a byte); one counts the frequencies
of these and designs an optimal coding. In the other case one
has RSTUV...... where RST is one entry in the dictionary, UV is
another, and each R, S, etc is a byte (8 bits), but the units,
on which the compression algorithm operates, are 'RST', 'UV', etc.,
which are each a group of bytes (i.e. each unit may consists of
more than one byte and hence be larger than 8 bits). Is this
clarification o.k. for you? If yes, please kindly proceed to
comment on my posts.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 29 Oct 1999 23:12:21 +0200
Tim Tyler wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> : If I understand correctly, you are now on compression not operating
> : on groups of 8 bits but on group of bytes.
>
> This is a strange way of putting it. There is no possibility of a
> non-byte aligned end-of-file, if you work with byte-aligned symbol
> strings.
>
> Of course my method is not *confined* to the use of byte-confined
> symbol strings - but your strings *must* differ from their replacements
> by a multiple of 8 bits or you will introduce the type of file-ending
> problems that only David Scott knows how to solve ;-)
Let me explain what I meant. You have certain symbols; let's
for convenience identify these with A, B, C, etc. (they could in fact
be anything you define through grouping any number of bits). Now your
dictionary does translations. An example could be that 'ABCD' is
translated to 'HG'. This is the compression direction. On decompression
it goes backward to translate 'HG' to 'ABCD'. Am I o.k. till here?
Now I denote the side with 'ABCD' above side1 and the side with 'HG'
side2. So on compression one matches the source string with entries
of side1 and replaces the found entries with the corresponding
entries of side2. On decompression one reverses that. Now side1,
if correctly constructed, should be able to process any given source
input and translate that to the target output. (I like to note
however that it needs some care for ensuring this property, if your
symbols are arbitrarily defined.) Let's say that in a concrete case
one has XYZ....MPQABCD compressed to UV.....ERHG. Suppose now I
change the compressed string to UV.....ERHN (HG is changed to HN).
Then this modified string is decompressible if and only if there
is an entry 'HN' on side2. How are you going to ensure conditions
of this sort of your dictionary? If this condition is not fulfilled,
then the decompression algorithm will get stuck at file end. (The
analogous case with normal Huffman encoding on ASCII symbols is
characterized by the fact that, if one makes changes to a compressed
file, then there is a chance that at the end of file there remains
a few bits in such a special combination that they have no
correspondence on the source side. The trick of Mr. Scott to deal
with this situation is that he makes a convention that such (normally
untranslatable) bit combination can be extended with 0's till a
valid source symbol is obtained, thus allowing proper termination
of the decompression process.)
> : (2) due to the larger granularity the compression ratio is
> : likely to be poor, I believe.
>
> One of the routine's targets is plain-text. This is also "granular" in
> 8-bit chunks.
The normal Huffman, operating on ASCII, have codes that, if of
unequal size, may have difference in length of only one bit. In your
case the codes may have in analogous situation difference in length
of one 'unit' that is presumably larger than one bit. That's what I
meant by larger granularity.
>
> It appears that while bijective *compression* routines are rare,
> there are a number of other known reversible operations that are of
> interest to the prospective bijective compressor as they may
> "reveal structure" in certain types of file.
>
> One is the fourier transform, and its sister algorithms. /If/ a routine
> that can reversibly transform a file *of arbitrary size* into the
> frequency domain can be found, this would be of significance to makers of
> one-on-one compressors. *Many* common types of data exhibit regularities
> in the frequency domain.
I am not aware of any loseless compression scheme that employs Fourier
transform and the like. I doubt that that could ever be done.
>
> Another operation of potential interest is treating the data as a
> byte-stream, and then rearranging the bits so that all the 0th bits
> come first in the file, followed by all the 1-bits ... followed by the
> 7th bit in each byte at the end of the file.
>
> Perform this bijective operation on some ASCII text, and the regularity in
> the 7th bit winds up as a handy long string of 00s at the end of the
> file...
This is a permutation of the bits on the whole file. It destroys the
natural correlations that is present in the input. This could be of
value cryptologically. But for compression this should lead
to less compressibility than the original source, i.e. disadvantageous,
if your goal is compression.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: the ACM full of Dolts?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 29 Oct 1999 21:28:10 GMT
Obviously if you has written your letter with your 'carefree writing style',
it is unlikely to get an answer.
Dolts or not, most people don't like to be called 'pompous assholes'.
On Fri, 29 Oct 1999 20:29:46 GMT, SCOTT19U.ZIP_GUY wrote:
> I asked more than once for a response but got nothing except the
>oringinal no appeal were not interested good bye you piece of shit letter. I
>did write back to get more info. Of course the popmous assholes
>never anwsered. Maybe they are to stupid to anwser or don't like
>my carefree letter writting style. It pisses me off when you tell them
>up front your not a writer and the assholes promise to work with you
>but they really don't give a fuck.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 29 Oct 1999 22:38:27 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> >> >> TIm I did a quick look at it and yes I feel it would work. I have
> been
>> >> >> thinking of a more complicated version but yours is more straight
> forward.
>> >> >> I hope to is clear to users that as you search the long strings are
>> >> >> replaced by the short one and that if a short string is found it is
>> > replaced
>> >> >> by the long one.
>> >> >>
>> >> >> The weird way I was thinking of doing it was things like "th"
> replace
>> > with
>> >> >> "q" if "th" not followed by "u" this way since q is usually followed
> by
>> > u
>> >> >> then it would not be replaced and since th seldom has a u after it it
>> > would
>> >> >> generally be replaced by a q
>> >> >> So you can see mine would be messier.
>> >> >>
>> >> >> An alternate approoach is to allow for more than 256 symbols. You can
>> > expand
>> >> >> from 8 bits to 9 bits with leading bit a zero for common stuff that
> way
>> >> >> ( note the 9 bit or even 16 bit is a temporary file to allow for more
> than
>> >> >> 256 leaves at start mabye only 267 leaves in huffman tree)
>> >> >> "th" could be replaced by a new symbol when at the compression stage
>> > since I
>> >> >> can easily allow 512 symbols with a slight mod to the current
> compressor.
>> >> > Know
>> >> >> on decompression if a "th" not there as a special symbol. It would be
>> > count
>> >> > as
>> >> >> a repeat of "th" where combinations of "th" and specail new symbol
> would
>> >> >> represent the repeat count. This is what I am playing with lately.
>> >> >>
>> >> >> Keep up the good work
>> >> >
>> >> >If I understand correctly, you are now on compression not operating
>> >> >on groups of 8 bits but on group of bytes. That certainly removes
>> >> >the remaining bits problem at the last byte of file on decompression
>> >> >of an arbitrary file which is a factor giving rise to the original
>> >> >one-to-one problem. However: (1) the frequency counts of such group
>> >> >of bytes takes much larger work and the Huffman tree is much much
>> >> >larger, (2) due to the larger granularity the compression ratio is
>> >> >likely to be poor, I believe.
>> >> >
>> >> >M. K. Shen
>> >> You lost me Mok. I was using groups of 8 bits to mean bytes. Some
>> >> people don't use the common defination of byte to mean 8 bits. There
>> >> was no change. To clarify
>> >> "8bits==byte"
>> >
>> >Did I ever deviate from the common naming convention of bytes??
>> >Note also the arguments of mine in an addendum given in a follow-up
>> >posted some hours later. No comments to any argument are yet seen.
>> >
>> Then reask your question so I know what your asking. You have be
>> confused since "on groups of 8 bits but on group of bytes" seems to
>> me to mean you don't think 8bits is a typical byte.
>
>'Groups of 8 bits' means a number of groups, each of which has 8 bits.
>'Group of bytes' means a group, which contains a number of bytes. Well,
>natural language has the disadvantage of sometimes incurring
>ambiguities, particularly on quick reading. Let me say it hence more
>clearly: In one case one compresses a string ABCDE... where each A, B,
>etc. is a seperate unit having 8 bits (each unit is a group of
>8 bits -- commonly also called a byte); one counts the frequencies
>of these and designs an optimal coding. In the other case one
>has RSTUV...... where RST is one entry in the dictionary, UV is
>another, and each R, S, etc is a byte (8 bits), but the units,
>on which the compression algorithm operates, are 'RST', 'UV', etc.,
>which are each a group of bytes (i.e. each unit may consists of
>more than one byte and hence be larger than 8 bits). Is this
>clarification o.k. for you? If yes, please kindly proceed to
>comment on my posts.
>
I think your refering to TIm Tylers suggustion.
Which describes a one to one mapping which could be used
as a compression or even a first pass to my compression
program. He was trying to explain how others could start to
build there own compressor.
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: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Sat, 30 Oct 1999 00:08:36 +0200
SCOTT19U.ZIP_GUY schrieb:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
> >SCOTT19U.ZIP_GUY wrote:
> >>
> >> >> >> TIm I did a quick look at it and yes I feel it would work. I have
> > been
> >> >> >> thinking of a more complicated version but yours is more straight
> > forward.
> >> >> >> I hope to is clear to users that as you search the long strings are
> >> >> >> replaced by the short one and that if a short string is found it is
> >> > replaced
> >> >> >> by the long one.
> >> >> >>
> >> >> >> The weird way I was thinking of doing it was things like "th"
> > replace
> >> > with
> >> >> >> "q" if "th" not followed by "u" this way since q is usually followed
> > by
> >> > u
> >> >> >> then it would not be replaced and since th seldom has a u after it it
> >> > would
> >> >> >> generally be replaced by a q
> >> >> >> So you can see mine would be messier.
> >> >> >>
> >> >> >> An alternate approoach is to allow for more than 256 symbols. You can
> >> > expand
> >> >> >> from 8 bits to 9 bits with leading bit a zero for common stuff that
> > way
> >> >> >> ( note the 9 bit or even 16 bit is a temporary file to allow for more
> > than
> >> >> >> 256 leaves at start mabye only 267 leaves in huffman tree)
> >> >> >> "th" could be replaced by a new symbol when at the compression stage
> >> > since I
> >> >> >> can easily allow 512 symbols with a slight mod to the current
> > compressor.
> >> >> > Know
> >> >> >> on decompression if a "th" not there as a special symbol. It would be
> >> > count
> >> >> > as
> >> >> >> a repeat of "th" where combinations of "th" and specail new symbol
> > would
> >> >> >> represent the repeat count. This is what I am playing with lately.
> >> >> >>
> >> >> >> Keep up the good work
> >> >> >
> >> >> >If I understand correctly, you are now on compression not operating
> >> >> >on groups of 8 bits but on group of bytes. That certainly removes
> >> >> >the remaining bits problem at the last byte of file on decompression
> >> >> >of an arbitrary file which is a factor giving rise to the original
> >> >> >one-to-one problem. However: (1) the frequency counts of such group
> >> >> >of bytes takes much larger work and the Huffman tree is much much
> >> >> >larger, (2) due to the larger granularity the compression ratio is
> >> >> >likely to be poor, I believe.
> >> >> >
> >> >> >M. K. Shen
> >> >> You lost me Mok. I was using groups of 8 bits to mean bytes. Some
> >> >> people don't use the common defination of byte to mean 8 bits. There
> >> >> was no change. To clarify
> >> >> "8bits==byte"
> >> >
> >> >Did I ever deviate from the common naming convention of bytes??
> >> >Note also the arguments of mine in an addendum given in a follow-up
> >> >posted some hours later. No comments to any argument are yet seen.
> >> >
> >> Then reask your question so I know what your asking. You have be
> >> confused since "on groups of 8 bits but on group of bytes" seems to
> >> me to mean you don't think 8bits is a typical byte.
> >
> >'Groups of 8 bits' means a number of groups, each of which has 8 bits.
> >'Group of bytes' means a group, which contains a number of bytes. Well,
> >natural language has the disadvantage of sometimes incurring
> >ambiguities, particularly on quick reading. Let me say it hence more
> >clearly: In one case one compresses a string ABCDE... where each A, B,
> >etc. is a seperate unit having 8 bits (each unit is a group of
> >8 bits -- commonly also called a byte); one counts the frequencies
> >of these and designs an optimal coding. In the other case one
> >has RSTUV...... where RST is one entry in the dictionary, UV is
> >another, and each R, S, etc is a byte (8 bits), but the units,
> >on which the compression algorithm operates, are 'RST', 'UV', etc.,
> >which are each a group of bytes (i.e. each unit may consists of
> >more than one byte and hence be larger than 8 bits). Is this
> >clarification o.k. for you? If yes, please kindly proceed to
> >comment on my posts.
> >
>
> I think your refering to TIm Tylers suggustion.
> Which describes a one to one mapping which could be used
> as a compression or even a first pass to my compression
> program. He was trying to explain how others could start to
> build there own compressor.
If his mapping is used that way, doesn't that ALSO has to fulfill
the one-to-one property?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Omar Y. Inkle)
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Date: Fri, 29 Oct 1999 22:21:39 GMT
[EMAIL PROTECTED] (jerome) wrote:
>from bruce schneier
>> The best and brightest of the cryptographers are staying in the open
>> academic community, and are not being swallowed up by the NSA (or
>> by its counterparts in other countries).
>How can he affirm that ? It is unlikle that anybody on the world has
>the knowledge to affirm that, just because it require to know each
>military cryptographic service and it is a secret field by definition.
Since he can account for all of the really brilliant cryptographers, the
only way there could be some working for the NSA would be if they were
secretly cooking them up in a lab somewhere or recruiting beings from
another planet.
--
"Omar Y. Inkle" better known as [EMAIL PROTECTED]
0123 4 56789 <- Use this key to decode my email address.
Fun & Free - http://www.5X5poker.com/
------------------------------
** 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
******************************
