Cryptography-Digest Digest #612, Volume #11 Sun, 23 Apr 00 09:13:01 EDT
Contents:
Re: quantum computation FAQ? (David Crick)
Re: papers on stream ciphers (Thierry Moreau)
Re: Proving that you are who you say you are (Thierry Moreau)
Re: (MERCY) Overcomming the slack used by IV's (Tom St Denis)
Re: OAP-L3: Secure, but WAY more dificult to use than other equally secure
programs (Anthony Stephen Szopa)
Re: OAP-L3: Secure, but WAY more dificult to use than other equally (Tom St
Denis)
Re: quantum computation FAQ? (John Bailey)
Re: Szopa: troll or snake-oil salesman? (SCOTT19U.ZIP_GUY)
Re: OAP-L3: Secure, but WAY more dificult to use than other equally secure
programs (Anthony Stephen Szopa)
Re: OAP-L3: Secure, but WAY more dificult to use than other (Tom St Denis)
----------------------------------------------------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: quantum computation FAQ?
Date: Sun, 23 Apr 2000 09:23:15 +0100
I have to quote Schneier here from the latest Crypto-gram.
His comment made me laugh anyway :)
> Someone's built a 7-qubit quantum computer.
> Any RSA moduli less than three bits should watch out.
> <http://www.wired.com/news/technology/0,1282,35121,00.html>
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Subject: Re: papers on stream ciphers
Date: Sun, 23 Apr 2000 00:19:59 -0500
Joseph Ashwood wrote:
> Hey I've said the same thing over and over about stream
> ciphers, there aren't that many of them, roll your own and
> add to our knowledge. Of course I've also said that one
> should not limit yourself just using a good random number
> generator and XOR, that's weak against known attacks (like
> if I know your plaintext I can send valid streams as you).
> Try to add knowledge, not just security. I've tried many
> times, but I haven't found one that even begins to be
> secure.
> Joe
>
As I understand it, there are two issues in your call for stream cipher
enhancement:
The session key management issue, that arises because stream ciphers
need a different key for each message (to resist the known weaknesses of
stream ciphers). This issue is complex because not only the system
designer must be convinced that a unique secret session key is used for
each message, but each participant must be independently convinced as
well, according to the trust model implied in a given application. For
instance, the session key management issue might additionally call for
secret key freshness assurance for each participant.
The other issue ("knowledge") you seem to be referring to is less clear
to me. If it is a percieved need to change the properties of stream
ciphers, it looks like an impossible task. In any event, you might look
at http://www.connotech.com/frogbit.htm which is *not* a stream cipher
proposal, but mainly a proposal to add integrity protection, given that
a stream cipher primitive is the only tool at hand.
- Thierry Moreau
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Subject: Re: Proving that you are who you say you are
Date: Sun, 23 Apr 2000 00:38:24 -0500
[EMAIL PROTECTED] wrote:
> I'm going to be working on developing a client/server application pair
> [...]. I need some mechanism to insure that only _my_ client talks to
> the server. [...]This application will be used inside a large corporate
> intranet system, and, based on certain 'organizational politics' type
> issues, it is extremely likely that someone will try to create a
> rogue/imposter client. My job is to make sure that the person who tries
> this does not succeed. :-)
>
If you further think about this requirement, you might realize that a
central issue is granting and revoking access keys to legitimate users, in
a one-to-many configuration (one server location, many clients). Then, you
might look at http://www.connotech.com/sakem.htm.
>
> Does anyone have any suggestions? I feel like I must be missing an
> obvious solution here...
No, there are no obvious solution here ...
- Thierry Moreau
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: (MERCY) Overcomming the slack used by IV's
Date: Sun, 23 Apr 2000 11:45:29 GMT
Joseph Ashwood wrote:
>
> Because if you expand the sector number, you simply cannot
> run a defragmenter that doesn't know all your keys.
> Joe
>
> > However why can't
> > you just expand the sector number to the size of the
> block?
Actually that is moot since your disk is encrypted at the driver level.
When the defrager tries to read a sector the driver decrypts it, and
when it writes it to the new location it's encrypted.
So again my idea is valid.
Tom
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other equally secure
programs
Date: Sun, 23 Apr 2000 04:50:21 -0700
"Trevor L. Jackson, III" wrote:
>
> James Felling wrote:
>
> > This program is a clasic example of the assertion that any algortihim that
> > does not form a group over its keys can if reiterated enough be made
> > arbitrarially secure.
> >
> > I have withdrawn any criticisms that I have in re: the security of this
> > program provided that the Mix files are generated by a sulficient number of
> > passes of his processes.
>
> I think this begs the question of the definition of "sufficient". In another
> post the suggestion was made to have the user enter ~3000 characters of input,
> all of it "truly random". Since this is well over the average page of text (at
> ~2500 characters), we're not talking about a pass phrase, we're describing a
> "pass page".
>
> 1.) Given ~3000 "truly random" characters, or ~24K bits, one can find far more
> efficient application of that amount of entropy for security purposes. Even a
> 50% efficient application of the entropy should give a space of 2^12,000
> (10^~3600) rather than the quoted figure of 10^~459.
>
> 2.) Given that typing in a page of characters is an onerous, error prone
> process, one immediately considers automating it with a machine-readable
> representation of the input. But if the communicants using this system are
> going to pass around machine readable media why would they not pass around
> large keys and use a true OTP instead of a fake one?
>
> > I now wish for him to adress the severe usability and documentational
> > issues that his program possesses.
>
> I believe we have yet to see an adequate excuse for the existence of this
> software. I'm interested in learning it, if it becomes available.
The software is available at http://www.ciphile.com
Sufficient is user defined.
Here is a quote from the Helpful Hints Help File:
"Security Level -
1) Here is how you can convert from base two security levels to base
ten, and from base ten security levels to base two. Let's say you
have heard that a particular encryption software has a security
level of 8192 bits. This means that there are 2^8192 possible keys.
The calculation is to divide the base two exponent by 10 then
multiply by log 1024 or about 3.0103 to get the equivalent base ten
exponent. So the 8192 bit security level is the same as
approximately a 1E2466 base ten security level because
(8192 / 10) * 3.0103 = 2466.
And conversely, a base ten security level of 1E10,000 is equivalent
to a base two security level of 33,219 bits because
(10,000 / 3.0103) * 10 = 33,219."
Here also is a list of the current processes available and their
security levels as explained in the Security Level Help Page:
SETUP AND ARRAY PROCESSING MENU -
(1) Mix a MixFile(X) Program
(2) MixFile(X) Shuffle / Re-Distribute Program
(3) Re-Distribute / Shuffle Program
(4) Variable Re-Distribute / Append Program
(5) Variable Re-Distribute / Shuffle Program
(11) Scramble MixFile(X) Program
(1) 14! = 87.18E9
(2) 2! - 14! = 2 - 87.18E9
(3) 14! = 87.18E9
(4) (999)^14 = 9.86E41
(5) ((999)^14)*14! = 8.6E52
(11) 10! = 3.63E6
RANDOM NUMBER PROCESSING MENU -
(1) Mix a RandOut(X) Program
(2) RandOut(X) Shuffle / Re-Distribute Program
(3) Re-Distribute / Shuffle Program
(4) Variable Re-Distribute / Append Program
(5) Variable Re-Distribute / Shuffle Program
(1) 14! = 87.18E9
(2) 2! - 10! = 2 - 3.63E6
(3) 14! = 87.18E9
(4) (999)^14 = 9.86E41
(5) ((999)^14)*14! = 8.6E52
The user simply runs as many processes as needed to achieve the
desired security level.
Also, here is the table that describes the current implementation of
OAP-L3 random digit generator.
Set1 Set2 Set3 Set4 Set5 Num
7246301598 5382460791 1352094678 9275041683 6504213987 1
7845069213 6153704298 7801354926 4851973062 9235746081 5
1904735268 4019682573 2184065379 0219578634 1920346857 1
0819374256 4273860915 8670159423 1740298365 8263041759 0
3145682790 6421935087 9710324865 4317502968 0732461859 5
1495638027 8601534279 8523419670 7985134260 5401937826 5
6712958403 4139708562 8642375190 3620189754 5164079382 4
1093865724 9152743860 7618943205 5641298037 6758034219 4
8610273495 6491830725 2705941368 1987652304 6172035984 0
7568421390 3091268475 1846327095 6158479302 0279348651 1
9310845672 6729480531 0876925413 5473910268 3680192547 3
6327491805 0567483192 0835974162 0741965823 4531928607 6
And finally, here is a table (without explanation) that forms the
basis of OAP-L3 Version 5.0
When I release Version 4.3, then I will post the entire document
describing the fundamentals of Version 5.0 (including this table)
on my web site.
Table 1 -
Usg IIP MixFile1 MixFile2 MixFile3 Digit
5 8 6327491805 5382460791 1352094678 9
1 3 7246301598 6153704298 7801354926 3
6 5 7845069213 4019682573 2184065379 4
2 9 1904735268 4273860915 8670159423 7
4 1 0819374256 6421935087 9710324865 9
3 7 3145682790 8601534279 8523419670 4
1 2 1495638027 4139708562 8642375190 4
4 0 6712958403 9152743860 7618943205 5
6 4 1093865724 6491830725 2705941368 6
2 6 8610273495 3091268475 1846327095 8
5 8 7568421390 6729480531 0876925413 8
3 1 9310845672 0567483192 0835974162 9
Usg = usage
IIP = initial index pointer
You might be able to determine how this new random digit generator
functions by inspection. (Try to solve it as a brain teaser puzzle.)
I explain the software and suddenly a post appears with a retraction,
and an affirmation of the security of OAP-L3. My explanation is the
very same one found in the Help Files. My posted explanation was
clear and convincing. So are the Help Files. Yet you insist that
the Help Files are problematic. (Or whoever it is that still has a
problem with the documentation. You expect me to believe you read
it 5 times? And only when I post the explanation do you begin to
get it? It is the same explanation that appears in the Help Files.
I cannot possibly believe you have been telling the truth unless
you are ill.)
I am not confused.
You appear to still be diseased with some sort of mental illness.
Would you like to admit it and talk about it.
Or I can give you my standard challenge:
The first word on the Theory Help File page is "Theory." So, is
there anything you don't understand about this word "theory?"
If you need to look it up in the dictionary or encyclopedia,
please. We will wait.
Here is the following sentence, the first sentence on the Theory
Help Page:
"The foundation of the OTP system for encrypting messages rests on
generating and using random numbers such that predicting any given
random number used to encrypt a character in an original message is
just as likely to be any of all the possible random numbers
available."
Is there anything you don't understand about this sentence?
Here is the following sentence:
"So the primary goal of this encryption software is to generate
such random numbers."
Is there anything you don't understand about this sentence?
Now please continue reading each sentence. When you come to a
sentence you do not understand post a reply to this post and we
will evaluate the problem you have with the sentence that is
incomprehensible to you. Let us know which sentence it is and the
nature of your confusion so I can give you a good response.
You wanted help, I am here to give it to you.
Do you accept my challenge?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other equally
Date: Sun, 23 Apr 2000 12:00:30 GMT
Anthony Stephen Szopa wrote:
> The software is available at http://www.ciphile.com
>
> Sufficient is user defined.
Then you allow the users to be insecure. Very good.
> Here is a quote from the Helpful Hints Help File:
>
> "Security Level -
>
> 1) Here is how you can convert from base two security levels to base
> ten, and from base ten security levels to base two. Let's say you
> have heard that a particular encryption software has a security
> level of 8192 bits. This means that there are 2^8192 possible keys.
Actually no you are wrong. Typically when we say something vague like
"128 bit security" that means the best method to find the plaintext is
to try all keys. It doesn't mean that there are 2^128 keys. For
example a 256-bit RSA key is could be vaguely called 40-bit security (or
less). Although that comparaison is not techincally valid it shows off
what it means.
> The calculation is to divide the base two exponent by 10 then
> multiply by log 1024 or about 3.0103 to get the equivalent base ten
> exponent. So the 8192 bit security level is the same as
> approximately a 1E2466 base ten security level because
> (8192 / 10) * 3.0103 = 2466.
That is so meaningless.
> And conversely, a base ten security level of 1E10,000 is equivalent
> to a base two security level of 33,219 bits because
> (10,000 / 3.0103) * 10 = 33,219."
Any symmetric key in excess of 128 bits is truly a waste. In a *real*
cryptosystem thirty-three thousand bits are probably not as easy to come
about.
>
> Here also is a list of the current processes available and their
> security levels as explained in the Security Level Help Page:
>
> SETUP AND ARRAY PROCESSING MENU -
> (1) Mix a MixFile(X) Program
> (2) MixFile(X) Shuffle / Re-Distribute Program
> (3) Re-Distribute / Shuffle Program
> (4) Variable Re-Distribute / Append Program
> (5) Variable Re-Distribute / Shuffle Program
> (11) Scramble MixFile(X) Program
>
> (1) 14! = 87.18E9
Why not just write 14! = 87178291200 ?
> (2) 2! - 14! = 2 - 87.18E9
> (3) 14! = 87.18E9
> (4) (999)^14 = 9.86E41
> (5) ((999)^14)*14! = 8.6E52
> (11) 10! = 3.63E6
Again 10! = 3628800, what are these for?
>
> RANDOM NUMBER PROCESSING MENU -
> (1) Mix a RandOut(X) Program
> (2) RandOut(X) Shuffle / Re-Distribute Program
> (3) Re-Distribute / Shuffle Program
> (4) Variable Re-Distribute / Append Program
> (5) Variable Re-Distribute / Shuffle Program
>
> (1) 14! = 87.18E9
> (2) 2! - 10! = 2 - 3.63E6
> (3) 14! = 87.18E9
> (4) (999)^14 = 9.86E41
> (5) ((999)^14)*14! = 8.6E52
>
> The user simply runs as many processes as needed to achieve the
> desired security level.
>
> Also, here is the table that describes the current implementation of
> OAP-L3 random digit generator.
>
> Set1 Set2 Set3 Set4 Set5 Num
> 7246301598 5382460791 1352094678 9275041683 6504213987 1
> 7845069213 6153704298 7801354926 4851973062 9235746081 5
> 1904735268 4019682573 2184065379 0219578634 1920346857 1
>
> 0819374256 4273860915 8670159423 1740298365 8263041759 0
> 3145682790 6421935087 9710324865 4317502968 0732461859 5
> 1495638027 8601534279 8523419670 7985134260 5401937826 5
>
> 6712958403 4139708562 8642375190 3620189754 5164079382 4
> 1093865724 9152743860 7618943205 5641298037 6758034219 4
> 8610273495 6491830725 2705941368 1987652304 6172035984 0
>
> 7568421390 3091268475 1846327095 6158479302 0279348651 1
> 9310845672 6729480531 0876925413 5473910268 3680192547 3
> 6327491805 0567483192 0835974162 0741965823 4531928607 6
>
> And finally, here is a table (without explanation) that forms the
> basis of OAP-L3 Version 5.0
>
> When I release Version 4.3, then I will post the entire document
> describing the fundamentals of Version 5.0 (including this table)
> on my web site.
How about the source code? Or make a C ref copy of your algorithm.
Basically just grow up. Stop posting small numbers in E notation to
make yourself look smart, post some C ref code and let us try to tear it
apart.
I am being sincere now, I am not joking around. If you respond to this
(at all) in your typically hazing manner then the group will be able to
see you for the troll we think you really are.
Tom
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: quantum computation FAQ?
Date: Sun, 23 Apr 2000 12:43:25 GMT
On 23 Apr 2000 04:13:02 GMT, David A Molnar <[EMAIL PROTECTED]>
wrote:
>I've drafted an outline of a possible FAQ which follows this message.
>Comments appreciated. Everything from "we don't need no steenkin' FAQ"
>to "it's been done before and done better" to "you're not qualified to
>write it" to specific comments on formatting, addition or deletion of
>questions, and so on.
Right On!!
To help the project, I can offer a key word indexed collection of
reprints from Los Alamos National Archive on quantum computing topics
from which I would be happy to glean articles (by URL to pdf) which
answer key subjects--eg what's a good survey available on the web,
where can I find Shor's or Grover's original papers, etc.
Also, I am sure many could contribute reviews of recent survey books
which cover the subject: eg Feynman and Computation
and lastly, there are web pages on the subject--some of which are
current and coherent.
Lastly--there may be a need for it to be multi-lingual--computerspeak
vs physicsspeak :-)--- or in some way manage a bridge between the two
disciplines without talking down to monolinguals from either.
A start would be to cross-post your original message to sci.physics
(where you pick-up the nuts) or sci.physics.research (where if you are
a non-physicist they may moderase your post)
John
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Szopa: troll or snake-oil salesman?
Date: 23 Apr 2000 12:43:18 GMT
[EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
>lordcow77 <[EMAIL PROTECTED]> wrote:
>
>: If he's a snake-oil salesman, someone might want to
>: prepare a reasonably comprehensive FAQ specifically mentioning
>: his software for posting whenever he comes around again.
>
>The "crypto link farm"
>(http://www.cs.auckland.ac.nz/~pgut001/links.html) already has Ciphile
>Software placed in its comprehensive "snake oil" section.
>
>This section makes for amusing reading, incidentally.
By the way Tim some of the sites that are in the list are not
Snake Oil. The maintainer of the list tends to put methods that
are different in the list. Mine is proudly in the list becuase I
think most of the so called crypto gods are phony, No one sloved
my contests and the last contest was such none of the weak phony
AES methods could have been used to do a contest in the same way
since they lack the ability to be secure enough. I made a challange
to the phony crypto gods none took it up because in there hearts they
know the AES stuff is a joke to lull the public into using weak crypto
TakeCare
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other equally
secure programs
Date: Sun, 23 Apr 2000 05:49:51 -0700
Tom St Denis wrote:
>
> Anthony Stephen Szopa wrote:
> > The software is available at http://www.ciphile.com
> >
> > Sufficient is user defined.
>
> Then you allow the users to be insecure. Very good.
>
> > Here is a quote from the Helpful Hints Help File:
> >
> > "Security Level -
> >
> > 1) Here is how you can convert from base two security levels to base
> > ten, and from base ten security levels to base two. Let's say you
> > have heard that a particular encryption software has a security
> > level of 8192 bits. This means that there are 2^8192 possible keys.
>
> Actually no you are wrong. Typically when we say something vague like
> "128 bit security" that means the best method to find the plaintext is
> to try all keys. It doesn't mean that there are 2^128 keys. For
> example a 256-bit RSA key is could be vaguely called 40-bit security (or
> less). Although that comparaison is not techincally valid it shows off
> what it means.
>
> > The calculation is to divide the base two exponent by 10 then
> > multiply by log 1024 or about 3.0103 to get the equivalent base ten
> > exponent. So the 8192 bit security level is the same as
> > approximately a 1E2466 base ten security level because
> > (8192 / 10) * 3.0103 = 2466.
>
> That is so meaningless.
>
> > And conversely, a base ten security level of 1E10,000 is equivalent
> > to a base two security level of 33,219 bits because
> > (10,000 / 3.0103) * 10 = 33,219."
>
> Any symmetric key in excess of 128 bits is truly a waste. In a *real*
> cryptosystem thirty-three thousand bits are probably not as easy to come
> about.
>
> >
> > Here also is a list of the current processes available and their
> > security levels as explained in the Security Level Help Page:
> >
> > SETUP AND ARRAY PROCESSING MENU -
> > (1) Mix a MixFile(X) Program
> > (2) MixFile(X) Shuffle / Re-Distribute Program
> > (3) Re-Distribute / Shuffle Program
> > (4) Variable Re-Distribute / Append Program
> > (5) Variable Re-Distribute / Shuffle Program
> > (11) Scramble MixFile(X) Program
> >
> > (1) 14! = 87.18E9
>
> Why not just write 14! = 87178291200 ?
>
> > (2) 2! - 14! = 2 - 87.18E9
> > (3) 14! = 87.18E9
> > (4) (999)^14 = 9.86E41
> > (5) ((999)^14)*14! = 8.6E52
> > (11) 10! = 3.63E6
>
> Again 10! = 3628800, what are these for?
>
> >
> > RANDOM NUMBER PROCESSING MENU -
> > (1) Mix a RandOut(X) Program
> > (2) RandOut(X) Shuffle / Re-Distribute Program
> > (3) Re-Distribute / Shuffle Program
> > (4) Variable Re-Distribute / Append Program
> > (5) Variable Re-Distribute / Shuffle Program
> >
> > (1) 14! = 87.18E9
> > (2) 2! - 10! = 2 - 3.63E6
> > (3) 14! = 87.18E9
> > (4) (999)^14 = 9.86E41
> > (5) ((999)^14)*14! = 8.6E52
> >
> > The user simply runs as many processes as needed to achieve the
> > desired security level.
> >
> > Also, here is the table that describes the current implementation of
> > OAP-L3 random digit generator.
> >
> > Set1 Set2 Set3 Set4 Set5 Num
> > 7246301598 5382460791 1352094678 9275041683 6504213987 1
> > 7845069213 6153704298 7801354926 4851973062 9235746081 5
> > 1904735268 4019682573 2184065379 0219578634 1920346857 1
> >
> > 0819374256 4273860915 8670159423 1740298365 8263041759 0
> > 3145682790 6421935087 9710324865 4317502968 0732461859 5
> > 1495638027 8601534279 8523419670 7985134260 5401937826 5
> >
> > 6712958403 4139708562 8642375190 3620189754 5164079382 4
> > 1093865724 9152743860 7618943205 5641298037 6758034219 4
> > 8610273495 6491830725 2705941368 1987652304 6172035984 0
> >
> > 7568421390 3091268475 1846327095 6158479302 0279348651 1
> > 9310845672 6729480531 0876925413 5473910268 3680192547 3
> > 6327491805 0567483192 0835974162 0741965823 4531928607 6
> >
> > And finally, here is a table (without explanation) that forms the
> > basis of OAP-L3 Version 5.0
> >
> > When I release Version 4.3, then I will post the entire document
> > describing the fundamentals of Version 5.0 (including this table)
> > on my web site.
>
> How about the source code? Or make a C ref copy of your algorithm.
>
> Basically just grow up. Stop posting small numbers in E notation to
> make yourself look smart, post some C ref code and let us try to tear it
> apart.
>
> I am being sincere now, I am not joking around. If you respond to this
> (at all) in your typically hazing manner then the group will be able to
> see you for the troll we think you really are.
>
> Tom
I thought you were a phony.
You are in high school?
You find abstract algebra difficult?
You post in several news groups on many subjects?
And I need to grow up, too?
Since it appears obvious to me that you misrepresented yourself to
me, I am interested as to how many others you have misrepresented
yourself to, and how may others you continue to misrepresent
yourself to. (no response expected. this is just a rhetorical
statement.)
A liar like an adulterer can never be trusted again.
When people look into your eyes I hope they see what I have learned
about you. Think about it when they gaze into your eyes.
I am sure you can find others in this and other news groups to play
with. If they trust you it is at their own risk.
So you should not waste anymore of your time conversing with me.
There are plenty of other suckers out there for your delectation.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other
Date: Sun, 23 Apr 2000 13:07:57 GMT
Anthony Stephen Szopa wrote:
> I thought you were a phony.
>
> You are in high school?
>
> You find abstract algebra difficult?
>
> You post in several news groups on many subjects?
>
> And I need to grow up, too?
You are doubting I am in high school? I don't need to prove myself to
you. Look me up if you want my DOB is April 7th 1982, My legal name is
Thomas James St Denis, that should be enough to find where I am, you can
call me up if you wish.
>
> Since it appears obvious to me that you misrepresented yourself to
> me, I am interested as to how many others you have misrepresented
> yourself to, and how may others you continue to misrepresent
> yourself to. (no response expected. this is just a rhetorical
> statement.)
>
> A liar like an adulterer can never be trusted again.
But I am not lying.
> When people look into your eyes I hope they see what I have learned
> about you. Think about it when they gaze into your eyes.
>
> I am sure you can find others in this and other news groups to play
> with. If they trust you it is at their own risk.
>
> So you should not waste anymore of your time conversing with me.
> There are plenty of other suckers out there for your delectation.
You see, you didn't respond to my questions. You just targteted *me*.
How about you focus on your 'theory' and less the posters.
Face it, your a troll.
Tom
------------------------------
** 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
******************************
