Cryptography-Digest Digest #85, Volume #10 Fri, 20 Aug 99 16:13:02 EDT
Contents:
Re: Angewandte Kryptographie von Bruce Schneier (SCOTT19U.ZIP_GUY)
Re: bias of boolean expressions (Medical Electronics Lab)
Is this old? :-) (JPeschel)
Re: NIST AES FInalists are.... ([EMAIL PROTECTED])
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: DoD & ITU under attack ? (SCOTT19U.ZIP_GUY)
Twofish on a 68HC11 (David SAMYDE)
Re: compress then encrypt? (Anton Stiglic)
Re: Is this old? :-) (John Savard)
Re: I HOPE AM WRONG (SCOTT19U.ZIP_GUY)
Re: Challenge: mental authentication (Asher)
Re: compress then encrypt? (John Savard)
Re: New encryption algorithm (SCOTT19U.ZIP_GUY)
Re: NIST AES FInalists are.... (SCOTT19U.ZIP_GUY)
Re: DoD & ITU under attack ? (Doug Stell)
Re: New encryption algorithm (SCOTT19U.ZIP_GUY)
Re: Is this old? :-) (JPeschel)
Re: I need strongest weak elliptic curve... (Medical Electronics Lab)
Human-Readable Encryption (Newbie)
Re: compress then encrypt? (SCOTT19U.ZIP_GUY)
Re: Where to find (David Hamilton)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Angewandte Kryptographie von Bruce Schneier
Date: Fri, 20 Aug 1999 18:57:44 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Buchinger Reinhold wrote:
>> Ich w�rde dringend das Buch "Angewandte Kryptographie. Protokolle,
>> Algorithmen und Sourcecode in C." von Bruce Schneier (ISBN: 3893198547)
>> ben�tigen. Da es aber nicht gerade billig ist, w�rde ich mir es zuerst gerne
>> ausleihen. Nur leider wei� ich nicht ob und wo das in �sterreich (Wien)
>> m�glich ist.
>> Falls jemand das Buch besitzt und nicht mehr ben�tigt, w�rde ich es auch
>> gerne zu einem fairen Preis kaufen.
>> Vielen Dank f�r Hinweise schon im Voraus !
>
>No being fluent in German, I ran the above through www.systransoft.com's
>automatic translator and came up with this amusing result:
> I became urgently the book " applied cryptography. Logs, algorithms
> and SOURCE code in C." of Bruce Schneier (ISBN: 3893198547) need.
> Since it is cheap however not even, I became it first gladly
> check-out counters. Only unfortunately white I not whether and
> where in Austria (Vienna) is possible. If someone possesses the
> book and no more necessarily, I would buy it also gladly at a fair
> price. Thank you for notes already in advance!
Seems straght forward to me. It even has commas so what is your problem.
think about the porr bastadrs that try to trsnalate my text from enlish to
whatever the hec they use.
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: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: bias of boolean expressions
Date: Fri, 20 Aug 1999 13:13:01 -0500
Tom St Denis wrote:
>
> What is the generic algorithm to find the bias towards 0 (or 1) in an
> expression?
>
> Can we use F(a,b,c) = ((a and b) or (a and c) or (b and c)) as an
> example? (or just ((a or b) and c)) ...
You need to count up the number of 0 bits or 1 bits and the total
number of bits. Bias is then 1/2 - [count of 0's]/[total count].
If you get 0 exactly, there's no bias. In general, you'd expect
sqrt(total count) deviation in your count of 0's. So do lots
of trial runs, and average your bias measurements over all the
trials.
If you know the function F, then you can track each bit position.
Do the same thing algebraicly as the above description with each
bit, and sum all the bit position results.
That's pretty generic, but it may not be so simple to actually
implement!
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Is this old? :-)
Date: 20 Aug 1999 18:16:39 GMT
http://www.theonion.com/onion3311/microsoftpatents.html
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: NIST AES FInalists are....
Date: Fri, 20 Aug 1999 18:09:50 GMT
Douglas A. Gwyn wrote:
> [EMAIL PROTECTED] wrote:
> > A number of people who post here have, or previously
> > had, security clearances.
>
> I have of course never posted information about any
> clearances I may have or not have. People who need
> to know that have ways to check up on it.
And neither have I. Why exactly did you point out
your employer and location? Why did you invite people
to draw conclusions from that?
> > To lie you'd actually have to say something.
>
> What I have said, which you contradicted, is that I
> have a basis for judging whether Agency cryptanalysts
> have an edge over outside cryptographers;
You have said everything I quoted you as saying.
> there are
> several ways I could have obtained such information,
> and I am not obliged to disclose them to you.
I agree you are under no obligation to justify
your claims. But when you post "security rules
(OPSEC etc.) prohibit me from providing details,"
of course people are going to point out what
nonsense that is. You can't post conclusions
drawn from classified information.
> There
> have been posts by other people making reasonable
> arguments that agree with what I said on this topic.
That's exactly what I thought you were doing - drawing
your conclusions from the same rumors and speculation
as everyone else.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Fri, 20 Aug 1999 19:09:33 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>SCOTT19U.ZIP_GUY wrote:
>>
>> First of all the proof is in the working program. Find an example
>> od where a file that when being decompressed and then compressed
>> again does not back to the same and you haev found a error
>>
>> the file ... xxxxxxxy yyyyyyyy would decompress to what I guess
>> you want.
>> the file xxxxxxxxy and the last byte gone would decompress to
>> something different. But when you compress the file you got from
>> decompressing you get a file that ends with xxxxxxxy
>
>But you can't decompress according to the Huffman scheme, because
>suppose this first y following x is, say, 0, then, since 0 followed
>by 8 bits is a valid Huffman code, 0 alone can't be a valid huffman
>code (this follows from the principle of construction of the
>Huffman tree). This proves that the algorithm after finishing the x's
>and finding the first y (here 0) can't do anything anymore. Isn't that
>clear?
It is clear to me you have a very closed mind. What is being done
is a "mod" to handle the fact that huffman compression may end on
a non byte boundary. I handle the mode such that sometimes the
last byte is left alone. Sometimes zeros are added. Sometimes it is
deleted. The mode is such that there are no incconsisties. Every file
as a "unique expansion" and every file has a "unique compression".
But since this is over your head you sit and argue. WHY DON'T you
test it. IT WORKS. just because you can't seem to expand on the
concept in your limited way of thinking does not mean it is not
being done. As I feared I am going out of my way to help you. At least
this time it is on this forum. Instead of email. I do have one question
have you ever been a member of MENSA?. I was for a while since I worked
for a boss who thought it was hot shit. Pissed him off when they allowed
a beer drunking asshole like me in.
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: DoD & ITU under attack ?
Date: Fri, 20 Aug 1999 19:14:04 GMT
In article <[EMAIL PROTECTED]>, Paul Koning <[EMAIL PROTECTED]> wrote:
>Medical Electronics Lab wrote:
>>
>> Padgett 0sirius wrote:
>> >...
>> > Recently pressure is being put on the ITU to relax this requirement and
>> > permit on-line servers which hold user's private keys. I suspect this
>> > pressure is from vendors whose products require online KMS machines.
>> >
>> > Given the current state of COTS servers, I feel this would be a
>> > serious mistake and that key generation should always be done either
> offline
>> > or by a machine on an MLS protected subnet behind an evaluated guard.
>> >...
>>
>> Why use systems which require holding user's private keys? Change
>> the requirements so that no private keys are held anywhere, let the
>> user regenerate it each time. You _could_ escrow the keys with a
>> CA key, but that too should be off line.
>>
>> Anything that holds user's private keys and is accessable to the
>> net will be attacked.
>
>I agree.
>
>Having private keys held by third parties is a Bad Idea.
>Having those third parties keep the keys on-line is an ABSURD idea.
>Especially given that most machines run MS software, which was never
>designed with even the slightest concept of security anywhere.
>
> paul
I am sure that for a few bucks from the NSA MS would be willing
to design the security standards that law enforement personnel would
consider to be adaquit. Of course that what I get a machine with Lunix
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: David SAMYDE <[EMAIL PROTECTED]>
Subject: Twofish on a 68HC11
Date: Fri, 20 Aug 1999 20:31:11 +0200
Hello,
I'd like to know if anybody has got
Twofish on a 68HC11.
Thanks in advance.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: compress then encrypt?
Date: Fri, 20 Aug 1999 13:54:31 -0400
One think that I have asked myself is, if you have a perfect coder,
that
takes away all redundancy, isn't the entropy of the message smaller, and
thus, decryption harder? Can someone back up or refute this claim?
Anton
Tom St Denis wrote:
> Ok other then
>
> 1. Making the message smaller
> 2. Making the plaintext harder to guess (but not impossible with
> several adjacent blocks).
>
> What are the clear benefits of compression before encryption?
>
> I am led to believe by DS that you can only use his 'adaptive huffman'
> coder (although zlib as he flames, is adaptive)...
>
> Any thoughts?
>
> Tom
> --
> PGP 6.5.1 Key
> http://mypage.goplay.com/tomstdenis/key.pgp
> PGP 2.6.2 Key
> http://mypage.goplay.com/tomstdenis/key_rsa.pgp
>
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Is this old? :-)
Date: Fri, 20 Aug 1999 18:47:51 GMT
[EMAIL PROTECTED] (JPeschel) wrote, in part:
>http://www.theonion.com/onion3311/microsoftpatents.html
Yes, at least a year old...
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: I HOPE AM WRONG
Date: Fri, 20 Aug 1999 19:31:13 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Greg wrote:
>> I suppose you are correct. I suppose the fact that he used words
>> like sucks, crap, and bullshit, ...
>
>So do other posters, they're just not usually as blatant.
>
>> I wonder where I can go to a "professional" forum where people like
>> David are not welcomed and are denied access. Do you know of any?
>
>sci.crypt.moderated is a moderated newsgroup for discussions
>relevant to cryptologic research. It doesn't get much traffic,
>other than announcements for meetings, etc.
Actually I have tried several times to write to sci.crypt.research hope
i spelled the site write. Any way the moderators don't like me there
so that is a "good" group. I think they feel the class of english is of the
most inportance. When Mac came up with X8 he published there as an
improvemetn to scott16. Then he had a few other suggestions to prevent
the Onions attack. But we went in different directions. I choose the Paul
function and with the shifting of each round not just the odd lenght ones.
Some one came up with a new attack that affected some of his vertions
but not sure the mod witht the round keys was attacked. His approach
is based on scott16 But like I said he chose a different forms of protection
for plain text attacks. And I think he always stayed with 8 bit versions
A regular poster Hopwood had info on all this I think. Any way I still owe
him a beer.
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] (Asher)
Subject: Re: Challenge: mental authentication
Reply-To: [EMAIL PROTECTED]
Date: Fri, 20 Aug 1999 18:44:07 GMT
It seems that the entropy of the user's input should be very small compared to
the entropy of his memorized key. That means it would take a lot of observed
sessions to reconstruct the key.
Also, it seems that diffusion is needed - this means the challenge/response
must proceed on a bulk, not interactive basis. That way, the observer can't
tell what part of the stimulus caused what part of the response.
Ok, how about this?
The user knows a string of digits {1-9}. Example: 9218578. He also knows a
starting position. Example: third row, fourth digit.
He sees this on the terminal:
789
456
123
0638074488
0260772203
7402142230
4468376736
7384372603
0881116430
4752780563
2472020280
6006217851
0105374442
The first group of digits is just a numeric keypad - a navigation reminder.
The second group (which should be larger in practice) is a randomly generated
block of digits.
The user starts at his starting position, containing digit '2'. He mentally
adds this to 9, the first password digit, yielding 11. Using the least
significant digit as a navigation guide, he 'moves' southwest, since 1
corresponds to the southwest key on the keypad.
Now he adds 6 (from the random digits) and 2 (from the password) to 11,
yielding 19. 9 means northeast, so 19+2+1=22. And then:
22+8+8=38
38+2+5=45 # 5 means stay on this square
45+2+7=54
54+0+8=62
So the user types 62 on the terminal. I think we gain strength from
aggregating the user's responses into one number, rather than typing them
as he goes. In consequence, the keyspace of the typed input is alarmingly
small - about 7 bits. Several things could be done to increase the amount of
entropy leaked from the traversal process, but of course this helps the
attacker eliminate invalid passwords.
>From a cracking standpoint, the password contains about 22 bits of entropy.
With the starting position, it increases to roughly 28 bits. To be secure,
the string would have to be painfully long. On the other hand, how many
sessions would you have to observe to unambiguously identify the password?
This is probably a bad technique, but it points to the abilities of humans as
state machines - e.g. playing blindfold chess.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: compress then encrypt?
Date: Fri, 20 Aug 1999 18:41:47 GMT
Anton Stiglic <[EMAIL PROTECTED]> wrote, in part:
>One think that I have asked myself is, if you have a perfect coder,
>that
>takes away all redundancy, isn't the entropy of the message smaller, and
>thus, decryption harder? Can someone back up or refute this claim?
A perfect one makes decryption impossible - subject to certain
conditions and restrictions. One would still be able, through
decryption, to limit the set of possible messages.
Redundancy is the basis of a ciphertext-only attack on a message. It
is as vital to the process as handholds and footholds are to climbing
a mountain. Without information on the plaintext input to a ciphering
process, there is no knowledge of what to look for, no constraint on
the manipulation that produced the ciphertext.
But a known-plaintext attack is not affected at all, since knowing
that a plaintext is "XqW@Bn*33" is just as good as knowing it is
"Hello There!".
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: New encryption algorithm
Date: Fri, 20 Aug 1999 19:41:45 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> Also I have afeeling that they would not publish my stuff
>
>So long as it was an interesting article, they would.
>I know some of the editorial and publishing staff of
>such magazines personally, and none of them strike me
>as likely to bow to pressure to suppress lawful articles.
>
>I think the main obstacle in your case would be in
>getting help in editorial/typographic matters and in
>resisting the urge to give a "soapbox" speech. So it
>might be best to assist somebody else who does the bulk
>of the writing.
I really don't need more than a page of writting with just a few
examples of how to use it. The bulk of the article would just be
the source code. Ask you buddies see if they would publish it.
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: NIST AES FInalists are....
Date: Fri, 20 Aug 1999 19:57:54 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:
>[EMAIL PROTECTED] (David Wagner) wrote, in part:
>
>>To put it another way, I think my argument will have to stand or fall on
>>the claim that analysis of AES block ciphers is largely orthogonal to analysis
>>of real-world COMSEC systems. (One justification for this is that attacks
>>on real-world systems never seem to attack the block cipher.)
>
>Although the NSA may excel by a greater margin in the area of
>attacking real-world COMSEC systems than it does in the area of
>attacking block ciphers,
>
>and - being the naive soul that I am - I would think that the ciphers
>used by foreign military and diplomatic users would not be as highly
>optimized as DES or the AES candidates, but would make use of things
>like large, key-dependent S-boxes (even if they don't _quite_ go to
>the lengths recommended by you-know-who), which means the NSA may well
>have little opportunity to actually obtain intelligence by means of
>solving block ciphers,
Actaully they may by hardware from the Swiss that is already "fixed"
see my site for pointer to article on that topic. And it is more likely that
a method with many reversable operations would be used. Then a simple
but effective S-box type of design. Since those in power seem to be more
impressed by what looks complicated in there eyes than what is secure.
I think it would be easier to sell an inferior small key desing than a real
secure system to a third world country. Just like management they would
be impressed by the interface the GUI interface. And then give some phony
balonely proof as to why its is the best and then they would not be smart
enough to know that it is bad. Also since it is in the interest of our
government to read every thing we may secretly be controlling there selection
of crypto. We may try through open government channels and through back
door means with the CIA. So wether they take in the front door or back door
they will have the same weak crap and not know it.
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] (Doug Stell)
Subject: Re: DoD & ITU under attack ?
Date: Fri, 20 Aug 1999 18:48:42 GMT
On Fri, 20 Aug 1999 11:40:03 -0400, Paul Koning <[EMAIL PROTECTED]>
wrote:
>Having private keys held by third parties is a Bad Idea.
Not always. For encryption keys and data recovery purposes when the
data is owned by the corporation in which you work, it has it
purposes. Suppose your private key is lost or corrupted or you are hit
by a truck, it would be nice if life went on for the corporation.
For signature keys, it is always a bad idea and is usually forbidden.
For encryption keys and private use, it depends on which side of the
fence you are on. Law enforcement is likely to take the opposite view
of the criminal, with both views being valid.
>Having those third parties keep the keys on-line is an ABSURD idea.
Very true. Having worked on CAs that do store encryption keys, I can
tell you that the level of protection on those keys must be
significant. At the least, they should be superencrypted, under
multi-person control and subject to tamper-proof auditing.
doug
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: New encryption algorithm
Date: Fri, 20 Aug 1999 19:46:14 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> I am not declinging but still want the apology first.
>
>You must realize that that is not likely to happen,
>especially if your theories about those people are true,
>because they would then would be helping you to get your
>ideas published.
Of course I'm right. And I don't expect an honest
apology from ether one.
>
>So it sounds very much like a rationalization for not
>making the attempt to publish your method in a form
>that can be widely understood and, yes, criticized.
Actually it is in a fom that can be understood. I think
over all horst did a good job. By the way have not heard from
him lately he was going to mod the write up. I hope he is not dead.
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] (JPeschel)
Subject: Re: Is this old? :-)
Date: 20 Aug 1999 19:23:18 GMT
[EMAIL PROTECTED] (John Savard) writes:
>[EMAIL PROTECTED] (JPeschel) wrote, in part:
>
>>http://www.theonion.com/onion3311/microsoftpatents.html
>
>Yes, at least a year old...
Oh, well -- it might be amusing to some who haven't seen it.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: I need strongest weak elliptic curve...
Date: Thu, 19 Aug 1999 12:27:02 -0500
David A Molnar wrote:
> I think you need a license technically no matter what kind of encryption
> you use. It's just that this need is overlooked for "trivial" stuff. You
> may be thinking of the fact that getting an export license is supposed to
> be "easy" for certain bit-lengths of symmetric and asymmetric ciphers. (I
> haven't tried it myself). Some info can probably be found at
> http://bxa.doc.gov .
But what about Wassner? That says any free code has no restrictions.
If he's giving it away, then an export license isn't needed. Only
code sold for money needs a license.
As long as the code is free (like a demo) you can use any strength
you want. If it's shareware, and you send a floppy outside the US,
you'll need an export license. Even if you send some kind of auth
code which turns on the full version of the demo you'd need a
license to send the auth code.
Greg, a good demo size would be a 148 bit Koblitz curve. It's
"reasonably" strong, but equivelent to only 70 bits of a symmetric
cipher. If you actually find customers outside the US, it will
be worth it to have someone rewrite your code so it can be sold
from outside the US. Then you can sell to the US market and they
can sell to everyone else.
Patience, persistence, truth,
Dr. mike
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Human-Readable Encryption (Newbie)
Date: Fri, 20 Aug 1999 15:19:17 -0400
I am looking for algorthims (even a weak cipher will do nicely) that will
encrypt a message into a human-readble encrypted form. Specifically I would
like to specify a resulting numeric range that could correspond to the ASCII
character set (e.g. ASCII 32-126, or {space} through {~}). I would also
like to be able to decrypt (is this implied?).
Thanks for any help you can provide!
Jeff Kanel
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: compress then encrypt?
Date: Fri, 20 Aug 1999 20:26:50 GMT
In article <[EMAIL PROTECTED]>, Anton Stiglic <[EMAIL PROTECTED]> wrote:
>One think that I have asked myself is, if you have a perfect coder,
>that
>takes away all redundancy, isn't the entropy of the message smaller, and
>thus, decryption harder? Can someone back up or refute this claim?
>
>Anton
Actually if the compressed message is smaller and the compression was
lossless the total entropy should be exactly the same and the entropy per bit
should be higher making the job of encryption easier. And the job of
decrypting harder. IF you had a perfect coder then almost any trival
encryption would work. Example you compress your whole message down
to ten bytes. You XOR each byte with a secret number 0 to 255. Even though
this is a small key and the enemy has to look at only 256 messages. Since
your coder was "perfect" He still does not know what message you sent since
any of the other messages is equally as valid. IF they are not as valid then
you don't have a perfect coder. To look at it deeper assume you did not
compress and the message was 256 bytes in lenght and you used a super dooper
thing like IDEA on it. Even though the key is longer and better. If the enemy
just stumbles on one solution then he can tell if it is the correct one and he
needs to look no father. Lets make this example more interesting. You have
5 spys working for you they are caght by the enemy. The enemy is highly
trained by our CIA and they torture the spys to death. While they are dying
they are made to give out a key. If they give out different keys and the long
method was used the enemy can tell which one if any was correct. IF the short
compressed one was given they enemy does not know if any are valid since
they all produce likely results.
That being said it would be very hard to get perfect compression. But it is
nice to try to get close. One problem is that the actual entropy of the
compressed message my be less then in the original message.
This may be due to the fact known headers are in the file. So this can
give someone trying to break the code a tremendous edge in busting it.
One sure way that one can tell that no information is added to the
compressed file is to require the "one to one" feature that is in my adaptive
huffman compression. There may be others on the net I have not found
them. It is easy to test for this property. Take "any" file A compress it to B
Note B may be longer. Take B uncompress it to C. Take A decompress it
to D. Take D compress it to E. the 3 file A C E should all be the same for
any and every choice of A. IF not then the compression method sucks and gives
the attacker more info to chew on.
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] (David Hamilton)
Subject: Re: Where to find
Date: Fri, 20 Aug 1999 19:19:07 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
(snip)
> As you can see David Hamiltion is one of my favortie haters. I piss him off
>a lot.
You overestimate your importance to me (and everybody else I guess). In fact,
I don't hate you and you don't piss me off.
All I do is to try to protect other beginners from you and your software. The
best advertisement AGAINST you and your software is, er, you and your
software. So, all I have to do is help things along a bit by referring to
your documented UNprofessionalism.
By the way, have you cracked IDEA yet? You did say you would didn't you?
(snip)
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with 2048 bit RSA key
iQEVAwUBN72eX8o1RmX6QSF5AQGoVAf/fhOkTnIuaHXl5Pc3mrEaMwJNAjaMSHJT
2XAkI0TrNCYw99GzxwoivonZV/i2z7wey8lc/8xvFNSf5wRbf/5dB27lcpsbd9Qq
ofLBsSQ/Zapkgojodkug4m8Xqte1YmBZlKXqxxS7XtamSIbmrx5XYG8MrTtY1Fe+
Mxyb/rxc2FPvWgqEmFQcVAm3OSASALAQuFcGN4i4TC1aDY3KnDKPkuWmX7ttuFnr
TV7MIYxFXqzq7P2McKHOZYqtnOwAJmvYNbaw920aN3cQJrrWul0WPERHexFOx/Yf
yPNKUgtmclWlkxA6BfUbX8x7AmH39JXbQmJmmpAgZwldlrrccFt+dA==
=AG/3
=====END PGP SIGNATURE=====
------------------------------
** 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
******************************
