Cryptography-Digest Digest #565, Volume #12 Tue, 29 Aug 00 14:13:01 EDT
Contents:
Re: Optimal length of the sieve before a Miller-Rabin test (DJohn37050)
Re: could someone post public key that is tempered ? (Rich Wales)
Re: 96-bit LFSR needed ([EMAIL PROTECTED])
Re: e-cash protocol concept, comments wanted (Eric Murray)
Re: Reading recommendations on protocol design (Chris Yuen)
Re: A little technical note about intepreters (Daniel Leonard)
Re: Optimal length of the sieve before a Miller-Rabin test ([EMAIL PROTECTED])
Re: On pseudo-random permutation (Herman Rubin)
Idea for creating primes ([EMAIL PROTECTED])
Re: I need ADK tampered key that PGP will not detect ADK, on it ... (jungle)
Re: A little technical note about intepreters (Andrew Carol)
Re: Patent, Patent is a nightmare, all software patent shuld not be allowed ("Paul
Pires")
Re: Idea for creating primes (David A Molnar)
Re: Future computing power (John Myre)
Re: PRNG Test Theory ("Trevor L. Jackson, III")
Re: Future computing power (James Felling)
Re: I need ADK tampered key that PGP will not detect ADK, on it ... ("JL")
RSA n-bit key...is p and q n or is the mod n? ("John Matzen")
Re: Future computing power (Ichinin)
Re: PROMIS-software for worldwide spy network by US/Isreal ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Optimal length of the sieve before a Miller-Rabin test
Date: 29 Aug 2000 15:46:16 GMT
My understanding of the reason to do the small primes tests before MR is that
you really want to have SOME confidence that what you run an MR test on is a
prime. That is, sieving is very fast, MR is slow, so just doing MR is a waste
on a totally random number. As fast RN methods could be considered a
competitve advantage, the dirty details are often left to discover for
yourself, like the break even point. Of course, this depends on how fast you
can make the MR test run.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Rich Wales)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: could someone post public key that is tempered ?
Date: 29 Aug 2000 09:07:19 -0700
"jungle" wrote:
> the question is open : could someone post public key
> that is tempered & pgp will not detect added ADK to it ?
Have you read Ralf Senderek's paper?
(http://senderek.de/security/key-experiments.html)
Try Ralf's key "A4".
==> http://senderek.de/security/ADK-testkeys/key-A4
contains the actual binary key
==> http://senderek.de/security/ADK-testkeys/html/key-A4.html
contains an analysis of the key
According to Ralf, this key contains one legitimate ADK -- but it
also contains a second (illegitimate) ADK, which was added to the
unhashed part of the key (the kind of thing a malicious attacker
could do).
Ralf reported that PGP 5.5.3i and 6.5.1i saw both ADK's on key A4,
but they failed to note that the second ADK was in the wrong place,
and they encrypted messages to all three keys (the main key, the
legitimate ADK, and the unauthorized ADK) without complaining.
Now, I will admit that Ralf's tampering with this key did not go
totally undetected (since the newly added ADK was reported by PGP).
However, PGP did =not= report any problem with the extra ADK; it
treated the bogus addition exactly as if it were a legitimate part
of the user's public key.
By the way, the correct word in this situation is "tamper", not
"temper". (These two words may sound identical to native speakers
of some non-English languages, but they are completely different.)
Also, "tamper" is normally used together with the preposition "with"
(as in, "someone has tampered with this key", or "this key has been
tampered with").
Rich Wales [EMAIL PROTECTED] http://www.webcom.com/richw/
PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED.
RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: 96-bit LFSR needed
Date: Tue, 29 Aug 2000 15:59:23 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > I am trying out the stream cipher where I take three bytes from the
> > LFSR in the form (a, b, c) and return (((a+1)(b+1)) mod 257)+c) mod
256
> > as the stream output.
>
> Why? And how does the plaintext enter into this?
You use the output and xor it against the input.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED][Rot 13] (Eric Murray)
Crossposted-To: alt.cypherpunks,alt.cypherpunks.technical
Subject: Re: e-cash protocol concept, comments wanted
Date: 29 Aug 2000 09:21:03 -0700
In article <[EMAIL PROTECTED]>,
Julian Morrison <[EMAIL PROTECTED]> wrote:
>If you are knowledgeable about ecash, please check out my idea for a
>signature-based ecash protocol at
>http://fling.sourceforge.net/concepts.html
>
>Are there any major design bugs?
You don't make it clear, but I'm guessing from the context that the
'transaction recipt' is a use count, signed by the bank. Also, does the
originating bank keep a copy of the coin and check the hash against that,
or does it only keep the hash and associated use count, and check coins
against the hash? I'm guessing the latter. Which means that you're
depending on the difficulty of forcing a hash collision to keep the
coins secure. That's probably reasonable given appropriately-small
numbers of coins and an appropriately-large hash.
However, this scheme isn't fully anonymous- it requires that
you trust the banks not to collude. If Alice is spending a coin
with Bob and Bob's bank wants to know who he is buying things from,
it could collude with the other banks to look for coins with the same
hash value. Since there should only be one that matches, it's
easy to for the banks to track transactions if they wish.
>Are there major improvements you could suggest?
Redesign so that contacting the bank when receiving a coin is not required.
--
Eric Murray http://www.lne.com/ericm ericm at lne.com PGP keyid:E03F65E5
Security consulting: secure protocols, security reviews, standards, smartcards.
------------------------------
From: Chris Yuen <[EMAIL PROTECTED]>
Subject: Re: Reading recommendations on protocol design
Date: Tue, 29 Aug 2000 23:48:41 +0800
David A Molnar wrote:
>
> Chris Yuen <[EMAIL PROTECTED]> wrote:
> > Dear all,
>
> > Right now I'm looking for some materials on protocol design(in the
> > computer security area, not network protocols I'm referring to). Could
> > anyone of you recommend me some books, or materials(preferably online)
> > that contain such info? Thanks. Some introductory material would
> > probably
> > be very useful.
>
> Avi Rubin had a course on protocol design at NYU a few years back.
> The reading list and problem sets are on the web and they are very
> good. I think it's www.avirubin.com/ and look under courses taught.
>
> Another paper I like is "Robustness Principles for Public Key
> Protocols" by Ross Anderson (and someone else - Needham?).
> Google search for Ross Anderson and you'll find it.
>
> I'm not familiar with any books specifically in this area; would like to
> hear of any.
Thanks for the site and paper recommendations, I just went there and I
found it very useful, thanks a lot ;)
Chris
------------------------------
From: Daniel Leonard <[EMAIL PROTECTED]>
Subject: Re: A little technical note about intepreters
Date: Tue, 29 Aug 2000 16:23:20 GMT
On 29 Aug 2000, SCOTT19U.ZIP_GUY wrote:
> Also as far as maintaning code often a bad comment
> can lead the maintainer astray so that the code will
> remain buggy for years. For better to use comments that
> tell what comes in a routine and what goes out. Then a
> few comments as to what method but don't get excessive
>=20
>=20
> David A. Scott
> --=20
What I told in CS course as TA was that you should put comments as if you
would put footpage notes in an article or a book. That are comments in the
code, not function header comments. More often than not, the code speaks
for itself.
==========
Daniel L=E9onard
OGMP Informatics Division E-Mail: [EMAIL PROTECTED]
D=E9partement de Biochimie Tel : (514) 343-6111 ext 5149
Universit=E9 de Montr=E9al Fax : (514) 343-2210
Montr=E9al, Quebec Office: Pavillon Principal G-312
Canada H3C 3J7 WWW :
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Optimal length of the sieve before a Miller-Rabin test
Date: Tue, 29 Aug 2000 16:33:14 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (DJohn37050) wrote:
> My understanding of the reason to do the small primes tests before MR
is that
> you really want to have SOME confidence that what you run an MR test
on is a
> prime. That is, sieving is very fast, MR is slow, so just doing MR
is a waste
> on a totally random number. As fast RN methods could be considered a
> competitve advantage, the dirty details are often left to discover for
> yourself, like the break even point. Of course, this depends on how
fast you
> can make the MR test run.
In general with all the primes that are 16-bits, I find that about when
finding 512-bit primes I get a ratio of 206/26 for the two tests. This
means that 206 numbers were rejected by the trial division and 26 by MR
before a pseudo-prime was found.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Herman Rubin)
Crossposted-To: comp.programming
Subject: Re: On pseudo-random permutation
Date: 29 Aug 2000 11:31:39 -0500
In article <8ofpsm$g5e$[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote:
>David A. Wagner wrote:
>> Bryan Olson wrote:
>> > Given a generator
>> > of perfect random bits as the one and only source of
>> > randomness, can you find any procedure for generating
>> > perfectly uniform random permutations (of more than two
>> > elements) that strictly terminates?
>> Sure, no problem. It suffices to pick an integer in
>> the range 1 .. n!. The latter can be done by treating
>> the random bits as the binary expansion of a random real
>> number R in the interval [0,1).
Such a procedure does not "strictly terminate"; it
only terminates with probability 1. In fact, one
cannot get an event whose probability is not of the
form of m/2^n, m, n integers, which is guaranteed
to terminate.
A simple strategy is to
>> say that we output the integer i (where 1 <= i <= n!)
>> if (i-1)/n! <= R < i/n!. Note that we don't need all the
>> binary digits of R to determine which bucket R falls into;
>> it suffices to know a finite prefix of the binary
>> expansion of R, since (i-1)/n! and i/n! must differ at
>> some bit position of finite index.
This is correct. However, the method described is
not optimal, although the expected number of bits
used is within one of the optimal one.
Also, while the method you have proposed is correct, it
is not practical for large n. Computing i/n! is quite
difficult for n not small, and hard to handle. However,
one can generate random integers from 1 to k (or better,
from 0 to k-1) "optimally", but even doing it crudely
does not double the expected number of bits used over
the information bound.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
[EMAIL PROTECTED] Phone: (765)494-6054 FAX: (765)494-0558
------------------------------
From: [EMAIL PROTECTED]
Subject: Idea for creating primes
Date: Tue, 29 Aug 2000 16:58:51 GMT
Say you want to make an 'n' bit prime that is some multiple of 128 (I
chose this out of my head). What you do is make n/128 128-bit primes
as described below then multiply them all together (and multiply by
two) then add one. Next using all the known prime factors try to find
a primitive generator. If you can find one then you know for a fact
that the number is prime, iff the 128-bit primes are in fact prime.
You can test to see if a number is a genrerator by performing g^(p/q) !
= 1 for various 'q's that divide your testing prime 'p'.
To make the 128-bit primes you can use a sieve of divisors, then 8
Fermats tests and finally five MR tests. I find that no composites
ever get passed both the sieve and fermat tests, but the MR tests are a
bit more exacting.
So once you have the product 'p = p' + 1' where p' is the product of
the smaller primes and you have 'g' a primitive generator modulo p, you
now have a prime 'p'.
Since the smaller primes must be prime for this to work, we can recurse
a bit and factor those 128-bit primes and try to find a multiplicative
primitive.
One problem is that the first multiplicative primitive may be a big
number. So we can resolve this by testing 2..1000 (or any suitable
pattern).
This method is exacting (assuming the smaller primes are primes) giving
what are provable primes. I don't know if it's any faster since it
requires you to first find a suitable number of pseudo primes, then to
factor one less then them, then to find a multiplicative generator in
all the various fields.
Just an idea :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: I need ADK tampered key that PGP will not detect ADK, on it ...
Date: Tue, 29 Aug 2000 13:13:51 -0400
thanks for correction, stupid mistake ...
the question is open : could someone post public key that is tampered
& pgp will not detect added ADK to it ?
I need ADK tampered key that PGP will not detect ADK, on it ...
Rich Wales wrote:
>
> "jungle" wrote:
>
> > the question is open : could someone post public key
> > that is tampered & pgp will not detect added ADK to it ?
>
> Have you read Ralf Senderek's paper?
> (http://senderek.de/security/key-experiments.html)
>
> Try Ralf's key "A4".
>
> ==> http://senderek.de/security/ADK-testkeys/key-A4
> contains the actual binary key
I have this key ... thanks ...
have you read my post ?
==========================
the rule, from the time of introduction ADK was simple ...
don't use it, when key has ADK, don't use key ...
this is the rule that everyone should follow ...
PGP has no problem to indicate to me that public key has 2x ADK's in it ...
PGP is detecting 2x ADK keys ...
=========================
------------------------------
From: Andrew Carol <[EMAIL PROTECTED]>
Subject: Re: A little technical note about intepreters
Date: Tue, 29 Aug 2000 10:19:46 -0700
In article
<[EMAIL PROTECTED]>,
Daniel Leonard <[EMAIL PROTECTED]> wrote:
> What I told in CS course as TA was that you should put comments as if you
> would put footpage notes in an article or a book. That are comments in the
> code, not function header comments. More often than not, the code speaks
> for itself.
Code is telling the computer exactly WHAT to do.
Comments tells other programmers WHY you did it that way.
They might also explain assumptions about external state which MUST be
true for the code, as written, to work.
There is a huge difference.
Anybody who has put significant code away for a year or two and tried
to pick it back up. Or taken over someone elses code knows what I'm
talking about.
If code is written very cleanly, without clever optimisations, the code
might speak for itself.
The instant you do something "clever", like take advantage of some
trick of twos complement math, or a sneaky xor trick, or rely on a
subtle side-effect of another routine you've got problems. Even things
like assuming you can access unaligned integers is probably worth a
comment.
Oh well.....
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be allowed
Date: Tue, 29 Aug 2000 10:25:27 -0700
Sundial Services <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Mack wrote:
> > hmm seems to cover most of what PGP servers have done for a while
> > and kerberos and various other methods. wonder when the patent
> > was applied for.
> >
> > It may be facially invalid due to prior art.
>
>
> Thomas Edison once succintly described patents as "a license to steal,"
> although he owned more of them than almost anyone. They are a wonderful
> lawyer-esque invention, because even after you spend a boatload of legal
> fees to acquire one, you still have to defend it against all comers, any
> one of whom could [successfully] claim that (essentially) you or the
> patent-examiner screwed-up and your claim was invalid from the start ..
> as Mack essentially suggests here.
>
> So a patent provides what is actually a very dubious level of
> protection, especially in the software business, and it endlessly
> requires you to "defend it or lose it."
>
> The patent examiners simply can't, and don't, affirm that your claim is
> in fact worth the paper it is printed on. What they say is essentially
> what you heard in a game of "Clue," namely "I cannot disprove it," which
> when you think about it is -not- saying terribly much at all.
>
> In the very best of circumstances, patent law requires you to COMPLETELY
> DISCLOSE your invention in exchange for the right to (maybe..) exclude
> others from using it for a period of many years. That can be awful in
> the software business because your secrets are fully exposed to
> competitors who, likely as not, can simply "trump your trick" and have
> you begging them for a license. Even the slightest change to your
> algorithm can qualify as an "improvement" which is not only legal -- but
> blocks you from adopting the improvement in your own implementation!
>
> In my not-so-humble I'm-not-a-lawyer opinion, patents were an idea
> steeped in manufacturing .. and that is where they ought to stay.
> Computer software is much too close to the direct expression of "ideas"
> (which are unpatentable) and offer too many alternate ways of expressing
> the same "idea" (all of which qualify as "prior art" or "improvements"
> or simply "patent killers" .. and all of which you discover only after
> the patent has been granted and before you discover that it's
> worthless).
>
> If you're gonna make money with software, you're gonna have to do it by
> producing an altogether "better product," not by planting stakes around
> a particular embodiment of a particular idea or trick in your code,
> disclosing it to the world and proclaiming to all comers that "It's
> Mine!"
>
> I fear that good Mr. Edison was right after all.
Nice post. Well thought out points all around.
I think the famous quote was "A patent is just a license for a lawsuit"but I
could well be wrong.
The process has problems and as you pointed out, they are highlighted in the
software field. One point I'd like to add is the idea that these problems are
not easily addressed by logical solutions. As an example, many times the issue
of peer review, challenge and retirement and other "feedback" solutions are
discussed without the question being asked, "Does the solution remove all value
from the problem activity?"
Proponents of "content or functional review" fail to recognize that this is
really
weakness to a denial of service attack. Dealing with the examiner is bad enough,
if you are required to answer challenges from the field, you might as well pack
it in. This is unfair but why is it bad? It is a discriminator. Consider that it
separates the independent inventors and small companies from the process. Once
big company X gets a valuable patent in an area they simply fund an effort to
thwart all subsequent work by challenge.
The recent (hehehe) change requiring maintenance fees is a simple step that
results in the lapsing of a lot of nonsense. The biggest problem highlighted by
patents and software is the sheer speed of this new area and the archaic
structure of the patent office and process. Beings from dimension X are
trying to interact with beings from dimension Y.
In a new and specialized
field like computer cryptography, where are the bright folks found to serve
in the special art section? I still think this is a blip on the radar screen. A
sign
of living in interesting times. Your points are dead on target though, it seems
that something has to give.
Paul
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Idea for creating primes
Date: 29 Aug 2000 17:21:38 GMT
[EMAIL PROTECTED] wrote:
> This method is exacting (assuming the smaller primes are primes) giving
> what are provable primes. I don't know if it's any faster since it
> requires you to first find a suitable number of pseudo primes, then to
> factor one less then them, then to find a multiplicative generator in
> all the various fields.
Well, you can do this recursively until you get to a point where it's easy
to prove primality via trial division.
Try checking out Preda Mihailescu's work or Ueli Maurer's paper on
generating provable primes. This is intriguing stuff...
> Just an idea :)
Nice idea!
Next question - can we work out a way to encrypt a proof of primality
along with the number of which it proves the primality in such a way that
a) we know that the encrypted number is prime (i.e. the proof still works)
but
b) we have no idea what the encrypted number is
and potentially
c) we can multiply together two encrypted numbers E(p), E(q) which have
encrypted proofs of primality to obtain E(pq), then give a proof
that D(E(pq)) = n, the product of two primes and an RSA modulus?
It seems at the minimum we'd need an encryption scheme which is
a multiplicative homomorphism. But there may be more to it than that;
I haven't thought about it at length. For one thing, over what would it
be a homomorphism, since you have many different groups involved? :\
-David
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Future computing power
Date: Tue, 29 Aug 2000 11:34:44 -0600
David A Molnar wrote:
<snip>
> Suddenly I have a vision of Furbies chattering keys in their sleep.
> Sort of like the Chinese Lottery, but without the set top boxes.
And the children's talk provides the entropy to randomize the
search so we don't need central coordination.
JM
------------------------------
Date: Tue, 29 Aug 2000 13:43:42 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: PRNG Test Theory
Paul Pires wrote:
> Yes but there is an interesting question here. Can rejecting Non-random
> (determined by any means) ever result in random? My Knee jerk reaction is no
> but I never thought of it that way before.
The answer is clearly no for finite rejection tests. Consider that a set of
tests that deals only with the most recent N bits of output must enter a cycle
with length < 2^N.
For rejection systems that deal with all of the output (finite in each instance,
but ever-increasing), but have a description of "random" of finite size must
also enter a cycle (*) because a finite description of "random" permits only a
finite criteria for choosing the next bit. The N-bit definition of "random"
provides only 2^N fitness values. So as the output sequence grows the
collisions among the fitness results will increase in frequency until they
dominate the generator.
I have not spent the time to prove that the increasing collision frequency
actually forces a cycle, but I believe this can be shown.
(*) this assumes that when the fitness of the prefix+'0' sequence is identical
to the fitness of the prefix+'1' sequence a deterministic selection is made; say
alternation.
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Future computing power
Date: Tue, 29 Aug 2000 12:46:01 -0500
Jeffrey Williams wrote:
> Tom, like most of us, you've developed a case of tunnel vision. Most
> people do not read sci.crypt and have little or no clue at all about
> security. I suspect that it would be insanely easy to sell Joe Q Public
> some software that used 64-bit keys.
Preach on Brother..
The public is easily sold on seeming difficulty, and does not often understand
the difference between paper strength and solid code.
>
>
> We're a society that uses technology heavily while maintaining a minimal
> understanding of that technology. What's scary is that the reporters and
> teachers whose job it is to inform the public don't really understand the
> technology either. Not that long ago, I was told by a high school computer
> science teacher that putting comments in code was very bad because it made
> the code run slower (true enough, but only if you're using an
> interpreter). He didn't understand the difference between interpreted and
> compiled languages. And he's teaching our kids to program.
He is totally wrong in the context of compilers,
Partially wrong in the case of bytecode generating interpreters( perl) in that
you will have a front end bytecode translation speed hit, after which there
will be no speed drop
and Fully correct in the case of true interpreted language that always
traverses the code.
OTOH if you are concerned about speed you use a compiled language(preferably a
good optimizing compiler) If you are forced to use an interpreter, you
generate your source code, and use a comment stripper to generate the "live"
code. In any case, the source should ALWAYS be commented -- trust me, it is
easier to comment it on the first pass than to come back to it 6 months later
and try to figure out how your(or worse someone else's) clever hack works, and
how to fix it/ add new functionalities.
Commenting is also an excellent tool for making you think about what exactly
you are doing, and has( at least for me) led to some substantial speedups by
eliminating bogus code.
------------------------------
From: "JL" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: I need ADK tampered key that PGP will not detect ADK, on it ...
Date: Tue, 29 Aug 2000 17:55:53 GMT
"jungle" <[EMAIL PROTECTED]> a �crit dans le message news:
[EMAIL PROTECTED]
> the question is open : could someone post public key that is tampered
> [with] & pgp will not detect added ADK to it ?
It doesn't depend on the key, but on the PGP version which is used.
PGP versions from 5.x and up to 6.5.3 will always detect and encrypt to ADKs,
whether legitimate or not. Version 6.5.8 (the fixed one) will only detect and
encrypt to legitimate ADKs. There currently are no versions which will detect
fake ADKs but not encrypt to them.
JL.
------------------------------
From: "John Matzen" <jmatzen(at)origin(d0t)ea(d0t)com>
Subject: RSA n-bit key...is p and q n or is the mod n?
Date: Tue, 29 Aug 2000 12:54:34 -0500
When one speaks of a 512-bit RSA key, are p and q 512-bits, or is the
modulus 512-bits (meaning p and q are 256 bits)?
Thanks!
------------------------------
From: Ichinin <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Future computing power
Date: Tue, 29 Aug 2000 08:49:38 +0200
Actually, i have never laughed out loud when reading
Sci.crypt, but this is one exception :o)
Really, my question was serious. 65xx/80xx processors
are easy to program, and is the only asm language i
have experience with. (As well as the C64 kernel)
Regards,
Glenn
------------------------------
Date: Tue, 29 Aug 2000 14:09:03 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: PROMIS-software for worldwide spy network by US/Isreal
[EMAIL PROTECTED] wrote:
> Can we distinguish between stupid government and citizens please?
Probably not. The citizens are responsible for the actions of their
government.
------------------------------
** 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
******************************
