Cryptography-Digest Digest #903, Volume #10 Fri, 14 Jan 00 10:13:01 EST
Contents:
Re: Why is EDI dead? Is S/MIME 'safe'? Who and why? ("Meint Post")
Re: LSFR ("Michael Darling" noral<dot>co<dot>uk>)
Re: LSFR ("Michael Darling" noral<dot>co<dot>uk>)
Re: LSFR ("Michael Darling" noral<dot>co<dot>uk>)
Re: Random numbers generator (Bob Deblier)
Re: About DES algorithm. ("Rick Braddam")
Re: Need some design suggestions for mass encryption ("Lyal Collins")
Re: LSFR (Robert Largent)
Re: LSFR ("Michael Darling" noral<dot>co<dot>uk>)
Re: Random numbers generator (Sander Vesik)
Re: Triple-DES and NSA??? (Bernie Cosell)
Re: Ciphers for Parallel Computers (John Bailey)
RSA ("Kreuzer Michael")
Re: LSFR (Terje Mathisen)
Re: "1:1 adaptive huffman compression" doesn't work (SCOTT19U.ZIP_GUY)
Re: "1:1 adaptive huffman compression" doesn't work (SCOTT19U.ZIP_GUY)
Re: RSA (Michael J. Fromberger)
----------------------------------------------------------------------------
From: "Meint Post" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.misc,alt.security.pgp
Subject: Re: Why is EDI dead? Is S/MIME 'safe'? Who and why?
Date: Fri, 14 Jan 2000 10:26:05 +0100
Michael Str�der <[EMAIL PROTECTED]> schreef in berichtnieuws
[EMAIL PROTECTED]
> I would expect that people will use S/MIME to embedd XML data (as
> MIME object) and that there might be DTDs which describes how to
> embedd encrypted/signed data into XML.
Have a look at http://www.w3.org/Signature/
excerpt "This document specifies the syntax and processing rules for the
encoding of digital signatures using XML. Such signatures can provide
integrity, message authentication, and/or signer authentication services for
data of any type, whether located within the XML that includes the signature
or locatable elsewhere."
Regards,
Meint
------------------------------
From: "Michael Darling" <michaeld<at>noral<dot>co<dot>uk>
Subject: Re: LSFR
Date: Fri, 14 Jan 2000 09:40:27 -0000
No I'm not considering using this method, I couldn't even begin to store the
data.
The counter running at 200Mhz will loop after 32 days, so they are
reachable.
regards,
Mike.
Scott Nelson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 13 Jan 2000 "Michael Darling" wrote:
>
> >if you order the list then you must store the sequence index along with
the
> >item.
> >This would double the size of the data storage required.
> >
>
> Some orderings are more compact, but yes, for efficiency
> you should save more than just the data value.
>
> If increasing memory use by a factor of two is significant,
> (in other words, if you're seriously contemplating doing this,
> and are already thinking about memory optimization)
> then you should consider how many of those states are
> really reachable. You might be able to rule out states
> that won't be reached for several hundred years,
> by which time computers will have improved enough to
> make a complete search more reasonable.
>
> Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: "Michael Darling" <michaeld<at>noral<dot>co<dot>uk>
Subject: Re: LSFR
Date: Fri, 14 Jan 2000 10:03:06 -0000
Unfortunately Gray codes are expensive logically and suffer from the same
delays as a binary counter because each
bit needs to be monitored.
>
> Have you looked at gray codes? They have no carry propagation because
only a
> single bit changes between states. And the transform from gray numbers to
> normal numbers is quite simple in both directions.
>
------------------------------
From: "Michael Darling" <michaeld<at>noral<dot>co<dot>uk>
Subject: Re: LSFR
Date: Fri, 14 Jan 2000 10:05:27 -0000
We like this idea - looking into it.
Cheers,
Mike.
Scott Nelson <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> You might also consider a hybrid approach,
> as much ripple counter as you can stand, and the
> rest lfsr.
>
> Scott Nelson <[EMAIL PROTECTED]>
------------------------------
From: Bob Deblier <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator
Date: Fri, 14 Jan 2000 11:39:57 +0100
Simone Molendini wrote:
> Hi all,
>
> where can I find C code for a *good* random number generator?
>
> C rand() routine seems me to be a weak one: it has only a 32768 cycle (it
> seems me).
>
> Ciao, Simone
Check out the Mersenne Twister, at
http://www.math.keio.ac.jp/~matumoto/emt.html
Bob Deblier
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: About DES algorithm.
Date: Thu, 13 Jan 2000 03:25:02 -0600
Katsamakas Kostas <[EMAIL PROTECTED]> wrote, in part:
> I know that unix systems use the crypt function to encrypt a
>password.
>According to the man page, this function uses a variation of the DES
>algorithm
>using two extra characters as salt.
>Where can i find the description of the algorithm the crypt function
>uses, so i could implement it?
>I would like also the DES algorithm.I have searched, but i have found
>general descriptions of it.
It contains a lot more than just the DES algorithm, but you may want to
download the source for OpenSSL from http://www.openssl.org/ . It is
based on Eric Young's SSLeay library.
Rick
------------------------------
From: "Lyal Collins" <[EMAIL PROTECTED]>
Subject: Re: Need some design suggestions for mass encryption
Date: Fri, 14 Jan 2000 22:57:22 +1100
Take a look at Centura's databases
Lyal
Albert Yang wrote in message <[EMAIL PROTECTED]>...
>Hey there crypto-heads, I need some help.
>
>My company has commissioned me with a daunting task. We deal with
>highly sensitive private information (phone, credit card #, addy, etc..)
>and we want to save it on our DB encrypted. But there are certain
>things that have to happen. For example, I'm allowed to share my phone
>number or address with certain people, kind of like a group
>phonebook... So I would need to allow them access at any time. Yes, I
>know, sounds like a Public key deal, where I just encrypt with all the
>public keys that I want to have access to my stuff. But I need to be
>able to revoke access from certain people at any given time. So is
>there any way to design this smartly, where I don't have to basically
>decrypt, reencrypt with one less key, just to deny someone who use to be
>on my access list? Also, Public key crypto is slow, I'm not sure this
>is something that public crypto can do on the fly, fast enough. I would
>need to use something that's really fast. So any suggestions are
>welcome!
>
>Thank you,
>Albert
------------------------------
From: Robert Largent <[EMAIL PROTECTED]>
Subject: Re: LSFR
Date: Fri, 14 Jan 2000 23:16:45 +1100
Reply-To: [EMAIL PROTECTED]
Dear Michael,
>From reading through your posts it looks like what you are after
is a digital way of determining at what time an event occurred.
>From the hardware side this is most easily done by counting clock
ticks with a binary counter. If you are looking at having a
digital output that is referenced to a specific time then
binary counters that can be pre-loaded (such as cascaded s
ynchronous 4 bit 74hc191's) form a building block.
This allows you to have a specific number such as 0x87ab22
which is pre-loaded into the counters to represent today's
date and time and then off they go counting like a clock.
(Of course the number you load tomorrow is different than
today's.)
If you need to count clock ticks only, not referenced to an
absolute time--say the number of clock ticks since the device
was turned on (such as an hour meter for a device with a
1,000 hour warranty)-then, a binary counter is all that
is needed.
If the clock signals are coming fast (ns) then you will
need a big counter and if you have slow clock signals
(ms or seconds) you need smaller counters.
These counters can be tailored to your need by using
logic arrays. Then it looks as if one chip does it all
for you.
Your desire to use a lfsr is understandable. The lfsr is
really a sneaky way of making a counter out of a shift
register. Very easy to electronically implement; however,
the output of the shift register is gibberish, and, there is
no easy way to translate the binary presented at the output
of the shift register into a meaningful value (in your
case, time). The circuit is easy and the value changes
for every count but the method does not come with a
correspondingly simple way to interpret the output.
If you are interested in lfsr, a very nice Application
Note with all of the taps listed for maximum-length
lfsr up to 168 bits can be found at
http://www.edtn.com/scribe/reference/appnotes/md000769.htm
A logic array to fabricate synchronous counters could
be the way to go. You can get a lot in a little package
nowadays-all you have to do is tell it what you want it
to be by programming it. It is a solution waiting for
a problem.
Regards,
Rob
Michael Darling wrote:
>
> We wish to use an LSFR to generate a time stamp for an electronic component
> we are designing.
>
> The idea is to use a very simple 2 tap LSFR which is 49 bits long with taps
> at bit 9 and bit 0.
> This would provide us a nice non-repeating sequence which we could use to
> uniquely identify each stamp.
>
> Now then: We want to say when each stamp occurred, i.e. map each output to
> its location in the sequence.
>
> In other words we want to get an output and say that it is output 'n' in the
> sequence.
>
> Obviously, we don't want to run through the sequence in software and match
> the output we got from the
> hardware - as this could take some time :)
>
> Are we being naive to expect that we can do this, or is there a method that
> we don't know about?
>
> Thanks in advance for any replies,
> Mike Darling.
--
________________________________________________________________
Robert Largent Photovoltaics Special Research Centre
Design Assistance Division University of New South Wales
[EMAIL PROTECTED] School of Electrical Engineering
http://www.pv.unsw.edu.au Sydney, NSW 2052 Australia
------------------------------
From: "Michael Darling" <michaeld<at>noral<dot>co<dot>uk>
Subject: Re: LSFR
Date: Fri, 14 Jan 2000 12:36:50 -0000
Hi Rob, Thanks for your reply.
We could indeed use a binary counter - and that is what we will do if we
cannot solve this problem.
However the binary counters suffer from carry propagation delays whereas an
LSFR wouldn't, this
gives us a big boost in speed which is what we need. I'll pass on the log
array synchronous counter
info to our electronics bods and see what they think. Meanwhile thanks for
the link.
regards,
Mike.
Robert Largent <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Dear Michael,
>
> From reading through your posts it looks like what you are after
> is a digital way of determining at what time an event occurred.
> From the hardware side this is most easily done by counting clock
> ticks with a binary counter. If you are looking at having a
> digital output that is referenced to a specific time then
> binary counters that can be pre-loaded (such as cascaded s
> ynchronous 4 bit 74hc191's) form a building block.
>
> This allows you to have a specific number such as 0x87ab22
> which is pre-loaded into the counters to represent today's
> date and time and then off they go counting like a clock.
> (Of course the number you load tomorrow is different than
> today's.)
>
> If you need to count clock ticks only, not referenced to an
> absolute time--say the number of clock ticks since the device
> was turned on (such as an hour meter for a device with a
> 1,000 hour warranty)-then, a binary counter is all that
> is needed.
>
> If the clock signals are coming fast (ns) then you will
> need a big counter and if you have slow clock signals
> (ms or seconds) you need smaller counters.
>
> These counters can be tailored to your need by using
> logic arrays. Then it looks as if one chip does it all
> for you.
>
> Your desire to use a lfsr is understandable. The lfsr is
> really a sneaky way of making a counter out of a shift
> register. Very easy to electronically implement; however,
> the output of the shift register is gibberish, and, there is
> no easy way to translate the binary presented at the output
> of the shift register into a meaningful value (in your
> case, time). The circuit is easy and the value changes
> for every count but the method does not come with a
> correspondingly simple way to interpret the output.
>
> If you are interested in lfsr, a very nice Application
> Note with all of the taps listed for maximum-length
> lfsr up to 168 bits can be found at
> http://www.edtn.com/scribe/reference/appnotes/md000769.htm
>
> A logic array to fabricate synchronous counters could
> be the way to go. You can get a lot in a little package
> nowadays-all you have to do is tell it what you want it
> to be by programming it. It is a solution waiting for
> a problem.
>
>
> Regards,
>
> Rob
>
> --
> ________________________________________________________________
> Robert Largent Photovoltaics Special Research Centre
> Design Assistance Division University of New South Wales
> [EMAIL PROTECTED] School of Electrical Engineering
> http://www.pv.unsw.edu.au Sydney, NSW 2052 Australia
------------------------------
From: Sander Vesik <[EMAIL PROTECTED]>
Subject: Re: Random numbers generator
Date: 14 Jan 2000 12:52:34 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> Simone Molendini wrote:
>> C rand() routine seems me to be a weak one: it has only a 32768 cycle (it
>> seems me).
> The example implementation found in the 1989 C standard has a period
> of 2^32, as I recall. I've seen it misimplemented (e.g. on some BSD
And problems with the randomness of many of the lower bits, IIRC.
> UNIX systems) such that it has worse properties, but for a generator
> of that general class (affine multiplicative) it is a good one. For
> some applications it suffices; for others, it doesn't. That is true
> of any pseudo-random number generator.
Why would one ever use rand() instead of random()?
--
Sander
There is no love, no good, no happiness and no future -
these are all just illusions.
------------------------------
From: Bernie Cosell <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.security
Subject: Re: Triple-DES and NSA???
Date: Fri, 14 Jan 2000 08:31:52 -0500
[EMAIL PROTECTED] (mdc) wrote:
} On Wed, 12 Jan 2000 01:16:11 -0500, anonymous <[EMAIL PROTECTED]>
} wrote:
}
} >Did the NSA screw around with Triple-DES like they did with DES back in
} >the 70s? How secure is it in comparison to blowfish and other
} >algorithms?
}
} I don't have the inside dope to either confirm or deny any "screwing around"
} with DES, so I'll just stick to the facts.
Other than to observe that in 25 years no one has found *any* weakness or
other problem with DES and so one can conclude either that the 'screwing
around' was so subtle and deep that *no* cryptographer has stumbled across
the weakness they hid; or else that they didn't screw around with it at all
[in the sense the original poster implied].
/Bernie\
--
Bernie Cosell Fantasy Farm Fibers
[EMAIL PROTECTED] Pearisburg, VA
--> Too many people, too few sheep <--
------------------------------
From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: Ciphers for Parallel Computers
Date: Fri, 14 Jan 2000 13:33:41 GMT
On Fri, 14 Jan 2000 07:00:30 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>While I can't think of a form of encryption suitable for use on a
>quantum computer, the ultimate form of parallel computer (quantum
>cryptography has to do with a secure communications medium, and thus
>relates to invisible ink rather than being algorithmic), an ordinary
>parallel computer could be used efficiently for one type of cipher.
(snip)
>Thus, if technology reaches an upper limit to how _fast_ a single
>processor can be made - but does not reach an upper limit to how
>_cheap_ such a processor can be, thus allowing very large parallel
>computers to be made, it is possible to make full use of such a
>computer in encipherment with this kind of approach. Hence preventing
>the otherwise inevitable result of an advantage to the cryptanalyst
>resulting from the technology going in that direction.
In a thread on sci.math, the question of what Quantum Computers could
do that a Turing Machine could not do? On response by webster2000:
http://www.deja.com/[ST_rn=ap]/getdoc.xp?AN=566605921&fmt=text
included the suggestion that since quantum computers could solve NP
complete problems in polynomial time, one needed to find problems
which would require Exponential time for solution even on a Quantum
Computer
Your proposal is a step in that direction. Hopefully, some good ideas
will emerge.
In article <84gftk$42l$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> In article <[EMAIL PROTECTED]>,
> "Dan Goodman" <dog AT fcbob DOT demon DOT co DOT uk> wrote:
> > Is it possible than quantum computers could conceivably compute things
> that
> > a Turing machine could not compute?
>
> Theoretically no.
> D. Deutsch, Proc. Roy Soc A400,97(1985)
> D. Deutsch, Proc. Roy Soc A425,73(1989)
>
> Today, we depend on computing tasks that are NP-complete hence requiring
> exponential times for completion and thus protecting data essential for
> commerce. As quantum computing becomes a reality, larger tasks will
> have to be designed, requiring the solution of galaxies of NP-complete
> problems (without the known backdoor), so that critical data can be
> protected.
>
> Here is the challenge: what is the structure of a Quantum Computing
> task which would require the solution of M NP-complete problems in order
> to break the embedding. Devising such a problem so that it also has a
> way that the constructor can solve it without such a brute force search
> might well position the inventor:
> a) Become a Billionaire
> b) Win a Nobel Prize or
> c) Be spririted away by a three letter organization and pampered for
> life.
>
> Back to the original question. A problem, designed to be large and time
> consuming for a Quantum Computer would be essentially intractible for a
> classic computer. The implications of this are explored in
> http://xxx.lanl.gov/abs/quant-ph/9602016
------------------------------
From: "Kreuzer Michael" <[EMAIL PROTECTED]>
Subject: RSA
Date: Fri, 14 Jan 2000 14:44:23 +0100
Hello,
i have a big big problem. i must decode a rsa code. its my homework *g* can
anyone help me?
the code :
key : 51,3
616
591
382
350
788
630
892
180
665
999
176
504
227
936
423
908
it should be a german word. please help me :)
thx
Kreuzer Michael
[EMAIL PROTECTED]
------------------------------
From: Terje Mathisen <[EMAIL PROTECTED]>
Subject: Re: LSFR
Date: Fri, 14 Jan 2000 15:23:03 +0100
(posted and emailed)
"Michael Darling noralco" wrote:
>
> Hi Rob, Thanks for your reply.
>
> We could indeed use a binary counter - and that is what we will do if we
> cannot solve this problem.
> However the binary counters suffer from carry propagation delays whereas an
> LSFR wouldn't, this
> gives us a big boost in speed which is what we need. I'll pass on the log
> array synchronous counter
> info to our electronics bods and see what they think. Meanwhile thanks for
> the link.
You have another quite simple approach:
Use a carry-save adder!
This doubles the amount of storage needed, but the electronics becomes
dead simple:
Each stage of the counter will have two inputs:
carry_in and data_in
and it will generate two outputs:
carry_out and data_out
The truth table is obvious:
carry_in 0 0 1 1
data_in 0 1 0 1
carry_out 0 0 0 1
data_out 0 1 1 0
I.e. carry_out = data_in AND carry_in, data_out = data_in XOR carry_in
To sample this counter, just read both the data and carry array, and add
them together.
To do this in sw for a 64-bit counter I'd use code like this:
static u64 data, carry;
void increment(void)
{
u64 temp_carry;
// Generate the new carry array:
temp_carry = data & carry;
// Generate the next state of the data array:
data = data ^ carry;
// Shift up the carry array and set the bottom bit, ready for the next
iteration:
carry = (temp_carry << 1) | 1;
}
So, to generate this counter, you'll need to use a single two-input XOR
and a similar two-input AND gate, with the bottom bit of the carry array
hardwired to shift in '1' bits.
The latches needed to be able to read out the current value of the
counter will take more hardware than the counter itself, but this is
true for the LFSR approach as well.
Terje
--
- <[EMAIL PROTECTED]>
Using self-discipline, see http://www.eiffel.com/discipline
"almost all programming can be viewed as an exercise in caching"
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Fri, 14 Jan 2000 15:36:55 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>Tim Tyler wrote:
>>
>> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>>
>> : My proposal is able to satisfy the requirement you
>> : originally raised, i.e. to give the analyst no information via
>> : the decompression-(re-)compression process.
>>
>> Which it would do reasonably well, /if/ you could get hold of some "real"
>> random numbers. Getting hold of them in a portable way would be better
>> still.
>
>I have explained in a previous follow-up that one needs only
>'non-constancy'. Here is a repetition: Suppose the decrypted
>compressed file is uncompressed and compressed again. The two
>files can be compared to easily find out the filling bits. Suppose
>the old and new filling bits are 00 and 11 respectively. What
>information does the analyst get from that? He knows that if, for
>example, he contitunes to do uncompress-compress he will get
>in most cases different filling bits. So from these filling bits
>he knows nothing. If you don't agree with this, please kindly show
>where my argument is wrong with details. Simply claiming that it
>doesn't work or doesn't work well is not sufficient.
>
if you have two filling bits. And if you assume the person decodeing
has the compression programns he can just ignore the filling bits during
the comparsions. That way the person trying to break the code can really
just ignore them.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: "1:1 adaptive huffman compression" doesn't work
Date: Fri, 14 Jan 2000 15:38:31 GMT
In article <[EMAIL PROTECTED]>, Mok-Kong Shen <[EMAIL PROTECTED]>
wrote:
>SCOTT19U.ZIP_GUY schrieb:
>>
>> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> <[EMAIL PROTECTED]> wrote:
>> >SCOTT19U.ZIP_GUY wrote:
>> >>
>> >> <[EMAIL PROTECTED]> wrote:
>
>> >> >least theoretically more satisfying) products. But on retrospect,
>> >> >if my proposal were put forth earlier, there would be in my humble
>> >
>> >> What humble opinion
>> >
>> >If you consider modesty is bad, then substitute it with 'my high
>> >opinion'. o.k. for you now??
>>
>> I don't consider modesty bad. I consider false modesty bad.
>
>What do you mean false modesty here? I don't absolutely exclude that's
>because I am not a native English speaker. But to my best knowledge
>there is nothing 'particular' implied in the 'courtesy' words in
>phrases like 'yours sincerely', IMHO, etc. etc. Look at what the French
>people write when they end their letters!! On the other hand, I find
>those (not infrequent) posts on the internet that contain bad words
>(swear-words) simply horrible.
>
Well Mr Mok that life.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: Michael J. Fromberger <[EMAIL PROTECTED]>
Subject: Re: RSA
Date: 14 Jan 2000 14:12:21 GMT
In <387f285f$0$[EMAIL PROTECTED]> "Kreuzer Michael" <[EMAIL PROTECTED]>
writes:
>Hello,
>i have a big big problem. i must decode a rsa code. its my homework *g* can
>anyone help me?
>the code :
>key : 51,3
>616
>591
>382
>350
>788
>630
>892
>180
>665
>999
>176
>504
>227
>936
>423
>908
>it should be a german word. please help me :)
Michael,
The RSA encryption and decryption rule are modular exponentiation --
that is:
C = M^e (mod n)
M = C^d (mod n)
If n = 51, and d = 3, then you can take each x from the list above,
and compute:
x^3 (mod 51)
... to get the decoding. (With n = 51, p = 3 and q = 17, so e = 11).
Hint:
616 = 4 (mod 51), 4^3 = 13 (mod 51)
591 = 30 (mod 51), 30^3 = 21 (mod 51)
You should work out the rest on your own (after all, this is your
homework, not mine :)
-M
--
Michael J. Fromberger Software Engineer, Thayer School of Engineering
sting <at> linguist.dartmouth.edu http://www.dartmouth.edu/~sting/
v6rycpQqzbZWnSpxba6RiABupdywJ7xnotJXiGqGdXdYnsmjpUmFajXMcrJ3Ob6Sw5vofJPN
"Who needs exclamation points when you have capital letters?"
-- C. Emmons
------------------------------
** 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
******************************
