Cryptography-Digest Digest #870, Volume #8 Sat, 9 Jan 99 10:13:03 EST
Contents:
Secure Method Intact ("hapticz")
Re: RSA-Modulus decomposition (David Hamilton)
Re: U.S. Spying On Friend And Foe ([EMAIL PROTECTED])
How Many PINs Can Fit In The Head Of An Angel? (Moniker)
Free Public Key Pascal Source Code (Walied Othman)
Re: Factoring ("Hub-R-ISS-1")
Re: Help me with this crypto ! ([EMAIL PROTECTED])
Re: Help me with this crypto ! ([EMAIL PROTECTED])
Re: Factoring ("Michael Scott")
AES and diffusion with 128-bit block length (David Crick)
Re: On the Generation of Pseudo-OTP ([EMAIL PROTECTED])
Re: On the Generation of Pseudo-OTP ([EMAIL PROTECTED])
Re: Birthday Attack calculations. ([EMAIL PROTECTED])
SCOTT19U ENTROPY ([EMAIL PROTECTED])
Re: ScramDisk - password size - high ASCII ([EMAIL PROTECTED])
Re: On the Generation of Pseudo-OTP ("Trevor Jackson,III")
----------------------------------------------------------------------------
From: "hapticz" <[EMAIL PROTECTED]>
Subject: Secure Method Intact
Date: Sat, 9 Jan 1999 01:37:46 -0500
after fiddling with des, blowfish, rsa and others, i have discovered a
truely secure process.
it is within my wifes head, it is completely secure and public. only she and
her women friends understand how it works and are able to utilize it with no
hindrance to/from any known government. it allows them to communicate
across vast reaches of topics and cultures yet requires no visible
parapernalia other than the air between their mouth and ears.
i have no clue as to how they are able to totally obfuscate the most mundane
of ideas topics and concepts into a stream of completely random utterings
and vocalizations.
maybe some day they will reveal this marvelous system to me, but for now,
oh welll......
has anyone else noticed this??
--
best regards
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (David Hamilton)
Crossposted-To:
alt.privacy,alt.security,alt.security.pgp,comp.security.pgp.discuss,talk.politics.crypto
Subject: Re: RSA-Modulus decomposition
Date: Fri, 08 Jan 1999 18:43:36 GMT
=====BEGIN PGP SIGNED MESSAGE=====
[EMAIL PROTECTED] wrote:
>Hello all,
>It is very easy to find decomposition of a
>modulus to it�s primes.
>Let n=pq be a modulus. Let m be a least
>message for which m^2 mod n = m.
>Then m-1 is p or q.
(snip some)
This is how things are. Alex ([EMAIL PROTECTED]) makes silly, untrue
claims. People issue challenges that give him/her a chance to prove those
claims. Alex refuses to accept all challenges. Why? Because Alex makes silly,
untrue claims.
David Hamilton. Only I give the right to read what I write and PGP allows me
to make that choice. Use PGP now.
I have revoked 2048 bit RSA key ID 0x40F703B9. Please do not use. Do use:-
2048bit rsa ID=0xFA412179 Fp=08DE A9CB D8D8 B282 FA14 58F6 69CE D32D
4096bit dh ID=0xA07AEA5E Fp=28BA 9E4C CA47 09C3 7B8A CE14 36F3 3560 A07A EA5E
Both keys dated 1998/04/08 with sole UserID=<[EMAIL PROTECTED]>
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
Comment: Signed with RSA 2048 bit key
iQEVAwUBNpZQOso1RmX6QSF5AQHVAAgApK3JRo94kTQan/KBa84FipmGg8f0MT4f
Qi01pIOTN2d2dcya8xur9EfmzKRUh541XlzpgFXuz/zVZMfd9qBKbvRtIXPsH0Bh
X7unFNGm8Tzebn2/Sni5mzqshQCDiaiAuHRAA7eJtT9QaLgcQjsKF0q4uHcF+Ccx
wKtwH9QDc+AEFMaSrwvwUAzo1PVRon2xJuW0hzb4OAFxK8FFAnzr4vi5RAsJ4b6g
9OYeHK9KEobzSnb07VzXroNYIHSB8vg6tD4Eb1zWtPcx71Z0X1c+R3Yx9pTxDiPT
AqpChj3c5XPLlMGumWNz0xP9SZL0/Z7ZfFPVgfBm7ki1O1FJxV7UZg==
=yEa7
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: U.S. Spying On Friend And Foe
Date: Tue, 05 Jan 1999 23:57:24 GMT
In article <[EMAIL PROTECTED]>,
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
> "Tony T. Warnock" wrote:
> > The great problem of "friends" spying on the US is that the
> > "friend" may not be able to keep secrets. Some of our allies may not
> > mean harm to us, but they cannot keep secrets. Vice versa.
>
> The British can keep secrets, and they have an Official Secrets Act to
> enforce it.
>
You mean the British Government can keep secrets from the people.
Which may be one reason the Mad Cow thing was so bad there. It is
a polite society that hids the truth from it's people until almost
to late.
--
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Moniker <[EMAIL PROTECTED]>
Subject: How Many PINs Can Fit In The Head Of An Angel?
Date: Sat, 09 Jan 1999 02:39:17 -1000
How Many PINs Can Fit In The Head Of An Angel?
144,000
http://www2.csl.sri.com/csfw/
http://www.itd.nrl.navy.mil/ITD/5540/ieee/CSFW96proceedings.html
aa bb cc dd ee ff g9 h8 i1 j7 k8 l1
m3 n4 o0 p4 q6 r2 s5 t2 uc v7 w3 xf y7 z2
=====BEGIN PGP SIGNATURE=====
Version: PGPgodware 9.5.3i for extraterrestrial use
<http://www.holymackerel.org>
Comment: Signed with RSA 1048576 bit key
feeddeadbeef205ee1fl05e25ca4e7e22eada5e42e45e2ha215s4e11ed
3i282815a148abe21f70cca42eada110fa3e55a9e14ave2754ec1a13a7
5a113ea3e55agec514937e3a11adde55d5c022a24e23028c5ad02c03==
=eSGO
=====END PGP SIGNATURE=====
------------------------------
From: Walied Othman <[EMAIL PROTECTED]>
Subject: Free Public Key Pascal Source Code
Date: Sat, 09 Jan 1999 12:16:11 +0100
avilable at
http://ace.ulyssis.student.kuleuven.ac.be/~triade/GInt/
------------------------------
From: "Hub-R-ISS-1" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Factoring
Date: Sat, 9 Jan 1999 22:18:00 +1100
I'd just like to repeat the warning against downloading .exe files from even
slightly suspect sites.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Help me with this crypto !
Date: Sat, 09 Jan 1999 11:18:55 GMT
>
> > I need some help with this crypto (or algorithm).
> > I have a special box where you input some numbers and the box give you
> > some numbers back.
> > The first person who solves this will get a 40 dollars reward.
> > I have some examples where i have input some numbers.
> >
> > Examples:
> >
> > Input Output
> > -------- --------
> > 11111111 28234105
> > 00000000 84335240
> > 00000001 74331395
> > 00000002 12539925
> > 00000003 09409071
> > 99999999 84348439
> > 88888888 15936752
> > 10000000 25903915
> > 12345678 59340407
> >
> > (if i input these numbers i always get the same output)
>
Can you reverse the process, use the Outputs for input and get Inputs for
output?
NO, i cant reverse the input/output numbers.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Help me with this crypto !
Date: Sat, 09 Jan 1999 11:28:10 GMT
> >
> > I need some help with this crypto (or algorithm).
> > I have a special box where you input some numbers and the box give you
> > some numbers back.
>
> C'mon, we need more information than this. What sort of box? With wires
> in it? How do you input the numbers? Switches?
>
No, its looks/acts like a standard calculator without + - * / = keys.
> Anyway, more than nine sample numbers will be needed to solve
> the problem...
>
> > (if i input these numbers i always get the same output)
> >
> > PS. Could it be randomly generated numbers ??
>
> Well...not if you're always getting the same results..
>
Actually, it could be random numbers, because after every input
i must press the enter-key and then i get the output number.
After that the box could intialize the random generator so it always is
using the same random pattern.
But im not sure...
As i wrote earlier, if i input 00000000 i always get 84335240.
/Simon
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: Factoring
Date: Sat, 9 Jan 1999 12:53:12 -0000
So download the source from ftp://ftp.compapp.dcu.ie/pub/crypto/miracl.zip
and compile it yourself!
I recommend Borland C V4.5. Find the file factor.c and the library bc32.lib,
copy the header files miracl.h and mirdef.h32 (renamed to mirdef.h) to
....\bc45\include\, and compile as:-
bcc32 factor.c bc32.lib
Mike Scott
Hub-R-ISS-1 wrote in message <[EMAIL PROTECTED]>...
>I'd just like to repeat the warning against downloading .exe files from
even
>slightly suspect sites.
>
>
------------------------------
Date: Sat, 09 Jan 1999 13:14:22 +0000
From: David Crick <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: AES and diffusion with 128-bit block length
In AC2 (section 15.3, p363 in my copy), BS writes:
"There is some argument in the academic community whether a 64-bit
block is long enough. On the one hand, a 64-bit block length only
diffuses plaintext over 8 bytes of ciphertext. On the other hand,
a longer block length makes it harder to hide patterms securely;
there is more room to make mistakes."
How do the various AES submissions perform and compare with their
larger block sizes?
David.
--
+---------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/~vidcad/ |
| Damon Hill WC '96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| Brundle Quotes Page: http://members.tripod.com/~vidcad/martin_b.htm |
| PGP Public Key: (RSA) 0x22D5C7A9 00252D3E4FDECAB3 F9842264F64303EC |
+---------------------------------------------------------------------+
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On the Generation of Pseudo-OTP
Date: Sat, 09 Jan 1999 14:03:19 +0100
Mok-Kong Shen wrote:
>
> [EMAIL PROTECTED] wrote:
> > ...
> > There are some special problems that can be solved using OTPs based on
> > hardware. In this case it wouldn't make sense to use the much weaker
> > software to solve the problem.
> >
> > In all other cases I wouldn't even think about OTPs and use the present
> > cryptographic systems or develope new ones based on existing technology.
>
> However the context of my proposal is that one can only get
> 56-bit cryptos (and very likely only software). So I think that even
> a not so good approximation of an OTP helps to a certain degree, for
> it can be used in conjunction with a 56-bit crypto software and
> enhance its strength. We have to collect all useful things and
> combine them, so that those who can only get 56-bit cryptos (those
> outside of the 33 countries) can still obtain adequate security
> in their communications.
>
> M. K. Shen
I think there are much better (simpler and more conservative) solutions:
gnuPG (http://www.d.shuttle.de/isil/gnupg/) is a completely free and
this way not restricted cryptographic package compatible to PGP (at the
moment a beta version exists).
The developer of commercial cryptographic software are beginning to
deliver
their products from countries that don't restrict the export of
cryptographic software.
The solutions you try to find are only interesting as part of
applications.
So what do you want to do with your algorithm?
EMail clients will be more useful when using PGP/gnuPG plugins so they
can simply interact with existing software (mutt, mailcrypt for emacs,
exmh and pine do exactly this).
For harddisk encryption scramdisk will do the same if you are using
win95.
Some time ago in this group a free program for NT was mentioned.
Cryptographic archivers may be used multiply, so if you want to export
such a program use one with 56bit-blowfish and add a mode that strips
off all headers
that aren't encrypted.
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: On the Generation of Pseudo-OTP
Date: Sat, 09 Jan 1999 14:20:59 +0100
R. Knauer wrote:
>
> On Fri, 8 Jan 1999 18:44:27 +0100, <[EMAIL PROTECTED]>
> wrote:
>
> >The best approximation of an OTP is a hardware TRNG based on quantum
> >mechanics: The effects used for this TRNG are neither reproducable nor can
> >be foreseen using any technology we know at the moment, and - if our
> >theories are not completely wrong - they will be unforseeable forever.
>
> You don't believe in Hidden Variable theories, eh.
>
No :-)
> >The main problem is to make such a device statistically good or we
> >wouldn't get an unbreakable cipher.
>
> A TRNG has only one "statistical" property, namely that it is capable
> of outputting all sequences of a given finite length equiprobably.
>
> That, however, is not verifiable - not even "statistically". The best
> you can do is test a TRNG to see if it does something which violates
> its prime directive, like output all 0s in worst case.
This is good enough for me - and this is exactly the way all natural
sciences work as long as doing experiments: Do experiments to show that
your theory is wrong. If you don't find any you may believe that the
theory is right as long
as nobody else found a better experiment.
If there is a noise generator that produces some megabytes output with
good statistical properties (same probability for all bitsequences that
are short enough to be tested with the teststream) I'd use it.
>
> I remind you that you cannot decide by formal means if TRNG or its
> output is truly random, only that they are *not* truly random. The
> reason for this goes to the heart of number theory. (See Chaitin, op.
> cit.)
>
I don't have any problem with this: If radioactive decay or transistor
noise is deterministic and there is no way for the attacker to get
enough parameters to calculate the resulting bitstream, so what?
> >My suggestion is to make the device as
> >good as possible and hash a larger amount of the output to generate the
> >pad.
>
> There are cryptographers who would disagree that a hash is suitable to
> "randomize" the output of a faulty TRNG. The reason is that all
> algorithmic procedures introduce non-random characteristics such as
> periodicity and correlation by their very nature.
Maybe my suggestion is not the best, but what I expect when using
quantum mechanic sources of noise is not a long-term periodicity but a
bipass that causes my generator to produce more 0es that 1es or some
short bitsequences more frequently than others. In this case it may be a
good idear to hash the output of the RNG.
>
> I would have thought that the scheme for removing correlation that
> Schneier discusses in his main book would have done the trick, since
> it involved the simple "mixing" of two or more streams. But someone
> who claimed to know what he was talking about said that is not the
> case.
>
> >While this system is not perfect it is much better than everything that
> >could be done in software: Whatever is done using software is
> >reproducable.
>
> So is hashing. Once the attacker discovers that you are hashing the
> output of a faulty TRNG, he can presumably use that against you.
Of course hashing is reproducable, but it concentrates entropy.
>
> Bob Knauer
>
> "We hold that each man is the best judge of his own interest."
> --John Adams
Andreas Enterrottacher
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Birthday Attack calculations.
Date: Sat, 09 Jan 1999 13:40:58 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
snip...
> >NO it is not even close to my thoughts
> >
> > I thought it was a very good reply on my part sorry
> >you where not capable of understanding it. So here
> >it is in different words. It was previously stated
> >that a cut down version of method tested. Apparently
> >short enough to be able get meaning ful data based
> >on probability of collisions. But the thing was
> >worded that he should never test the FULL LENGTH
> >case since the collision probabilty was virtually
> >ZERO for any real number of tries one could make
> >with the FULL LENGTH caae. But if the FULL LENGTH
> >case is what one is programming the stupid hash
> >function for. It would be FUCKING stupid not to run
> >a few cases just to be DAM SURE non occurred. People
> >can fuck up code you know.
> >
> >David Scott
> >
> Unfortunately running one test of a 256 bit hash for even a tiny part
> of its range will require far more disk space than I have access to
> and will have virtually zero chance of finding a collision. Even
> testing a mere 2^32 hashes compared with the > 2^64 required for a 50%
> collision of a 256 bit hash would require 128 GigaBytes of disk space
> to store all of the calculated hashes. I only wish that I had that
> much.
>
Then run 100 cases after your done with your low level
testing. I you can't run 100 cases your method sucks.
if you get any collisions at all in the 100 cases then you
FUCKED up the CODE. But you MUST check the code for some
cases that you actually suspect the code to run on.
It reminds me of work when we bought code that was to run
on a DEC machine using VT100 terminals. THE CRAP didn't work
we talked to the company on phone several times. They claimed
it was developed on DEC machines using VT100 terminals after
months when one of there representatives came out to our site
after several visits they brougth one of there VT100 termainals
the CRAP ran. But they had used a VT100 clone there code
would not work on a real VT100 DEC terminal. I think the
company died I sure hope so. But you have to run REAL TESTS
on the real one you expect the code to be used. Even if your
a pompous asshole and irrigantly expect no problem.
> I will carry the testing into as far as I can go and still generate
> statistically significant numbers. There is no point expending all my
> computing power trying to force a collision of one relatively large
> hash because the result would be a matter of dumb luck and completely
> meaningless. But by testing millions of tiny hashes and tens of
> thousands of 40 or 48 bit hashes I can generate some meaningful
> numbers.
>
> If the hash is so fatally flawed that I could routinely find a
> collision at much lower than the normal values then I would have found
> this out at the smaller hash sizes. The algorithm is scalable, there
> is no real difference between a small hash and a large hash except for
> the obvious. Therefore I expect that the properties of the smaller
> sizes to carry into the larger sizes.
>
You can expect all you want. Yor should more like a manager than
a real programmer with much common sense.
> Fred van Andel
>
David Scott
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: SCOTT19U ENTROPY
Date: Sat, 09 Jan 1999 14:19:12 GMT
The entidy that prodded me into getting a web page that
goes by name "Horst O.." (can't spell rest of name).
Has finally realized that its calculaation of Entopy bits
H(D) is wrong. He wants it changed. So I am willing to do
this the question is what should I replace it with. I
would really like a honest valid one. There was a theard
on this topic several months ago but at that time I refused
to change it since wanted to leave his work untouched even
if wrong. However I have received Email that is from Horst
and he did not give what I wanted for a change since if I
bother to change it I want it RIGHT.
He came up with one number that he said was based on
work of "Sandy Harris" as an approximate number which
I think is low. Then he came up with
log( (2**19)! ) and got a number I did not agree with.
I read Shannons paper and felt that it should be
log<base2>( ((2**19)-1)! ) which is same as
log( ((2**19)-1)! )/( log(2) )
which is 9,205,076.12815.... This is based on a uniformily
random key. But if one uses a uniformly random remainder table
the keyraw.key file. it would be reduced by at most 1.00 so
I would like to flat state it is above
entropy is 8,000,000+ bits
does anyone have heart burn or a different anwser.
Also made the scott19u contest files. Sent them to
Joe P. He has stated he would look for obvious errors
and write a user friendly "read.me" file for it since
my english not the best. But have yet to hear from
him so hopefully soon the contest which one only needs
to solve for 64 bits max is almost ready. I KNOW
64 BITS IS LESS THAN 8,000,000+ BITS but I want to
show it is strong and a hope it takes at least 3 months
for some one to grind out this unsecure contest. The
NSA will have anwser in an hour. I just hope they don't
give it to one of there stooges to make contest end
quickly. Also if method is weak some one may actually
use there brain to vastly short cut this so a full 64 bit
search is not necessisary. I am sure that problem is reduced
in such a way that many such short cuts exisit. I have thought
of several that reduce it to close to 56 bits.
So people like Paul Onions may come up with something quite
fast.
David A. Scott
P.S. as they so on the prono sites "ENJOY"
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: ScramDisk - password size - high ASCII
Date: Sat, 09 Jan 1999 12:47:55 GMT
In article <[EMAIL PROTECTED]>,
Jim Dunnett wrote:
> On Fri, 08 Jan 1999 10:52:51 GMT, [EMAIL PROTECTED] wrote:
>
> >> however any serious
> >> cryptographic system worth its salt :) either "hashes" or otherwise
> >> scrambles its passwords, before using them as keys, or uses a cipher
> >> whose ciphertext is relatively random with respect to any arbitrary
> >> key.
> >
> >I can confirm that ScramDisk uses a hash (SHA-1 to be specific) to compress
an
> >arbitrary length passphrase into a fixed width 160-bit digest.
>
> So making it ridiculously long does not increase the
> security by that much.
>
> The structure of the passphrase is more important than
> its length as such.
Kind of. It depends what kind of attack you are worried about...
Most users are (quite rightly) worried about dictionary attacks and brute
force attacks against the passphrase. A long passphrase that doesn't exist
in the dictionary is the best choice.
An adversary can of course try and brute-force the hash function, but this
takes on average 2^159 operations - which is totally infeasible.
In summary, both length and lack of structure are important in any passphrase.
ScramDisk tries to offer the user a mechanism for creating good, long
passwords - by offering 4 individual lines on which the user can enter
different words or sentences.
Hope this helps,
Sam Simpson
Comms Analyst
-- http://www.hertreg.ac.uk/ss/ for ScramDisk hard-drive encryption &
Delphi Crypto Components. PGP Keys available at the same site.
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Sat, 09 Jan 1999 09:44:07 -0500
From: "Trevor Jackson,III" <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
You want concrete? Try this: Separate the fundamental physical process
that one is measuring to capture truly unpredictable numbers, from the
actual device performing the capture. Clearly we can find physical
processes that are unbiased. Just as clearly it will be extremely
difficult, though certainly feasible, to create an unbiased capture
device.
For purposes of this discussion, I propose that we stipulaed that
"unbiased" means that whatever bias is present falls below some epsilon
value that we can adjust as necessary. This assumption is almost
mandatory when dealing with large volumes of numbers because the
probability of getting forst order perfection (exactly the same number
of zeros and ones) is fairly small, even from a theoretically "perfect"
source.
If the first 50 bits from the device are all ones do we have a biased
device or an N-sigma event? I believe this question to be undecidable
without further samples from the device.
Mok-Kong Shen wrote:
> R. Knauer wrote:
> >
> > On Fri, 08 Jan 1999 08:30:24 +0100, Mok-Kong Shen
> > <[EMAIL PROTECTED]> wrote:
> >
> > >Have you ever encountered a physical device that is absolutely
> > >perfect??
> >
> > Have you ever encountered a written statement that is Absolutely
> > Perfect?
> >
> > For example, is the written statement you just made Absolutely
> > Perfect?
>
> I don't think this group is the right place for meta-logical
> tricky sentences. We want concrete discussions relevant to
> the issue being discussed.
>
> M. K. Shen
------------------------------
** 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
******************************
