Cryptography-Digest Digest #963, Volume #12      Fri, 20 Oct 00 06:13:00 EDT

Contents:
  Re: Looking for small implementation of an asymmetric encryption algor (lcs 
Mixmaster Remailer)
  Key activation problem on e-mail server ("Rd. Mikhail Malama")
  Masterkey Cracked (JPeschel)
  Re: BIOS password, will it protect PC with PGPDisk against tampering ? (Guy Macon)
  Re: old factoring tricks (David Blackman)
  Re: Which "password" is best. (wtshaw)
  Re: working with huge numbers (Ray Dillinger)
  Re: Which "password" is best. (Ray Dillinger)
  Re: idea for spam free email (Graceful Twerp)
  Re: Rijndael in Perl (Runu Knips)
  Re: Encrypting large blocks with Rijndael (Runu Knips)
  Re: ---- As I study Rinjdael... (Runu Knips)
  Re: What is desCDMF? (Runu Knips)
  How to post absolutely anything on the Internet anonymously (Anthony Stephen Szopa)
  Re: Works the md5 hash also for large datafiles (4GB) ? (Runu Knips)
  "INTERNET_ANONYMITY - Speech without Accountability" (Anthony Stephen Szopa)
  Re: Why trust root CAs ? (Kempelen)
  Re: My comments on AES (Runu Knips)
  Re: idea for spam free email (Richard Heathfield)

----------------------------------------------------------------------------

Date: 20 Oct 2000 04:00:07 -0000
From: lcs Mixmaster Remailer <[EMAIL PROTECTED]>
Subject: Re: Looking for small implementation of an asymmetric encryption algor

> I'm looking for a small implementation of an asymmetric encryption
> algorithm suitable for a low-memory embedded system.

Here's a small math library to do modular arithmetic (multiplication
and exponentiation).  From this you could construct an RSA or ElGamal
encryptor.  It's kind of slow, but would be fine for RSA encryption with
a small exponent.  You do need to make sure your keys are big enough.


/* Small MP package */

#define BITS    1024
#define LEN     (BITS/(sizeof(unsigned)*8))
#define ULEN    (LEN * sizeof(unsigned))


/* Add two numbers mod a third.  Inputs must be < modulus */
void
modadd( unsigned *a, unsigned *b, unsigned *m, unsigned *rslt )
{
    int i;
    unsigned ai, s, ri, df, carry, borrow;

    carry = 0;
    for( i=0; i<LEN; ++i ) {
        ai = a[i];
        s = ai + b[i] + carry;
        carry = ((s==ai) && carry) || (s < ai);
        rslt[i] = s;
    }

    /* Subtract modulus if necessary */
    if( carry == 0 ) {
        for( i=LEN-1; i>=0; --i ) {
            if( rslt[i] < m[i] )
                return;
            if( rslt[i] > m[i] )
                break;
        }
    }
    borrow = 0;
    for( i=0; i<LEN; ++i ) {
        ri = rslt[i];
        df = ri - m[i] - borrow;
        borrow = ((ri==m[i])&&borrow) || (ri < m[i]);
        rslt[i] = df;
    }
    return;
}

/* Multiply two numbers mod a third.  Inputs must be < modulus */
void
modmul( unsigned *a, unsigned *b, unsigned *m, unsigned *rslt )
{
    unsigned ashft[LEN];
    unsigned bit;
    int bitoff;
    int i;

    memset( rslt, 0, ULEN );
    memcpy( ashft, a, ULEN );

    bit = 1;
    bitoff = 0;
    for( i=0; i<ULEN*8; ++i ) {
        if( b[bitoff] & bit ) {
            modadd( ashft, rslt, m, rslt );
        }
        modadd( ashft, ashft, m, ashft );
        bit <<= 1;
        if( bit == 0 ) {
            bit = 1;
            ++bitoff;
        }
    }
}


