Cryptography-Digest Digest #340, Volume #10 Thu, 30 Sep 99 20:13:03 EDT
Contents:
Re: Comments on ECC ([EMAIL PROTECTED])
Re: Comments on ECC ([EMAIL PROTECTED])
Re: Perfect Shuffle Algorithm? ("Douglas A. Gwyn")
Re: msg for Dave Scott ("Douglas A. Gwyn")
Re: Compress before Encryption ("Douglas A. Gwyn")
Re: Compress before Encryption ("Douglas A. Gwyn")
Re: How good is java.security.SecureRandom ? (Tim Tyler)
Re: msg for Dave Scott (Jerry Coffin)
Re: msg for Dave Scott (JPeschel)
Re: crypto export rules changing ("Stephen M. Gardner")
Re: msg for Dave Scott ("Douglas A. Gwyn")
Re: Cryptic manuscript... Help ("Douglas A. Gwyn")
Re: EAR Relaxed? Really? ("Douglas A. Gwyn")
Re: Compress before Encryption (SCOTT19U.ZIP_GUY)
Re: NEMA, Swiss cipher machine ("Douglas A. Gwyn")
Re: Glossary of undefineable crypto terms (was Re: Ritter's paper) ("Douglas A.
Gwyn")
KeyNote trust management open source toolkit now available (Matt Blaze)
Re: Cryptanalysis of 2 key TDES ("Richard Parker")
Re: Brute forcing salt instead of storing it (Was: Increasing password security
...) (Kevin Buhr)
Re: Ritter's paper (wtshaw)
Re: RSA encryption algorithm. ("Stephen M. Gardner")
Re: Compress before Encryption (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comments on ECC
Date: Thu, 30 Sep 1999 20:36:40 GMT
Douglas A. Gwyn wrote:
> [EMAIL PROTECTED] wrote:
> > Douglas A. Gwyn wrote:
> > > Unless somebody also invents an algorithm for converting
> > > any NP-complete problem into a P problem, knowing that
> > > P=NP wouldn't be of any practical use.
> > That doesn't make sense. If P=NP then then any
> > NP-complete problem _is_ a P problem. The "algorithm
> > for converting" can just compute the identity function.
>
> What I mean is that knowing that the *class* NP = the
> *class* P does not help us find a polynomial-time algorithm
> for the problem (e.g. traveling salesman). Existence proofs
> often have this nonconstructive quality.
What's the difference between "the *class* NP" and
NP? NP is a set of languages. I follow that the
mistake in your claim was referring to a poly-time
problem when you meant a poly-time algorithm, but
I don't see what the "class" adds.
> As to nondeterministic automata, there seem to be several
> ways of formulating them, none of which seem to make
> "Lucky guess" = "non-deterministic" (which was the claim
> I was disputing.)
I don't think you followed what he meant.
Suppose we augment Turing machines so they start
by guessing some string and writing it after their
input. From then on, they operate as
deterministic Turing machines. If this kind of
machine always makes the best guess for the given
input string, then the set of languages such
machines can accept in polynomial time is NP.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Comments on ECC
Date: Thu, 30 Sep 1999 20:46:27 GMT
I wrote:
> If P = NP then NP-complete = P - {Sigma* + phi}
^
Oops, notational error. That should be:
If P = NP then NP-complete = P - {Sigma*, phi}
> where Sigma* is the language containing all strings
> and phi is the language containing no strings.
--Bryan
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Crossposted-To: sci.stat.math,sci.math
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Perfect Shuffle Algorithm?
Date: Thu, 30 Sep 1999 14:39:50 GMT
David Franklin wrote:
> Firstly, I knocked up a brute force program to do this (took
> about 5 mins to write), and got the same answer as Clive Tooth
> (97020); the running time was just under 1 second. Which leads
> me to wonder about the LCM solution being "much simpler and
> faster" as the original interviewer apparently said. When the run
> time is 1 second, it's hard to justify spending time speeding it
> up (as a one-off problem at any rate).
But brute force doesn't scale well, while finding the cycles does.
You were just lucky that the period was only 97,020; it could have
been much larger if the parameters had been slightly different.
Not knowing in advance whether that was the case, it would be
better to use a method that is *known* to not take long instead
of one that *might* take too long.
Also, presumably the interviewer wasn't looking for just skills
in translating the problem description into a running simulation,
but for skills in analyzing the problem.
"The purpose of computing is insight, not numbers." - R.W.Hamming
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: msg for Dave Scott
Date: Thu, 30 Sep 1999 14:48:17 GMT
Tom St Denis wrote:
> ... I think I made my point.
You sure did, but probably not the point you thought
you were making.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Compress before Encryption
Date: Thu, 30 Sep 1999 14:58:38 GMT
"SCOTT19U.ZIP_GUY" wrote:
> But then again maybe I over estimate Mr B.S.'s crypto ability
> after all his Cohort Wagner can't even decrypt the source code
> of scott19u written in C that compiles on DJGGP GNU C.
That is poor argumentation on several counts.
For one thing, have you heard of the "Obfuscated C Competition"?
For another, what does DW's skill have to do with BS's skill??
Please cut out the personal invectives and stick to reasoned
argumentation. Thanks!
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Compress before Encryption
Date: Thu, 30 Sep 1999 14:55:58 GMT
Tim Tyler wrote:
> Since so much crypto-research goes on behind closed doors, it may
> eventually emerge (when the technique becomes more widespread), that
> it was in fact invented years ago - but never escaped from government
> custody.
I'm sure that precompression is mentioned in several places
in the open literature. The term "one to one" has a technical
meaning different from the way D.Scott uses the term, so it is
not used that way in the literature.
I think the plain fact is that the small amount of structure
from the compression header is generally not considered sufficient
to exploit, given that a cipher is already infeasible to brute-force
even in a known-plaintext attack. Therefore nobody other than
D.Scott has spent much time worrying about this aspect. The gain in
security from squelching the source statistics is so significant
that it dominates the other issue.
------------------------------
Crossposted-To: comp.lang.java.security
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: How good is java.security.SecureRandom ?
Reply-To: [EMAIL PROTECTED]
Date: Thu, 30 Sep 1999 20:53:46 GMT
In sci.crypt Mikael Fiil <[EMAIL PROTECTED]> wrote:
: You may take a look here:
: http://www.counterpane.com/yarrow.html
: These guys have a lot of information on security, which also includes
: random numbers
It's very hard to see any connection between this and the
java.security.SecureRandom class.
I have no idea about the securty of the "SecureRandom" class, but know
that the "Random" class is very, very insecure: see the Java applet at
http://www.alife.co.uk/nonrandom/ for the problem.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
No Such Agency.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: msg for Dave Scott
Date: Thu, 30 Sep 1999 14:03:10 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ...]
> btw: with only 1 block, even a caesar cypher is unconditionaly secure
> with a random key.
Hmm...either you and I have somewhat different understandings of what
a Ceaser Cipher IS, or else this doesn't make a lot of sense. At
least as I understand it, a Ceaser Cipher is basically not a block
cipher at all. It's a stream cipher that works on character at a
time. In a Ceaser Cipher, the "key" is an offset in the alphabet, and
for each character, you substitute the character at that offset from
the original to get the encrypted text. E.g. ROT13 is essentially a
Ceasar Cipher with a fixed key of 13. If you took ROT13 code and
allowed the user to enter a different value instead of 13, you'd have
a generalized version of a Ceasar Cipher. As I recall, in the
original form, the key was also fixed, but at 3 instead of 13.
In any case, unless you define a block as a character, there's no real
way to talk about a number of blocks WRT a Ceasar Cipher. Using a
known-plaintext attack, you can break a Ceasar Cipher with only one
character. Using a ciphertext-only attack, you have to collect enough
to gather a little bit in the way of statistics, but we're looking at
a pretty small number in most cases -- you stand a chance as soon as
you see the same character twice (it's most likely a space or an 'e',
depending on whether they've taken the spaces out of the plaintext
before encryption). With only one repeated character, you might well
be wrong, but it doesn't take very many more to reduce the chances of
being wrong to nearly nonexistent.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: msg for Dave Scott
Date: 29 Sep 1999 14:30:34 GMT
>[EMAIL PROTECTED] (Patrick Juola) writes:
>However, *because* DES has the reflexivity property, you should be able
>to find the proper key in an expected 2^54 operations, yes?
Sorry, Patrick, can't say I've heard of it.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: "Stephen M. Gardner" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: crypto export rules changing
Date: Thu, 30 Sep 1999 17:35:51 -0500
Greg wrote:
> ANY licensing by the government constitutes compromised software.
> No one will ever be able to have confidence that the software they
> are using has a trap door courtesy of NSA secret requirements if
> it had to pass NSA for a government license.
Even open source software? I don't think so. Some people seem to
have an almost mystical faith in the NSA to pull off supernatural acts
of evil. Get a grip folks. One does not have to trust the government
(any government) to trust one's own eyes and the eyes of thousands of
people who couldn't possibly be on the NSA payroll. Crimus, I see more
than a few folks here whose dosages are still in need of minor
adjustment. ;-)
--
Steve Gardner Technical Staff Member 1320 Systems Engineering
ALCATEL USA
1225 N. Alma Road Tel: 972-996-5888
Richardson Tx. 75081-2206 http://ctnwww.aud.alcatel.com/~gardsm/
You who choose to lead must follow,
But if you fall you fall alone,
If you should stand then who's to guide you?
If I knew the way I would take you home.
"Ripple" -- The Grateful Dead
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: msg for Dave Scott
Date: Thu, 30 Sep 1999 14:47:09 GMT
Tom St Denis wrote:
> Ok let me rephrase if I give you
> bfaqaaa2q2IpYXBMmmaaaauaaaaqF43{QqmvUThKIkZ7aa65z
> will you be able to read it faster then say brute force?
That's not a rephrasing, that's a completely different issue.
If you had provided *sufficient* ciphertext from any of several
well-known symmetric systems, then certainly there would be ways
of attacking it that are faster than a brute-force key search,
especially if there are isomorphs, period overlaps, or other
favorable conditions that do often arise in practice. It's
called "cryptanalysis"; look it up.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Cryptic manuscript... Help
Date: Thu, 30 Sep 1999 15:06:22 GMT
Matthew Harley wrote:
> http://www2.micro-net.com/~ixohoxi/voy/voynich.htm
Also check out Jim reed's Web site; he has a lot of material
on the Voynich problem, including lots of references.
------------------------------
Crossposted-To: talk.politics.crypto
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: EAR Relaxed? Really?
Date: Thu, 30 Sep 1999 15:10:33 GMT
Greg wrote:
> Defendant: Your honor, I move that this case be dismissed
> for a lack of evidence.
> Judge: Your argument has no standing in this court.
It would be the defendant's attorney that would so move,
and he certainly would have "standing", and lack of
evidence certainly *is* considered grounds for dismissal.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compress before Encryption
Date: Thu, 30 Sep 1999 23:43:18 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> But then again maybe I over estimate Mr B.S.'s crypto ability
>> after all his Cohort Wagner can't even decrypt the source code
>> of scott19u written in C that compiles on DJGGP GNU C.
>
>That is poor argumentation on several counts.
>For one thing, have you heard of the "Obfuscated C Competition"?
Know could you enter my code or does it require some crappy
ps type of format.
>For another, what does DW's skill have to do with BS's skill??
Do you really want to know. I think they form mutual
admeration society. They use each other as some sort of
reference when in fact one just works for the other. Some one
a short time ago found out and posted the info.
>
>Please cut out the personal invectives and stick to reasoned
>argumentation. Thanks!
YOur welcome
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: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NEMA, Swiss cipher machine
Date: Thu, 30 Sep 1999 17:45:10 GMT
[EMAIL PROTECTED] wrote:
> ... I think that this needs to be avoided: and one way to help
> to avoid it is simply to avoid the use of the word 'rotor' to describe,
> when discussing a cipher machine, any kind of gear, cam, or pinwheel, or
> indeed any other item but a _wired_ rotor.
Unfortunately it doesn't really help. Indeed, wired rotors
have also frequently been called "wheels". Basically, from
the cryptanalyst's viewpoint, it is the periodicity that is
interesting, not the construction of the equipment.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Glossary of undefineable crypto terms (was Re: Ritter's paper)
Date: Thu, 30 Sep 1999 17:40:20 GMT
"Trevor Jackson, III" wrote:
> Also Known As the Karnak Atack. You hold the cipher text up to your
> forehead and guess the plaintext. There is no possible cryptologic
> defense against someone who can guess your message. A ouija board is a
> tool to assist in such guessing.
Well, yes, there is a defense. In a true "Ouija" attack, a correct
guess can be *verified* against the intercepted ciphertext. But OTP
is immune to this, so it is an example of an Ouija-resistant system.
------------------------------
From: Matt Blaze <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix,comp.security.misc,alt.security
Subject: KeyNote trust management open source toolkit now available
Date: 30 Sep 1999 18:33:55 -0400
We are pleased to announce the production (non-beta) release of the
KeyNote Trust Management Toolkit and Open-Source Reference
Implementation, version 2. The toolkit was developed by Angelos
Keromytis of the University of Pennsylvania.
KeyNote is a small, flexible trust management system designed to be
especially suitable for Internet-style applications. KeyNote provides
a single, uniform language for specifying security policies and
credentials, and can be used as an application policy description
language as well as as a format for public-key credentials. KeyNote
is a joint project of Matt Blaze, Joan Feigenbaum and John Ioannidis
of AT&T Laboratories and Angelos Keromytis of the University of
Pennsylvania.
KeyNote provides a standard, common mechanism for managing security
policy, credentials, access control, and authorization. An
application built with KeyNote simply asks the "compliance checker"
whether potentially dangerous actions should be allowed according to
policy. Policies and credentials are written in a standard language
that is shared across applications; the security configuration
mechanism for one application carries exactly the same syntactic and
semantic structure as that of another, even if the semantics of the
applications themselves are quite different.
The basic KeyNote language and implementation are essentially without
intellectual property constraints (as far as we know). We have not
patented the KeyNote system or trust management generally (although of
course anyone, including us, could invent and patent some specific
novel application of trust management based on KeyNote). The KeyNote
toolkit is covered under a Berkeley-style open source license and can
be freely incorporated (with attribution) into commercial and
non-commercial software. The software is, of course, distributed
completely without warranty. Use it, like everything obtained from
the net, completely at your own risk.
This release has been tested under several flavors of BSD and Linux,
and should work with limited coaxing on most UNIX and Win32 platforms,
but we make no guarantee that it will work correctly in any specific
environment. The API interfaces are substantially compatible with the
recent KeyNote toolkit beta releases. To build KeyNote with
credential signature verification, you'll need the OpenSSL toolkit or
a recent release of the SSLeay library. The toolkit is distributed as
a GZIPed TAR archive (".tar.gz" format). Unpack it with either
gzcat keynote-2.0.tar.gz | tar xvf -
or with
tar xzvf keynote-2.0.tar.gz
A full description of the KeyNote language can be found in RFC-2704,
which can be obtained from the standard Internet RFC archives or from:
<http://www.crypto.com/papers/rfc2704.txt>
This release of the KeyNote toolkit can be downloaded from:
<http://www.crypto.com/keynote-2.0.tar.gz>
or via anonymous ftp from:
<ftp://ftp.research.att.com/dist/mab/keynote-2.0.tar.gz>
or from Angelos Keromytis' KeyNote web page at:
<http://www.cis.upenn.edu/~angelos/keynote.html>
If you use KeyNote, please let us know at [EMAIL PROTECTED]
There is a (low-bandwidth) mailing list for KeyNote users and
developers. To subscribe, send an email message to
<[EMAIL PROTECTED]> containing the line:
subscribe keynote-users
-matt
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis of 2 key TDES
Date: Thu, 30 Sep 1999 23:43:01 GMT
It is possible to make time/space tradeoffs when attacking
two-key triple-DES. Here are a few attacks arranged from the
most computationally expensive to the most storage intensive:
brute-force attack
2^112 computation
2 known plaintexts
meet-in-the-middle known-plaintext attack
(2^120)/n computation
n storage
n known plaintexts
meet-in-the-middle chosen-plaintext attack
2^56 computation
2^56 storage
2^56 chosen plaintexts
key table attack
2^112 storage
2 chosen plaintexts
References for a few papers that discuss the security of triple-DES:
R.C. Merkle and M.E. Hellman, "On the security of multiple
encryption," Communications of the ACM, v. 24, July 1981,
pp. 465-467.
P. van Oorschot and M. Wiener, "A known plaintext attack on two-key
triple encryption," Advances in Cryptology - Eurocrypt '90,
Springer-Verlag, 1991, pp. 318-325.
B. Kaliski and M. Robshaw, "Multiple encryption: weighing
security and performance," Dr. Dobbıs Journal, January 1996,
pp. 123127.
-Richard
------------------------------
From: [EMAIL PROTECTED] (Kevin Buhr)
Subject: Re: Brute forcing salt instead of storing it (Was: Increasing password
security ...)
Date: 30 Sep 1999 18:44:28 -0500
[ newsgroups trimmed ]
"Thomas J. Boschloo" <[EMAIL PROTECTED]> writes:
>
> BTW: [The idea of storing the salt is just 'lame' I think. I would just
> concatenate the username with the password if I had written Unix. That
> also allows the system administrator to see if a user used the same
> password twice on two systems, and warn the user.]
One problem with your scheme that comes to mind: if you collect a
number of encrypted passwords for the same username on different
machines, they will all obviously have the same salt, simplifying a
dictionary attack against a particular user. This is made all the
more problematic in the Unix world, since a certain Mr. I. M. Root
seems to have accounts on the vast majority of the Unix machines I've
seen. User "root"'s presence would allow the construction of huge
pre-fabricated dictionaries on CD for cracking purposes, exactly the
sort of thing the salt was meant to prevent (or, more accurately, make
4096 times more inconvenient).
One could get around this by concatenating machine-specific
information to the password, but this would render the encrypted
passwords non-portable across machines, a big disadvantage.
Kevin <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Ritter's paper
Date: Thu, 30 Sep 1999 18:11:14 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Johnny Bravo) wrote:
> On Wed, 29 Sep 1999 15:10:22 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
> wrote:
>
> > Mok
> > I thought I would anwser this last question for you. The AES contest
> >is about finding a WEAK method so that it can be used for all encryption
> >in all aplications.
>
> Please post your proof that the AES candidates are weak. You can start with
> the ones who were accepted into the second round, since by your logic
the strong
> ones would have been discarded first. Take all the screens you need.
>
Strength and weakness being relative things, it does seem that the AES
goals are barely out of the parking lot, much less down the highway.
Consider any ciphers that can be assured of being solved when only a
couple of blocks of plaintext are known, regardless of the amount of brute
force required, are weak sisters. The essence of really strong
cryptography is not part of the AES parlor game. Some don't get it, but a
few do.
I will likely disagree with many on what strength is, for it is a
combination of many things. I continue to fight for a reasonable
composite definition of strength.
--
Still a good idea from Einstein: If you can't explain something clearly to a child,
you do not understand it well enough.
So much for models of trust, they generally are ill-founded.
------------------------------
From: "Stephen M. Gardner" <[EMAIL PROTECTED]>
Subject: Re: RSA encryption algorithm.
Date: Thu, 30 Sep 1999 17:47:25 -0500
Jeremy Botha wrote:
> Hi all.
>
> My problem is that I'm trying to code this in C/C++, and encryption /
> decryption requires *huge* numbers. I've tried long ints, long long ints,
> and finally in a fit of desperation, doubles. doubles seem to work okay,
> apart from the irritating fact that they loose precision, so when I decrypt
> the cypher it doesn't return to plaintext.
None of these will work. You especially don't want doubles! That precision
you lose is absolutely necessary. There are a number of alternatives. You
could get Dr. Mike's
book,(http://www.amazon.com/exec/obidos/ASIN/1884777694/qid%3D938731501/002-9296106-1692859)
he shows you how to implement multiprecision math in C or you could use one of
the multiprecision libraries (usually written in assembler for efficiency) that
are available on the web. Don't waste time with the native C/C++ types, they
do not contain enough bits to do RSA keys of reasonable size (>512).
--
Steve Gardner Technical Staff Member 1320 Systems Engineering
ALCATEL USA
1225 N. Alma Road Tel: 972-996-5888
Richardson Tx. 75081-2206 http://ctnwww.aud.alcatel.com/~gardsm/
You who choose to lead must follow,
But if you fall you fall alone,
If you should stand then who's to guide you?
If I knew the way I would take you home.
"Ripple" -- The Grateful Dead
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Compress before Encryption
Date: Thu, 30 Sep 1999 23:56:10 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Tim Tyler wrote:
>> Since so much crypto-research goes on behind closed doors, it may
>> eventually emerge (when the technique becomes more widespread), that
>> it was in fact invented years ago - but never escaped from government
>> custody.
>
>I'm sure that precompression is mentioned in several places
>in the open literature. The term "one to one" has a technical
>meaning different from the way D.Scott uses the term, so it is
>not used that way in the literature.
I for one have not found it mentioned in the way that would
state it is desirable that if a wrong key is used that the underlying
text when uncompressed and recompressed comes back to same
file. If you know so fucking much where is a reference and what is
this comon term in the literature or are you just blowing smoke out
your ass. What the fuck would you call it if not "one to one".
>
>I think the plain fact is that the small amount of structure
>from the compression header is generally not considered sufficient
>to exploit, given that a cipher is already infeasible to brute-force
In the real world crypto game any weakness is used for an attack
it is very foolish to say no one worries about such weaknesses.
Maybe where you work they are to stupid to pay attension to minor
details. Or maybe your just part of the cover up.
>even in a known-plaintext attack. Therefore nobody other than
>D.Scott has spent much time worrying about this aspect. The gain in
>security from squelching the source statistics is so significant
>that it dominates the other issue.
I truely belive the smart people do worry about these weakness.
The only possible reason people like Mr B.S. did not mention these
kind of weakness in his book is either he really is a lot dumber than
most people think or he is doing the bidding of a certain 3 letter agency
that I will not mention.
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
------------------------------
** 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
******************************
