Cryptography-Digest Digest #534, Volume #11 Wed, 12 Apr 00 09:13:01 EDT
Contents:
Re: Q: Entropy (Mok-Kong Shen)
SHA2 (Gregor Leander)
Re: [Q] PGP - RSA - DH/DSS - Newbie ("Gilles Ferrand")
Re: SHA2 (Tom St Denis)
Re: General principles of design (Mok-Kong Shen)
Re: Q: Inverse of large, sparse boolean matrix, anyone? (Mok-Kong Shen)
Re: Q: Inverse of large, sparse boolean matrix, anyone? (Mok-Kong Shen)
Re: DES ("Chris Williams")
Re: Is AES necessary? (Tom St Denis)
Re: SHA2 (Runu Knips)
Re: Checksum for digits (Runu Knips)
Re: OAP-L3: Semester 1 / Class #1 All are invited. ([EMAIL PROTECTED])
Re: Cryptanalysis Challenge - Will anyone accept? ("Geir Rastad")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Wed, 12 Apr 2000 12:19:54 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
> > Bryan Olson wrote:
> > > Given a string of, say, a million zeros and a "random"
> > > million-bit string, Kolmogorov complexity does not say which
> > > is more complex.
> >
> > If the shortest program to describe the former is shorter than
> > the one for the latter (a case which seems fairly likely), then
> > by definition the former has less Kolmogorov complexity than
> > than the latter.
>
> Wrong. Kolmogorov complexity allows the program to be
> written in a large class of languages. For any pair of
> distinct finite strings there's a pair of legal language that
> disagree on which string has the shorter program.
That issue of difference of languages is understandably treated
in Kolmogorov complexity. Otherwise that theory wouldn't be
able to exist at all. The fact that no real-world algorithm to
measure that theoretical quantity exists can also be interpreted
to mean that no very exact comparison could be made, in my view.
But surely some more or less useful comparison can be made.
Allow me to use an analogy: one can surely claim that the code
for an operating system is more complex than one for the
quick sort, and that totally independent of what programming
languages one uses, including those of year 3000, can't one?
M. K. Shen
------------------------------
From: Gregor Leander <[EMAIL PROTECTED]>
Subject: SHA2
Date: Wed, 12 Apr 2000 12:14:10 +0200
Hallo,
I read something about a new hash function from the NSA called SHA-2.
This new function is said to be stronger than SHA1 and that is why I am
interessed in information about SHA2. So I now hope, that somone knows
somthing about this topic, or can tell me where to find more
information.
Thanks
Gregor
------------------------------
From: "Gilles Ferrand" <[EMAIL PROTECTED]>
Subject: Re: [Q] PGP - RSA - DH/DSS - Newbie
Date: Wed, 12 Apr 2000 11:01:15 GMT
Thanxx.
OK, knowing that (ElGamal), I read the chapter in B.Schneier "Applied
Cryptography"
Thanxx again
"Tom McCune" <[EMAIL PROTECTED]> a écrit dans le message
news: Vo3I4.687$[EMAIL PROTECTED]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Gilles
> F) wrote:
> >Can you answer me ?
> >
> >RSA is an asymetric cryptosystem (or algorithm), OK.
> >PGP uses a secret session key, encrypted with public key, OK
> >
> >PGP promotes Diffie Hellman/DSS instead of RSA/MD5 (for royaltie-free
> >reasons, I think).
> >
> >I know (or I believe) that Diffie Hellman is a key exchange
> >protocolbetween Alice and Bob, without actually exchanging (sending)
> >the secret key on the network:
> >
> >X= g^x mod(p) / Y= g^y mod(p)
> >
> >and the secret key ist g^xy mod(p) after Alice and Bob have exchanged
> >information X and Y
> >
> >In which way this protocol can replace RSA ?
> >(may be, it's an another Diffie Hellman protocol, diffrent form the
> >exchanging key protocol ... ?)
> >
> >Can u help ?
> >
> >Thanxx a lot ;-)
>
> Hi Gilles,
>
> PGP actually uses ElGamal instead of DH - they refer to it as the ElGamal
> variant of DH. PGP uses ElGamal keys in the exact same way as RSA keys -
> in either case, the message/file is actually encrypted to a symmetric
> algorithm (IDEA, CAST, or 3DES) using a randomly generated session key,
the
> session key is then encrypted to the public key (either RSA or DH) and
then
> the encrypted message/file is packaged with with encrypted session key.
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Personal Privacy 6.5.3
> Comment: My PGP Page & FAQ: http://McCune.cc/PGP.htm
>
> iQA/AwUBOPDC7g2jfaGYDC35EQK1TQCfREUFOYltfnAKj1vyQvBLvUPbIRkAmwe8
> hCOY4nrWw25XZwzbRMhE1Mit
> =eVD/
> -----END PGP SIGNATURE-----
>
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: SHA2
Date: Wed, 12 Apr 2000 11:03:25 GMT
Gregor Leander wrote:
>
> Hallo,
> I read something about a new hash function from the NSA called SHA-2.
> This new function is said to be stronger than SHA1 and that is why I am
> interessed in information about SHA2. So I now hope, that somone knows
> somthing about this topic, or can tell me where to find more
> information.
Where did you get this? I looked up SHA on www.nist.gov, and didn't
find anything of the sort.
Tom
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: General principles of design
Date: Wed, 12 Apr 2000 13:13:18 +0200
Boris Kazak wrote:
>
> About a year ago I wrote this just because I wanted to present serious
> things in a humoristic way. You please be the judge, is it funny or not,
> and can it be useful or not. BTW, it was published in the online
> "Journal of Craptology" by Lars Knudsen, he apparently understood the
> humor of it. You can find the "Journal" at
I haven't made a deep study of your article. But as far as I have
understood, some of the arguments put forward are correct. There
is nothing 'inherently' wrong with algorithm parts that are key
dependent. After all, the whole encryption process is 'by definition'
controlled (governed) by the key, and that alone. One generally
says up till now that the algorithm should be assuumed to be
(completely) known to the opponent. That's o.k. But shouldn't
we also assume that he also knows the key?? Certainly not, right?
>From this one clearly sees that, if an algorithm is of the
parametrized type, i.e. one part of it is fixed and constant, while
the other part is variable and key dependent, one can legitimately
recon that variable part to the key, i.e. that portion of the
encryption system which is kept unknown to the opponent and from
which the security is expected to stem. As to 'plantext dependency'
I wonder even more why there are arguments against it. Firstly,
the ciphertext coming from any algorithm is itself 'dependent' on
the plaintext, isn't it? Secondly, look e.g. how the S-Boxes of DES
function. A S-Box has 6 input bits and 4 output bits. It is a 4 bit
to 4 bit mapping (substitution) controlled by the remaining 2 input
bits. These 2 bits (of 'plaintext' relative to the round concerned)
provides so to say the context (a context-sensitive translation)
to control that mapping. Isn't this 'plaintext dependency'?
You are the author of your article. Should I have misunderstood
something, or you like to express points for/against the above,
I should appreciate very much to be able to know them.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Inverse of large, sparse boolean matrix, anyone?
Date: Wed, 12 Apr 2000 13:13:25 +0200
Manuel Pancorbo schrieb:
>
> Mok-Kong Shen :
> > Gadi Guy wrote:
> > >
> > >
> > > My algorithm fails miserably most of the time, which lead me to
> > > believe that maybe there's something more to inverting boolean
> > > matrices than they teach in numerical analysis.
> >
> > Perhaps I am over cautious. But I do want to avoid a probable
> > language ambiguity. A Boolean matrix is not identical to (though
> > has the same form as) an integer matrix whose elements are either
> > 0 and 1. One uses Boolean arithmetics, e.g. 1 + 1 = 0. A normal
> > library Gaussian elimination subroutine, such as the one in
> > Numerical Recipes, is hence not applicable to a Boolean matrix.
> >
>
> Why not? all you have to do is apply the given recipes but modulo 2.
I am afraid you misunderstood the context. The word 'Recipes' was
capitalized. 'Numerical Recipes' is a particular book in which
is given the code for normal Gaussian elimination, employing real
arithmetics (not modulo 2 arithemetics). Your 'given recipe'
refers to the Gaussian elimination as the algorithm as such.
So one can take the code of that book and adapt it, but that
code cannot be directly applied or else one gets wrong answers.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Inverse of large, sparse boolean matrix, anyone?
Date: Wed, 12 Apr 2000 13:13:30 +0200
Tim Tyler wrote:
>
> Calculate the determinant to find out if the matrix you're trying to
> invert is singular, and thus has no inverse. This /should/ be a little
> bit easier than actually inverting it.
One doesn't do in the way you proposed. One performs a Gaussian
elimination. If the matrix is singular, one gets stuck at some point.
M. K. Shen
------------------------------
From: "Chris Williams" <[EMAIL PROTECTED]>
Subject: Re: DES
Date: Wed, 12 Apr 2000 11:09:52 GMT
"Jim Gillogly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
<snip>
> specialties include wiretaps, "fat checkbook cryptanalysis", "rubber
> hose cryptanalysis", and "svelte blonde cryptanalysis".
Where do I sign up for the "svelte blonde cryptanalysis" ? :)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is AES necessary?
Date: Wed, 12 Apr 2000 11:10:30 GMT
Mok-Kong Shen wrote:
>
> Tom St Denis wrote:
> >
>
> > > > I don't understand what MK's original argument is? Serpent for example
> > > > is directly *based on* the analysis of previous ciphers, that's why it's
> > > > so secure. So what is wrong with AES?
> > >
> > > The point is that one can effectively USE the previous ciphers,
> > > without spending great efforts to design new ones. If the elevator
> > > of a building is defect, one tries to repair it. One doesn't pull
> > > down the building and build a new one for that.
> >
> > Yea, but for anyone designing new applications [like me] why would I
> > want to go back to that old, slow cipher? That doesn't make much sense
> > from where I am sitting.
>
> For those creative minds, I certainly don't object creative work.
> My point is only to establish whether AES is really 'necessary'.
> One is entirely free to do things that are not (absolutely)
> necessary, like taking a long walk after dinner, which is certainly
> beneficial.
Oh well, yea you are right AES is completely not required, but neither
is further space exploration. Been there, done that.
> >
> > > > The whole purpose of AES were to find a replacement for DES stronger
> > > > then 3des right? Then all the AES finalists are *already* better then
> > > > 3des?
> > >
> > > Maybe, maybe not. Who REALLY knows (or will REALLY know)?
> >
> > Well I think the leading cryptographers in the field really have a good
> > feel for what they can do, and for the most part they can tell when a
> > cipher is secure and when one is not.
>
> I agree that (for those who are pious) the words of a Pope can
> NEVER err (by definition).
>
> To repeat a point, sometimes a cipher is 'downcried' to be broken,
> when it is shown that the key could be recovered with plaintext
> and ciphertext pairs corresponding to a fraction of the key space,
> without mentioning that such amounts of materials are never
> available in actual practice. It is my personal impression that
> that is in some sense comparable to those theses in connection
> with the Y2K problem, where the firms were over-terrified with
> extremely exaggerated risk senarios to spend huge amounts of money
> (to the well-being of the software specialists, of course).
Yea 3DES is secure, but I think by properly implementing [*] the new AES
ciphers in my program that others will eventually use, I am doing those
cryptographers a nice favor. It's one thing to design a cipher,
cryptanalyze it, [and get the women] but if it's never used who cares?
Tom
[*] For the most part I believe my CB implements the algorithms properly
[they pass the test vectors], but further peer-review is required.
http://24.42.86.123/cb.html
Tom
------------------------------
Date: Wed, 12 Apr 2000 13:58:09 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: SHA2
Gregor Leander schrieb:
>
> Hallo,
> I read something about a new hash function from the NSA called SHA-2.
> This new function is said to be stronger than SHA1 and that is why I am
> interessed in information about SHA2. So I now hope, that somone knows
> somthing about this topic, or can tell me where to find more
> information.
>
> Thanks
> Gregor
AFAIK it has been mentioned in this NG not long ago, and the
poster said it will be published soon. He also said it will
have 256 bits of output.
------------------------------
Date: Wed, 12 Apr 2000 14:09:57 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Checksum for digits
lordcow77 schrieb:
> Verhoeff's check digit scheme based on the symmetry of the
> dihedral group D_5 catches all single errors, all adjacent
> transpositions, and most twin errors and other transpositions.
Well this is an old piece of code of mine which was taken
from an article of the german magazine ct in 04/1997 (no
its not the april joke ;-) ). Hope it helps :)
__________________________
/*
** dieder.h Mon, Mar 17 1997
**
** Copyright (c) 1997, Runu Knips, Siegen, Germany
** All rights reserved. No warranty.
**
** $Id$
**
** Last Edit: Tue, Mar 18 1997
**
** $Log$
*/
#ifndef INTERFACE_dieder
#define INTERFACE_dieder
#ifdef __GNUG__
#pragma interface
#endif
/*
** Checksum for expanded bcd format numbers. Secound
** argument is always the length. For compute_verhoeff,
** the third argument is the position of the checking
** char as 3rd argument; specify -1 and put the number
** after the last position if you want.
**
** The compute_* functions will return a number between
** 0 and 9, which is the checksum, or -1 for error.
** The check function will return a bool value
** (0 = false, 1 = true).
*/
extern int compute_dieder (const char[], int);
extern int compute_verhoeff (const char[], int, int);
extern int check_verhoeff (const char[], int);
/*
** Check a german money string. This will take
** an ascii string argument (of fixed size 12)
** and return the character which should stand
** at the 12th position (which isn't checked
** by itself).
** Be warned: check_german_money_cksum is an
** macro which evaluates its argument multiple
** times!
*/
extern int compute_german_money_chksum (const char[]);
#define check_german_money_cksum(s) \
((s[11]) == compute_german_money_chksum(s))
#endif /* !def(INTERFACE_dieder) */
__________________________
/*
** dieder.c Mon, Mar 17 1997
**
** Copyright (c) 1997 Runu Knips, Siegen, Germany
** All rigths reserved. No warranty.
**
** Checksum program using dieder groups (and
** especially dieder multiplication). Works for
** decimal numbers only!
**
** Contained is an implementation of a permutated
** dieder group checksum, the algorithm for german
** money, and the verhoeff permutation.
**
** Source: c't april 1997, page 452 (article 448ff).
**
** Last Edit: Tue, Mar 18 1997
**
** $Log$
*/
#ifdef __GNUG__
#pragma implementation "dieder.h"
#endif
#ifndef lint
static char RCSid[] = "$Id$";
#endif
#include <string.h>
#include <ctype.h>
#include "dieder.h"
/******************************************************/
/* dieder multiplication (always mod 10) */
static const int dieder_mult[10][10] = {
{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 },
{ 1, 2, 3, 4, 0, 6, 7, 8, 9, 5 },
{ 2, 3, 4, 0, 1, 7, 8, 9, 5, 6 },
{ 3, 4, 0, 1, 2, 8, 9, 5, 6, 7 },
{ 4, 0, 1, 2, 3, 9, 5, 6, 7, 8 },
{ 5, 9, 8, 7, 6, 0, 4, 3, 2, 1 },
{ 6, 5, 9, 8, 7, 1, 0, 4, 3, 2 },
{ 7, 6, 5, 9, 8, 2, 1, 0, 4, 3 },
{ 8, 7, 6, 5, 9, 3, 2, 1, 0, 4 },
{ 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 }
};
/* permutation for better dieder chksum */
static const int dieder_perm[8][10] = {
{ 1, 5, 7, 6, 2, 8, 3, 0, 9, 4 },
{ 5, 8, 0, 3, 7, 9, 6, 1, 4, 2 },
{ 8, 9, 1, 6, 0, 4, 3, 5, 2, 7 },
{ 9, 4, 5, 3, 1, 2, 6, 8, 7, 0 },
{ 4, 2, 8, 6, 5, 7, 3, 9, 0, 1 },
{ 2, 7, 9, 3, 8, 0, 6, 4, 1, 5 },
{ 7, 0, 4, 6, 9, 1, 3, 2, 5, 8 },
{ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }
};
/* inverse of dieder multiplication */
static const int dieder_mult_inv[10] =
{ 0, 4, 3, 2, 1, 5, 6, 7, 8, 9 };
/* permutation table of verhoeff */
static const int verhoeff_perm [12][10] = {
{ 2, 8, 6, 3, 4, 1, 0, 9, 7, 5 },
{ 3, 1, 2, 0, 4, 5, 6, 7, 8, 9 },
{ 4, 9, 1, 2, 5, 6, 3, 0, 7, 8 },
{ 4, 8, 5, 0, 9, 7, 2, 6, 3, 1 },
{ 1, 2, 6, 9, 4, 5, 7, 8, 3, 0 },
{ 3, 5, 0, 1, 2, 8, 9, 6, 7, 4 },
{ 3, 8, 9, 4, 7, 2, 6, 1, 5, 0 },
{ 2, 4, 8, 6, 9, 0, 7, 1, 3, 5 },
{ 1, 7, 9, 5, 0, 3, 8, 6, 4, 2 },
{ 1, 8, 2, 9, 5, 0, 4, 7, 6, 3 },
{ 4, 3, 2, 6, 8, 7, 0, 1, 5, 9 },
{ 2, 6, 9, 8, 5, 4, 1, 3, 0, 7 }
};
/* inverse permutation table */
static const int verhoeff_inv_perm [12][10] = {
{ 6, 5, 0, 3, 4, 9, 2, 8, 1, 7 },
{ 3, 1, 2, 0, 4, 5, 6, 7, 8, 9 },
{ 7, 2, 3, 6, 0, 4, 5, 8, 9, 1 },
{ 3, 9, 6, 8, 0, 2, 7, 5, 1, 4 },
{ 9, 0, 1, 8, 4, 5, 2, 6, 7, 3 },
{ 2, 3, 4, 0, 9, 1, 7, 8, 5, 6 },
{ 9, 7, 5, 0, 3, 8, 6, 4, 1, 2 },
{ 5, 7, 0, 8, 1, 9, 3, 6, 2, 4 },
{ 4, 0, 9, 5, 8, 3, 7, 1, 6, 2 },
{ 5, 0, 2, 9, 6, 4, 8, 7, 1, 3 },
{ 6, 7, 2, 1, 0, 8, 3, 5, 4, 9 },
{ 8, 6, 0, 7, 5, 4, 1, 9, 3, 2 }
};
/* @@@: fixme: that may not work under strange character systems */
#define to_digit(ch) ((ch) + '0')
#define from_digit(ch) ((ch) - '0')
/******************************************************/
int
compute_dieder (const char arg[], int len)
{
int i, j, res;
for (res = 0, i = 0; i < len; i++) {
j = dieder_perm [i % 8] [arg [i]];
res = dieder_mult [res] [j];
}
return res;
}
/*
** Get the checksum for a german money number.
*/
int
compute_german_money_chksum (const char arg[])
{
int ch, i, j, res;
char tmp[11];
/* at these positions, alphanumeric chars
** are in the string.
*/
static const int alpha_pos[3] = { 0, 1, 9 };
/* we change fields in the string, so.. */
memcpy (tmp, arg, sizeof(tmp));
for (i = (sizeof(alpha_pos) / sizeof(int)); i--;) {
j = alpha_pos[i];
switch (tmp[j]) {
case 'a': case 'A': ch = '0'; break;
case 'd': case 'D': ch = '1'; break;
case 'g': case 'G': ch = '2'; break;
case 'k': case 'K': ch = '3'; break;
case 'l': case 'L': ch = '4'; break;
case 'n': case 'N': ch = '5'; break;
case 's': case 'S': ch = '6'; break;
case 'u': case 'U': ch = '7'; break;
case 'y': case 'Y': ch = '8'; break;
case 'z': case 'Z': ch = '9'; break;
default: return -1; /* error: unallowed char */
}
tmp[j] = ch;
}
res = 0;
for (i = 0; i < sizeof(tmp); i++) {
ch = tmp[i];
if (! isdigit (ch)) {
return -1;
}
j = from_digit (ch);
if (i < 10) {
j = dieder_perm [i % 8] [j];
}
res = dieder_mult [res] [j];
}
return to_digit(res);
}
/*
** If pos < 0, or pos >= len, you may append the
** result to the number.
*/
int
compute_verhoeff (const char arg[], int len, int pos)
{
int i, j, res, left, right;
for (left = 0, i = 0, res = 0; i < len; i++) {
if (i == pos) {
left = res;
res = 0;
continue;
}
j = verhoeff_perm [i % 12] [arg [i]];
res = dieder_mult [res] [j];
}
right = res;
/* force (left * perm[pos+1][res] * right == 0) */
i = dieder_mult [dieder_inv_mult [left]] [dieder_inv_mult [right]];
res = verhoeff_inv_perm [pos % 12] [i];
return res;
}
/* @@@: checkme: This had been cutted from the c't listing,
** but I guess it's correct this way.
*/
int
check_verhoeff (const char arg[], int len)
{
int i, j, res;
for (i = 0, res = 0; i < len; i++) {
j = verhoeff_perm [i % 12] [arg [i]];
res = dieder_mult [res] [j];
}
return res == 0;
}
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 12 Apr 2000 11:50:17 GMT
In article <[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> writes:
> But if you sum three single digit numbers they will be on avg [the
> output] near 4.5. So that can't be entirely random.
Do you mind sharpening this point for us?
What is it about the distribution the sum of three random single digit
numbers that is non-random? As opposed to non-uniform. And what does
this distribution have to do with the distribution of the sum of 1 times
the first plus 10 times the second plus 100 times the third?
Or is your sarcasm simply too subtle for me?
John Briggs [EMAIL PROTECTED]
------------------------------
From: "Geir Rastad" <[EMAIL PROTECTED]>
Subject: Re: Cryptanalysis Challenge - Will anyone accept?
Date: Wed, 12 Apr 2000 14:57:26 +0200
Or if you want a free analysis just brag about how well written your
algorithm is, and
that no one will ever find *any* flaws to this brilliant piece of software
....... :)
"Dave Hazelwood" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> The bad news is I think this is an instance where you will get your
> moneys worth. For $100 you will get about $100 worth of analysis. I
> suspect you are hoping for more.
>
> The good news is you will probably get just as much from the good
> people here in this ng without offering the $100.
>
> But if the cipher is really good and you want the best minds to spend
> the umpteen zillion hours it takes for serious analysis well that is
> gonna require bigger bucks. I suspect for 10K you will get some pretty
> good analysis. For 100K you will have some very good people try very
> hard at it. For $1M you will have the undivided attention of the best.
>
> My advice, save your $100 and pick the brains here until you are sure
> you have something that at least passes the taste test. Once the boys
> here agree it does, then you might want to get serious and offer at
> least 1K to see if you can reach second base. When you do that, if it
> is an interesting method you might get a free ride where people do it
> out of interest and not just view it as the attempt of yet another
> wannabe wasting their valuable time, in which case you can also save a
> cool million dollars <grin>.
>
>
> "Jeff Hamilton" <[EMAIL PROTECTED]> wrote:
>
> >I was thinking of placing a stream cipher out here that I developed about
3
> >years ago. Source and Ciphertext. I was curious if a $100.00
Cryptanalysis
> >offer would be sufficient to gain attention. I'm a novice at this and
really
> >haven't had a chance to get back in to Cryptography until these last 2
> >months.
> >
> >Would anyone be up to the offer? If so tell me your thoughts. I myself
> >already know of it's flaws. Not to mention that some of you who have been
on
> >this newsgroup for a while have seen it when I posted it about 3 years
ago.
> >
> >-Jeff28
> >
>
------------------------------
** 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
******************************