/* Exponentiate two numbers mod a third.  Inputs must be < modulus */
void
modexp( unsigned *a, unsigned *b, unsigned *m, unsigned *rslt )
{
    unsigned asq[LEN];
    unsigned tmp[LEN];
    unsigned bit;
    int bitoff;
    int i;

    memset( rslt, 0, ULEN );
    rslt[0] = 1;
    memcpy( asq, a, ULEN );

    bit = 1;
    bitoff = 0;
    for( i=0; i<ULEN*8; ++i ) {
        if( b[bitoff] & bit ) {
            modmul( asq, rslt, m, tmp );
            memcpy( rslt, tmp, ULEN );
        }
        modmul( asq, asq, m, tmp );
        memcpy( asq, tmp, ULEN );
        bit <<= 1;
        if( bit == 0 ) {
            bit = 1;
            ++bitoff;
        }
    }
}


/* Testing */

#include <stdio.h>

unsigned a[LEN], b[LEN], c[LEN];
unsigned r[LEN];

unsigned p[LEN] = {
    0xFFFFFFFF, 0xFFFFFFFF, 0xECE65381, 0x49286651, 0x7C4B1FE6, 0xAE9F2411,
    0x5A899FA5, 0xEE386BFB, 0xF406B7ED, 0x0BFF5CB6, 0xA637ED6B, 0xF44C42E9,
    0x625E7EC6, 0xE485B576, 0x6D51C245, 0x4FE1356D, 0xF25F1437, 0x302B0A6D,
    0xCD3A431B, 0xEF9519B3, 0x8E3404DD, 0x514A0879, 0x3B139B22, 0x020BBEA6,
    0x8A67CC74, 0x29024E08, 0x80DC1CD1, 0xC4C6628B, 0x2168C234, 0xC90FDAA2,
    0xFFFFFFFF, 0xFFFFFFFF
};


main (int ac, char **av)
{
    /* Calculate a^(p-1) mod p */
    a[0] = 2;
    memcpy( b, p, ULEN );
    b[0] -= 1;
    modexp( a, b, p, r );
}

------------------------------

From: "Rd. Mikhail Malama" <[EMAIL PROTECTED]>
Subject: Key activation problem on e-mail server
Date: Thu, 19 Oct 2000 22:50:43 -0600

Dear All,

I've been trying to activate PGP key on a web site where I receive e-mail
from.  This sites supports PGP, without PGP tech support, though.  So, I
uploaded PGP key in ASCII format to .PGP directory that I created and tried
to run PGPK command.  However, I am getting an error message that says that
PGP executable is not found.

I guess, there it is something simple, but a lot of people I discussed this
issue with have no idea what to do.

copland:/home2/istok$ pgpk -a istoke~1.asc
Cannot open configuration file /home/istok/.pgp/pgp.cfg
Retreiving hkp:/horowitz.surfnet.nl:11371/istoke~1.asc
Looking up host horowitz.surfnet.nl
Establishing connection
Sending request
Receiving data
Cleaning up
Complete.
Unable to import keyfile "istoke~1.asc".

Regards,

Michael Malama









------------------------------

From: [EMAIL PROTECTED] (JPeschel)
Date: 20 Oct 2000 04:50:37 GMT
Subject: Masterkey Cracked

I've just added to my web site Casimir's
new essay, "The Cracking of MasterKey 
v1.02/1.05."

Parts A and B are up now; parts C and
D will soon follow.

You'll find a link to the essay on
my "Key Recovery Resources" page.

Joe
__________________________________________

Joe Peschel 
D.O.E. SysWorks                                 
http://members.aol.com/jpeschel/index.htm
__________________________________________


------------------------------

From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: 20 Oct 2000 04:51:26 GMT

Dido Sevilla wrote:
>
>If your machine has wide open physical access, then all that the
>attacker needs to do is remove and replace the battery which keeps the
>CMOS information powered, or to short a jumper on the board.  Any
>competent person with an understanding of PC hardware could probably do
>all of these things in under five minutes with a proper screwdriver.
>

Many modern motherboards use flash, and the battery trick doesn't work.


------------------------------

