Cryptography-Digest Digest #700, Volume #12 Sun, 17 Sep 00 14:13:01 EDT
Contents:
Re: RSA?? (Simon Johnson)
Re: Double Encryption Illegal? (Paul Schlyter)
Assistance (Teo Li Xi)
Re: Carnivore article in October CACM _Inside_Risks (Jonathan Thornburg)
Re: RC4: Tradeoff key/initialization vector size? ("Scott Fluhrer")
Re: Double Encryption Illegal? (Tom St Denis)
Re: Dangers of using same public key for encryption and signatures? (Simon Johnson)
Re: RC4: Tradeoff key/initialization vector size? (Tom St Denis)
Re: RC4: Tradeoff key/initialization vector size? (Tom St Denis)
Re: Weaknesses in this algorithm? (Tim Tyler)
Re: Serpent S-boxes (again) (Tim Tyler)
Re: Music Industry Offers US$10K for cracking their encryption system (Tim Tyler)
Re: "Secrets and Lies" at 50% off (Tim Tyler)
Re: ExCSS Source Code (David A. Wagner)
Re: Serpent S-boxes (again) (Mack)
Re: Tying Up Loose Ends - Correction (John Savard)
Re: Double Encryption Illegal? (Mok-Kong Shen)
Re: Specially for Dr. mike (with regard to patience, persistence, truth, (John M.
Gamble)
Re: wince encryption algorithm (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Guy Macon)
Re: Weaknesses in this algorithm? (Guy Macon)
Re: Assistance (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: RSA??
Date: Sun, 17 Sep 2000 13:15:24 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> ANSI X9 requires 1024 bit RSA and DSA keys and 161 bit ECC keys.
> Don Johnson
>
Hrm, DSA is a government standard right?
I find it alarming that while the NSA produces conventional algorithms
such as skipjack, it doesn't directly produce new public key algorithm.
I sometimes wonder if all the work of Turing has been released. Prehaps
somewhere in the archives of some government agenicy is a paper which
proves p=np :)
and yes, i'm sprinkling fairydust :)
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: 17 Sep 2000 15:25:39 +0200
In article <8q273q$5aj$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <8q1tea$bhp$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Paul Schlyter) wrote:
>> In article <8pvnav$gdt$[EMAIL PROTECTED]>,
>> Tom St Denis <[EMAIL PROTECTED]> wrote:
>>
>>> In article <[EMAIL PROTECTED]>,
>>> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>> PRdO wrote:
>>>>>
>>>>> IMHO double encryption *does not* add security, i.e., double
>>>>> encryption in 128-bit doesn't equal better encryption.
>>>>> (since encryption uses random keys, "randoming" again the data
>>>>> would not lead to more secure data).
>>>>
>>>> If you have an algorithm that does a perfect job (do
>>>> you happen to have one?), then there is by definition
>>>> nothing to improve. Otherwise, multiple encryption may
>>>> help, if done properly.
>>>
>>> Ah but double encryption is not the way to go about it.
>>
>> So you're claiming that triple-DES is no more secure than single-
>> DES ???
>
> Read my message. Geez. I said "double" encryption is not the way to
> go about added security.
But you believe "triple" encryption is, since you don't think your
statement applied to triple-DES?
==========================================================================
One cannot generally state that multiple encryption enhances, or does
not enhance, security -- it depends a lot on the encryption used.
Consider for instance the good ol' Caesar cipher: applying it
multiple times with different "keys" makes the final encryption no
safer than if it was applied only once with one single "key".
Now, instead consider DES, where applying it three times does indeed
make tne encryption safer than if applied only once -- that's why
3DES is so popular.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: Teo Li Xi <[EMAIL PROTECTED]>
Subject: Assistance
Date: Sun, 17 Sep 2000 22:30:09 +0800
Dear all:
Does anyone here have any experience with implementing Wei Dai's
Crypto++ library in Microsoft Visual C++ 6 environment? I need to use
some of the algorithms in there like DES/IDEA/RSA.
Regards,
jon
------------------------------
From: [EMAIL PROTECTED] (Jonathan Thornburg)
Subject: Re: Carnivore article in October CACM _Inside_Risks
Date: 17 Sep 2000 16:35:00 +0200
In article <[EMAIL PROTECTED]>,
Douglas A. Gwyn <[EMAIL PROTECTED]> asked
>Should we require
>builders to install listening devices in every house in
>order to facilitate bugging, or auto manufacturers to plant
>tracking devices in every car they make so that they can be
>switched on by law enforcement if the need arises?
Very good questions indeed!
Another thought in the same vein...
During the cold war, it was widely known that people from the west
who visted the USSR routinely had their telephones tapped, their
mail monitored, etc, and in the west this was widely held to be
a classic example of the USSR's "police state" government.
[As only one example of many, many, such assessments,
see pp. 14--16 of Hedrick Smith's "The Russians"
(Ballentine, New York, 1976, ISBN 0-345-25521-6-250).]
Now fast-forward to today: What do the US digital telephony
legislation, Carnovior, and similar programs in other countries,
say about our nominally democratic and "free" societies?
--
-- Jonathan Thornburg <[EMAIL PROTECTED]>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
"Washing one's hands of the conflict between the powerful and the powerless
means to side with the powerful, not to be neutral." - Freire / Oxfam
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: RC4: Tradeoff key/initialization vector size?
Date: Sun, 17 Sep 2000 07:53:51 -0700
Tom St Denis <[EMAIL PROTECTED]> wrote in message
news:8q2711$58u$[EMAIL PROTECTED]...
>
> I would strongly recommend against using ASCII text as the key for
> RC4. You should really hash it first.
>
Mind if I ask why? What weakness do you claim RC4 has if you don't hash
your keys?
--
poncho
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: Sun, 17 Sep 2000 15:07:20 GMT
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>
> Tom St Denis wrote:
> >
> > [EMAIL PROTECTED] (Paul Schlyter) wrote:
>
> > > So you're claiming that triple-DES is no more secure than single-
> > DES ???
> >
> > Read my message. Geez. I said "double" encryption is not the way
to
> > go about added security.
>
> Could you be more explicit and explain why? Are you
> saying that superencipherment is always nonsense?
> Is 2-DES not better than DES?
Given sufficient memory 2-des is not better then des.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Dangers of using same public key for encryption and signatures?
Date: Sun, 17 Sep 2000 15:08:04 GMT
These laws are written by ignorant people for ignorant people. Since
the one-time pad is unbreakable, it lends itself to this situation. Say
the ask for the keys to some file. You xor a non-incriminating plain-
text with the encrypted file to retreive a 'pseudo-one-time-pad key'
You the surrender this as the key.
They can't prove the key is incorrect without lauching an attack on the
underlying encryption algorithm. Which is probably impossible.
>
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC4: Tradeoff key/initialization vector size?
Date: Sun, 17 Sep 2000 15:10:38 GMT
In article <8q2aa6$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Guy Macon) wrote:
> Tom St Denis wrote:
> >
> > David Crick <[EMAIL PROTECTED]> wrote:
> >>
> >> From the CipherSaber[-1] documentation
(http://ciphersaber.gurus.com)
> >>
> >> The user key is a text string, rather than a hex value, because
> >> humans are more likely to be able to memorize a text string with
> >> sufficient entropy. To leave room for the initialization vector,
> >> the length of the user key must be less than 246 bytes. To insure
> >> adequate mixing of the initialization vector and user key, we
> >> recommend you select a user key of 54 bytes or less.
> >
> >I would strongly recommend against using ASCII text as the key for
> >RC4. You should really hash it first.
> >
>
> I believe that the implementation of RC4 described on the web
> page [ http://ciphersaber.gurus.com ] is secure without any
> such hashing. Ciphersaber has withstood a lot of analysis
> and attacks so far.
The problem with using ascii data in the RC4 key schedule (assuming you
still use it) is that alot of the swaps will not use the high bits
randomly such as
y = (y + Key[x] + S[x]) mod 256
The high bit of Key[x] will never be set, the values of Key[] are also
terribly limited making them a poor choice for a good random RC4 key.
If you hash it the values of Key[] will take on 0-255 almost perfectly
distributed (assuming all is well).
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: RC4: Tradeoff key/initialization vector size?
Date: Sun, 17 Sep 2000 15:38:43 GMT
In article <8q2n42$lp8$[EMAIL PROTECTED]>,
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote in message
> news:8q2711$58u$[EMAIL PROTECTED]...
> >
> > I would strongly recommend against using ASCII text as the key for
> > RC4. You should really hash it first.
> >
> Mind if I ask why? What weakness do you claim RC4 has if you don't
hash
> your keys?
As I said earlier in the expression
y = (y + key[x] + s[x]) mod 256
most values of key[x] in 0..255 are not valid or probable. This makes
the statement biased towards those values.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Weaknesses in this algorithm?
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Sep 2000 09:41:32 GMT
Runu Knips <[EMAIL PROTECTED]> wrote:
: You simply gain NOTHING, really, really NOTHING with this technique.
There are methods involving encrypting random pads of data with a
conventional cypher (in an attempt to get around OTP key distribution
problems) that do seem to provide interesting security twists, though.
See section 15.8, p.368 of AC (2nd ed.) for details.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Serpent S-boxes (again)
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Sep 2000 09:48:24 GMT
[EMAIL PROTECTED] wrote:
: [EMAIL PROTECTED] (Gregory G Rose) wrote:
:> I guess this could be considered an example of "proof by assertion",
:> but, has anyone actually checked the stated algorithm to see if it
:> does produce the chosen s-boxes?
: The algorithm presented in the serpent paper is not complete they have
: a step labeled "test for given criteria" which doesn't say "how" the
: tests are done.
*If* the criteria are well defined, it shouldn't matter how the tests are
done. For example, "non-linearity of 4" should be unambiguous, no matter
how you do your tests.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Music Industry Offers US$10K for cracking their encryption system
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Sep 2000 10:02:29 GMT
Mack <[EMAIL PROTECTED]> wrote:
: http://www.hackSDMI.org
: But the idea is just an idea for now. Their web site
: is just a message saying check back ...
According to http://hacksdmi.org/hackDownload.asp you can
download and start cracking today - but you can't submit any
results until the 20th of September.
The competition shuts on October 7th - though "SDMI reserves
the right to terminate the challenge at an earlier date, or to
extend the testing period."
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
Crossposted-To: comp.security,comp.security.misc
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: "Secrets and Lies" at 50% off
Reply-To: [EMAIL PROTECTED]
Date: Sun, 17 Sep 2000 10:07:26 GMT
In sci.crypt Tom St Denis <[EMAIL PROTECTED]> wrote:
: If I was interested in his book I would want to know about the contents
: and the purpose, not just the cost.
The previously-mentioned http://www.counterpane.com/sandl.html ?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: ExCSS Source Code
Date: 17 Sep 2000 08:57:19 -0700
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> David A Molnar wrote:
> > Also the licensing of players. Since you can't build a player without
> > implementing CSS.
>
> Actually, you could -- e.g. ship a copy of the disk data off via
> high-speed link to some existing player and ship back the audio
> in a non-CSS encoded form. Probably not feasible any time soon,
> but someday things like this might be done.
My understanding is that the MPAA would probably consider this
circumvention of the player. (Existing players include security devices
that are supposed to prevent you from doing this.) Maybe we should
modify David Molnar's statement slightly to "You can't build a player
without implementing or circumventing CSS".
------------------------------
From: [EMAIL PROTECTED] (Mack)
Date: 17 Sep 2000 16:21:43 GMT
Subject: Re: Serpent S-boxes (again)
>[EMAIL PROTECTED] wrote:
>: [EMAIL PROTECTED] (Gregory G Rose) wrote:
>
>:> I guess this could be considered an example of "proof by assertion",
>:> but, has anyone actually checked the stated algorithm to see if it
>:> does produce the chosen s-boxes?
>
>: The algorithm presented in the serpent paper is not complete they have
>: a step labeled "test for given criteria" which doesn't say "how" the
>: tests are done.
>
>*If* the criteria are well defined, it shouldn't matter how the tests are
>done. For example, "non-linearity of 4" should be unambiguous, no matter
>how you do your tests.
In that specific case there are a number of measures of non-linearity.
So it isn't really a well defined criteria.
>--
>__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
> |im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
>
>
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Tying Up Loose Ends - Correction
Date: Sun, 17 Sep 2000 16:28:24 GMT
On Sat, 16 Sep 2000 21:58:21 -0400, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote, in part:
>It would be infinitely more useful to simply tell us how.
Well, we do know that using an end-of-file code _slightly_ reduces the
security of encryption, at least if a simple, classical method is used
that doesn't have much resistance to a known plaintext attack.
The redundancy of the whole message is increased, because space has to
be reserved in the table for the end-of-file code, which is only used
once.
The end-of-file code constitutes known plaintext - it can have only
eight possible positions, with 0 to 7 irrelevant bits following it.
This is the "how". In previous postings, Mr. Scott has indicated that
he believes the NSA either _can_ perform brute-force searches on
ciphers with 128-bit keys, or they have enough cracks on the major
ciphers with such keys, such as IDEA and the AES candidates, that
cryptanalyzing them is within the realm of possibility.
Hence, he is advocating the most meticulous attention to compression,
so that after a candidate key is tried, the resulting candidate
plaintext generated from an incorrect key cannot be distinguished from
real plaintext by any simple automated test.
Thus, while compressing better is, on general principles, a good idea,
he rejects the conventional wisdom, which tells us: it is very hard to
make compression _that_ good, and it is very easy to switch to 256-bit
keys.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal?
Date: Sun, 17 Sep 2000 19:21:17 +0200
Tom St Denis wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >
> > Tom St Denis wrote:
> > >
> > > [EMAIL PROTECTED] (Paul Schlyter) wrote:
> >
> > > > So you're claiming that triple-DES is no more secure than single-
> > > DES ???
> > >
> > > Read my message. Geez. I said "double" encryption is not the way
> to
> > > go about added security.
> >
> > Could you be more explicit and explain why? Are you
> > saying that superencipherment is always nonsense?
> > Is 2-DES not better than DES?
>
> Given sufficient memory 2-des is not better then des.
Please exlpain your claim or refer to literature.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (John M. Gamble)
Subject: Re: Specially for Dr. mike (with regard to patience, persistence, truth,
Date: 17 Sep 2000 17:14:04 GMT
[Long (but strangly polite) rant snipped]
Hmm. You've just attacked one of the most genial and pleasant posters
here. Not a good start.
If people here are viewing your posts with suspicion, it is because your
posts are exhibitting all the signs of the standard crackpot postings.
Some advice, NOT meant to be a put-down, but instead to help:
Don't refer to yourself in the third person.
Define your terms when you post something technical. From the looks
of things, your terms seem to be the result of technical short-hand
that you've developed for your own purposes, and you are so comfortable
with them that you've forgotten that the only one who knows the definitions
is you.
ONE posting is sufficient for an announcement, and all the necessary
information should be there, rather than spread out over multiple postings.
Irrelevant annoyances that you've experienced (like the customs officer
that you found overly officious) don't belong on this group.
And finally: There are a lot of highly intelligent people on this group,
and despite the fact that some of them will occasionally be impolite, it
will not change the fact that they might turn out to be right. You have
to deal with the content in the posting, not the level of the language.
-john
February 28 1997: Last day libraries could order catalogue cards
from the Library of Congress.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: wince encryption algorithm
Date: Sun, 17 Sep 2000 19:33:57 +0200
An Metet wrote:
>
> This is the secret Ace (and WinAce) encryption algorithm. It is a
> combination of a Blowfish derivation and a SHA-1 derivation and it
> uses Cipher Block Chaining. I called it AceFish therefore...
It would be nice, if you would explain in English how
your algorithm is made out of the same compnents in
some understandable fashion.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Sun, 17 Sep 2000 19:34:06 +0200
John Savard wrote:
>
> "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote, in part:
>
> >It would be infinitely more useful to simply tell us how.
>
> Well, we do know that using an end-of-file code _slightly_ reduces the
> security of encryption, at least if a simple, classical method is used
> that doesn't have much resistance to a known plaintext attack.
>
> The redundancy of the whole message is increased, because space has to
> be reserved in the table for the end-of-file code, which is only used
> once.
>
> The end-of-file code constitutes known plaintext - it can have only
> eight possible positions, with 0 to 7 irrelevant bits following it.
>
> This is the "how". In previous postings, Mr. Scott has indicated that
> he believes the NSA either _can_ perform brute-force searches on
> ciphers with 128-bit keys, or they have enough cracks on the major
> ciphers with such keys, such as IDEA and the AES candidates, that
> cryptanalyzing them is within the realm of possibility.
>
> Hence, he is advocating the most meticulous attention to compression,
> so that after a candidate key is tried, the resulting candidate
> plaintext generated from an incorrect key cannot be distinguished from
> real plaintext by any simple automated test.
>
> Thus, while compressing better is, on general principles, a good idea,
> he rejects the conventional wisdom, which tells us: it is very hard to
> make compression _that_ good, and it is very easy to switch to 256-bit
> keys.
I don't think that it is worthwhile to worry about the
slight 'increase in redundancy'. Normally, the frequency
distribution on which the Huffman tree is based is
only approximately true of that of the actual message
(unless one does two passes and transmit the frequency
distribution or its equivalent) so that arguing about
tiny stuffs is not justified. Further, as I said in
my follow-up, one can do a secret Huffman compression
so that the main reason of having Scott's 1-1 no longer
holds.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Tying Up Loose Ends - Correction
Date: 17 Sep 2000 17:29:05 GMT
John Savard wrote:
>
>The end-of-file code constitutes known plaintext - it can have only
>eight possible positions, with 0 to 7 irrelevant bits following it.
>
>This is the "how". In previous postings, Mr. Scott has indicated that
>he believes the NSA either _can_ perform brute-force searches on
>ciphers with 128-bit keys, or they have enough cracks on the major
>ciphers with such keys, such as IDEA and the AES candidates, that
>cryptanalyzing them is within the realm of possibility.
>
>Hence, he is advocating the most meticulous attention to compression,
>so that after a candidate key is tried, the resulting candidate
>plaintext generated from an incorrect key cannot be distinguished from
>real plaintext by any simple automated test.
>
>Thus, while compressing better is, on general principles, a good idea,
>he rejects the conventional wisdom, which tells us: it is very hard to
>make compression _that_ good, and it is very easy to switch to 256-bit
>keys.
Is there a particular reason why he couln't just state his position
plainly instead of acting like an asshole and insulting everyone who
disagrees with him? Regardless of the merits of his scheme, such
behavior makes him seem like a kook, and kooks seldom have much that
is of value to add to technical discussions.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Weaknesses in this algorithm?
Date: 17 Sep 2000 17:35:49 GMT
Tim Tyler wrote:
>
>There are methods involving encrypting random pads of data with a
>conventional cypher (in an attempt to get around OTP key distribution
>problems) that do seem to provide interesting security twists, though.
>
It is an interesting concept. It seems weaker than an OTP but may be
stronger than the conventional cypher, on the theory that if having
known or chosen plaintext is an advantage to an attacker, having
random plaintext is a disadvantage.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Assistance
Date: Sun, 17 Sep 2000 19:51:16 +0200
Teo Li Xi wrote:
> Does anyone here have any experience with implementing Wei Dai's
> Crypto++ library in Microsoft Visual C++ 6 environment? I need to use
> some of the algorithms in there like DES/IDEA/RSA.
It would be informative for us to know what kind of
troubles you got in trying to get the library operating
in your environment. Question: If you found something
wrong, why didn't you send an e-mail to the author of
the library?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Tying Up Loose Ends - Correction
Date: 17 Sep 2000 17:30:45 GMT
[EMAIL PROTECTED] (John Savard) wrote in
<[EMAIL PROTECTED]>:
>On Sat, 16 Sep 2000 21:58:21 -0400, "Douglas A. Gwyn"
><[EMAIL PROTECTED]> wrote, in part:
>
>>It would be infinitely more useful to simply tell us how.
>
>Well, we do know that using an end-of-file code _slightly_ reduces the
>security of encryption, at least if a simple, classical method is used
>that doesn't have much resistance to a known plaintext attack.
>
>The redundancy of the whole message is increased, because space has to
>be reserved in the table for the end-of-file code, which is only used
>once.
>
>The end-of-file code constitutes known plaintext - it can have only
>eight possible positions, with 0 to 7 irrelevant bits following it.
>
>This is the "how". In previous postings, Mr. Scott has indicated that
>he believes the NSA either _can_ perform brute-force searches on
>ciphers with 128-bit keys, or they have enough cracks on the major
>ciphers with such keys, such as IDEA and the AES candidates, that
>cryptanalyzing them is within the realm of possibility.
I claim it is one of the ways. What people should do is close
all door to a possible attack. Something the Germans and Japanese
did not do in WWII. Know it seems modern crypto gods are saying
forget the minor doors that are not important. They seem to say
forgot the details and instead focus on one lock only. Even if they
are locks can help. This is stupid.
>
>Hence, he is advocating the most meticulous attention to compression,
>so that after a candidate key is tried, the resulting candidate
>plaintext generated from an incorrect key cannot be distinguished from
>real plaintext by any simple automated test.
>
Yes. But this meticulous attention to detail we also make for
better compressors in the future. 1-1 RLT and routines like my DSC
should be used. THe bit savings are small but they do save some space.
>Thus, while compressing better is, on general principles, a good idea,
>he rejects the conventional wisdom, which tells us: it is very hard to
>make compression _that_ good, and it is very easy to switch to 256-bit
>keys.
>
Not exactly. I say do what you can in both areas. It is just people
seem to only focus in the other area. Don't forget we can never prove that
any of the AES candidates are secure. Why give any hooks for an attacker.
And allowing one to use compression which grantees only one possible
decryption is a damn big hook.
So dam big that no mater if the file was random or whatevwe before the
compression there may well be only one solution. Do people really want
that when every generation has under estimated what is safe from the next.
Do you really belive quatom computers will not some day make mince meat of
all the AES candidates in a few decades at most.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
** 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
******************************
