Cryptography-Digest Digest #397, Volume #9 Thu, 15 Apr 99 16:13:03 EDT
Contents:
Re: True Randomness & The Law Of Large Numbers ("Tony T. Warnock")
SMARTCARD SECURITY NEWS ISSUE #6 ([EMAIL PROTECTED])
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: Radiation/Random Number question (Medical Electronics Lab)
Re: Adequacy of FIPS-140 (R. Knauer)
Re: Large Key Length XOR and Scramble Question (Frank Gifford)
Re: Adequacy of FIPS-140 (R. Knauer)
Re: True Randomness & The Law Of Large Numbers (R. Knauer)
Re: discreate logarithm problem ("Trevor Jackson, III")
Re: Adequacy of FIPS-140 ("Trevor Jackson, III")
Re: Adequacy of FIPS-140 ("Trevor Jackson, III")
Re: SNAKE#10 (Peter Gunn)
Re: Adequacy of FIPS-140 (R. Knauer)
Re: SNAKE#10 (Thomas Wu)
----------------------------------------------------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Thu, 15 Apr 1999 10:57:18 -0600
Reply-To: [EMAIL PROTECTED]
Jim Felling wrote:
>
> No, but if a coin that I do not know anything about is given 10 'random' tosses and
> comes up heads 10 times I'd bet on it coming up heads on the 11th time too.(It
>probably
> isn't a 100% fair coin)
>
I think that the "stick with a winner" strategy does well with an unknown coin.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.security,comp.security.misc,alt.cellular-phone-tech
Subject: SMARTCARD SECURITY NEWS ISSUE #6
Date: Thu, 15 Apr 1999 17:37:30 GMT
Smartcard security technical info page is updated at URL:
http://www.geocities.com/ResearchTriangle/Lab/1578/smart.htm
This page contains technical information and links about
smartcards and especially smartcard security (including satellite
cards, GSM SIM cards, phonecards, banking cards,
secure microcontrollers, smartcard standards,
and smartcard protocols). Big attention is held on smartcard attacks.
There is no commercial and marketing blah blah.
The Smartcard Security News Issue #6 is also launched.
Hadlines:
- Next part of ISO 7816-4 on line
- New telecards information
- Featured article: An article about smartcard attacks by Pieter Grobler
- An overview article Introduction To Smart Cards by David Everett
- An Overview of Smart Card Security by CHAN, Siu-cheung Charles
- nad much more...
Bo Lavare [EMAIL PROTECTED]
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Thu, 15 Apr 1999 17:31:07 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 15 Apr 1999 15:56:18 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>I have to go by the available evidence, namely what you yourself
>say on the matter.
Yeah, but that assumes you are capable of knowing what I am up to.
Most people know me as a Devil's Advocate, someone whose purpose is to
stimulate discussion/debate. You, on the other hand, have consistently
misinterpreted me for your own purposes. That doesn't speak well for
your ability to gauge my understanding of these matters.
>I didn't expect you to understand my explanation, but my hope is
>that other readers appreciated it.
You can hope all you want, but that is still not going to change the
fact that you babbled incoherently. Do you take the time to re-read
and correct you own posts? Or do you just regurgitate the nonsense
that was fed to you in school and push the send button, hoping that
you have laced in enough bluster and pontification to cover up for the
deficiencies?
You should know better than to try to defend silly tests like the
FIPS-140 Monobit Test. It is so amateurish that I cannot believe
anyone who claims to understand the concept of true randomness would
imagine for even a moment that such a simplistic test could decisively
characterize something that fundamental.
You should realize that true randomness goes to the very heart of
quantum mechanics, and serves as one of the most profound mysteries of
science. To claim to be able to determine when it is not present in a
process by something as superficial as counting 1-bit bias is beyond
comprehension.
Bob Knauer
"I read a funny story about how the Republicans freed the slaves. The
Republicans are the ones who created slavery by law in the 1600's.
Abraham Lincoln freed the slaves and he was not a Republican."
- Marion Barry, Mayor of Washington DC
------------------------------
From: Medical Electronics Lab <[EMAIL PROTECTED]>
Subject: Re: Radiation/Random Number question
Date: Thu, 15 Apr 1999 12:39:47 -0500
R H Braddam wrote:
> Does anyone here know of any efforts to make *more* sensitive ICs for the
> purpose of detecting radiation?
It's not really necessary. Most people need to detect high energy
particles and the IC's to do that work pretty well.
> Can anyone here tell me if the Americium 241 (1 microcurie) source used in
> smoke detectors would cause soft (or hard) errors in chips if placed in
> contact with RAM or ROM chips?
Am241 has a 5 MeV alpha for a decay product. Range is about 5 cm in
air, about 200 microns in plastic. Won't cause any problems at all :-)
> What if the chips were obtained as dice, or as dice bonded to the bottom
> half of the package and pin connections made... would the passivation layer
> block alpha radiation?
Most of it. but it's about the most expensive way possible I can
think of!
> If radiation causes picking or dropping of bits in RAM or ROM chips and
> doesn't cause catastrophic failure of the chip, wouldn't this be a useable
> bit source for desktop computers for generating random numbers?
>
> I'm not asking for a schematic diagram, just discussion of the feasibility.
Not very feasible. A much simpler way is to amplify the signal
off a smoke detector and use that for a random noise source. I'm
submitting a paper to the CHES workshop on this, if you'd like a
schematic as well as a paper I can send you what we've got. It
will be submitted for refereeing next week ('cause that's the
deadline!) but I don't know if it will be accepted. It passes
DIEHARD and Diaphony at reasonable data rates (about 2kBytes/sec)
so the basic idea appears to be sound. It will never be useful
commercially tho, it's just too much fun :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Adequacy of FIPS-140
Date: Thu, 15 Apr 1999 18:50:19 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 15 Apr 1999 09:58:15 -0500, Jim Felling
<[EMAIL PROTECTED]> wrote:
>Your QC may well produce random results.
There is no maybe about it. The algorithm for computing true random
numbers has been written, so all that remains is to build a quantum
computer to run it on.
>But what about: the methods used to
>read its state -- they can change it and/or lead to correlation.
What state? The internal state is the quantum superposition that
occurs in nature. The result is what is obtained from the operation of
the quantum computer. How results are obtained depends on the design.
For example, a Feynman QC has so-called "cursor" qubits which indicate
the successful conclusion of the calculation. Other designs do that in
other ways.
>What about outside phenomena such as Magnetic fields, or EM radiation both can mess
>with quantum state transitions. What about other such phenomena? You cannot
>consider the QC all alone. The system has potential points of failure and
>therefore is NOT provably random.
The very important subjects of decoherence and error correction are
discussed at length in Williams & Clearwater (op. cit.) and methods to
overcome them are proposed. Whatever the actual methods are, they will
be part of the design. IOW, you cannot have a half functional quantum
computer - it is either fully functional or it is not a quantum
computer, because decoherence and errors destroy the quantum state.
I am assuming that such a device will be built (if it hasn't already
been built) and that it will function as advertised. Once that
happens, you will be able to compute true random numbers with complete
certainty. But don't forget that quantum cryptography already exists
and has been tested over a 30 kilometer distance. Quantum crypto is a
transmission technique in which eavesdropping is instantly detectable,
because the measurement act of the eavesdropper affects the cipher, as
is expected for any quantum measurement.
Bob Knauer
"I read a funny story about how the Republicans freed the slaves. The
Republicans are the ones who created slavery by law in the 1600's.
Abraham Lincoln freed the slaves and he was not a Republican."
- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED] (Frank Gifford)
Subject: Re: Large Key Length XOR and Scramble Question
Date: 15 Apr 1999 14:00:26 -0400
In article <7f34e9$338$[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]> wrote:
>Hello again...
>
>What about the following scenario:
>
>- 1 GByte of raw data to be encrypted
>- 4Kbit XOR key
>- 4Kbit * 4 = 16Kbit Scramble key
>- All 20Kbits of key are randomly generated
>- Random scrambling of every 16-bit word of raw data after XOR
>
>4Kbits of raw data are XORed with the 4Kbit XOR key to produce a block of
>4Kbit XORed data. All 256 16-bit blocks of the 4Kbit XORed data are
>scrambled according to the 16Kbit Scramble key. This process is repeated
>until the entire 1 GByte of data is encrypted.
>
>The question is: Is this at all secure? Would someone be able to break this
>as easily as a simple XOR? How does it compare to 56-bit or 112-bit DES?
Since the attacker knows the method used for encryption, this should be
breakable with a chosen plaintext attack. Basically, the attacker creates a
string of zero bits in the first 'block', which will pull out the XOR key.
Then each following block has a single bit set and the attacker can see how
the bits get shuffled around.
Short anwer: Easy to break.
-Giff
--
[EMAIL PROTECTED] Too busy for a .sig
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Adequacy of FIPS-140
Date: Thu, 15 Apr 1999 18:55:32 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 15 Apr 1999 15:51:31 GMT, "Douglas A. Gwyn" <[EMAIL PROTECTED]>
wrote:
>The point about OTP key handling is well taken; in the real world,
>it is such a practical problem that inevitably it provides breaks
>into the system.
It is rumored that the Washington to Moscow hotline is secured with an
OTP cryptosystem. I suppose it is important not to let anyone have
even the slightest chance to make a false communication on that
channel, and to make absolutely sure they used the only proveably
secure classical cryptosystem there is - the OTP.
If you must have proveable security, then you have to pay the price to
implement it. All you are saying in your statement above is that there
are instances in which people are unwilling to pay that price. That is
not a proper indictment of the OTP system, only an anecdotal reference
to the stupidity of some people.
Bob Knauer
"I read a funny story about how the Republicans freed the slaves. The
Republicans are the ones who created slavery by law in the 1600's.
Abraham Lincoln freed the slaves and he was not a Republican."
- Marion Barry, Mayor of Washington DC
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: True Randomness & The Law Of Large Numbers
Date: Thu, 15 Apr 1999 19:26:34 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 15 Apr 1999 21:00:17 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>It is not to 'believe' or 'not believe', but to 'recognize' or else
>with sound arguments to 'refute' the theories that the statistitians
>have developed through centuries. I know only very little about
>statistics but, as far as I am aware, the issue of sample size is
>well taken into consideration by them. I am of the opinion that
>only statistitians have the knowledge and hence are in a proper
>position to judge whether the application of statistical tests are
>correct or not. For a non-expert in the field, like you and me,
Please speak for yourself. You don't have a clue whether I am an
expert or not in reality. Since you claim that you are not an expert,
you do not have the capability to judge me in that regard.
As Devil's Advocate I hide behind a facade of amateurishness, but I
could just as well be quite knowledgeable of the subject matter at
hand and not be letting on.
>it
>is entirely nonsensical to merely 'speculate' and do 'believing' or
>'not believing' (worse dogmatically 'claiming') this or that. For
>statistics is a serious natural science discipline, not a religion!!
You still don't get it, do you.
You still don't grasp the fact that I am challenging simplistic small
sample statistical tests in only one instance - the determination of
non-randomness.
I am not addressing the broader issue of applicability of such tests
to other areas.
Bob Knauer
"I read a funny story about how the Republicans freed the slaves. The
Republicans are the ones who created slavery by law in the 1600's.
Abraham Lincoln freed the slaves and he was not a Republican."
- Marion Barry, Mayor of Washington DC
------------------------------
Date: Fri, 16 Apr 1999 04:32:28 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: discreate logarithm problem
David A Molnar wrote:
>
> Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
> > *SIX* copies of this? Nasty stutter.
>
> he's discussing DL algorithms. as noted, they take a substantial amount
> of space to compute. even on a quantum computer, oddly enough. except
> there substantial = 3 registers. :-)
Right!
Hmmm, those registers are single particles, right? So they're one bit
wide!
------------------------------
Date: Fri, 16 Apr 1999 04:41:38 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Adequacy of FIPS-140
Who are you and what have you done with R. Knauer? He's the guy arguing
for PROVABLE security, remember?
R. Knauer wrote:
>
> On 15 Apr 1999 12:50:57 -0400, [EMAIL PROTECTED] (Patrick Juola)
> wrote:
>
> >If need be, he can employ an exhaustive search technique. There are,
> >after all, probably fewer than a trillion documents on the Web; this,
> >in turn, is about 2^40 documents, which is too small a keyspace (40 bits)
> >for people to feel comfortable with.
>
> Again, you make it sound so easy when in reality it is far from easy.
>
> For one thing, you are assuming that the text is from a single source
> and is indexed from the beginning. If instead multiple sources are
> used with different offsets from the beginning of each document, and
> the text streams are mixed together, the number of combinations
> increases substantially.
>
> For another thing, you left out the fact that you have to download all
> that information and store it somewhere. How long would it take to
> download a trillion documents? To begin with you have to establish
> contact with each server for each document. If it takes 1 second to
> make such a connection for each document, that is a trillion seconds
> which is about 30,000 years. And that is just to establish the link
> with each document, not to download all the documents and archive
> them.
>
> Let's say for the sake of discussion that the keystream is made up of
> 10 different documents each with a different offset from the
> beginning, hashed and strongly mixed. Now you have to form the
> cartesian product of all possible documents with all possible offsets
> in combinations of 10 at a time.
>
> I consider exhaustive search to be feasibly impossible, even under the
> most trivial assumptions.
>
> >Of course. And chance are he wouldn't be able to use AltaVista; instead
> >he would want to write his own custom SpiderBot that would index
> >documents by some cryptographic property instead of by keyword.
>
> What cryptographic quality? The assumption here is that the text is
> hashed and strongly mixed so that no significant amount of information
> leaks. That is not a poor assumption either since we know that there
> is some amount of randomness in text streams - randomness that
> presumably can be distilled using hashes.
>
> >Not a difficult task;
>
> I think it is a very daunting task indeed.
>
> >I'd feel comfortable assigning one of my undergraduates
> >to index the Web according to a particular hash scheme.
>
> First have him do the kind of calculation I did above, which addresses
> the feasibility of such a program as you suggest even making the most
> relaxed of assumptions as I did above.
>
> Bob Knauer
>
> "I read a funny story about how the Republicans freed the slaves. The
> Republicans are the ones who created slavery by law in the 1600's.
> Abraham Lincoln freed the slaves and he was not a Republican."
> - Marion Barry, Mayor of Washington DC
------------------------------
Date: Fri, 16 Apr 1999 04:39:51 -0400
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Adequacy of FIPS-140
R. Knauer wrote:
>
> On 15 Apr 1999 08:53:07 -0400, [EMAIL PROTECTED] (Patrick Juola)
> wrote:
>
> >If you're pulling the text off the web, *and the cryptanalyst knows it*,
> >then it's not secret as he has the same access to the Web that you do.
>
> OK, to keep this subthread going, I will reply by asking how he would
> find the source - by exhaustive search? If so, how many resources must
> be employed to accomplish the task of discovering the "secret"?
>
> >Even if the cryptanalyst doesn't know it, he's likely to guess that
> >the most likely source of a large block of text is *somewhere* on the
> >Web. So he fires up AltaVista....
>
> You make it sound too easy.
>
> What keywords would you use? Hell, you are lucky to find what you want
> using AltaVista with ordinary keywords. For instance, see how much of
> a hassle it is to find out the manufacturer of an automotive chemical
> product called "casite". Anybody who has putzed around with cars knows
> about Casite. Use that as the keyword in AltaVista and you will get
> all sorts of nonsense before you finally discover Hastings is the
> manufacturer.
>
> The web is so vast and so diverse, you would be better off looking for
> a needle in a haystack. If the resources you must commit to this
> search is excessive, it would be essentially impossible - like trying
> to do a brute force attack on a 128-bit IDEA cipher.
A truly excellent rationale for obscurity. But it fails elementary
arithmetic. The largest collection of text in existence consists of
some 2^44 characters or ~2^51 bits. The web is no where near that
large. And even if it were, 2^51 and 2^128 are never going to meet in
this lifetime (universe lifetime).
>
> Here, for example, is a text-key-based stream cipher (totally made up
> for purposes of illustration):
>
> fo@kh*ga%rg!qe^pr^tgj$gas@hafj
>
> Please tell us how, in principle, you would mount an attack on that
> cipher using the web.
>
> Bob Knauer
>
> "I read a funny story about how the Republicans freed the slaves. The
> Republicans are the ones who created slavery by law in the 1600's.
> Abraham Lincoln freed the slaves and he was not a Republican."
> - Marion Barry, Mayor of Washington DC
------------------------------
From: Peter Gunn <[EMAIL PROTECTED]>
Subject: Re: SNAKE#10
Date: Thu, 15 Apr 1999 16:19:02 +0100
Peter Gunn wrote:
> I think Ive figured out what was wrong with SNAKE#9
> where A sends g^A, B sends g^B, and they use g^ABP
> as the key... MITM would know g^AB and be able to
> crack key for P by offline guessing since he has
> s1 and E[g^ABP](s1).
>
> Hmmm... this is hard.
>
> Ok, back to basics...
>
> * standard DH, key=g^AB is secure apart from the "man
> in the middle attack" (MITM)
> * MITM can be avoided by proving possesion of short
> password P, and session key g^AB.
> * Cant mangle g^A and g^B with P due to legal
> restrictions.
>
> I wish I knew more about the legalities of these things,
> but it seems to me that the EKE patent couldnt possibly
> cover all instances where a public key get encrypted
> by some shared secret, and must apply simply to the
> use in creating a strong session key. Is this right??
>
> If it is, can I not use a random value symmetrically
> encrypted with P simply to prove I know P, and that
> therefore there is no MITM, so that it is safe to
> use a standard Diffie-Hellman???
>
> Something like this... (SNAKE#10 :-)
>
> A,S,T are random numbers ownded by the client
> B,R,V are randoim numbers ownded by the server
> U is the user identifier or equivalent
> P=H(password), password is a short text string
> g is an agreed generator
> p is a large safe prime
> E[x](y) means y encrypted using x as a key
> H() is a one way hash function (SHA or similar)
>
> Im dropping the %p notation...
>
> 1) A->B: g^A, U
> 2) B->A: g^B
>
> both work out session key K=H(g^AB) which is used
> to encrypt all traffic from now on.
>
> Now they need to prove to each other that they
> both know the session key, and P, which they can do
> using something which looks awfully like EKE,
> but is only being used to verify possesion of
> the session key and P, and nothing to do with the
> session key calculation itself.
>
> 3) A->B: E[P](g^S), T
> 4) B->A: E[P](g^R), V
> 5) A->B: E[g^ABRS](V)
> 6) B->A: E[g^ABRS](T)
>
> A and B check that the values returned match
> their own calculations as soon as they get them,
> breaking the connection if they dont match.
>
> Hmmm... how else can I prove posession of P,
> and K=g^AB ??
>
> how about ...
People with maths degrees will probably laugh at what
I'm about to suggest, but surely I cant be the
only one who doesnt understand the basics of the
Diffie-Hellman or Diescrete Logarithm Problems :-)
What about if I create a function called m...
where m(K,P)=(H(K,P)*2)+1+2^(Z+1) where Z
is the width in bits of the hash output.
This should always result in a large odd number
which is Z+2 bits 'long'.
So, after exchanging DH public values and calculating a
session key K as before, I can verify possession of
P and K by doing something like (not using p anymore)...
3) A->B: (g^S)%m(P,K), T
4) B->A: (g^R)%m(P,K), V
5) A->B: E[(g^ABRS)%m(P,K)](V)
6) B->A: E[(g^ABRS)%m(P,K)](T)
Question is how much easier is it to crack this when using
a large odd modulus rather than a large safe prime??
Any help is appreciated :-)
ttfn
PG.
------------------------------
From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Adequacy of FIPS-140
Date: Thu, 15 Apr 1999 18:04:38 GMT
Reply-To: [EMAIL PROTECTED]
On 15 Apr 1999 12:50:57 -0400, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>If need be, he can employ an exhaustive search technique. There are,
>after all, probably fewer than a trillion documents on the Web; this,
>in turn, is about 2^40 documents, which is too small a keyspace (40 bits)
>for people to feel comfortable with.
Again, you make it sound so easy when in reality it is far from easy.
For one thing, you are assuming that the text is from a single source
and is indexed from the beginning. If instead multiple sources are
used with different offsets from the beginning of each document, and
the text streams are mixed together, the number of combinations
increases substantially.
For another thing, you left out the fact that you have to download all
that information and store it somewhere. How long would it take to
download a trillion documents? To begin with you have to establish
contact with each server for each document. If it takes 1 second to
make such a connection for each document, that is a trillion seconds
which is about 30,000 years. And that is just to establish the link
with each document, not to download all the documents and archive
them.
Let's say for the sake of discussion that the keystream is made up of
10 different documents each with a different offset from the
beginning, hashed and strongly mixed. Now you have to form the
cartesian product of all possible documents with all possible offsets
in combinations of 10 at a time.
I consider exhaustive search to be feasibly impossible, even under the
most trivial assumptions.
>Of course. And chance are he wouldn't be able to use AltaVista; instead
>he would want to write his own custom SpiderBot that would index
>documents by some cryptographic property instead of by keyword.
What cryptographic quality? The assumption here is that the text is
hashed and strongly mixed so that no significant amount of information
leaks. That is not a poor assumption either since we know that there
is some amount of randomness in text streams - randomness that
presumably can be distilled using hashes.
>Not a difficult task;
I think it is a very daunting task indeed.
>I'd feel comfortable assigning one of my undergraduates
>to index the Web according to a particular hash scheme.
First have him do the kind of calculation I did above, which addresses
the feasibility of such a program as you suggest even making the most
relaxed of assumptions as I did above.
Bob Knauer
"I read a funny story about how the Republicans freed the slaves. The
Republicans are the ones who created slavery by law in the 1600's.
Abraham Lincoln freed the slaves and he was not a Republican."
- Marion Barry, Mayor of Washington DC
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: SNAKE#10
Date: 15 Apr 1999 12:00:04 -0700
Peter Gunn <[EMAIL PROTECTED]> writes:
>
> Ok, back to basics...
>
> * standard DH, key=g^AB is secure apart from the "man
> in the middle attack" (MITM)
> * MITM can be avoided by proving possesion of short
> password P, and session key g^AB.
> * Cant mangle g^A and g^B with P due to legal
> restrictions.
>
> I wish I knew more about the legalities of these things,
> but it seems to me that the EKE patent couldnt possibly
> cover all instances where a public key get encrypted
> by some shared secret, and must apply simply to the
> use in creating a strong session key. Is this right??
It applies when you derive authentication directly from the
mangled key exchange itself, like some past versions of your
SNAKE. You need to come up with a different "family" of
protocols, which may require a bit of out-of-the-box thinking.
EKE - Encrypt the ephemeral public keys
SPEKE - Base is a function of the password
SRP - Balance addition on one side with multiplication on the other
> If it is, can I not use a random value symmetrically
> encrypted with P simply to prove I know P, and that
> therefore there is no MITM, so that it is safe to
> use a standard Diffie-Hellman???
I can't help noticing that the latest SNAKE's require upwards
of six modular exponentiations - performance is an important
factor in protocol design, especially when expensive PK operations
are involved.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
** 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
******************************
