Cryptography-Digest Digest #468, Volume #10 Fri, 29 Oct 99 21:13:03 EDT
Contents:
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Uncle Al)
Re: Bruce Schneier's Crypto Comments on Slashdot (SCOTT19U.ZIP_GUY)
Re: use of US export restricted library (Greg)
Re: ComCryption (SCOTT19U.ZIP_GUY)
Re: the ACM full of Dolts? (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
For sale: Cryptography and Network Security - Stallings (JB)
Re: ComCryption (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 29 Oct 1999 23:33:30 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>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).
I will not commit to much since I feel you are addressing Tims stuff.
But I think you are wrong. The HG does not change as you say to HN
but either is a perfectly valid string that would decompress properly if
that is what you are asking
>Then this modified string is decompressible if and only if there
>is an entry 'HN' on side2. How are you going to ensure conditions
Wrong if it is not in dictionary then it is not changed for this example
>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.)
I thought you knew what I did. I do not just extend the pattern sometimes
it not extended but contracted. I assume you have played with it and used
a hex editor so you can see this. TIm you handle the rest if you wish but
I warn you his exchanges go on for along long time.
>
>
>> : (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
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: Uncle Al <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Fri, 29 Oct 1999 22:41:11 GMT
DSM wrote:
>
> If this is off-topic, please forgive me;
> I am thinking that the groups this message is directed to
> are frequented by those who may be interested in the method.
>
> ***
>
> Currently, any experiment (or other procedure) for which "true"
> random data is required must be conducted on a computer equipped
> with a special-purpose peripheral device (usually quite expensive.)
> Applications for "true random data" include statistical research
> and strong encryption.
>
> PROPOSAL:
[snip]
The digits of pi are purely random (except for being pi). We've got
pi to about 50 billion decimal places. Nobody would suspect using the
digits of pi becaise it is not a random number. No problem. Use pi.
--
Uncle Al
http://www.mazepath.com/uncleal/
http://www.ultra.net.au/~wisby/uncleal/
http://www.guyy.demon.co.uk/uncleal/
(Toxic URLs! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?" The Net!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Bruce Schneier's Crypto Comments on Slashdot
Date: Fri, 29 Oct 1999 23:51:03 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Omar Y.
Inkle) wrote:
>[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.
Dream on.
The NSA does not like the so called brilliant cryptographers that are in the
public domain. The main reason may be that they feel those in the public
domain are already poisoned by the false crap the NSA puts in the public
domain so that little real crypto can be done by other people.
People like Mr BS could never get to be famous in the NSA since the
NSA tries to recruit the brighest Mathematicians directly from college
this was not MR BS field of expertise. I might have been hired if I stayed
in Mathematics since I even attended the National Science Math
camp one year for gifted students. Got a full scholorship to ASU but
becasue all I wanted was math classes and my English sucked big
time I had to switch to Elcectral Engineering the Fields and Waves part
so that I could take more math than a Math major and less English
crap the other Math Majors had to take. I did write to the NSA
about a job a few years ago but the Bastards never even wrote back. So I feel
they are fair game to critisize since they so arragantly think they are better
than the rest of us. I am sure they look down there noses at MR BS
as much as he looks down his nose at me.
But if your dumb enough to belive MR BS knows the skill level of the
NSA then they are doing a good job. But I do suspect that the NSA like
the NAVY is undergoing a dumbing down procceedure were appearances
are more improtant than real work so maybe we may start to gain on the
bastards but you can beat your ass there still decades ahead of the public
sector.
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: Greg <[EMAIL PROTECTED]>
Subject: Re: use of US export restricted library
Date: Fri, 29 Oct 1999 23:01:44 GMT
> I am living outside US/ Canada.
> If I write a program which uses US export restricted crypto libraries
that
> have been exported in some way to my country and then I would like to
sell
> the program in US and other countries is there any problem?
The only problem you will have is violating any laws against
the land you live in. If you are outside the US, then US
export laws (and any law for that matter) is of no concern.
--
The only vote that you waste is the one you never wanted to make.
http://www.ciphermax.com/book for a look at our times
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ComCryption
Date: Fri, 29 Oct 1999 23:56:30 GMT
In article <[EMAIL PROTECTED]>, James Felling
<[EMAIL PROTECTED]> wrote:
>Given the SOTA in compression algorithims I don't think that this is so --
OK I know something about compression but what the fuck is SOTA
>most modern compression algorithims leave very recognisable elements
>embeded in their file structures, and thus will probably be easily
>defeated by basic analasys.
I agree most do but if you used my 1-1 huffman compression you
could mod the starting table with any of 2^n stings from some code
book for the compression part. Where would the easily recognisable
elements be their file structure. Not I would still use normal encryption
afterwards. Since compression not entirely a substitute for encryption.
>
>John Savard wrote:
>
>> One "Dr. Richard Crandall of Apple Computer" is credited with
>> suggesting, at a conference in 1998, an encryption idea called
>> "ComCryption", where a key of n bits is used to select one of 2^n
>> compression algorithms...since the result of compression appears
>> random, the cipher might be secure.
>>
>> I'll have to admit I don't think this is a particularly good idea.
>> It's a fruitful original thought, which one can play with in some more
>> pedestrian ways, such as Huffman coding with random, keyed code
>> assignment as a simple subsitution without easily visible boundaries.
>>
>> But universal algorithms which are relatives of LZW start out by not
>> compressing until they "learn" about the text, so an unknown algorithm
>> of that type could still be guessed at...see if the characters make
>> sense as 9 bits plus a flag bit; if something different comes along,
>> see where the earlier string is that could fit here, and figure out
>> how the following bits might point there.
>>
>> Anyhow, someone had been asking what had become of it. I suppose there
>> is the difference between someone like Dr. Crandall - who threw out a
>> potentially fruitful suggestion for creative thought - and others who,
>> once thinking of an idea that doesn't happen to be really very
>> practical, tirelessly advocate it as the cure for ingrown toenails.
>>
>> John Savard ( teneerf<- )
>> http://www.ecn.ab.ca/~jsavard/crypto.htm
>
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: the ACM full of Dolts?
Date: Sat, 30 Oct 1999 00:01:26 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>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'.
No while waiting to see if it was to be published I pretended to be a
nice guy. But it is hard for me to fake it like most of you can.
>
>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.
http://members.xoom.com/ecil/dspaper.htm for the rejected paper
http://members.xoom.com/ecil/compress.htm for cryptographical useful
compression
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 01:13:31 +0200
SCOTT19U.ZIP_GUY wrote:
>
> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
><[EMAIL PROTECTED]> wrote:
> >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).
> I will not commit to much since I feel you are addressing Tims stuff.
> But I think you are wrong. The HG does not change as you say to HN
> but either is a perfectly valid string that would decompress properly if
> that is what you are asking
I was making an example of a 'wrong file' such as one that is obtained
with decryption using a wrong key. For simplification, I assume
it is wrong only in one symbol. (This justifies the 'change'.)
If side2 of the dictionary does not happen to have the entry 'HN',
then one has the same problem that one discussed in the context
of your one-to-one problem concerning the ending bits of a wrong
file.
> >Then this modified string is decompressible if and only if there
> >is an entry 'HN' on side2. How are you going to ensure conditions
> Wrong if it is not in dictionary then it is not changed for this example
> >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.)
> I thought you knew what I did. I do not just extend the pattern sometimes
> it not extended but contracted. I assume you have played with it and used
> a hex editor so you can see this. TIm you handle the rest if you wish but
> I warn you his exchanges go on for along long time.
I didn't describe fully what you did in your modified Huffman,
but extending with 0's (in a number of cases) is one of the features.
I don't understand the proper sense of your last sentence (probably
due to my poor language competency in English).
M. K. Shen
------------------------------
From: JB <[EMAIL PROTECTED]>
Subject: For sale: Cryptography and Network Security - Stallings
Date: Fri, 29 Oct 1999 23:10:18 GMT
http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=190503076
Cryptography and Network Security : Principles and Practice by William
Stallings. Hardcover - New! 528 pages 2nd edition (July 1998). Lists
for $73.00. Prentice Hall; ISBN: 0138690170. From the Back Cover This
book presents detailed coverage ofnetwork security technology, the
standards that are being developed forsecurity in an internetworking
environment, and the practical issues involvedin developing security
applications. Opening with a tutorialand survey on network security
technology, Stallings provides a soundmathematical foundation for
developing the algorithms and results that are thecornerstone of
network security. Each basic building block of network securityis
covered, including conventional and public-key cryptography,
authentication,and digital signatures, as are methods for countering
hackers and otherintruders and viruses. The balance of the book is
devoted to an insightful andthorough discussion of all the latest
important network security applications,including PGP, PEM, Kerberos,
and SNMPv2 security. Now in its SecondEdition, the book has been
completely updated, reflecting the latestdevelopments in the field.
Buyer to pay $3.00 for domestic shipping & handling. Good Luck!
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: ComCryption
Date: Sat, 30 Oct 1999 00:10:51 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>John Savard wrote:
>>
>> One "Dr. Richard Crandall of Apple Computer" is credited with
>> suggesting, at a conference in 1998, an encryption idea called
>> "ComCryption", where a key of n bits is used to select one of 2^n
>> compression algorithms...since the result of compression appears
>> random, the cipher might be secure.
>>
>> I'll have to admit I don't think this is a particularly good idea.
>> It's a fruitful original thought, which one can play with in some more
>> pedestrian ways, such as Huffman coding with random, keyed code
>> assignment as a simple subsitution without easily visible boundaries.
>
>It's certainly not a good idea for 'compression', but not a bad idea
>for encryption in my humble view. Compression is the technique being
>'borrowed' here for persuing another purpose, namely encryption. It
>is the large number of potentially possible compression schemes that
>thwarts the analyst. This is an example of application of the principle
>of variability.
>
>M. K. Shen
But don't you think one has to be very carful which compression schemes
are used so that by inspection one can't immeately tell which method was
used.
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***
------------------------------
** 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
******************************