From: David Blackman <[EMAIL PROTECTED]>
Subject: Re: old factoring tricks
Date: Fri, 20 Oct 2000 15:53:17 +1100

Tom St Denis wrote:
> 
> Ok I am a bit behind in the times, but I am messing with pollard-rho
> factoring (again).  I was wondering if it was specifically designed for
> smooth composites?
> 
> I am trying to factor a 79-bit RSA style modulus (ooh baby that's big)
> and it's still chugging away minutes later, while I can factor smooth
> 1000-bit composites in a few seconds...
> 
> Oh boy.
> 
> Tom
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Are you using X ** 2 , or (X ** 2) + 1 .
If you add one, performance depends on the size of the smallest factor
and not much else. And it's nearly always faster.

------------------------------

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Which "password" is best.
Date: Thu, 19 Oct 2000 23:48:16 -0600

In article <8sni5l$gn4$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:

> In article <[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED] (wtshaw) wrote:

> > >
> > The use of a password/passphrase is based on it being both obscure and
> > rememberable.   The use of a 26 character permutation, an optionfor a
> > constant sized string could be based on a pangram, harvesting each
> > different letter in order.
> 
> If you expect a user to remeber a 26-char random looking string you are
> nuts.  Your best bet is with a max of 15 char ASCII password (random)
> such as something like "A1N2bbt5zmt591" which has about log2(26+26+10)
> *15 bits or 89.31 bits of entropy.

Try reading what I wrote before getting too excited.  A pangram is
memorable. It is so memorable that it makes a good source for a
permutation.  A 26 character permutation represents 88.38 bits.  I'd say
that I was in the same ballpark as your best bet.

If you want added security, there are lots of ways to pile on, but unique
pangrams are so easy to make:

> Even if you write that down in your wallet it's much better
> then "123password" which is the limit of most peoples memories.

Come off it: Keeping a written password in your wallet jinxes quized behavior.
comefitkpngawrsdyuljxqzbhv, Raw Length = 64, Singles = 12, Voids = 0

I would choose an original one perhaps somewhat shorter, but this one was
too tempting.
-- 
52) *Part of job is making whimsical, zippy, and vexing key sequences.

------------------------------

From: Ray Dillinger <[EMAIL PROTECTED]>
Subject: Re: working with huge numbers
Date: Fri, 20 Oct 2000 06:46:13 GMT

Ray Dillinger <[EMAIL PROTECTED]> wrote:


: Oh, right.  I have used that form in a second-tier routine for 
: *MODULAR* multiplication -- but it doesn't 'win' for general 
: multiplication.  Sorry about the confusion over terms.

: By Montgomery form, you mean a vector of residues modulo various 
: smaller primes, where the smaller primes have a product greater 
: than the current modulus. Any number smaller than the product 
: of the smaller primes can be represented uniquely this way, and 
: most modular arithmetic on this form is more efficient.  This is 
: cool, but when the "modulus" is bigger than the product of the 
: operands (ie, for general multiplication), you have to include 
: a greater number of residues to push their representable limit 
: higher.  When working with that number of residues, it is no 
: more efficient than the russian algorithm.

I hate to follow up to myself, but I was just plain wrong here. 
I went and reviewed the algorithms in Knuth (v2) and it is in 
fact possible to do general multiplication in near-linear time 
using a vector of residues to moduli whose LCM is greater than 
the expected answer.  

The disconnect was in me thinking that I had to use the first 
N primes as moduli, when in fact you can use selected nonprimes 
having a GCD of 1, which are just smaller than your word size.

So, this is 2 cool techniques out of this conversation.  Thank 
you, everybody. 


                        Bear




------------------------------

From: Ray Dillinger <[EMAIL PROTECTED]>
Subject: Re: Which "password" is best.
Date: Fri, 20 Oct 2000 07:18:33 GMT

: I have been "kicking around various ideas for encryption.  I have tried to
: get some random-passwords generated.  In picking a password, which one of
: the 2 below would you chose, and why? I am testing stream ciphers based on
: cellular transform methods.

