Cryptography-Digest Digest #415, Volume #10 Fri, 15 Oct 99 09:13:04 EDT
Contents:
fast PSRG ++ A5 question ([EMAIL PROTECTED])
Re: --- sci.crypt charter (David A Molnar)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Mok-Kong
Shen)
Q: Optimal diffusion (Mok-Kong Shen)
Re: des question ("Richard Parker")
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Peter
Galbavy)
Re: Block encryption with variable keys
Re: Q: Optimal diffusion (Hideo Shimizu)
Re: where to put the trust ([EMAIL PROTECTED])
SG100 Hardware Random Number Generator (Bo D�mstedt)
Re: where to put the trust ([EMAIL PROTECTED])
Re: fast PSRG ++ A5 question ("Trevor Jackson, III")
Re: where to put the trust ([EMAIL PROTECTED])
Re: where to put the trust ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: fast PSRG ++ A5 question
Date: Fri, 15 Oct 1999 07:57:21 GMT
Which stream cipher or PSRG provide the
best speed in hardware implementation?
The security requirement is oriented on
a block cipher with app: 2^^64 possibilities.
****************
The algorithm A5/1 which is used in GSM
includes three LFSR.
The key is 64 bit. In which way the key
is used. Is the key the initial state of
the registers or the feedback coefficients.
gransche
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: --- sci.crypt charter
Date: 15 Oct 1999 07:43:55 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> I see that you haven't been following recent developments in
> steganography. A typical example is: embed the covert message
> indetectably in an overt, unobjectionable image; you might for
> example be allowed to send news photos along with wire-service
> news stories. Before you jump on the one simple example, look
> up "steganography" on the Web, to get a feel for the various
> ways that information can be hidden in modern communications.
You're right. Thank you for pointing out the
existence of more modern methods. I've now come across the workshops on
information hiding, which by themselves should keep me reading for a
while. Plus everything else...
Thanks,
-David
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: Fri, 15 Oct 1999 10:13:27 +0200
Roger Schlafly wrote:
>
> Trevor Jackson, III <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Let those who like standards pick from the final five. If you like
> standards,
> > more standards is better isn't it?
>
> No. Two standards for the same thing means that there is
> no standard. Your statement is like saying, if you like
> monogamy, more wives is better.
Remember that triple DES IS a seperate standard from single DES.
Why did the financial people think that single DES could be a
risk to them well before the hardware (processing speed) and
theory (differential analysis etc.) have pushed such a risk
out of a dream into reality? I guess from this fact that the
risk assessment and security requiments of one person can be VERY
different from another. Thus it is extremely difficult to have
one thing that fits all. I personally don't deem it entirely
unrealistic that the history might indeed repeat here: After AES
there would soon be triple AES.
M. K. Shen
=======================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Q: Optimal diffusion
Date: Fri, 15 Oct 1999 10:42:13 +0200
Is there a mapping of n bits to n bits that gives the best diffusion?
Let me illustrate the problem: With n=8 the following matrix appears
to do quite an amount of diffusion
1 1 1 1 0 0 0 0
0 0 0 0 1 1 1 1
1 1 0 0 1 1 0 0
0 0 1 1 0 0 1 1
1 0 1 0 1 0 1 0
0 1 0 1 0 1 0 1
1 0 0 1 1 0 0 1
0 1 1 0 0 1 1 0
My question is then the existence of an optimal matrix or matrices.
Thanks in advance.
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Richard Parker" <[EMAIL PROTECTED]>
Subject: Re: des question
Date: Fri, 15 Oct 1999 08:41:46 GMT
"King" <[EMAIL PROTECTED]> wrote:
> Is triple DES simply running the message through DES rounds three times?
Three-key triple DES passes each 64-bit block of data through DES
three times, each time using an different independent 56-bit key, for
a total key size of 168 bits.
> Why three?
It turns out that double DES is not as strong as one might expect.
Merkle and Hellman invented an attack on double DES. The attack,
called a meet-in-the-middle attack, has a complexity of about 2^57.
This is not significantly stronger than an exhaustive key search of
single DES, which has a complexity of 2^56. Merkle and Hellman also
found a meet-in-the-middle attack on three-key triple DES. It has a
complexity of about 2^112.
> And why and how much does it increase the security?
If one assumes that exhaustive key search is the most practical attack
on single DES and that a meet-in-the-middle attack is the most
practical attack on three-key triple DES then triple DES is about 2^56
times more resistant to attack. However, if the adversary can choose
to encrypt a great deal of his own plaintext then there is an attack
with a complexity of 2^43 on single DES. Furthermore, there is an
improved attack on triple DES with a complexity of about 2^90, but it
requires a lot of known plaintext and a truly huge amount of memory.
Using these numbers would make triple DES about 2^47 times more
resistant to attack than single DES.
Here is a reference for Merkle and Hellman's meet-in-the-middle
attacks:
R.C. Merkle and M.E. Hellman, "On the security of multiple
encryption," Communications of the ACM, v. 24, July 1981,
pp. 465-467.
-Richard
------------------------------
From: [EMAIL PROTECTED] (Peter Galbavy)
Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
Date: 15 Oct 1999 09:18:32 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
Brian Gladman wrote:
>I am inclined to believe that five algorithms provides too much diversity
>and this might be the result of choosing just one winner. I have less of a
>concern if we eliminate two and choose a winner from the remaining three but
>we would need to ensure that all three that remain are free of all IPR
>constraints.
Should I, in all seriousness, be thankful that the AES contest is
being undertaken in the US ? In the UK, I can guarentee you the
outcome: The winner would be the company holding the most profitable
IPR that then subsequently employs the government miniter(s)
responsible for the selection, after they leave parliment.
What safeguards are there to prevent this ? I remember reading that
most participants will give out "free" licenses if their contestant is
chosen - but is there a mandatory surrender of those rights required
to complete ? (Kudos to those who are entering non-IPR laden entries).
Regards,
--
Peter Galbavy
Knowledge Matters Ltd
http://www.knowledge.com/
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Block encryption with variable keys
Date: 15 Oct 99 09:06:39 GMT
Paul Crowley ([EMAIL PROTECTED]) wrote:
: [EMAIL PROTECTED] () writes:
: > That last is perhaps the main point: a block cipher *can* be used in modes
: > that do not require an IV (initialization vector), and a stream cipher
: > cannot. (Yes, that too is an oversimplification...) Since for some
: > applications (i.e. in-place disk encryption) no expansion of the
: > plaintext can be tolerated, therefore a block cipher.
: Building a secure disk block encryption algorithm from a block cipher
: is distinctly non-trivial. I know of no secure way of doing it that
: is not more complex than Anderson and Biham's approach of using a hash
: function and a stream cipher in an unbalanced Feistel network (BEAR
: and LION).
That is a good point, but I think that simplistic methods of disk
encryption, even if not fully secure (an adversary who only has a one-time
snapshot of the disk, rather than one who can observe the encrypted disk
on an ongoing basis, and see which sectors change, may be being
considered) were still present in the thinking of those who initiated the
strong preference for block ciphers.
John Savard
------------------------------
From: Hideo Shimizu <[EMAIL PROTECTED]>
Subject: Re: Q: Optimal diffusion
Date: Fri, 15 Oct 1999 19:10:05 +0900
Mok-Kong Shen wrote:
>
> Is there a mapping of n bits to n bits that gives the best diffusion?
> Let me illustrate the problem: With n=8 the following matrix appears
> to do quite an amount of diffusion
>
> 1 1 1 1 0 0 0 0
> 0 0 0 0 1 1 1 1
> 1 1 0 0 1 1 0 0
> 0 0 1 1 0 0 1 1
> 1 0 1 0 1 0 1 0
> 0 1 0 1 0 1 0 1
> 1 0 0 1 1 0 0 1
> 0 1 1 0 0 1 1 0
>
> My question is then the existence of an optimal matrix or matrices.
Yes.
Linear transform matrix and coding theory have close relations.
We can make generator matrix of linear code by concatinating identity
matrix and transpose of transform matrix, say G = (I|P^t).
The code generated from best diffusion matrix have best minimum distance.
In the 8x8 transform matrix case, best diffusion (branch number or
diffusion order) is 5.
Because no (16, 8, 6) binary codes exist, and there is only (16,8,5)
binary linear code. So, AES candidate E2 achieve best diffusion.
In other than binary case, MDS code can achieve best diffusion
such as SHARK. Suprisingly, Serpent's branch number is only 3.
Sorry for bad English.
Hideo Shimizu
TAO, Japan
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: where to put the trust
Date: Fri, 15 Oct 1999 10:14:41 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> : [EMAIL PROTECTED] wrote:
>
> :> Still, the question remains: if we don't trust the experts then
what
> :> is the better alternative?
>
> : I am tempted to say that in any case where the "experts" are
> : not bound to us by contract or compensation, the expert we
> : should first trust is ourself.
>
> That would be easy for you to say - you're an "expert".
>
> Try preaching that council to an application programmer who's been
told
> to add security features to his program - and watch the blank stare.
>
> He doesn't have /time/ to learn all about the ins and outs of
> crypyanalysis before he makes his implementation decision. He needs
> to trust the work of others.
Yes, I know. I suspect even that most people on sci.crypt
cannot or will not reason the implications for themselves.
Still, who do we trust with our money? We may select
someone, but it is us doing the selecting. Typically we
select those who have some contractual responsibilities.
But, ultimately, we are responsible.
> : We need to accept that *any* cipher may be weak, and think
> : of what we can do in that environment, since that is our
> : reality.
>
> It sounds like a council of doom. Certainly spend /some/ time
considering
> the worst possible scenario, but don't spend /all/ your time doing
so, or
> you're likely to wind up in a state akin to paranoia, and fail to
take
> positive action.
I think what we need do is first accept reality for what it
is, and then see if we cannot mitigate the situation with
new approaches and protocols. My suggestions are well known
(3-level multiciphering, independent keys, ciphers changing
frequently by automatic negotiation).
If someone knows something better, let's hear about it.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: SG100 Hardware Random Number Generator
Reply-To: [EMAIL PROTECTED]
Date: Fri, 15 Oct 1999 11:34:25 GMT
We have today released the complete source for our SG100
Hardware Random Number Generator. The purpose of the release,
of the source code, is to give our customers a better understanding
of our product. The internal workings of the hash function, inside
the SG100 driver, could be of interest to sci.crypt readers as
this hash function is especially designed to extract entropy from a
source with correlations and statistical deficiencies.
The SG100 page
http://www.protego.se/sg100_en.htm
The link to the source can be found on page
http://www.protego.se/document_centre_en.htm
Statistical testing of the SG100 driver:
http://www.protego.se/doc/plabreport8.pdf or
http://www.protego.se/doc/pLabReport8.ps
Bo D�mstedt
Chief Cryptographer
Protego Information AB
IDEON,Lund,Sweden
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: where to put the trust
Date: Fri, 15 Oct 1999 10:30:56 GMT
I appear to be losing messages in my ISP. If someone wants
a reply, give me a nudge.
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
>
> : While "trust many experts" may be better than trusting any
> : one "expert," this still does not address the essence of the
> : problem: there can be no expertise on strength which applies
> : to our opponents.
>
> Yours seems to be a council of doom ;-(
>
> In reality there /is/ some feedback about whether cyphers are being
> broken. Ships get sunk, troops get shot, battles get lost, etc.
>
> Now the enemy can do their best to avoid revealing that their
information
> has been obtained by compromising a cypher, but this necessarily
limits
> the uses to which they can put their information.
>
> You can sometimes test to see whether a code has been broken: change
the
> code to something cumbersome, but secure for a while.
>
> If this results in improvements to your situation, you can suspect
> strongly that the cause is due to the enemy being able to break your
> cypher.
>
> Things can be bad - but they need not always be as bad as all that.
It is certainly true that security professionals should
try to test cipher strength by tempting the other side in
various ways. It is also true that the opposing security
professionals can and do run complex operations to convince
everyone that any exposure was not from cipher but instead
from some other event. Now the issue is not just whether
we have an effective cipher, but whether we also have the
best security professionals who happen to be on top of the
whole thing.
Nevertheless, individual users cannot know, in most cases,
when their opponents have broken their cipher. Indeed,
this is compounded when everyone uses the same cipher,
because only a few people will get indications of trouble,
and the rest will rationalize that they were from some
other exposure.
> I believe your assertion that there can be no experts in
cryptographic
> strength seems too strong.
I believe my assertion is correct in the domain of open
cryptography. In military or state cryptography, there
may indeed be some such expertise. It will never be the
kind of expertise we expect in other areas, however.
> I /know/ that there are people who know very little about
cryptographic
> strength. An "expert" is someone at the opposite pole. They may not
know
> *everything* - or even very much - but they're the best we have.
I disagree. The best we have is to first realize that we
have a problem, and then try to solve, or at least mitigate
the problem. I have made some proposals. If anybody has a
better idea, I'd be glad to hear it. And if there are no
better ideas, I think we'd be well advised to go with what
we have.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 15 Oct 1999 07:03:07 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: fast PSRG ++ A5 question
[EMAIL PROTECTED] wrote:
> Which stream cipher or PSRG provide the
> best speed in hardware implementation?
> The security requirement is oriented on
> a block cipher with app: 2^^64 possibilities.
>
> ****************
>
> The algorithm A5/1 which is used in GSM
> includes three LFSR.
> The key is 64 bit. In which way the key
> is used. Is the key the initial state of
> the registers or the feedback coefficients.
>
I cannot answer you definitively, but I can point out that usually the
key is used as the initial state of the register. The reaosn for this
is that, given a good (maximal) feedback function all non-zero initial
states are equally good in that they have the same (maximal) period. So
all keys have the same strength.
The opposite arrangement is not true. Keying the feedback function
produces a key-dependent period that may be maximal, trivial, or
something intermediate, and there is no initial state that works for all
feedback functions. So some keys would be very weak.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: where to put the trust
Date: Fri, 15 Oct 1999 11:04:15 GMT
In article <7tvqq2$5lr$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Patrick Juola) wrote:
> In article <[EMAIL PROTECTED]>,
> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> >
> >
> >Patrick Juola wrote:
> >
> >> In article <[EMAIL PROTECTED]>,
> >> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> >> >Patrick Juola wrote:
> >> >
> >> >> In article <[EMAIL PROTECTED]>, Terry Ritter
<[EMAIL PROTECTED]> wrote:
> >> >> >And I think you are fooling yourself.
> >> >> >
> >> >> >Cryptography is different from the areas in which we trust
expertise
> >> >> >because in cryptography there is no way for anyone to know
whether any
> >> >> >particular approach is successful.
> >> >> >
> >> >> >Would you really trust a doctor who could not know whether the
> >> >> >patients, having been treated, were alive or dead?
> >> >>
> >> >> That's most of the doctors, actually. Once you leave the
office, very
> >> >> few of them will follow you around to confirm that you stayed
alive.
> >> >>
> >> >> Similarly, very few bridge designers hang around their work
watching
> >> >> it for years lest it should suddenly fall over.
> >> >
> >> >Hardly.
> >> >
> >> >When a person dies an inquest detemines the cause, and if a
doctor's care was
> >> >involved it will be closely scrutinized. When a bridge falls
down a similar
> >> >process, failure analysis, determines the cause, and if the cause
was a design
> >> >flaw the architect (civil engineer) is going to hear about it.
>From the victim's
> >> >laywers if from no one else.
> >>
> >> And, similarly, if your information is compromised, ...
> >
> >That's the critical IF. IF my information is compromised. How do I
tell? I know how
> >to tell if I am dead, and I can take action to prevent it when I
notice that I am
> >ill. I know how to tell if a bridge falls down, and when chunks of
steel and concrete
> >come loose I know how to take action to fix it.
>
> Yes, but you don't know when your bridge is aging, or succeptible to
flood
> damage, or when recent traffic has been exceeding the maximum
recommended
> load.
Measuring or predicting strength is in fact a continuing
issue of interest in the re-certification of public
structures. It is a known problem and is handled in
practice, in California in particular. If certification
is incorrect and the structure fails, we see that on the
news, which cannot be said of cryptography.
> You can only tell there's something wrong when the bridge fails
> catastrophically, at which point it's very difficult to tell what the
> root cause of the bridge failure was. As long as the bridge is still
> standing, you don't have any way of proving that the bridge will, or
> will not, stand up to another truck driving over it.
Nonsense. We know about the strength of materials. We know
the process of failure. We are able to detect this process
in many cases, and most of our failures to detect this are
failures to look, not failures of interpretation.
The original argument was that we trust bridges because of
bridge experts, so why not trust ciphers because of cipher
experts. The response was that there is no cipher expertise
with respect to strength, because such expertise requires
interactive knowledge of the outcome, and our opponents do
not grant that to us. We thus can know quite a lot about
how bridges fail. But we cannot know how our ciphers fail
in the hands of our opponents, and that is all we care about.
> You also won't know about a lot of other possible failure modes for
the
> bridge other than total collapse. Perhaps asphalt wear has made the
> bridge particularly slick, so that anyone who drives across in the
rain
> has a high chance of skidding out of control. Of course, you *could*
> sue the bridge designer every time you skid, but that would get
laughed
> out of court.
Actually, no. If the bridge can be said to cause skids, then
the state may have some liability. It is unlikely, because we
know how to design acceptable roads, because we know the
results. We do not know the outcome in cryptography, which
is why failure is not similarly unlikely.
> >How do I tell if my cipher is "showing signs of age?" The people
who know about the
> >symptoms of failure hae a vested interested in hiding those
symptoms.
>
> Not all of them. "Gee, I wonder if DES is strong nowadays. I guess
I'll
> never know, because there's no publically available information about
> the costs and difficulties of breaking DES."
That is a false summary of the reasoning. We cannot know
whether DES is strong, because we cannot know what capabilities
our opponents possess. Twenty years of DES analysis is not
comforting because it does not tell us how the cipher will
stand up to unknown attacks by the only people of interest.
Some would have us believe that what we do not know is just
the remaining 0.1% of knowledge, and we can never expect to
know it all. But of course there is no calibration for such
a value. Any possible value is beside the point if it
allows our opponents to read our mail in practice. That is
the only issue. And there can be no expertise about it.
>Yes, some people will
want
> to compromise security and keep it secret. Others will want to
compromise
> security and publicize that they can do it, for whatever reason.
The
> nice thing about security is that this gives a means of learning that
> your cypher is weak *before* your system is compromised, because
someone
> can show how an identical bridge will collapse.
I have no idea what this is trying to say. It would be nice
if we had a mathematical proof of strength which could be
applied in practice. But absent that, we must survive in
an environment where every cipher is suspect.
> >Note that it is in the vested interest of the opponents to hide not
only the fact of
> >their break but also the fruits thereof.
>
> However, unless they do *nothing* with the fruits of their break,
then
> they *will* reveal the break to a sufficiently suspicious eye.
This is of course incorrect. One whole arm of military
security has involved complex and costly security operations
deliberately intended to assure the viewer that any security
lapse was *not* due to cipher failure. To the extent that
such failure is not obvious to all security professionals,
it obviously has *not* been revealed.
And this has very little if anything to do with private use.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: where to put the trust
Date: Fri, 15 Oct 1999 11:22:38 GMT
My original (better) response to this apparently was lost.
In article <[EMAIL PROTECTED]>,
John Myre <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >
> > While "trust many experts" may be better than trusting any
> > one "expert," this still does not address the essence of the
> > problem: there can be no expertise on strength which applies
> > to our opponents.
>
> "We don't know the limits of our opponents' ability" seems a
> reasonable statement. "No expertise" seems an exaggeration.
> Real-world events combined with simple reasoning leads to
> rational (if not iron-clad) conclusions.
Military and state cryptography may have such expertise,
although it can never be the sort of expertise we see in
building roads or bridges. But individual users are unlikely
to be able to monitor their exposure nearly as well, or
assign it to cryptography. And if they must use the single
"interoperable" cipher, they would be unable to do much
about such exposure, even if they suspected it.
> For example, the existence of U.S. export restrictions on
> cryptography (and especially the embarrasment forced on public
> officials who must endorse them) makes me believe that the NSA
> cannot, in fact, (economically) break all of the publicly known
> ciphers.
While I certainly agree with the outcome, let me caution
against trying to predict motive from external events.
When we do, we set ourselves up to be deceived.
> Of course, they might be able to break *my* favorite...
>
> >
> > In general, we must assume that our opponents know everything
> > in the open literature, plus whatever has been accumulated by
> > dedicated secret organizations of many bright people over long
> > time.
>
> Agreed.
>
> > Academic review simply provides no logical insight
> > about what true opponents know or can do.
>
> Not warranted. "No logical insight"? This isn't the same
> thing as incomplete knowledge.
>
> > We are thus forced
> > to assume the worst.
>
> Well...
>
> I'm not sure what "the worst" means. Literally, it means we
> must assume that there is no defense, at all. Karnak attacks
> must be assumed to work, etc.
In context, "the worst" is that our cipher is weak. In use,
we do not care what attacks are used.
> > Looking for expertise which cannot exist seems a rather
> > futile exercise, even if we collect as many opinions as we
> > can.
>
> I disagree. People must make decisions on incomplete information
> all of the time. Take the experts' opinions with a grain of salt,
> consider their possible bias or blind spots, but recognize that
> the expert opinion is useful data.
Cryptography is just different from other areas. There can
be experts in cryptography, or cryptanalysis, but there can't
be experts in cryptographic strength, because we have no
feedback from the only interaction of interest -- between
ciphertext and opponent. That is the only thing which must
be assured, and we do not even know in practice whether any
of our ciphers do that.
Under reasonable assumptions, we suspect that many ciphers
are strong, especially when they are not subject to
known-plaintext attack. Under these assumptions, using a
sequence of ciphers can be said to improve the situation.
And changing ciphers frequently means that any existing break
is terminated.
>
> > Reality is not a vote.
>
> Indeed!
>
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
