Cryptography-Digest Digest #209, Volume #10 Thu, 9 Sep 99 11:13:02 EDT
Contents:
Re: GnuPG 1.0 released (SCOTT19U.ZIP_GUY)
Re: some information theory (SCOTT19U.ZIP_GUY)
Re: "NSA have no objections to AES finalists" (Geoff Lane)
Re: "NSA have no objections to AES finalists" ([EMAIL PROTECTED])
Re: GnuPG 1.0 released (Charles Blair)
Re: THE NSAKEY (jerome)
Re: Beale (was: Mystery inc.) ("Douglas A. Gwyn")
DES and initial permutation (jerome)
Re: RC4 modifications (Paul Crowley)
DES and sbox 'middle bits' (jerome)
Re: Different Encryption Algorithms (Anton Stiglic)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: GnuPG 1.0 released
Date: Thu, 09 Sep 1999 13:50:51 GMT
In article <7r7fn9$7d0$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Matthew
Skala) wrote:
>In article <7r77c9$hmf$[EMAIL PROTECTED]>,
>Tom St Denis <[EMAIL PROTECTED]> wrote:
>>Second PGP source code is avail... why not check it yourself instead of
>
>The best you can do by checking the source code of PGP (or GnuPG, or any
>other product) is verify that it is a correct implementation of the
>algorithms it claims to implement. Mr. Scott's problem is on a higher
>level: he believes that the algorithms themselves are inherently insecure.
>So no amount of proof that the product implements them correctly, will
>convince him that the product is secure. That's perfectly reasonable,
>as far as it goes.
I feel that one is left with little chocie there are just not that many
public key methods and if they are broken we are in trouble. But we
really have no choice but to use them for a shared key. However I
do think that even in this area. There should be an option to use
several Public Key methods like (DH RSA and etc) where the session
key is the XOR of the output of the Public Key methods invovled.
I still think the chaining and quick key test are a bad feature and wish
or hope an option is created where user could turn these features off.
Since I am on a wish list it would be nice to have the option of using
previous information the formation of session key. That is once you
have recieved a message from A when you sent back your next
session key is that which was last sent XORed with the random ones
generated by the Public key. That way at least you have the option
that if you fear Public Key is weak you can at least know that the
enemy would have to get all your message in order. You could even
send a message on a floppy through UPS at some point if you feel
security is comprimissed. But then again I am more concerned about
security than the average proggramer.
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: some information theory
Date: Thu, 09 Sep 1999 14:20:14 GMT
In article <[EMAIL PROTECTED]>, Anti-Spam
<[EMAIL PROTECTED]> wrote:
First of all let me say Nice article but a few mistakes.
>
>I've followed these thread debates on encryption vs. compression for
>months without saying anything. Now it's time to speak.
>
>This is a long post, so here's the summary and then read all below it to
>see how I back up this statement:
>
>Compression with huffman-encoding type schemes is identical to a
>substition encipherment.
>The relative order of SYMBOLS as ENCODED in the uncompressed data/file
>with ASCII, UNICODE or any other binary representation is PRESERVED by
>the compression and appears intact in the compressed data/file. Each
>SYMBOL is ENCODED with a shorter bit string in the compressed file/data,
>but the SYMBOLS still appear in the same frequency and order as they did
>in the original uncompressed data/file. Compression is just the encoding
>of the SYMBOLS with the least number of bits (ie. as close as possible
>to a Maximal Entropy Code.)
>
>Compression PRESERVES the TOPOLOGY of the SYMBOLS as ordered elements in
>a finite set. SYMBOLS in positions 1, 2, 3...i, j, k... n in an n
>symbol long message that are neighbors, encoded in the uncompressed
>data/file, are still neighbors, encoded in the compressed data/file.
>
>Compressing data/files prior to encryption with a cipher system does not
>alter the frequency of the SYMBOLS encoded in the compressed data/file
>relative to their original frequencies in the uncompressed file/data.
>Compressing prior to encrypting does not permutate the order of the
>SYMBOLS encoded in the compressed data/file relative to their original
>order as encoded in the uncompressed file/data. Compression only alters
>the encoding of the SYMBOLS to achieve the maximal entropy possible as a
>function of the probabilites of the SYMBOLS themselves.
>
>So yes, Tom, you are on the right track. This arguement can be extended
>to other compression schemes (in fact , its a good idea for a paper.)
>
>Now down to the nitty gritty:
>
A lot of what you say is a function of the file that is compressed
for exmple you take a random file that passes the DIEHARD tests
or those below. You then uncompress that file. I give it to you
the file I am giving you is much long than the compressed file.
It fails most of not all the tests you have stated. But when you
compress it. It passes all the tests.
>First, Compressed data is NOT necessarily random data. Many of us assume
>the compressed form of a file is "equivalent" in some form to true
>random data. It is not. Compressed files will not pass statistical
>tests for random bit streams. A compressed file is non-random. Say the
>compressed file is n bits long. Apply the five basic tests for
>randomness to that binary sequence ( see Handbook of Applied
>Cryptography, Section 5.4.4).
>
>1. The Frequency Test ( or mono-bit test) - do 1s and 0s occur in the
>same total number (with some margin of difference based on the
>Chi-Square test.) A compressed file SHOULD pass this test.
>
>2. The Serial Test ( two-bit test) - do the patterns 00, 01, 10 and 11
>occur with the same frequency? Here we see a good chance that the
>compressed file should not pass this test, espcially if we use Huffman
>Encoding or Variable Huffman encoding.
>
>
>3. The Poker Test ( a generalization of the Frequency test )- looks for
>the number of occurances of k bit sequences ( such as 010, or 0110, or
>001, or 1000101, etc..) in the m bit sequence. (See ref. Handbook for
>exact details ) Again, compressed data should not pass this test.
>
>4. The Runs Test - looks at the number of runs of 0s (gaps)of various
>lengths (example 00, 000, 0000, etc.) and 1s (blocks)(example 11, 111,
>1111, 11111, etc.) that appear in the candidate random data verses the
>expected number of gaps and blocks of various sizes that should appear
>in random data ( with some margin of difference based on the Chi-Square
>test.)
>A compressed file should not pass this test.
>
>5. The Autocorrelation test - look for correlations between sequences of
>bits in the candidate random data with itself in non-cyclic shifts. A
>compressed file should exhibit correlations far larger than those
>expected for random bits.
>
>Why should a compressed file fail four out of five of these tests?
>
>Compression schemes like Huffman Coding,Shannon-Fano Coding do the
>following:
>
>Look the set of symbols in the file or data before compression ( or the
>"alphabet" of symbols in the data.) These symbols are strings of bits
>(0s and 1s) that appear many times in the data. Many times we use ASCII
>or UNICODE characters of fixed bit lengths. Determine the total number
>of all symbols in the file or data. Call it k. Determine each unique
>symbol's probability of occurance in the data by its frequency (unique
>symbol count/total number of symbols).
>
>Now, using the probability of occurance for each defined symbol from
>above, define a new encoding for that symbol. These new encodings are
>binary strings but they are not necessarily the same length as the
>binary strings representing the symbols in the original data or file.
>No two new encodings will be the same binary string. Each new encoding
>string shall be constructed such that no additional information is
>necessary to identify where that encoding starts or ends when it is
>written before or after another encoding string for a different symbol.
>Keep a dictionary that maps the correspondance between the original
>symbol and its binary representation in the original file or data and
>its new encoding bit string in the compressed file or data.
>
>The net result is that if you order the symbols by their probabilites,
>p1 >= p2 >= p3 >= p4... >= pk , the lengths of the binary strings of 1s
>and 0s for the new encodings for the symbols are in a similar order but
>decreasing in magnitude, L1 <= L2 <= L3 <= L4 ... <= Lk. Now these new
>encoding bit strings for the symbols should be less than (or equal) to
>the bit lengths of the encoding for the original symbols. If some are
>less than the original symbols' encoding bit lengths we WILL get
>compression. Huffman and Shannon-Fano algorithms use a binary tree
>algorithm to establish the 1/0 bit string representations for the
>symbols as a function of frequency. Usually these encodings use equal
>numbers of 1s and 0s. (they occur with equal frequency)
>
>We now take the original data or file and REPLACE the encoding of the
>symbols as appeared in the original data or file with these new encoding
>strings (which are different than the original bit strings for those
>symbols.) If the new encodings are shorter in bit length than the
>original encodings for the symbols we get smaller (less bits) data or
>files.
>
>There is a one-to-one correspondance between the occurances of the
>symbols (as encoded in ASCII or UNICODE for example) in the original
>data or file and the occurances of these same symbols in their new
>encoding for compression. THIS IS AN IMPORTANT POINT. We have
>substituted different encodings for those symbols in the compressed data
>or file. That is all we have done. We do not alter the relative
>positions of the symbols. There is no shuffling, no rearrangement of
>symbols occurances spatially in the data/file.
>
>At best what we have done can be called a "substitution encipherment"
>from a cryptological point of view but nothing more than that. If we had
>36 e's in the original uncompressed file, and e was encoded in ASCII, in
>the compressed file we now have 36 occurances of a new encoding string
>for e (say its 001) that is less than the ASCII bit encoding bit
>length. The relative order of symbols as they occurred in the
>uncompressed data/file IS PRESERVED BY COMPRESSION in the compressed
>data/file. The new encodings appear many times in the compressed
>data/file, and in the same frequency as the SYMBOLS for which they stand
>as those SYMBOLS appeared in the uncompressed data/file.
>
>This is necessary for the decompression to work! If the ordering of
>symbols is not preserved then decompression back to the original
>encoding in the uncompressed file/data will not return the original
>data/file. Decompression is just the recognition of the smaller
>encoding strings in the compressed data/file for replacement with the
>corresponding longer, original binary represenation for that symbol.
>That original represenation is in the dictionary for the compressed file
>generated during the compression (and must accompany the compressed
>file/data in an uncompressed form to ensure the decompression can occur
>- or be available at the time of decompression if sent by other means.)
>
>Tnis is why compressed data/files will/should fail the Serial test,
>Poker Test, Runs test and Autocorrelation tests for true randomness. The
>only cryptoanalytic challenge posed by compression is the cryptanalysis
>of a substitution cipher. The SYMBOLS that appeared in the uncompressed
>file/data are encoded with different codes in the compressed file/data.
>That's at most a substitution cipher. If we have only the compressed
>data/file, we can "attack" it as a substitution cipher.
>
>What makes this more of a challenge is the definition of those SYMBOLS.
>If the symbols are ASCII or UNICODE then I could apply language models
>in the "cryptanalysis" of the compressed data to identify probable
>compressed encodings for e, i, th, etc. If I just select every k bits
>as the occurance of a symbol, then the set of unique k bit values that I
>find (if much smaller than 2^k in number ) serves as my "alphabet" and I
>encode them with new codes that are less than k bits long to get
>compression. Here there are no language models to help me analyize the
>compressed data/file to try to determine the compression encoding. But,
>if I know what k is and I know something about the nature of what was
>compressed then I can use other examples of that compressed data/file to
>try to put together reasonable estimates of a dictionary to use in
>substitution cryptanalysis, and I can try autocorrelation tests on the
>compressed data to spot the compression encoding strings (which will
>repeat in the compressed data/file and thus will autocorrelate.)
>
>
>For those more mathematically inclined ( I think of rosi as I write
>this), Compression preserves the TOPOLOGY of SYMBOLS as they appear in
>relative order (neighbor to neighbor) and frequency in the uncompressed
>data/file. That preserved topology is a doorway to analytical attack.
>
>For example, let's say this is the message in SYMBOLS:
>
>T H E M E S S.......
>
>when encoded before compression, in binary,
>
>001001 101011 001001 110111 001001 101010 101010
>
>But, when compressed, T now is encoded as 0111, H as 0011, E as 01, S as
>10101, M as 1001...
>(just examples, didn't do the math for the encoding.....)
>
>0111 0011 01 1001 01 10101 10101
>
>We see the bit length of the message is shrinking with the new encoding,
>but note the occurances of the new codes follows the relative ordering
>of the occurances of the uncompressed code. An e no matter how encoded
>still follows the H no matter how encoded. A T starts the message, no
>matter how encoded. We can define a point-set topology on the SYMBOLS
>as they occur in the original message, and we can show that this
>point-set topology is preserved by the compression.
>
>Just my two cents,
>
>[EMAIL PROTECTED]
One major flaw in your method. Yes the symbols occur at the same rate and in
the same relative positions in the file durring Huffman Compression. But there
is one major difference that you failed to point out. IN the uncompressed file
a symbol has only one coding. That is the ascii code for a D will be the same
in the front of the file as in the back of the file. In adaptive huffman
coding that is not true. Since it is constantly changing the Huffman tree.
Most of your statisics is valid for only code that was compressed with
a static huffman table. But then you would have to know a little more about
huffman coding. One other point in useing adaptive huffman compression
you can always reasign not just the weights put you can choose focusing
or basising so that the way zero one is assinged as you go down the tree
can change with each new character that is read in the file. What this means
is that if you have a string of the same character you don't have to use the
same symbol each time even if that character makes up 90% of the input
file. The focused code is not at my site yet but I am playing with it.
Also if you look at my site. I tell people up front that if the use weak AES
types of methods that it may be best to run 2 compressions through the
file one in forward direction and one in the reverse direction. This is so
a user can approach "the all or nothing" propery that is so important
in secure encryption.
Tell me oh great one. Is there a nice relationship in this file to the
original file. I don' think so. Take a look. ALso you never
commented on weather one should use a "one to one" huffman
compression. You did not talke about the file ending problem.
compression page at http://members.xoom.com/compress.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] (Geoff Lane)
Subject: Re: "NSA have no objections to AES finalists"
Date: Thu, 9 Sep 1999 13:31:08 +0100
In article <7r78vh$93h$[EMAIL PROTECTED]>,
"rosi" <[EMAIL PROTECTED]> writes:
> "You wouldn't like it if one of your kids were kidnapped and
> we couldn't wiretap," Landau said Kallstrom told her.
"What do you mean you don't have a phone - how can we wiretap?"
--
Geoff. Lane. Manchester Computing
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: "NSA have no objections to AES finalists"
Date: Thu, 09 Sep 1999 14:14:48 GMT
In article <7r7c57$2k5g$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <[EMAIL PROTECTED]>, David Crick
<[EMAIL PROTECTED]> wrote:
> >For what it's worth....
> >
> >"On Friday, a source close to the NSA told Wired News that --
> > at the Commerce Department's request -- the agency reviewed
> > the five and decided it had no objections to any of them.
> >
> > [Carl] Ellison said there's one very good reason for the
> > NSA to be telling the truth about the ciphers' security:
> > The government will be using it, too."
> >
> > http://www.wired.com/news/news/business/story/21484.html
> >
>
> Oh really I thought AES was for unclassifed data. Is the US going to
use AES
> for "top secrect" data. HELL NO THAT is BULL SHIT. And only a fool
would think
> the NSA would give an honest anwser to anything about encryption.
Good lord David. You are so paranoid and eager to attack anything
related to the AES that you are reading stuff into plainly written
statements. It says absolutely nothing about the government using
AES for classified data.
Marc
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Charles Blair)
Subject: Re: GnuPG 1.0 released
Date: 9 Sep 1999 14:38:10 GMT
GnuPG says they don't have any patent problems. Did they get
permissions from McAfee, RSA, PGP partners, etc, or have the patents
in question expired?
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: Re: THE NSAKEY
Date: 9 Sep 1999 14:37:09 GMT
Reply-To: [EMAIL PROTECTED]
first let me repeat i don't take position in this debat. im not your enemy.
im personnaly very gratefull to b.scheiner for his book
'applied cryptography' and his effort to make a lot of
articles available on his web site. I don't know d.wagner
by except by a few papers and fact that people who worked with
him think he's smart.
>No 'he WORKED' (pass tense) for Bruce is what he said. In any rate, this is
>really none of our concern. Do I ask where you worked last week and for
>whom? Not really.
he's currently listed an a part of the personnel and by the way, it is
you who bring their relation on topic (see below).
i just wanted to be sure that everybody knew this publicly known fact
and thus being able to have a more knowledgable opinion.
>You might not believe this but David Wagner is a smart, talented person. He
>is not 'attached' to Bruce as you might think, he has done work with Rivest
>and others as well. I think this thread is way out of line.
d.wagner knows b.scheiner but it doesnt imply he will have the same
opinions about everything nor he will disagree just to show he's
independant.
moreover both are known as cryptographers but as far as i know don't
work for the NSA so i don't think they -know- if it is a backdoor
or not. The only thing they can do is to do suppositions.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Beale (was: Mystery inc.)
Date: Thu, 9 Sep 1999 14:25:47 GMT
Jim Gillogly wrote:
> In fact, there are four alphabetic sequences, as I detailed in another
> message in this thread. Their lengths, using John King's DOI which
> was adjusted to match Beale #2 without trying to optimize Beale #1,
> are 10, 11, 5, and 17 letters. The last one is 20 letters long if you
> grant an off-by-one.
Okay, I missed that. That is somewhat more suggestive of a hoax...
> Even without King's adjustments the longest one is 14 letters:
> DEFGHIIJKLMMNO.
... but that's not a contiguous alphabetic sequence! It is somewhat
consistent with the idea of a bored hoaxer losing track of which
letter he had just encrypted (making them up "on the fly", i.e.
nonexistence of an actual plaintext document of any sort).
> Any credible explanation of the Beale ciphers must have a credible
> explanation of these strings. Carl Hammer agreed that they were
> causal, but suggested that they might be a clue to the decryptor
> that he was on the right track, and that there was still a treasure
> at the end of the rainbow. This seems pretty lame, ...
I would say it is exceedingly lame. As you say, if the Beale
story is valid, this was not meant as a puzzle, but as hidden
information that could readily be deciphered when one had the
right key.
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: DES and initial permutation
Date: 9 Sep 1999 14:47:04 GMT
Reply-To: [EMAIL PROTECTED]
i try to understand the aim of the initial permutation in DES. several
sources said that there is no cryptanalisys influence.
But DES has been designed by knowledgeable people and i dont think
they will add a component without explicit reasons.
anyone know what is the aim of this initial permutation ?
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: RC4 modifications
Date: 9 Sep 1999 08:08:35 +0100
I recommend against both of the modifications you propose. A better
way to mix the key in more thoroughly is to discard the first 256
bytes of the RC4 key stream after key scheduling.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (jerome)
Subject: DES and sbox 'middle bits'
Date: 9 Sep 1999 14:58:15 GMT
Reply-To: [EMAIL PROTECTED]
there are the published design rules for the sbox generation of DES.
2 of them are about the 'middle bits' (bits 2 and 3 set in 001100).
i see how special are the most significant and the least significant
bits because they are duplicated with the expansion.
but what is the big deal with the 'middle bits' ?
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Different Encryption Algorithms
Date: Thu, 09 Sep 1999 10:08:30 -0400
"SCOTT19U.ZIP_GUY" wrote:
> In article <[EMAIL PROTECTED]>, Hideo Shimizu
><[EMAIL PROTECTED]> wrote:
> >> http://security.nsj.co.jp/products/cstv6/benchmark.html
> >
> >This page have no information about what platform does benchmark execute.
> >I don't see what does it mean by KB/s.
> >Do you have any information?
> >
> >Hideo Shimizu
> >TAO, Japan
>
> I can't read most of the fonts even in raw form with my web browser. I don't
> think much thought was put in site at all. If they ever make it so most
> browers can read it let me know?
It has some javascript thing with some special kind of files. With my Netscape
communicator 4.61 I have no problems.
------------------------------
** 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
******************************