I would definitely never use a password that had been published 
on usenet.  

The choosing of passwords is a balancing act -- always you are 
suspended between what the intended user can keep in their head 
and what level of security you actually need. 

In going for maximum security, you're going to want random digits 
out to the end of the maximum length for the password field.  In 
that case tell your people to shuffle three decks of cards, derive a 
number from the permutation, convert it to base 64 (capitals plus 
lowers=54, plus digits=64) and use it as the password. You will 
find that your security sucks because they write it down on sticky 
notes and put it on cards in their wallets. 

So try for something the user can keep in his/her head; it's less 
secure taken as a password, but it won't lead to as many stupid 
violations of security policy. I tend to prefer passphrases 
like this one (which I'm not using anymore):

"Tralfaz, blighted and benighted city, home to peanut butter, 
hovercraft, and rats." 

It's long enough and random enough to provide real security, but 
it is also possible for the user to keep in his/her head and (very 
important) structured enough for the user to touch-type quickly 
and easily.

Basically, humans will subvert any security that's too hard for 
them to deal with as users - so trying to push the limits of 
human memory and typing skill will only weaken your security in 
the long run. 

                                Bear






------------------------------

From: Graceful Twerp <abuse@localhost>
Subject: Re: idea for spam free email
Date: Fri, 20 Oct 2000 09:35:39 +0200
Reply-To: [EMAIL PROTECTED]

On Thu, 19 Oct 2000 10:06:01 GMT, "G. Orme" <[EMAIL PROTECTED]>
wrote:

>    Any suggestions are most welcome on the folowing.
>
>Basically the idea involves having two email addresses, a public known one
>such as e.g. [EMAIL PROTECTED], and a private address, e.g.
>[EMAIL PROTECTED]
[snip]

I can see two possible attacks. One is by sniffing the network traffic
and logging the TO: field when a real message is sent. This can be
done between the sender or receiver and his/her mail server, or
anywhere between the two mail servers. The other is by cracking the
software so that it yields the real address. Since your software is
able to decrypt the real address and you give away the executable
code, cracking the executable can force the real address out in the
same way used by crackers to generate serial numbers of commercial
programs. There is no way to protect executable code from a determined
cracker.

In my opinion, filters installed on the receiver's e-mail software are
still the best way to eliminate spam. Your sistem seems to be designed
so that you will receive e-mail only from a list of sources you have
hand-picked. You can obtain the same result by writing a filter that
lets in only e-mail originating from a list of approved addresses.

------------------------------

Date: Fri, 20 Oct 2000 09:48:13 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.perl.misc
Subject: Re: Rijndael in Perl

those who know me have no need of my name wrote:
> <[EMAIL PROTECTED]> divulged:
> 
> >Anyone that knows if Rijndael exists in Perl yet and/or if someone's
> >working on it?
> 
> ummm.  how would one protect the plaintext?

I've no clue what you're actually asking. The plaintext is guarded
by transforming it to ciphertext using some encryption routine, for
example Rijndael. But the simple fact that you know what 'plaintext'
is means you already know that.

So what do you want to know ???

------------------------------

Date: Fri, 20 Oct 2000 10:02:21 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Encrypting large blocks with Rijndael

John Myre wrote:
> David Crick wrote:
> > John Myre wrote:
> > > Under what circumstances would one be willing to pay
> > > this speed penalty?
> > Security.
> 
> Do you mean to say that encrypting with larger blocks
> is more secure?  (If not, why not go with smaller blocks?)

Yep. A single input bit can influence more output bits. Just
think about a 1-bit block cipher. There are only 2 possible
encryptions, either identity or inversion. Thats not hard to
break, no matter how nifty the algorithm is, isn't it ? That
is the reason why the minimal block size for serious block
ciphers is 64 bit, and 128 is again much better.

Too, the probability that information leaks in CBC mode
lowers substantly. It is already very high for 128 bit
blocks, however. You can encrypt 2**64 blocks until the
probability that two output blocks have the same value, and
information is leaked, reaches 50%.

------------------------------

Date: Fri, 20 Oct 2000 10:09:43 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: ---- As I study Rinjdael...

Sundial Services wrote:
> The assumption that is traditionally made in cryptography is that your
> opponent has already broken into your office and stolen a replica of
> your machine.  He knows everything about what you are doing -- except
> for your private key.

True, and just to make this list complete: you even have to assume
that the enemy knows some of your plaintext, and is able to force
you to send special messages (all this happened in the 2nd world
war), and can therefore do known plaintext and even chosen
plaintext attacks, and the algorithm should still not leak the key.

------------------------------

Date: Fri, 20 Oct 2000 10:16:07 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: What is desCDMF?

"Yonghan, Yoon" wrote:
> How to implement 40-bits des key?

Fill the rest with zeroes.

Btw, using a 40-bit key is absurd. Even the US has finally
agreed that people might export 128 bit crypto. Which was
far too late because its of course no problem for europeans
to implement even 256 bit crypto. My ssh client does this
all the time, for example :-)

