Cryptography-Digest Digest #508, Volume #10 Thu, 4 Nov 99 21:13:02 EST
Contents:
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Data Scrambling references (Mok-Kong Shen)
How protect HDisk against Customs when entering Great Britain (pgp651)
Re: Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: Data Scrambling references (John Savard)
Re: How protect HDisk against Customs when entering Great Britain (Ike R. Malony)
Re: The Code Book (Dr. Harley Mackenzie)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: Data Scrambling references (Steve Sampson)
Re: D.J. Bernstein's Cryptography Lecture Notes (slackjawyokel---*)
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Thu, 04 Nov 1999 23:01:40 +0100
SCOTT19U.ZIP_GUY wrote:
>
> You pointed out wrong the sacriffcing of one token the all zero
> token as an EOF symbol. This has repeatidly been shown to be wrong.
> You do not get one to one compression by this method. In summary
> how do you uncompress afile like
> 11000000 00000000 00000000 10101010 assuming as shallow a tree
> as possable. How do you uncompress in your method of your socalled
> EOF token is embedded in a file. I don't think you get the point yet.
If the tree is fairly shallow, this is indeed a problem for what
I said. (I don't have have a record of what we discussed quite a
time ago and don't remember every details. But isn't it that you
assume for your algorithm that a certain particular number of 0's
can't be the prefix of code symbols, which means that your tree has
certain restrictions which one has to take care of?)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Thu, 04 Nov 1999 23:01:34 +0100
SCOTT19U.ZIP_GUY wrote:
>
> In article <3820e4ad$[EMAIL PROTECTED]>, Don Taylor <[EMAIL PROTECTED]>
>wrote:
> >For example, we can allow say 2^16 different words, a very reasonable
> >vocabulary for any specialty, and in english, with an average length >5
> >bytes for words constructed from characters, the compressed result only
> >requires a length of 2 bytes to express the code for each translated
> >word.
>
> IF you ordered these 16 bit wordrs so that in hex 00 00 was in general
> the most commmon occuring token then 00 01 and 01 00 and 01 01 where
> the next most common token where you increase and use the next available 8 bit
> token to build this table and so on. So that the table is order based on some
> standard english text. Build your compressor to convert the english only
> words to something like this. Then used a FIXED HUFFMAN TABLE not
> my adaptive huffman table as the starting table. This could be done since the
> codes and huffman table are decided on in advanced based on the language.
> Compress this in a one to one way using the starting frequency of occurance of
> each of the 8 bit hex codes and end it using my way of ending so file is a one
> to one compression I would still use some sort of adaption like in h3com.exe
> The advantage of the almost fixed table (slowing adapting table) is that if
> an enemy tries to guess a key when he uncompresses he will always get text
> that would appear somewhat realistic since he would be using the almost fixed
> table based on the real frequency of occurrance. But the changes prevent
> imbedded plain text from compressing the same way if different text appears
> before it.
> The main disadvantge is that only 2^16words can be used but for most messages
> this should be ok. Since even in WWII the navjho code talkers had to use
> concepts in the language for words that where not in the language. You may
> have to write a program that converts words not in the language to strings of
> letters. This would take away from some of the 2^16 symboles. It would also
> mean people who such like me and can't spell worht a shit will me more apt
> to have longer messages unless some sort of specail spell checker built in.
There were discussions on that in the group quite a time back. I
remember that I suggested that the words in a commonly used
dictionary be numbered. If such a numbering is sort of an inofficial
'standard', then a software could automatically do the conversion.
Using numbers largely eliminates the frequencies present in natural
languages. However, there were opinions that 2^16 words is
insufficient, etc. etc.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Data Scrambling references
Date: Thu, 04 Nov 1999 23:02:03 +0100
Larry Mackey wrote:
>
> I have a project where we need to scramble (and unscramble) a parallel data
> stream such that when the data stream is serialized, the stream is a fairly
> symetrical set of ones and zeros.
>
> The data does not need to be compressed or encrypted rather we need to
> randomize the data on a bit level.
The most straightforward seems to be serializing your streams and
apply XOR with a statistically good bit sequence (from shift
registers or other PRNGs). Since encryption is not your purpose,
you have an easier choice of the sources of such bit sequences.
>
> I am trying to find a scheme that encodes and decodes the data words in as
> uncomplicated manner as possible. This is presently a bi-directional path
> but we would like to be able to do this in a single direction only if
> possible. Since all the data in the stream needs to be randomized, the
> decoding procress information needs to be extracted from the data stream or
> decoding logic.
It is not clear for me what you mean by later to have the process
to be in a single direction only. Does that mean that you then don't
need to convert the stuff back? Well, in that case you can simply
forget the possibility of converting back, can't you?
M. K. Shen
------------------------------
Date: 4 Nov 1999 22:06:21 -0000
From: pgp651 <[EMAIL PROTECTED]>
Subject: How protect HDisk against Customs when entering Great Britain
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
=====BEGIN PGP SIGNED MESSAGE=====
I'm considering to be crossing border of Great Britain [ GB ] very soon on
business & pleasure trip.
My friend did tell me that GB is scanning in / out coming computers for some
specific data / images / information. I'm privacy advocate & can not allow this
invasion of privacy to occur to me & my possessions.
I'm using PGP day in / day out but excluding PGPdisk. I'm protecting my files
by PGP on folders or / and individual files routinely.
I need now to implement more advance disk protection to protect myself when
entering GB.
- From my knowledge, we have 2 comparable products : PGPdisk & Scramdisk. Please
provide advise which I should implement to achieve the best hide & camouflage
results.
The points of interest are:
- - I do not like to create precedence at the border.
- - Very possible, when Customs can not scan / read info, they may opt for
detention / seizure & this will ruin my trip.
- - The best will be to camouflage the encrypted disk / partition / folders and
not to have encrypted disk / partition / folders readily visible / recognize by
Customs Scan as ENCRYPTED.
- - I need the appropriate balance between encrypt & camouflage.
- - Where the camouflage should play more important role than encryption.
- - I'm encrypting now my files but I'm not implementing camouflage technique.
- - Should be applicable to HD, CD-rom, CD-RW, CD-R [ Iomega ZIP when possible ]
With the above preferences what I should implement to protect my privacy ?
Any other techniques should I use ?
=======
[EMAIL PROTECTED]
PGP key at http://www.mit.edu:8001/finger?[EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: N/A
iQCVAwUBOCICjASqer1ykwjnAQFCRgQA0FQkyUvzenUGHnieGenQue+pQuNm/ZmJ
UzOb2R84ViVEPSDOn7ivZR+1K3uBs3NuqUKGlIv+y0U3JxJInF2ops00hEToa/97
avQkC0nQaEpFKWjESFqXoHMT3ZFtgPlMDRWelXANNlo4wUgYhQK9owXla9zuzYSA
HHAipD+PTIg=
=05Ws
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Re: Compression: A ? for David Scott
Date: Thu, 04 Nov 1999 23:42:29 GMT
In article <[EMAIL PROTECTED]>, this news group unless otherwise
instructed! wrote:
>On Wed, 3 Nov 1999 16:04:26 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
>
>>Not random. Structured. (Assuming some expansion takes place).
>
>If we have structure, where does this structure come from? Is it
>inherent to the algorithm or is added in? It would have to inherent
>to the decompression algorithm and not added it because the attacker
>could use this to his advantage.
>
>Pardon me if this has already been answered, but I couldn't follow
>some of the other threads, it was just over my head.
>
The structure from a non one to one compresssion comes in from
the compressor. And it gives information to the attacker even when
a random file is being compressed.
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] (John Savard)
Subject: Re: Data Scrambling references
Date: Thu, 04 Nov 1999 23:06:26 GMT
"Larry Mackey" <[EMAIL PROTECTED]> wrote, in part:
>I have a project where we need to scramble (and unscramble) a parallel data
>stream such that when the data stream is serialized, the stream is a fairly
>symetrical set of ones and zeros.
>The data does not need to be compressed or encrypted rather we need to
>randomize the data on a bit level.
Well, modems do this by using a simple LFSR, and XORing the bit stream
with its output. This "scrambling", as it is called, prevents long
runs of 1s and 0s, it is hoped.
More elaborate techniques are used when the ratio of ones and zeroes
must be more strictly controlled. Thus, data written to disk drives is
coded using one or more forms of GCR (group-coded recording), a
technique whose name was introduced by IBM when it came out with its
6250bpi tape drives.
Using a 4 of 8 code to represent 6 bits in 8 bits, for example, one
could keep the number of zeroes and ones exactly equal within every
eight bits.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Ike R. Malony)
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Thu, 04 Nov 1999 23:23:53 GMT
pgp651 <[EMAIL PROTECTED]> wrote:
Oops! I was going to make a suggestion, but this is cross-posted to too
many groups.
--
"Ike R. Malony" better known as [EMAIL PROTECTED]
012 3 456789 <- Use this key to decode my email address.
Fun & Free - http://www.5X5poker.com/
------------------------------
From: [EMAIL PROTECTED] (Dr. Harley Mackenzie)
Subject: Re: The Code Book
Reply-To: [EMAIL PROTECTED]
Date: Thu, 04 Nov 1999 23:25:39 GMT
I dont suppose anyone would like to post or put on an FTP site any of the challenge's
text? I can't believe that the author
didnt put them on the challenge website.
Regards,
Harley
On Thu, 04 Nov 1999 14:19:54 +0000, Nigel Mercier <[EMAIL PROTECTED]> wrote:
>Has anyone tried "The Cipher Challenge" in "The Code Book" by Simon
>Singh? I know this will be beneath some of you guys, but I don't know
>where else to ask. If you can suggest a more appropriate group please
>let me know.
>
>I've cracked stages 1 and 2 (this has an interesting twist), but I'm
>stuck on stage 3: I don't understand how the homophones are included.
>I've noticed that the most frequent character is X (207) at twice the
>frequency of the next (Q, 103) which leads me to think that "X plus
>other characters" may be the homophones for some letters - leaving the *
>to represent another letter.
>
>Any ideas?
>
>--
>Nigel Mercier
>
>Please remove NOSPAM from my return address
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 05 Nov 1999 00:49:38 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> You pointed out wrong the sacriffcing of one token the all zero
>> token as an EOF symbol. This has repeatidly been shown to be wrong.
>> You do not get one to one compression by this method. In summary
>> how do you uncompress afile like
>> 11000000 00000000 00000000 10101010 assuming as shallow a tree
>> as possable. How do you uncompress in your method of your socalled
>> EOF token is embedded in a file. I don't think you get the point yet.
>
>If the tree is fairly shallow, this is indeed a problem for what
>I said. (I don't have have a record of what we discussed quite a
>time ago and don't remember every details. But isn't it that you
>assume for your algorithm that a certain particular number of 0's
>can't be the prefix of code symbols, which means that your tree has
>certain restrictions which one has to take care of?)
I think I worded the above poorly. By Shallow tree I meant the longest
path was not very long so that the ALL zero symbol which you want to
be used as EOF would have to be used.
We had long arguments I really don't want to go over them again. I hope
Tim and I get together to write a FAQ but. My tree for h2com.exe was such
that the longest path was all ZEROS and since fixed at 256 leages. that meant
the ALL ZERO SYMBOL was 8 or more in lenght. THere are more rules than
the summary here my site has the rules I used in h2com.exe it was because
of you that I took the trouble to look at my code and get the actually rules
in as short a form as possible. But sometimes when a symbol ends I truncare
the token sometimes when I am not truncating I had 1 to 7 zeros to fill the
bit out. But this is done in such a way that along with the other rules for
building the huffman table and such that you get a one to one mapping of every
binary 8bit byte type of file when compressed or decompressed to another
unique 8bit byte file.
Yes there was restrictions on the tree
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: Fri, 05 Nov 1999 01:02:24 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>On Thu, 04 Nov 1999 02:33:55 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>>>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.
>> I think your actaully Tommy St Dennis since you don't seem to understand
>>what is goin on. And seem not to actaully read the posts.
>>
>It's not a question of understanding, it's a question of believing any
>of it.
>
>> Again if you don't use o-o-o compression you open your self up
>>to cipher only attacks. Do you understand this point before we go
>>into other areas to explore.
>>
>The only cipher only attack that has been presented is a reduction in
>the set of possible output files from standard compression, which is a
>factor of the compression being non-perfect, not of it being non
>o-o-o, and of irreversibility, and this also isn't a function of it's
>being non o-o-o. Both give less information than a full known
>plaintext attack, which would be possible with the headers of many
>file formats. They may also give less information than the patterning
>still present from less than optimal compression, o-o-o or not.
>
>Again, this o-o-o concept is not generally accepted, nor has it been
>proven to be true.
That is where you are wrong. It actually is fairly obvious. Ask you
crypto GOD Mr BS or DW since I think it is a waste of time to write
you.
>
>If you were to claim that a compressor where y=Decompress(x), where x
>can be any file, I'd agree it could be of some advantage. That's true
>for o-o-o, but o-o-o isn't required.
Look suppuse a file is A is compress to B and then encrypted to C
the enemy is only looking at traffic but has the compression encyption
decryption and decompression code.
The attacker could ( though math reduction may be faster) test a key
he could take C the file he has access to and decrypt it with a test key
to get D. Then he tries to decompress D to E. lets assume that he
can do this if not the key is wrong. Know the attacker wants to know if
the E he has is the original file A. One quick check the attacker could
do is compress E to see if it goes back to D if does than E and A might
be the same file. But if D compresses to another file it could not have
been A.
Think a little Tommy before you anwser this.
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: Steve Sampson <[EMAIL PROTECTED]>
Subject: Re: Data Scrambling references
Date: Thu, 04 Nov 1999 18:30:28 -0600
Your right, the scrambler is hard to find in a web lookup.
Get the PDF file on this page. It shows the schematic and
has a description:
http://www.st.com/stonline/books/ascii/docs/1117.htm
Steve
Larry Mackey wrote:
>
> I am trying to find a scheme that encodes and decodes the data words in as
> uncomplicated manner as possible. This is presently a bi-directional path
> but we would like to be able to do this in a single direction only if
> possible. Since all the data in the stream needs to be randomized, the
> decoding procress information needs to be extracted from the data stream or
> decoding logic.
>
> Does anyone have any suggestions, pointers to references, thoughts or
> ideas??
------------------------------
From: slackjawyokel---* <[EMAIL PROTECTED]>
Subject: Re: D.J. Bernstein's Cryptography Lecture Notes
Date: Thu, 04 Nov 1999 18:33:07 -0500
As if I should have to justify my reasons for wanting to obtain these
notes. I simply want them out of curiosity-- i want to know to what
extent these notes are deemed so "dangerous" in the eyes of the
government. so please keep your ever so witty and clever comments to
yourself. as for you steve sampson, i've got a tough message for you
to decode:
!ffo ssip
think you can manage this one?
All apologies to the group for taking my hostilies out here. I just
would like these note if anyone has them...is that so wrong?
On Thu, 04 Nov 1999 03:46:23 -0600, Steve Sampson
<[EMAIL PROTECTED]> wrote:
>> i want these course notes because i
>> can't have them.
>
>Then you can show all your friends and be
>famous. They will bow in your presense...
------------------------------
** 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
******************************
