Cryptography-Digest Digest #599, Volume #13 Wed, 31 Jan 01 21:13:00 EST
Contents:
Re: On combining permutations and substitutions in encryption (Mok-Kong Shen)
Re: Most secure code for US Citizen. (Bill Unruh)
strange code ("klaus hoepner")
Re: fast signing ("Joseph Ashwood")
Re: fast signing ("Joseph Ashwood")
Re: fast signing (Paul Rubin)
AIM roasting as encryption? (F83kskl3p)
Re: AIM roasting as encryption? (Bill Unruh)
Re: On combining permutations and substitutions in encryption (John Savard)
Re: fast signing ("Joseph Ashwood")
Re: AIM roasting as encryption? ("Joseph Ashwood")
Re: Most secure code for US Citizen. (Splaat23)
Re: fast signing (Paul Rubin)
Re: AIM roasting as encryption? (John Myre)
Re: More About Passwords (David Hopwood)
Re: fast signing (David Hopwood)
Re: AES and randomness (David Hopwood)
Re: MIKE - alternative to SPEKE and PAK ("Michael Scott")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On combining permutations and substitutions in encryption
Date: Thu, 01 Feb 2001 00:11:57 +0100
"Douglas A. Gwyn" wrote:
>
> Mok-Kong Shen wrote:
> > ... BTW, in this point, associations with 'fuzzy logic'
> > and 'naive physics' come to mind. But I don't believe
> > analogous stuffs would ever be accepted by the crypto
> > community.
>
> ? "Fuzzy logic", despite the name, is an exact mathematical
> discipline. (I haven't heard of "naive physics".)
There was no implication of any valuation. My guess is
that applying stuffs in direction of fuzzy logic wouldn't
be much appreciated in the field of crypto, where one wants
in general to have fairly exact numerical quantities, not
wide ranges, not to say something 'estimated'. Naive physics
deals with 'qualitatitive' matters for deduction and is a
tiny (in my view not very successful/accepted) subfield of
AI.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Most secure code for US Citizen.
Date: 31 Jan 2001 23:11:08 GMT
In <95a4kn$87m$[EMAIL PROTECTED]> Splaat23 <[EMAIL PROTECTED]> writes:
]What are you talking about? He didn't ask for perfect security, just
]the current best! I'll admit the context of this encryption is not
]known, but you don't need to jump on the man...
And I told him the "best"-- a one time pad. It is provably secure.
Nothing else is. Now he may have other constraints-- eg he cannot
exchange the pad in a secure way. Then some other system must balance
the loss of security against the other requirements. Ie, what is best
depends on your requirements. There is not absolute standard. He never
told us his requirements. Security is a balance. And if he does not know
that, then he should, or he will make a complete messup of his use of
the encryption.
]- Andrew
]In article <959tlp$hi9$[EMAIL PROTECTED]>,
] [EMAIL PROTECTED] (Bill Unruh) wrote:
]> In <959lkv$pd2$[EMAIL PROTECTED]> Michael Robbins
]<[EMAIL PROTECTED]> writes:
]>
]> >Pardon my naivate, I guess you guys will give me the straight dope.
]>
]> >Where can I get the most secure encryption code (C/C++).
]>
]> No such thing, Unless you want to use a one time pad. But that
]requires
]> and external source of random stuff, and requires you to securely
]> exchange it with your counterpart.
]>
]> If you told us what you were doing we might be of more help. As it is
]> your request makes little sense.
]>
------------------------------
From: "klaus hoepner" <[EMAIL PROTECTED]>
Subject: strange code
Date: Thu, 1 Feb 2001 00:10:13 +0100
A friend found a letter of ?codes? in his place. Can somebody help me ?
1-1=start
1-2=R4Y.43
1-3=HXY.41
1-4=7XY.4.
1-5=K6M.4Z
2-1=T63.4V
2-2=KZM.4X
2-3=7ZM.4V
2-4=?6CS36
2-5=94WS37
3-1=KXWS36
3-2=7XWS34
3-3=HN3S3Y
4-1=965Q3Y
4-2=HGPQ3Y
4-3=7G5Q3S
4-4=WQFZ3S
4-5=5NFZ3S
5-1=FDYZ3S
5-2=PDFZ24
5-3=F4PG2.
5-4=M45Z23
5-5=YZMG2Y
6-1=PZMZ24
6-2=CQCQ2W
6-3=54WQ2?
7-1=MXWQ2Y
7-2=W4M614
7-3=M43Q2Y
7-4=WXMQ2V
7-5=4Z5S13
7-6=.2Y.17
8-1=SLF.1.
8-2=.VYJ1Y
8-3=8BF.1Y
8-4=J2PJ1V
8-5= 6LP.1Z
8-6=ZV5.1X
9-1=SSP.1Z
9-2=ZJFS.6
9-3=Q.Y8.3
9-4=JVCS.4
9-5=SVWS1S
9-6=.23S.3
10-1=Q2M8.Y
10-2=.SM8.W
10-3=883S.W
10-4=BJC..T
10-5=L.WJ?7
10-6=B8W..W
10-7=4BYZ.T
10-8=XL5Z?5
11-1=LL5Z?3
11-2=XSPG??
11-3=NS5Z?2
11-4=X.FQ?1
11-5=2.FQ?Z
11-6=B8FQ?W
11-7=28FQ?V
11-8=DLMQ?X
12-1=L2MQ?Y
12-2=BBMQ?T
12-3=483QZ3
12-4=J47ZZ4
12-5=Q4RZZ7
12-6=GX7ZZ1
12-7=9Y9.Z?
12-8=H5K.Z1
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Wed, 31 Jan 2001 15:18:00 -0800
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm afraid your requirements still don't make any sense to me.
The requirements are quite simple. 20 times faster than DSA (or as close as
possible), verification does not imply ability to forge. All the other
requirements will be met if those two things can be met. If these can't be
met together, the speed is not as important as the verification != sign.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Wed, 31 Jan 2001 15:23:29 -0800
"DJohn37050" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> There are some free implementations of ECDSA out there. Wei Dai and U.
> Waterloo(?) I have heard about. Of course, if something goes wrong...
And I
> hear that Certicom's stuff is very fast (grin) and is priced reasonably.
Thank you for your help.
Joe
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: 31 Jan 2001 15:36:07 -0800
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> > I'm afraid your requirements still don't make any sense to me.
>
> The requirements are quite simple. 20 times faster than DSA (or as close as
> possible), verification does not imply ability to forge. All the other
> requirements will be met if those two things can be met. If these can't be
> met together, the speed is not as important as the verification != sign.
Exactly what do you mean by verification? Under what situations does
verification have to be allowed? When I say your requirements don't make
sense, I don't mean that I don't understand them. I mean that I don't
see how they provide useful security in a real-world application.
------------------------------
From: [EMAIL PROTECTED] (F83kskl3p)
Date: 31 Jan 2001 23:55:56 GMT
Subject: AIM roasting as encryption?
I was debating with someone on whether AIM's "roasting" method can be called
encryption. I consider it encoding, not encryption...you judge for yourselves,
let me know what you think.
The AIM client takes the user's password and simply XOR's it with a looping
static string "Tic/Toc". (i.e. a password such as "abcdefg1234" would be XOR'd
with "Tic/TocTic/") If I'm not mistaken, then a major idea behind encryption
is that the key isn't the same each time.
Tell me what you would call this.
- Hypah
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: AIM roasting as encryption?
Date: 1 Feb 2001 00:05:02 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (F83kskl3p) writes:
]I was debating with someone on whether AIM's "roasting" method can be called
]encryption. I consider it encoding, not encryption...you judge for yourselves,
]let me know what you think.
]The AIM client takes the user's password and simply XOR's it with a looping
]static string "Tic/Toc". (i.e. a password such as "abcdefg1234" would be XOR'd
]with "Tic/TocTic/") If I'm not mistaken, then a major idea behind encryption
]is that the key isn't the same each time.
]Tell me what you would call this.
encryption, but a very bad one. It is very easily broken. If a technique
is well known then you could call it encoding, although usually encoding
maps the same letter into the same output. This does not.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: On combining permutations and substitutions in encryption
Date: Thu, 01 Feb 2001 00:12:10 GMT
On Wed, 31 Jan 2001 22:00:54 GMT, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote, in part:
>Why there has been so little "outside" research in this
>area is anybody's guess; mine is that attention was
>diverted mainly into the new-fangled block ciphers.
True, but I would add that the diversion partly happened because block
ciphers were seen, starting with DES and its various modes of
operation, as being so convenient as to be of universal applicability.
The civilian market does *not* want to pay for security, so anything
with even slight costs in bandwidth or error-recovery is almost
automatically rejected.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: Wed, 31 Jan 2001 16:15:53 -0800
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> > > I'm afraid your requirements still don't make any sense to me.
> >
> > The requirements are quite simple. 20 times faster than DSA (or as close
as
> > possible), verification does not imply ability to forge. All the other
> > requirements will be met if those two things can be met. If these can't
be
> > met together, the speed is not as important as the verification != sign.
>
> Exactly what do you mean by verification?
Verification is the act of verifying whether or not the audit log has been
tampered with.
> Under what situations does
> verification have to be allowed?
The audit log has to be readable from the UNIX command 'more' and
verification has to take place at the same level of trust. So basically any
fool can read and verify the audit.
> When I say your requirements don't make
> sense, I don't mean that I don't understand them. I mean that I don't
> see how they provide useful security in a real-world application.
They make sense in a multi administrator situation, where one is trusted
completely while the other is trusted substantially less, for example the
second one could be an intern. In order to make it so that the intern can
verify the audit logs, but cannot forge them, signatures need to be used
because the PFY^H^H^Hintern is not trusted. The full admin of course has to
be trusted because someone needs to be in possession of the unlocking data
for the private key on the server. There were other examples that were given
to me (like the customer shouldn't have to trust _us_ with the private key
for bug reports, just the ability to write software). By using signatures
the trust model is greatly simplified.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: AIM roasting as encryption?
Date: Wed, 31 Jan 2001 16:17:40 -0800
I would call it encryption. It's a Vigenere cipher. It's very bad
encryption, but it is encryption.
Joe
"F83kskl3p" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I was debating with someone on whether AIM's "roasting" method can be
called
> encryption. I consider it encoding, not encryption...you judge for
yourselves,
> let me know what you think.
>
> The AIM client takes the user's password and simply XOR's it with a
looping
> static string "Tic/Toc". (i.e. a password such as "abcdefg1234" would be
XOR'd
> with "Tic/TocTic/") If I'm not mistaken, then a major idea behind
encryption
> is that the key isn't the same each time.
>
> Tell me what you would call this.
>
> - Hypah
> [EMAIL PROTECTED]
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Most secure code for US Citizen.
Date: Thu, 01 Feb 2001 00:29:30 GMT
You're being ridiculous... Yes, of course, an OTP is the "best", but
most people can't use it for practical applications. I'm not sure about
you, but _I_ could pretty much figure out what he wanted. If you just
wanted to yell at someone, you should have gone somewhere else, because
your original comment was definately NOT productive.
- Andrew
In article <95a62c$mqn$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Bill Unruh) wrote:
> In <95a4kn$87m$[EMAIL PROTECTED]> Splaat23 <[EMAIL PROTECTED]>
writes:
>
> ]What are you talking about? He didn't ask for perfect security, just
> ]the current best! I'll admit the context of this encryption is not
> ]known, but you don't need to jump on the man...
>
> And I told him the "best"-- a one time pad. It is provably secure.
> Nothing else is. Now he may have other constraints-- eg he cannot
> exchange the pad in a secure way. Then some other system must balance
> the loss of security against the other requirements. Ie, what is best
> depends on your requirements. There is not absolute standard. He never
> told us his requirements. Security is a balance. And if he does not
know
> that, then he should, or he will make a complete messup of his use of
> the encryption.
>
> ]- Andrew
>
> ]In article <959tlp$hi9$[EMAIL PROTECTED]>,
> ] [EMAIL PROTECTED] (Bill Unruh) wrote:
> ]> In <959lkv$pd2$[EMAIL PROTECTED]> Michael Robbins
> ]<[EMAIL PROTECTED]> writes:
> ]>
> ]> >Pardon my naivate, I guess you guys will give me the straight
dope.
> ]>
> ]> >Where can I get the most secure encryption code (C/C++).
> ]>
> ]> No such thing, Unless you want to use a one time pad. But that
> ]requires
> ]> and external source of random stuff, and requires you to securely
> ]> exchange it with your counterpart.
> ]>
> ]> If you told us what you were doing we might be of more help. As it
is
> ]> your request makes little sense.
> ]>
>
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: fast signing
Date: 31 Jan 2001 16:45:28 -0800
"Joseph Ashwood" <[EMAIL PROTECTED]> writes:
> The audit log has to be readable from the UNIX command 'more' and
> verification has to take place at the same level of trust. So basically any
> fool can read and verify the audit.
Are you saying you're going to give a shell account on your auditing
machine to any fool who asks for one? Can I have an account? Can
Kevin Mitnick have an account? If not, then who gets one?
> > When I say your requirements don't make
> > sense, I don't mean that I don't understand them. I mean that I don't
> > see how they provide useful security in a real-world application.
> They make sense in a multi administrator situation, where one is trusted
> completely while the other is trusted substantially less, for example the
> second one could be an intern. In order to make it so that the intern can
> verify the audit logs, but cannot forge them, signatures need to be used
> because the PFY^H^H^Hintern is not trusted. The full admin of course has to
> be trusted because someone needs to be in possession of the unlocking data
> for the private key on the server. There were other examples that were given
> to me (like the customer shouldn't have to trust _us_ with the private key
> for bug reports, just the ability to write software). By using signatures
> the trust model is greatly simplified.
I don't see why the full admin or anyone else should have access to
the raw signing keys. On the systems where I work, we go to great
lengths to make sure that nobody, and I mean nobody, has access to the
keys.
I think you're overestimating the amount of trust you can put in
digital signatures. If you're signing something with keys that are on
some Intel box somewhere that some admin can unlock, I'd trust those
sigs a lot less than a MAC from a sealed module that's been locked in
a secure hosting facility ever since it was first programmed. If some
audit log entries show up which have valid signatures but whose
contents are disputed by some suspected dope dealers, and meanwhile
your admin has quit and is later seen driving a Mercedes around
southern France, is your boss SURE he can convince a jury that nobody
paid off the admin to copy the keys?
Truly tamperproof hardware is an impossible dream, but fairly cheap
modules can be very difficult (far beyond the capability of random
interns) to get the keys out of. I'm pretty much a convert. It's
just too easy to have accidents with key material on computers, even
if you know what you're doing and are careful.
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: AIM roasting as encryption?
Date: Wed, 31 Jan 2001 18:14:26 -0700
F83kskl3p wrote:
<snip>
> The AIM client takes the user's password and simply XOR's it with a looping
> static string "Tic/Toc". (i.e. a password such as "abcdefg1234" would be XOR'd
> with "Tic/TocTic/") If I'm not mistaken, then a major idea behind encryption
> is that the key isn't the same each time.
<snip>
I'd say it this way: an encoding algorithm should be called
encryption if there is a secret (the algorithm itself, or a
key, or both). The "Caesar Cipher" is regarded as encryption
even though it has a tiny (and fixed) key, because it was
intended to be secret. On the other hand, some much more
complex methods, like compression algorithms, are "just"
encodings, because there is no (intended) secret.
So the label "encryption" is not solely a property of the
algorithm itself, but also includes its intended use.
JM
------------------------------
Date: Thu, 01 Feb 2001 01:38:27 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: More About Passwords
=====BEGIN PGP SIGNED MESSAGE=====
John Savard wrote:
> 6) Security computer
...
> - knows H(UPASS), ...
This value is password-equivalent. Also, passwords should always be
hashed with salt, to prevent precomputation attacks (where the same
precomputed dictionary applies to all users) in the case that verifiers
are compromised.
Another, more serious problem is that the host doesn't appear to have
any long-term secrets to authenticate it, so anyone can act as a
man-in-the-middle host between the user and the security computer.
Use one of the more recent strong password protocols to ensure that
the verifier is not password-equivalent, as I suggested in my response
to your original post:
User <-> Security (via Host): execute strong password protocol
Security -> Host: E[K_SH](Sign[Q_S](SessionID, K))
User <-> Host: proofs that user and host know K
User <-> Host: rest of session, encrypted and MAC'd using keys
derived from K
Here K_SH is a symmetric key shared between the Security computer and
host (i.e. the long-term secret mentioned as being required above), Q_S
is the security computer's private signature key, and K is the session
key from the password protocol.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOni97DkCAxeYt5gVAQFSvgf+Lr26peFseTe8BJXmXAS6+WnKCpCO7GVU
BZRLWFKMSrlJyC018jgKKsqG8Wwm5OuxpsPzSCZxcPzJtFH3zBWG463fcBhTTLEJ
RicHo4dA0A9G1Ijndt2OriSBWpQQ7WlKFIl0iaWplPeTuYBNVBkLfeqrlYw7WYgZ
y1GHIRHRxRF/fKRH2YQfC94p4Fn4FOboVrzia7bGZJO+rnt8UjoyTBPfYcTNfGwO
F0UFajVcHjOrekTLALnH5vd3BDTA/RjBzwwBwVTD4nbVp7i8fnFfT5zMJJtuOM/j
tLLWelLIeGhD4Qd05+Mqvnvj0tWvRuOAHJs725WPDukTItZIGzojwA==
=z031
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 01 Feb 2001 01:38:54 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: fast signing
=====BEGIN PGP SIGNED MESSAGE=====
Joseph Ashwood wrote:
> "Paul Rubin" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > What is being
> > signed? Web pages? From a web server?
>
> Just signing the audit log, everytime an audited page access is attempted
> an audit entry is generated, and every so often it is signed (default 16
> entries). It's basically so the admin can do post-mortem analysis.
So why can't you just use a larger number than 16, or sign at given time
intervals? (The latter is better because if the accesses stop for any
reason, the last few entries will still get signed.)
ESIGN is faster than DSA, but I think your problems are more with the
requirements, than the signature algorithm.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOnimXjkCAxeYt5gVAQEG3Qf+P1BYsuofFxq748bVnfK8agNXappTQLqV
YRVteh2dGtu4CvE9H50sdQZfUGRlHEraI0sD3IEQ533bB5aYGI0vkIW1FINtScjL
ZFVyWIgb7V8FkulH31KyJ6Anl6qgcl2jpq3ei46SwSC5iftUqXC1xmPAdx9L5SA9
Ph07SHP4rzzuNlOSP6lOLw8M2pR08DoukcK+PCD3aEigLXQPdb8Ys5atauQu+0cQ
53SyAIvqgYcR97Bt6zYSqwM7c70Ils66rkWoBrAhGP9m95+Kbja7nfsrBgemsu0N
sItKJ2mxRCCyOzWHjFGZJY2+D6WBtmAwYvIEotb/w57oTetfCit/ug==
=aQJe
=====END PGP SIGNATURE=====
------------------------------
Date: Thu, 01 Feb 2001 01:39:23 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: AES and randomness
=====BEGIN PGP SIGNED MESSAGE=====
Scott Fluhrer wrote:
> JCA <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> > I wonder if there are any results about Rijndael as a
> > PRNG. Anybody?
>
> If Rijndael in counter mode weren't a wonderful CSPRNG (that is, given
> 2**64 outputs, there was a better attack than brute-forcing the key),
> this would be *really* big news.
Given 2^64 outputs, it's possible to distinguish the output of Rijndael
in counter mode from random with non-negligable advantage: if there are
no block collisions, guess that the output is from Rijndael, otherwise
guess that it is random. Not that this is a practical attack, of course,
and it applies to any 128-bit block cipher in counter mode, not just
Rijndael.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOnirHTkCAxeYt5gVAQH4uQgAwSry1WBhnG7EEO+RbxiHWe83p1i9j5k1
uzk2fCBY3boNQctrzzlOnEFI+NBO0tJIszARekcSgSZRFLdxQA8VM9nD97xmXz9F
r4QsWIOMOOBFO4UBK/sfcm/mURIn4o7tnOU1f0a/NjW4eDSaRacSSGOfefufnoch
BmIM4+FMZhz2v+ec6HBwvjhVJw8DiNDOsM6isWHhNiJ9giJ7hMDXZPtXY9VGxogj
lWJTjD87QUeNBwH6Z2CW/dK+IWVAY44qHUS/Ga2ddRJZbsdFI5RP7aRVDxq9oAWD
XvCk1M39JOgfHI+++WyzEyFWAGkpegZsI4js2e/8zhrzhCVfvT+7vg==
=HKqy
=====END PGP SIGNATURE=====
------------------------------
From: "Michael Scott" <[EMAIL PROTECTED]>
Subject: Re: MIKE - alternative to SPEKE and PAK
Date: Thu, 01 Feb 2001 01:53:56 GMT
"Thomas Wu" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Michael Scott" <[EMAIL PROTECTED]> writes:
> >
> > Actually not so easily fixed. Steve hasn't committed to his knowledge of
v
> > early enough, which allows an off-line dictionary attack as outlined in
Wu,
> > section 3.2.3, so....
> >
> > 3. Carol: A=3^a.4^x mod p Carol sends A to Steve
> > 4. Steve: B=v.3^b. u=4^r. Steve sends B and u to Carol.
> > 5. Carol calculates S=(B/4^x)^a.u^x. Steve calculates S=(A/v)^b.v^r
> >
> But this is precisely Jablon's B- extension for converting a non-verifier
> based protocol into a verifier-based one; that's covered by his 1997
WETICE
> paper. If the server knows g^x and the client knows x, the server sends
> g^z (random z) and incorporates g^(zx) into the session key. The server
> can compute v^z, but the client is forced to compute (g^z)^x.
>
OK, so this might be better (must get that paper). Variables a,b and r are
randomly selected
3. Carol: A=3^a mod p, Carol sends A to Steve
4. Steve: B=3^b.v^r. u=4^r. Steve sends B and u to Carol.
5. Carol calculates S=(B/u^x)^a. Steve calculates S=A^b
In this case the mutual S is simply 3^(ab) - which doesn't include the
secret. The verifier v=4^x. Consider v and x as El Gamal public/private key
pair. As can be seen Steve is in effect carrying out an El Gamal encryption
of 3^b. Only Carol can decrypt it, and hence complete the base-3 D-H key
exchange.
Mike Scott
> Tom
> > Mike Scott
>
> --
> 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