------------------------------

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: How to post absolutely anything on the Internet anonymously
Date: Fri, 20 Oct 2000 01:51:48 -0700

How to post absolutely anything on the Internet anonymously

http://www.sciam.com/2000/1000issue/1000techbus2.html

------------------------------

Date: Fri, 20 Oct 2000 11:31:31 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Works the md5 hash also for large datafiles (4GB) ?

Tom St Denis wrote:
> In article <[EMAIL PROTECTED]>,
>   Runu Knips <[EMAIL PROTECTED]> wrote:
> > Sam Simpson wrote:
> > > Tom St Denis <[EMAIL PROTECTED]> wrote in message
> > > news:8sht3j$pui$[EMAIL PROTECTED]...
> > > > [...] who will use a 512-bit hash anyways?
> > > The same people that require AES with a 256-bit key - don't forget
> > > that a 256-bit hash is "vulnerable" to some attacks in 2^128
> > > operations (due to the birthday paradox).  So, for a balanced system,
> > > I guess it can make sense to use a 512-bit hash with a 256-bit block
> > > cipher?
> >
> > Yes, I think so, too. 512 bit hashes are just like 256 bit block
> > ciphers. Enough for eternity to our best knowledge.
> 
> Ah but I have two problems with the new SHA
> 
> 1.  It's gross, ugly, unbalanced and sloppy
> 2.  Who will spend 2^128 effort to forge a message?
> 
> I personally think they should have gone for some multipermutation
> structure (i.e FFT) which is suitable for low end processors.
> 
> Unbalanced structures are stupid, plus they use "nonlinear" function of
> only 3 out of the 7 available chaining variables.  Personally if you ar
> egoing to unbalanced the structure, go all the way since a 7x1 can be
> much more nonlinear then a 3x1.
> 
> Of course a 5 Layer FFT (using 16-bit mixing functions, assuming the
> input is divided into 32 8-bit words) would have much higher diffusion
> (assuming a multipermutation was used) and be somewhat compact in terms
> of a 8-bit MCU usage.

Okay, but having a 512 bit hash is perfect security 'for eternity'
anyway, isn't it ?

That of course doesn't mean it has to be SHA512. I think after SHA512
is out, there will be other hashes with that output size as well. I
had never liked the fact that the largest output size of a serious
hash was only 192 bits (Tiger/192), even if this would fit all
practical requirements for the moment. Schneier suggests not to use
ciphers with less than 112 bit keys. So the minimum size for a
hash should be 224 bits, shouldn't it ?

Well okay if one breaks a hash, in most cases far less is gained than
by breaking an encryption. :-)

------------------------------

From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: "INTERNET_ANONYMITY - Speech without Accountability"
Date: Fri, 20 Oct 2000 02:45:43 -0700

"INTERNET_ANONYMITY 

Speech without Accountability

New software makes it nearly impossible to remove illegal material 
from the Web--or to find out who put it there"

Scientific American

