Cryptography-Digest Digest #233, Volume #13 Tue, 28 Nov 00 05:13:00 EST
Contents:
Pari port for Win32 ("Dann Corbit")
Re: collision probability with file checksums (David Wagner)
Re: New symmetric-key distribution ("Scott Fluhrer")
Re: collision probability with file checksums (David Schwartz)
Re: collision probability with file checksums (Ed L Cashin)
Re: collision probability with file checksums (David Schwartz)
Re: collision probability with file checksums (Ed L Cashin)
Re: collision probability with file checksums (Ed L Cashin)
Playstation 2 In stock ("adsl5")
projective coordinates in ECC: worth it? (Paul Rubin)
Twofish codesize Q ("kihdip")
Re: P/w based authentication and key exchange (Per Claesson)
Re: Twofish codesize Q (Per Claesson)
Re: P/w based authentication and key exchange (David Schwartz)
Re: P/w based authentication and key exchange (Per Claesson)
Re: A Simple Voting Procedure (Niklas Frykholm)
Re: P/w based authentication and key exchange (Thomas Wu)
Re: A Simple Voting Procedure (David Schwartz)
Re: A Simple Voting Procedure (David Schwartz)
Re: projective coordinates in ECC: worth it? ("Michael Scott")
Re: P/w based authentication and key exchange (Per Claesson)
----------------------------------------------------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Pari port for Win32
Date: Mon, 27 Nov 2000 21:15:00 -0800
To play with...
ftp://cap.connx.com/pub/pari.exe
Q:\>pari
GP/PARI CALCULATOR Version 2.1.0 (released)
ix86 running Windows 3.2 (ix86 kernel) 32-bit version
(readline disabled, extended help not available)
Copyright (C) 2000 The PARI Group
PARI/GP is free software, covered by the GNU General Public License, and
comes WITHOUT ANY WARRANTY WHATSOEVER.
Type ? for help, \q to quit.
Type ?12 for how to get moral (and possibly technical) support.
realprecision = 28 significant digits
seriesprecision = 16 significant terms
format = g0.28
parisize = 4000000, primelimit = 500000
? factor(99999999999999999999999999999991)
%1 =
[7 1]
[13 1]
[433 1]
[39323 1]
[45177491 1]
[1428571428571429 1]
? factor(999999999999999999999999999999917719234)
*** user interrupt.
This one took so long that I interrupted it. I am surprised that MIRACL blows
its doors off.
No guarantees about quality.
Also a factor program using MIRACL:
ftp://cap.connx.com/pub/factor.exe
Q:\>factor 99999999999999999999999999999991
first trying brute force division by small primes
PRIME FACTOR 7
PRIME FACTOR 13
PRIME FACTOR 433
now trying 1000 iterations of brent's method
PRIME FACTOR 39323
PRIME FACTOR 45177491
PRIME FACTOR 1428571428571429
Q:\>factor 999999999999999999999999999999917719234
first trying brute force division by small primes
PRIME FACTOR 2
PRIME FACTOR 19
PRIME FACTOR 83
now trying 1000 iterations of brent's method
now trying william's (p+1) method
phase 1 - trying all primes less than 10000
phase 2 - trying last prime less than 1000000
now trying pollard's (p-1) method
phase 1 - trying all primes less than 100000
phase 2 - trying last prime less than 5000000
now trying lenstra's method using 10 curves
curve 1 phase 1 - trying all primes less than 20000
phase 2 - trying last prime less than 2000000
curve 2 phase 1 - trying all primes less than 20000
phase 2 - trying last prime less than 2000000
curve 3 phase 1 - trying all primes less than 20000
phase 2 - trying last prime less than 2000000
curve 4 phase 1 - trying all primes less than 20000
phase 2 - trying last prime less than 2000000
curve 5 phase 1 - trying all primes less than 20000
phase 2 - trying last prime less than 2000000
curve 6 phase 1 - trying all primes less than 20000
phase 2 - trying last prime less than 2000000
curve 7 phase 1 - trying all primes less than 20000
PRIME FACTOR 461807251568877587
PRIME FACTOR 686558522901260483
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: collision probability with file checksums
Date: 28 Nov 2000 05:34:14 GMT
Reply-To: [EMAIL PROTECTED] (David Wagner)
David Schwartz wrote:
>[...] the fact that SH1 is about 2^32 times harder than
>MD5 to find colisions for (it is at least that) [...]
This is not a fact; rather, if we assume that the best collision-finding
attack is blind collision search (as you seemed to be assuming), then SHA1
is about 2^16 times more secure than MD5 (2^80 work to find a collision for
SHA1 compared to 2^64 work for MD5).
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: New symmetric-key distribution
Date: Mon, 27 Nov 2000 21:37:53 -0800
<[EMAIL PROTECTED]> wrote in message news:8vvar5$u4m$[EMAIL PROTECTED]...
> I was curious are there any new symmetric-key distribution techniques
> being used today? No, asymmetric techniques...just symmetric techniques.
>
> I know of:
> 1) Trusted 3rd party
> 2) Key-splitting for delivery
> 3) Physical delivery
> 4) Kerberos
Errr, Kerberos is "a trusted 3rd party".
>
> If you have any others, please fill me in.
How about:
5) Joint computation on public/private data to form the symmetric key (e.g.
Diffie-Hellman)
6) Transport of symmetric key by public key encryption (e.g. as in PGP)
--
poncho
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: Mon, 27 Nov 2000 21:43:23 -0800
David Wagner wrote:
> This is not a fact; rather, if we assume that the best collision-finding
> attack is blind collision search (as you seemed to be assuming), then SHA1
> is about 2^16 times more secure than MD5 (2^80 work to find a collision for
> SHA1 compared to 2^64 work for MD5).
Actually, even if it's not blind blind collision search, it's still
likely that the difficulty will fall in proportion. The 2^80 assumes
that you can store every previous trial's outcome, which I'm not sure is
a reasonable assumption. But you can work the numbers any way you want,
so you can come up with your own numbers if you want. Would you care to
guess a year? ;)
DS
------------------------------
From: Ed L Cashin <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: 28 Nov 2000 00:59:05 -0500
[EMAIL PROTECTED] (David Wagner) writes:
> David Schwartz wrote:
> >[...] the fact that SH1 is about 2^32 times harder than
> >MD5 to find colisions for (it is at least that) [...]
>
> This is not a fact; rather, if we assume that the best collision-finding
> attack is blind collision search (as you seemed to be assuming), then SHA1
> is about 2^16 times more secure than MD5 (2^80 work to find a collision for
> SHA1 compared to 2^64 work for MD5).
Talking now about blind collision searches, as you say ...
Why do you say that it's 2^(n/2) work for an n-bit checksum? Do you
mean that an attacker needs to do 2^(n/2) tests?
--
--Ed Cashin PGP public key:
[EMAIL PROTECTED] http://www.coe.uga.edu/~ecashin/pgp/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: Mon, 27 Nov 2000 22:08:03 -0800
Ed L Cashin wrote:
> Why do you say that it's 2^(n/2) work for an n-bit checksum? Do you
> mean that an attacker needs to do 2^(n/2) tests?
Basically, what it comes down to is how many random numbers between one
and 2^N do you have to pick before you have a 50% chance of getting two
that match.
DS
------------------------------
From: Ed L Cashin <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: 28 Nov 2000 01:12:44 -0500
Ed L Cashin <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (David Wagner) writes:
>
> > David Schwartz wrote:
> > >[...] the fact that SH1 is about 2^32 times harder than
> > >MD5 to find colisions for (it is at least that) [...]
> >
> > This is not a fact; rather, if we assume that the best collision-finding
> > attack is blind collision search (as you seemed to be assuming), then SHA1
> > is about 2^16 times more secure than MD5 (2^80 work to find a collision for
> > SHA1 compared to 2^64 work for MD5).
>
> Talking now about blind collision searches, as you say ...
>
> Why do you say that it's 2^(n/2) work for an n-bit checksum? Do you
> mean that an attacker needs to do 2^(n/2) tests?
If by "blind collision searches" you mean a birthday attack, then I
understand why you say it takes 2^(n/2) tests, since it's easier when
you can choose both the input and the output of the hash function.
But we've been talking about a manipulation detection code on file
contents. In that case, the attacker must try to match a hash output
that is already there, which is harder, requiring 2^n tests. So David
would be right.
Please correct me if I'm wrong. I'm just going on fact 9.33 on p.336
of the Handbook of Applied Cryptography.
--
--Ed Cashin PGP public key:
[EMAIL PROTECTED] http://www.coe.uga.edu/~ecashin/pgp/
------------------------------
From: Ed L Cashin <[EMAIL PROTECTED]>
Subject: Re: collision probability with file checksums
Date: 28 Nov 2000 01:15:20 -0500
David Schwartz <[EMAIL PROTECTED]> writes:
> Ed L Cashin wrote:
>
> > Why do you say that it's 2^(n/2) work for an n-bit checksum? Do you
> > mean that an attacker needs to do 2^(n/2) tests?
>
> Basically, what it comes down to is how many random numbers between one
> and 2^N do you have to pick before you have a 50% chance of getting two
> that match.
But 2^(n-1) is half of 2^n. Not 2^(n/2). So if 2^n tests are needed
to be sure, then you're halfway there at 2^(n-1) tries.
--
--Ed Cashin PGP public key:
[EMAIL PROTECTED] http://www.coe.uga.edu/~ecashin/pgp/
------------------------------
From: "adsl5" <[EMAIL PROTECTED]>
Subject: Playstation 2 In stock
Date: Tue, 28 Nov 2000 06:53:32 GMT
--
WWW.ADSL5.COM
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: projective coordinates in ECC: worth it?
Date: 27 Nov 2000 22:54:20 -0800
Doing ECC over GF(p): is there a significant practical speedup by
representing all the points in projective coordinates, and normalizing
at the end? That adds a bunch of scalar multiplication mod p at each
step but puts off a GCD calculation til the very end. But it makes
the formulas look even messier than before. Anyone have any practical
advice, other than "implement it both ways and take benchmarks"?
I'll be using a pretty slow bignum library, if that matters.
Thanks.
================================================================
Btw, here's my pseudocode, I'd appreciate hearing of any obvious
mistakes. I'm new at this. Do I totally misunderstand what
projective coordinates are supposed to mean? I'm just using the raw
formulas from the Certicom web page and normalizing them to projective
coordinates.
# P = (p1, p2, p3)
# Q = (q1, q2, q3)
# start with p3=q3=1.
# To compute P+Q:
# if P != Q:
# ta = q2 - p2;
# tb = q1 - p1;
# else:
# ta = 3*p1*p1 + a; # a is the curve parameter, y**2 = x**3 + a*x + b
# tb = 2*p2;
# P+Q = R = (r1,r2,r3) where
# r1 = ta*ta - td**2*(p1 + q1)
# r2 = ta*td*(p1+r1) - p2*td**2
# r3 = td**2
# all calculations are mod p
# then at the end: normalize r with Euclidean GCD algor so r3==1.
================================================================
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: Twofish codesize Q
Date: Tue, 28 Nov 2000 09:16:46 +0100
I'm using the optimized C code from Counterpane (formerly also placed at the
AES website).
When I compile and link the code I get the following picture using FULL_KEY,
PART_KEY and ZERO_KEY switches:
ZERO_KEY: smallest code size
PART_KEY: Largest code size
FULL_KEY: Medium code size
The data size of the three codes are the same sizes.
I have tried this both with a Pentium/PC (MS visual C++ 6) and a
PowerPC/iMac (CodeWarrior 5), and I get the same picture.
Shouldn't FULL_KEY give the largest code size ?? - Have I missed something
??
Thanks in advance
Kim
------------------------------
From: Per Claesson <[EMAIL PROTECTED]>
Subject: Re: P/w based authentication and key exchange
Date: Tue, 28 Nov 2000 09:33:08 +0100
Thomas Wu wrote:
> Per Claesson <[EMAIL PROTECTED]> writes:
> If the client/server can store cryptographically strong keys, you ought
> to be able to do an ordinary authenticated key exchange using the long-
> term secrets.
Let me see if I got this part about right. :)
If I use cryptographically weak keys - for example keys intended for
human use - I need to take special measures to prevent ie the hash of
the key from leaking, as that would make a brute-force attack feasible,
while if I use cryptographically strong keys, I don't have to be as
picky, since a brute-force attack is not feasible anyway?
If I recall right and understood things properly, PAK and others prevent
brute-force attacks by never actually sending data in the open that can
be used to verify the key? (Or, at least, brute-force using the data
sent in the open would take as much work as if the key was actually
cryptographically strong?)
Out of curiousity, what would you guys consider a cryptographically
strong key in this case? Ie, how many random bits would be needed
(provided they are generated by a decent and properly used (P)RNG)?
Regards,
volley
------------------------------
From: Per Claesson <[EMAIL PROTECTED]>
Subject: Re: Twofish codesize Q
Date: Tue, 28 Nov 2000 09:37:26 +0100
kihdip wrote:
> When I compile and link the code I get the following picture using FULL_KEY,
> PART_KEY and ZERO_KEY switches:
<...>
> Shouldn't FULL_KEY give the largest code size ?? - Have I missed something
Sounds reasonable, but you never know... Did you try searching for
conditional compiles? Ie, look for pairs of this type:
#ifdef PART_KEY
...
#endif
The code in between the #ifdef/#endif pair will only be included if the
switch (def) in question has been set. Such pairs could explain the
anomaly...
//
P
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: P/w based authentication and key exchange
Date: Tue, 28 Nov 2000 00:37:25 -0800
Per Claesson wrote:
> If I recall right and understood things properly, PAK and others prevent
> brute-force attacks by never actually sending data in the open that can
> be used to verify the key? (Or, at least, brute-force using the data
> sent in the open would take as much work as if the key was actually
> cryptographically strong?)
These sophisticated authentication protocols prevent an attacker from
brute-forcing the key. That is, an attacker couldn't even tell whether
or not he knew the key just from watching (or MITMing) the
authentication process.
> Out of curiousity, what would you guys consider a cryptographically
> strong key in this case? Ie, how many random bits would be needed
> (provided they are generated by a decent and properly used (P)RNG)?
It depends upon who you need to be secure from. The question is really
the same as how many bits long a symmetric cipher key should be. So
56-bits if you want to prevent your little sister from breaking it.
64-bits if your little sister is an engineer with access to real
hardware. 128-bits to be safe for a dozen years or so. 168-bits if
you're paranoid.
DS
------------------------------
From: Per Claesson <[EMAIL PROTECTED]>
Subject: Re: P/w based authentication and key exchange
Date: Tue, 28 Nov 2000 09:53:21 +0100
David Schwartz wrote:
>
> Per Claesson wrote:
> These sophisticated authentication protocols prevent an attacker from
> brute-forcing the key. That is, an attacker couldn't even tell whether
> or not he knew the key just from watching (or MITMing) the
> authentication process.
Aha! Almost feels too good to be true...
How come such protocols aren't used more widely? I know they are pretty
new, and that things change slowly, but are there any drawbacks, such as
CPU or memory resource requirements?
*heading for the specs again*
> > Out of curiousity, what would you guys consider a cryptographically
>[little sister 56 to paranoid 168]
Ok! About the same picture I got at Uni a bunch of years ago... :)
BTW, thank you all for the feedback; _very_ appreciated!
//
P, reading the PAK spec. (again)
------------------------------
From: [EMAIL PROTECTED] (Niklas Frykholm)
Subject: Re: A Simple Voting Procedure
Date: 28 Nov 2000 08:57:51 GMT
On Fri, 24 Nov 2000 18:34:46 -0800, David Schwartz <[EMAIL PROTECTED]> wrote:
>Dan Oetting wrote:
>
>> An Even Simpler Voting Procedure:
>>
>> 1. Each voter privately enters a vote in the system.
>> 2. At the end of the voting period the system prints the totals.
>
> I would argue that P1 is not satisfied because a vote could get lost in
>the process, say if the results from one particular machine are not
>tallied into the final count.
You assume in your system:
The voting procedure, issuing of GUIDs, signing of recepits,
publication of the votes, etc proceeds honestly and without
errors.
Dan assumes:
The counting of the votes and publication of the total
proceeds honestly and without errors.
To me, these assumptions are not so different. And neither assumption is
very realistic.
// Niklas
------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: P/w based authentication and key exchange
Date: 28 Nov 2000 01:19:12 -0800
Per Claesson <[EMAIL PROTECTED]> writes:
> David Schwartz wrote:
> >
> > Per Claesson wrote:
>
> > These sophisticated authentication protocols prevent an attacker from
> > brute-forcing the key. That is, an attacker couldn't even tell whether
> > or not he knew the key just from watching (or MITMing) the
> > authentication process.
>
> Aha! Almost feels too good to be true...
>
> How come such protocols aren't used more widely? I know they are pretty
> new, and that things change slowly, but are there any drawbacks, such as
> CPU or memory resource requirements?
SRP and friends use public-key math operations, so they have the same
performance profiles. They are thus slower than conventional weak
authentication protocols, but no slower than commonly-used PK-based
key-exchange protocols.
Use of these protocols will continue to grow as awareness increases
and standardization improves. Working standards like RFC 2945 and
IEEE P1363 are positive steps in that direction.
--
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/
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Tue, 28 Nov 2000 01:25:22 -0800
Niklas Frykholm wrote:
>
> On Fri, 24 Nov 2000 18:34:46 -0800, David Schwartz <[EMAIL PROTECTED]> wrote:
> >Dan Oetting wrote:
> >
> >> An Even Simpler Voting Procedure:
> >>
> >> 1. Each voter privately enters a vote in the system.
> >> 2. At the end of the voting period the system prints the totals.
> >
> > I would argue that P1 is not satisfied because a vote could get lost in
> >the process, say if the results from one particular machine are not
> >tallied into the final count.
>
> You assume in your system:
>
> The voting procedure, issuing of GUIDs, signing of recepits,
> publication of the votes, etc proceeds honestly and without
> errors.
Not at all.
> Dan assumes:
>
> The counting of the votes and publication of the total
> proceeds honestly and without errors.
>
> To me, these assumptions are not so different. And neither assumption is
> very realistic.
Let's take your claims one by one:
1) Issuing of GUIDs: The GUID is shown to the voter before he or she
votes. You see a GUID, you choose who the GUID is mapped to, the GUID
appears counted for that candidate. That meets P1.
2) Signing of receipts: Each voter sees his GUID before he votes and
can check the signature before he leaves the poll. So if his vote is not
properly signed, he'll know. This meets P1.
3) Publication of the votes: If a vote is left out, counted in the
wrong column, or otherwise miscounted, the voter can detect this. If the
voter kept his signature, he can prove that the GUID that happens to be
his was miscounted, again meeting P1.
I still maintain that my system meets P1 in all cases.
There's an important distinction between the two assumptions. In my
case, the system can actually assure the voter his vote was counted if
the system is implemented correctly, even without the voter assuming the
system was implemented correctly. His system can only assure the voter
his vote was counted if both the system is implemented correctly, and
the voter is willing to assume that the system was implemented
correctly. Obviously no system can meet its goals unless it's
implemented correctly.
Do you see the difference?
DS
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: A Simple Voting Procedure
Date: Tue, 28 Nov 2000 01:34:32 -0800
David Schwartz wrote:
> There's an important distinction between the two assumptions. In my
> case, the system can actually assure the voter his vote was counted if
> the system is implemented correctly, even without the voter assuming the
> system was implemented correctly. His system can only assure the voter
> his vote was counted if both the system is implemented correctly, and
> the voter is willing to assume that the system was implemented
> correctly. Obviously no system can meet its goals unless it's
> implemented correctly.
>
> Do you see the difference?
This is actually a sufficiently important point that I think it
deserves more thorough treatment with an example.
Imagine if you were developing a system where people report
transactions to a bank over the Internet. A design goal is that people
be assured that the transactions were received.
Consider one system wherein TCP, a reliable transport, is used. Since
the transport is reliable, the transactions must be received. Thus
people can be assured that the transaction was received since they know
they sent it.
In another system, after the transaction is received, an employee calls
the person and personally assures them that the transaction was
received. If asked, they provide any transaction details the human
requests. They offer to FAX over a copy of the transaction immediately
if the customer wants.
Now, both systems, if properly implemented, will 100% assure that all
transactions are received by the bank if they are sent. Neither will be
able to assure anyone of anything if not properly implemented. However,
only one can actually assure the client that the transaction was
received by the bank.
So yes, I do assume that the system was properly implemented. But I
don't foist this assumption on others. I have reason to believe the
system was properly implemented since I'm the implementor. Others will
require provable assurances.
The P1 requirement was of this type of assurance. So, yes, no
improperly implemented system can provide this assurance. But many
systems can't provide this assurance even if implemented properly.
DS
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: projective coordinates in ECC: worth it?
Date: Tue, 28 Nov 2000 09:46:44 -0000
In our experience with MIRACL, having implemented elliptic curves over GF(p)
and GF(2^m) using both projective and affine coordinates (i.e. having
"implemented it both ways and taken benchmarks"), the projective is faster
over GF(p), and its very close over GF(2^m).
Follow IEEE P1363 Appendix A for implementation details. Its admittedly
rather complex, but accurate.
Mike Scott
http://indigo.ie/~mscott
MIRACL Cryptographic Library
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Doing ECC over GF(p): is there a significant practical speedup by
> representing all the points in projective coordinates, and normalizing
> at the end? That adds a bunch of scalar multiplication mod p at each
> step but puts off a GCD calculation til the very end. But it makes
> the formulas look even messier than before. Anyone have any practical
> advice, other than "implement it both ways and take benchmarks"?
> I'll be using a pretty slow bignum library, if that matters.
>
> Thanks.
> ================================================================
> Btw, here's my pseudocode, I'd appreciate hearing of any obvious
> mistakes. I'm new at this. Do I totally misunderstand what
> projective coordinates are supposed to mean? I'm just using the raw
> formulas from the Certicom web page and normalizing them to projective
> coordinates.
>
> # P = (p1, p2, p3)
> # Q = (q1, q2, q3)
> # start with p3=q3=1.
>
> # To compute P+Q:
>
> # if P != Q:
> # ta = q2 - p2;
> # tb = q1 - p1;
> # else:
> # ta = 3*p1*p1 + a; # a is the curve parameter, y**2 = x**3 + a*x +
b
> # tb = 2*p2;
>
> # P+Q = R = (r1,r2,r3) where
> # r1 = ta*ta - td**2*(p1 + q1)
> # r2 = ta*td*(p1+r1) - p2*td**2
> # r3 = td**2
>
> # all calculations are mod p
> # then at the end: normalize r with Euclidean GCD algor so r3==1.
>
> ================================================================
------------------------------
From: Per Claesson <[EMAIL PROTECTED]>
Subject: Re: P/w based authentication and key exchange
Date: Tue, 28 Nov 2000 11:03:58 +0100
Thomas Wu wrote:
> If the client/server can store cryptographically strong keys, you ought
> to be able to do an ordinary authenticated key exchange using the long-
> term secrets.
I found some protocol called Bellare-Rogaway, which is supposed to be
correct, given that the key used is strong. Familiar with it? It does
look a lot simpler than the other ones... =)
Again, thanks for the feedback!
Regards,
volley
------------------------------
** 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
******************************
