Cryptography-Digest Digest #563, Volume #14 Fri, 8 Jun 01 06:13:00 EDT
Contents:
Re: Best, Strongest Algorithm (gone from any reasonable topic)
([EMAIL PROTECTED])
Re: Def'n of bijection (Tim Tyler)
Re: Knapsack security??? Ah....huh ("Jakob Jonsson")
Re: Simple C crypto (Sergei Lewis)
Re: Def'n of bijection ([EMAIL PROTECTED])
Re: Def'n of bijection ([EMAIL PROTECTED])
Re: Def'n of bijection (Tim Tyler)
Algorithm take 3 - LONG (was : Re: RSA's new Factoring Challenges: $200,000 prize.
(my be repeat)) ("Michael Brown")
Re: Def'n of bijection (Tim Tyler)
Re: Some questions on GSM and 3G (Erwann ABALEA)
Re: Def'n of bijection ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
From: [EMAIL PROTECTED]
Date: 08 Jun 2001 05:12:05 -0400
Mok-Kong Shen <[EMAIL PROTECTED]> writes:
> Tom St Denis wrote:
>>
>> What's your thesis on? Mind sending me a copy?
>
> Unless you are a 'collectioner' by nature, I wouldn't
> in your (and my own) place access thesis in math, for these
> are invariably virtually 'undigestable' by non-mathematicians.
Mok is probably right, though I'm flattered. It's in PDE, specifically
quasiconformal analysis, and has nothing to do with cryptography. (But
if you want a pdf, email me and I'll send it to you.)
Len.
--
Frugal Tip #17:
Visit the Ford Foundation while disguised as a large, charitable
organization.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Fri, 8 Jun 2001 09:04:44 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> According to you "a statement is vacuously true when it cannot possibly be
:> false".
: No. [...]
Well, that *is* what you wrote - my statement above was correct.
: An implication is vacuously true if it's premise cannot possibly be
: true.
So how does that apply to Fermat's last theorem?
"x^n + y^n = z^n has a non-zero integer solution for x, y and z when n > 2"
...cannot /possibly/ be true - it has been *proven* to be false.
So - according to both of your own definitions - it is vacuously true.
It seems that being vacuously true (with your definition of the term) is
nothing to be ashamed of.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Jakob Jonsson" <[EMAIL PROTECTED]>
Subject: Re: Knapsack security??? Ah....huh
Date: Fri, 8 Jun 2001 11:14:38 +0200
> Diophantine encryption for public key encoding
>
http://www.frontiernet.net/~jmb184/interests/sci.crypt/numerical_encryption.
html
> In this last one, an encrypted message e = r*h + m*k where e is the
> encrypted message, r is a random number, h and k are public key
> values, and m is the encrypted message (number) m is recovered by
> computing m = e*g mod p mod q where g, p, and q are calculated from
> the private keys.
This scheme doesn't look terribly secure to me. If q divides p, then we may
decrypt messages as follows. We assume that h and k have no divisors in
common. Multiply e with the inverse k' of k modulo h and compute modulo h:
e*k' == r*h*k' + m*k*k' == m (mod h).
Since q divides p, we have that h = q*k mod p is a multiple of q and hence
larger than m. Thus m is recovered using (h,h) instead of (p,q).
If q does not divide p, then the expression m+q*r must not exceed p (if it
does, (m+q*r) mod p mod q won't be equal to m). We may assume that k and h
are relatively prime. Select q' such that q' is as small as possible but
larger than the largest allowed value on m. Define
p' = k*q'-h.
Then
(k^{-1} mod p')*e == k^{-1}*r*h + m == k^{-1}*r*k*q' + m == r*q' + m (mod
p').
>From this expression we will be able to recover m unless r*q'+m is larger
than p'. However, the correct private key (p,q) satisfies r*q+m < p. If
r*q'+m>=p', then
k-h/q' = p'/q' <= m/q' + r < m/q' + p/q - m/q.
Now the correct private key (p,q) satisfies t*p = k*q-h for some integer t
(h == k*q (mod p)). In particular, p/q <= k-h/q . Hence we obtain
k - h/q' < m/q' + p/q - m/q <= m/q' + k - h/q - m/q ==> (h+m)/q < (h+m)/q'.
This is a contradiction, because q' was minimal. Thus (r*q'+m) mod p' mod q'
= m.
This scheme does not seem to have anything in common with the NTRU scheme.
Jakob
------------------------------
From: Sergei Lewis <[EMAIL PROTECTED]>
Subject: Re: Simple C crypto
Date: Fri, 08 Jun 2001 10:28:17 +0100
> I'm looking for a simple algorithm to code text that is pretty difficult to
> break for an amateur without custom s/w.
> I had thought of something like (say) a 16 bit number, to be XORed with
> chars, and then this shifted each time it is re-used.
Looking around the thread, you don't actually care about people
*reading* the messages - you just don't want any of them *altered*
easily.
Ideally, you want copies of the messages to be encrypted with the public
key of someone you trust as they are created by the datalogger. That
person could then check that the stored encrypted copies match what the
lab technician's report says. The system is then as secure as the
datalogger itself, which you said you aren't bothered about since the
technician could just fake results anyway.
You're basically doomed, otherwise. If you can log a real message, you
can log a fake one.
You could keep a running CRC of all messages produced, and print a copy
of each message as it is produced; if the messages or their order are
interfered with, it will be impossible to reconstruct the CRC at a later
date by entering all the messages in order. One could attack this by
selecting an arbitrary message as the starting point, finding out the
CRC at the time, and spoofing the entire output from there; or
alternatively interfering with the data source again - you can't really
guard against that.
You could try dictionary compression - substitute sequentially each
substring of the message such that it is the longest substring that has
a match in the dictionary for the location of that match. Use the
alphabet as a starting dictionary, and include decompressed versions of
previous messages in the dictionary as messages are added (not
physically; just decompress a chunk of the log on the fly when searching
for matches). Impose an unsurmountable limit on the total size of the
compressed message file that is smaller than the likely size it will
reach when uncompressed, eg. by putting it on a floppy disk with the
rest of the software and running it on lab machines with no hard disk,
or limiting the size of the partition it resides in.
An attack in place then becomes nontrivial, since (a) the algorithm you
use needs to be determined, (b) naive attempts to change message text
result in other messages becoming corrupted, and (c) decompressing a
file becomes difficult when there's not enough room to store the
decompressed version in its entirety. Obviously it's still quite easy to
get around if you really want to, just not something you'd do in a tea
break with Notepad. Then again, the same effect is achievable with XOR.
In general, an attacker will probably spend about as long cracking your
software as you spend trying to stop them - so work out how long a
motivated lab technician would be prepared to spend trying, and act
accordingly.
--
Sergei Lewis - http://members.tripod.co.uk/~Folken
"I'm not falling - this is how I fly.."
------------------------------
Subject: Re: Def'n of bijection
From: [EMAIL PROTECTED]
Date: 08 Jun 2001 05:36:37 -0400
Tim Tyler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>:
>: ...you seemed to think that BICOM does some good in the *real*
>: world. In the *real* world, messages are not 129-bits long. In the
>: *real* world, the estimates I offered are more like it.
>
> All that can be compressed will have the liklihood of false positive
> decrypts arising increased by compressing before encryption.
(1) In the case of normal emails, it will increase from ``essentially
impossible'' to ``essentially impossible.''
(2) This is not an advantage of BICOM; any compressor will cause the
message to get a little shorter. But this benefit of BICOM has nothing
to do with ``bijectivity''; it depends entirely on the compression
ratio.
Len.
--
Frugal Tip #31:
Incrementally reduce your year-to-year operating expenditures while
aggressively recognizing unrealized receivables in the current quarter.
------------------------------
Subject: Re: Def'n of bijection
From: [EMAIL PROTECTED]
Date: 08 Jun 2001 05:39:36 -0400
Tim Tyler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>:
>: An implication is vacuously true if it's premise cannot possibly be
>: true.
>
> So how does that apply to Fermat's last theorem?
It doesn't.
> "x^n + y^n = z^n has a non-zero integer solution for x, y and z when n > 2"
That is not an implication. An easy way to see that is to notice that
words like ``implies'', ``if...then'', etc., are all absent in the
statement above.
Len.
--
Frugal Tip #34:
Use the stale Cheetos you find between your sofa cushions as an
inexpensive meat extender.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Fri, 8 Jun 2001 09:33:51 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> Lest anyone be misled by this sort of material, I did some
:> experiments...I took a few messages of a length that *exceeded* the
:> unicity distance and compressed them with BICOM.
[...]
:> How many plausible-looking English sentences compress with BICOM to
:> 32-byte files? I won't do the sums, but it is obviously a *huge*
:> number.
: Obviously a *huge* number, you say? Oh man, now I see it! How could I
: have been so misguided before?
I really don't know for certain. It /appears/ that you wandered into an
argument you knew nothing about mis-identified the situation as one you
were familiar with shot your mouth off and then got bogged down in
defending your initial mistakes. Much the same as in the other
threads we talked on - but on those you quietly gave up more rapidly
once I pointed your errors out. I hypothesise that an over-inflated
view of your own reasoning abilities in an unknown situation was probably
involved.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Algorithm take 3 - LONG (was : Re: RSA's new Factoring Challenges: $200,000
prize. (my be repeat))
Date: Fri, 8 Jun 2001 22:01:37 +1200
"Joseph Ashwood" <[EMAIL PROTECTED]> wrote in message
news:u32Ami47AHA.277@cpmsnbbsa07...
>
> "Michael Brown" <[EMAIL PROTECTED]> wrote in message
> news:VlDT6.707$[EMAIL PROTECTED]...
> > <BEGIN REPEAT>
> [snip]
> > Is this closer to an algorithm?
> No it's not.
OK. I'll try and do a smaller part of the method (the filling in of the boxes)
specifically.
> It's pure gibberish, you assumed definitions that simply don't
> hold in all computers, let alone all of mathematics (e.g. dword).
I assumed that the normal definition of dword would hold, ie: a dword is a 32
bit unsigned binary number. I acknowledge that some computers (the 8086 for
example) do not support dwords, and some computers (such as those based on
Motorola chips) have opposite endainess (MSB first) and I have no idea what
happens on supercomputers. I don't think this is really a problem with the
method though.
> You assume it will be implemented on a general purpose computer
I'm sorry, but that's the only one I know how to program. Since I can't
represent in in mathematical formulae, that's how it will stay.
> You make arbitrary definitions without foundation (e.g. A,B,O,C)
A, B, O, and C are (if you read the pages), input A, input B, output, and carry
to a 2-input 2-output addition box.
> You change the type of variables (e.g. moving from base 4 to dword)
I never was in base 4, but I think can see where I didn't make myself clear
enough in this case (Outlook Express didn't help by losing a few lines as well
...).
"BoxPart : (byte) 4 sets of 2 bits (0 = A, 1 = B, 2 = O, 3 = C)"
What I meant by this is that BoxPart is of the form (in binary) ccoobbaa where
aa, bb, oo, and cc are each 2 bit numbers. If aa = 10 (in binary) then the link
from input A of the current box joins to the output of the box it is connected
to (again, this may not be clear, but if you look at the diagrams it should be a
bit easier to visualise).
> You fail to define even the most fundamental of algorithms (e.g. the lookup
> table generation algorithm).
I made the lookup table by hand. I can post the whole thing here if you really
want it ...
> You spontaneously create variables and then depend on them to have specific
> values (e.g. HBoxes).
Another case where I was assuming you had read the pages (something I obviously
shouldn't have done). The boxes are all initialised to have every part (A, B, O
and C) set as unknown. As for initialising the links, I will leave this out of
the next attempt at the algorithm due to its relatively complex nature.
> You use variable notation when what you wanted was a function (e.g.
GetNextBox)
Sorry. My Pascal upbringing kicking in again :)
> You state simply "Repeat 4 & 5 until you can't
> go any further" instead of defining the termination conditions and building
> a proper loop.
OK. I'll fix that.
> You state that step 5 is constant per box, then state that
> there's a maximum of doing each one four times, which one is correct?
Arrgh. That section was really stuffed. I'll try to explain it better below.
> You
> then proceed to make a judgement on the speed without defining your
> algorithm in the slightest.
The number of boxes is a cubic (I assume you agree on this one?) but I think the
garbled section on how there is an upper limit to the number of operations per
box kinda ruined it.
> Did you even read my last message?
Yes.
> Did you notice the (incomplete, but specific) example of an algorithm?
Yes.
> Can you manage to express your gibberish simularly?
I'll try (again) on a small part of the method (the "filling in the boxes"
part).
A box is made up of the following structure:
Values : byte in the structure ccoobbaa (8 bit binary number).
cc = value for the link connected to the carry of the box
oo = value for the link connected to the output of the box
bb = value for the link connected to the second (B) input of the box
aa = value for the link connected to the first (A) input of the box
So each of these can be a value between 00 and 11 in binary.
00 = the link has a value of 0
01 = the link has a value of 1
10 = the link has an unknown value
11 = the link is in an invalid state
Each of these (cc, oo, bb, and aa) are initialised to the value of 01
(unknown).
ABox, BBox, OBox, CBox : dword (unsigned 32 bit integer)
ABox = the index into the array of boxes of the box that input A is
connected to.
BBox = the index into the array of boxes of the box that input B is
connected to.
OBox = the index into the array of boxes of the box that the output is
connected to.
CBox = the index into the array of boxes of the box that the carry is
connected to.
BoxPart : byte in the structure ccoobbaa (8 bit binary number).
cc = number indicating the part of the box that the link from the carry of
this box is connected to.
oo = number indicating the part of the box that the link from the output of
this box is connected to.
bb = number indicating the part of the box that the link from input B of
this box is connected to.
aa = number indicating the part of the box that the link from input A of
this box is connected to.
ABox, BBox, OBox, CBox, and BoxPart are assumed to be initialised to be
consistant with the diagrams shown on the web site.
Also, the values of the output (the oo part in Values) of the bottom row of
boxes are assumed to be set to represent the number to be factorised. [1]
There is an array of these (called Boxes) that has n^3 - n^2 - n elements, where
n is the size of the largest factor (initialised as above). It is indexed from
0.
Next we have the lookup table (called Lookup). I'm not going to paste the whole
thing here as it won't mean much by itself. It is an array of 256 bytes
(unsigned 8 bit integers). The contents of the table is best indicated through
an example:
Say we have a box with A = ?, B = 0, O = ?, C = ?. The Values element of the
box structure would therefore have the value 10100010 (or 0xA2). Element number
0xA2 in the lookup table would hold the new value for Values element, which
would be A = ?, B = 0, O = ?, C = 0. Thus element number 0xA2 would have the
value 0x22 (00100010 in binary).
As it is possible to have all A, B, O, and C zero, this array is also indexed
from zero.
Finally, we have the box stack (called BoxStack). This is an array of StackLen
dwords, indexed from 0. StackLen itself is also a dword. To start off with,
StackLen is 2n - 1. There is 2n - 1 columns of boxes (and one column, the
leftmost one with no boxes), and thus 2n - 1 boxes we have set in [1]. BoxStack
is an array of length 2n - 1 and holds the indexes into the Boxes array of each
box at the bottom of a column.
Note that none of the above is a algorithm. It is just the things that are
assumed to be set up before the sub-algorithm below will work.
The algorithm is written in Pascal, though it should be readable by non-Pascal
people.
<START OF ALGORITHM>
NextBox : dword;
OldVal : byte;
DestPart : byte;
DestMask : byte;
while StackLen > 0 do
begin
NextBox := BoxStack[StackLen - 1];
dec(StackLen);
redim(BoxStack, StackLen);
OldVal := Boxes[NextBox].Values;
Boxes[NextBox].Values := Lookup[Boxes[NextBox].Values];
// Has the link connected to input A changed?
if ((Boxes[NextBox].Values xor OldVal) and $03) > 0 then
begin
// Make the mask for the destination box
DestPart := Boxes[NextBox].BoxPart and $03;
DestMask := not ($03 shl DestPart);
// Set the destination box values:
// The original value OR'd with
// the state of the link shifted to the correct place
Boxes[Boxes[NextBox].ABox].Values :=
(Boxes[Boxes[NextBox].ABox].Values and DestMask) or
((Boxes[NextBox].Values shl DestPart) and (not DestMask));
inc(StackLen);
redim(BoxStack, StackLen);
BoxStack[StackLen - 1] := Boxes[NextBox].ABox;
end;
// Has the link connected to input B changed?
if ((Boxes[NextBox].Values xor OldVal) and $0C) > 0 then
begin
// Make the mask for the destination box
DestPart := (Boxes[NextBox].BoxPart shr 2) and $03;
DestMask := not ($03 shl DestPart);
// Set the destination box values:
// The original value OR'd with
// the state of the link shifted to the correct place
Boxes[Boxes[NextBox].BBox].Values :=
(Boxes[Boxes[NextBox].BBox].Values and DestMask) or
(((Boxes[NextBox].Values shr 2) shl DestPart) and (not DestMask));
inc(StackLen);
redim(BoxStack, StackLen);
BoxStack[StackLen - 1] := Boxes[NextBox].BBox;
end;
// Has the link connected to the output changed?
if ((Boxes[NextBox].Values xor OldVal) and $30) > 0 then
begin
// Make the mask for the destination box
DestPart := (Boxes[NextBox].BoxPart shr 4) and $03;
DestMask := not ($03 shl DestPart);
// Set the destination box values:
// The original value OR'd with
// the state of the link shifted to the correct place
Boxes[Boxes[NextBox].OBox].Values :=
(Boxes[Boxes[NextBox].OBox].Values and DestMask) or
(((Boxes[NextBox].Values shr 4) shl DestPart) and (not DestMask));
inc(StackLen);
redim(BoxStack, StackLen);
BoxStack[StackLen - 1] := Boxes[NextBox].BBox;
end;
// Has the link connected to the carry changed?
if ((Boxes[NextBox].Values xor OldVal) and $C0) > 0 then
begin
// Make the mask for the destination box
DestPart := (Boxes[NextBox].BoxPart shr 6) and $03;
DestMask := not ($03 shl DestPart);
// Set the destination box values:
// The original value OR'd with
// the state of the link shifted to the correct place
Boxes[Boxes[NextBox].CBox].Values :=
(Boxes[Boxes[NextBox].CBox].Values and DestMask) or
(((Boxes[NextBox].Values shr 6) shl DestPart) and (not DestMask));
inc(StackLen);
redim(BoxStack, StackLen);
BoxStack[StackLen - 1] := Boxes[NextBox].BBox;
end;
end;
<END OF ALGORITHM>
Basically it goes like this:
1) Get the next box to process
2) Find out the new value of the box
3) If input A has changed, update the other box and push the index onto the
stack.
4) If input B has changed, update the other box and push the index onto the
stack.
5) If the output has changed, update the other box and push the index onto the
stack.
6) If the carry has changed, update the other box and push the index onto the
stack.
7) Go back to 1 if there are more boxes still to process.
Before I try and do the more complex part to specify exactly, I'd like to know
whether I'm on the right track.
On a slightly different note, this is not really why I originally posted, which
was to try to get people to think about the concept (which many have). However,
since a lot of people on this NG won't even look at an concept unless is is
presented in algorithmic form (at which point it isn't really an concept any
more) it obviously needs to be translated into this form in order for people to
look at it. Unfortunately, as of tomorrow, I will no longer have much time to do
this, so I would ask that you try to look at the concept and figure out what's
going on rather than to ignore it until I finally can present a complete
algorithm (which quite probably will be in at least 6 months' time, more likely
further). I will be able to answer questions on the method (or whatever state
you wish to call it) as it stand, though. I make take a couple of days, and
since my news server seems to drop things after they are a couple of days old
it's probably safer to send these questions through email:
emboss1(AT)i4free.co.nz
Regards,
Michael
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Def'n of bijection
Reply-To: [EMAIL PROTECTED]
Date: Fri, 8 Jun 2001 09:47:18 GMT
[EMAIL PROTECTED] wrote:
: Tim Tyler <[EMAIL PROTECTED]> writes:
:> The results are here: The messages get a bit shorter.
Incidentally, chopping out a huge section from the middle of a post,
juxtaposing widely separated text on the same line while including no
editorial marks to show what you've done in order to produce the
impression that I /had/ no worthwhile results - attributing it to me
and then jeering at the newly created sentence with sarcastic comments
is *another* low debating tactic.
This is the fourth time I have had to draw issues of common courtesy to
your attention this week. :-(
I tire of you as a debating partner. You are ignorant, stubborn, unable
to follow arguments, don't acknowledge your mistakes - and treat the
discussion as though it's in a debating society in which any
detating ploy goes, so long as you win the argument.
This behaviour may be acceptable in the company you keep - but I am
accustomed to better, and no longer feel obliged to stoop to your
level in order to help correct your misconceptions.
--
__________
|im |yler [EMAIL PROTECTED] Home page: http://alife.co.uk/tim/
------------------------------
From: Erwann ABALEA <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: Some questions on GSM and 3G
Date: Fri, 8 Jun 2001 11:57:20 +0200
On Fri, 8 Jun 2001, Mok-Kong Shen wrote:
>
>
> Gregory G Rose wrote:
> >
> [snip]
> > There is, indeed, a COMP-128-2, but that still
> > belongs to the GSM Association, and I know
> > nothing about it. This should be looked at as a
> > "fix" for existing GSM rather than an evolution,
> > although operators have always been able to use
> > their own algorithms rather than COMP-128 anyway.
> > There is a corresponding set of algorithms called
> > Milenage (the name appears to be a Francophone
> > in-joke, I don't know what it means) that are
> > based on Rijndael, to be used for UMTS and GERAN.
> > Again, that specification is available off the
> > above URL.
>
> Does this imply that there would be a free choice
> between Kasumi and AES? Thanks.
For the authentication and key negociation parts, yes. A GSM operator is
free to use his own algorithm for these parts. In fact, COMP128 is a
proposed algorithm to perform these 2 operations.
The authentication part is performed with an algorithm named A3, and the
key negociation by an algo named A8. These algorithms are 'played' only by
the authentication center of the operator and the smartcard of the
subscriber to this operator. So the operator can use anything he wants as
A3 and A8, as soon as the inputs and outputs conform to the standard.
COMP128 is a proposed algorithm to perform both functions.
--
Erwann ABALEA
[EMAIL PROTECTED]
- RSA PGP Key ID: 0x2D0EABD5 -
------------------------------
Subject: Re: Def'n of bijection
From: [EMAIL PROTECTED]
Date: 08 Jun 2001 06:04:56 -0400
Tim Tyler <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>: Tim Tyler <[EMAIL PROTECTED]> writes:
>:
>:> The results are here: The messages get a bit shorter.
>
> Incidentally, chopping out a huge section from the middle of a post,
> juxtaposing widely separated text on the same line while including no
> editorial marks to show what you've done in order to produce the
> impression that I /had/ no worthwhile results [...]
You had no worthwhile results. The upshot of your ``experiment''
was the earth-shattering conclusion that ``the messages get a bit
shorter.'' For some reason you saw a need to prove that--but don't
see a need to prove that BICOM improves secrecy for real messages.
> ...no longer feel obliged to stoop to your level in order to help
> correct your misconceptions.
No need for hard feelings. You can't prove that normal messages are
any more likely to yield false decrypts after being compressed with
BICOM. You can't prove it because it isn't true--but if name-calling
makes you feel better about it, feel free.
Len.
--
That's why modern UNIX systems support resource limits. RTFM.
-- Dan Bernstein
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