http://www.sciam.com/2000/1000issue/1000techbus1.html

Publius Site

http://www.cs.nyu.edu/~waldman/publius/publius.html

------------------------------

From: Kempelen <[EMAIL PROTECTED]>
Subject: Re: Why trust root CAs ?
Date: Fri, 20 Oct 2000 09:36:13 GMT

In spain, we say: "quien vigila al vigilante?" (who check the
checker?). Goverment CAs publish the digital fingerprint of their CA
certificates on the Official State Bolletin (BOE), so it is in the law
and you can check by your own (if you trust in the BOE, so who check
the checker? :-))

In article <eMoD5.416654$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
>
> OK, so you're off to do some e-shopping. You click on the padlock and
> it says "this certificate belongs to bogus.com" and
> "this certificate was issued by snakeoil CA"   (no I don't mean
> the CA generated by OpenSSL, I mean one of the "normal" ones
> like verisign or thawte...).
>
> So, I can discover snakeoil CA's procedures for verifying bogus.com,
> and assure myself that they have checked out bogus.com.
> But how can I trust snakeoil CA itself ?
> I had a conversation with a CA on this subject and the answer was
> "because it's in the browser". But my browser was downloaded off
> the Internet in clear, and besides, do I really trust the browser
> vendor ? Do you trust Microsoft not to lie ? Do you trust Microsoft
> or Netscape to produce secure independantly verified code ?
> I have more faith in PGP/GPG, since the source code is open, I built
> it myself, and I can control who I trust. (OK, I can probably
> build Mozilla and OpenSSL ...)
>
> Is there a chain of trust from any institution that I might trust,
> such as my bank, back to the root CAs ?
> Is there any reason, apart from the fact that they've been operating
for
> a number of years now and AFAIK nothing's gone wrong, for us all to
trust
> the root CAs ? Apart from a general lack of trust leading the the end
> of e-civilization as we know it ?
>
> As a non-US citizen, I have a slight problem with most of the CAs and
browser
> vendors being US corporations. If I were a member of some organization
> or country that the US regards as an enemy (Libya, Iraq ??) I might
have
> a more serious problem with it.
>
> --
> Andrew Daviel
> PGP id 0xC7624B49
> The geographic search engine at http://geotags.com
> is looking for content.
>
>

--
Kempelen
[EMAIL PROTECTED]


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

Date: Fri, 20 Oct 2000 11:58:12 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: My comments on AES

Bruce Schneier wrote:
> 
> Recently there was a thread where people discussed my scant comments
> on AES.  Those who expected them to appear in Crypto-Gram were
> correct:
> 
>         http://www.counterpane.com/crypto-gram-0010.html#8

Seems to me that Schneier also believes Rijndael is breakable.
I think the selection of Rijndael will keep life exciting for
the cryptographers. Will someone once also find a non-academic
break ? We'll see :-)

------------------------------

Date: Fri, 20 Oct 2000 11:06:08 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: idea for spam free email

Graceful Twerp wrote:
> 
<snip>
> 
> In my opinion, filters installed on the receiver's e-mail software are
> still the best way to eliminate spam. Your sistem seems to be designed
> so that you will receive e-mail only from a list of sources you have
> hand-picked. You can obtain the same result by writing a filter that
> lets in only e-mail originating from a list of approved addresses.

Right, although some people may prefer a slightly more forgiving
three-level system, which filters emails like this:

Is the email from someone on this list of approved addresses? Yes -
Store in Inbox. No - Proceed.
Is it on this list of non-approved addresses? Yes - Junk. No - proceed.
Store in "hmmm" box for later human decision (and, perhaps, updates to
filter lists).

"Addresses" doesn't have to be the only criterion, of course. You might
want to check the high bit of each byte in the subject line (to identify
Unicode etc), or check the subject line against known words or phrases,
etc.

Filtering is an art.

Topicality note: is the study of *not* receiving unwanted but
unenciphered messages considered to be part of cryptology? ;-)


-- 
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html

------------------------------


** 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
******************************

Reply via email to