[7088] in cryptography@c2.net mail archive
Re: Automatic passphrase generation
daemon@ATHENA.MIT.EDU (David Jablon)
Fri May 12 19:11:40 2000
Message-Id: <3.0.5.32.20000512113620.008635f0@world.std.com>
Date: Fri, 12 May 2000 11:36:20 -0400
To: "Steven M. Bellovin" <smb@research.att.com>
From: David Jablon <dpj@world.std.com>
Cc: Paul Crowley <paul@cluefactory.org.uk>,
Rick Smith <rick_smith@securecomputing.com>,
Sergio Tabanelli <sergio.tabanelli@fst.it>, cryptography@c2.net
In-Reply-To: <20000511194424.C2BB735DC2@smb.research.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
For all those interested in EKE, A-EKE, and related methods,
the next P1363 meeting (May 31, Boston) will discuss the creation of
a new standard for Password-based Authenticated Key Exchange.
The P1363 home page is <http://grouper.ieee.org/groups/1363>.
The joint kick-off document for this effort is
"Proposal for P1363 Study Group on Password-Based
Authenticated-Key-Exchange Methods",
Bellare, Jablon, Krawczyk, MacKenzie, Rogaway, Swaminathan & Wu,
<www.IntegritySciences.com/p1363.html>
To participate in or track this effort, feel free to join the P1363 mailing lists
at <http://grouper.ieee.org/groups/1363/WorkingGroup/maillist.html>.
>>Rick Smith <rick_smith@securecomputing.com> writes:
>>> If you can control the risk of off-line attacks (i.e. theft of the password
>>> file) then attackers are stuck performing on-line attacks. The system under
>>> attack can usually detect on-line attacks and take countermeasures to
>>> reduce the risk of a successful penetration.
>>>
>>> A related strategy is to combine the simple secret with a larger, more
>>> random secret. But this provides better security only if you can keep
>>> attackers from stealing the larger secret. One approach is to embed the
>>> larger secret inside a tamper resistant device like a smart card, and set
>>> up a protocol that doesn't allow the secret to leak out. But there's still
>>> the challenge of protecting the copy of the secret stored on the server.
>In message <87wvl1cyum.fsf@hedonism.subnet.hedonism.cluefactory.org.uk>,
>Paul Crowley writes:
>>The SRP authors (http://srp.stanford.edu/) suggest that SRP can be
>>enhanced such that the server knows neither secret, only a verifier
>>for the secrets. This means you have to extract the secret from the
>>smartcard itself.
At 03:44 PM 5/11/00 -0400, Steven M. Bellovin wrote:
>Mike Merritt and I described such a mechanism in our A-EKE paper,
>http://www.research.att.com/~smb/papers/aeke.ps (or .pdf), several
>years earlier. Briefly, use a DSA public key as the shared secret for
>EKE (http://www.research.att.com/~smb/papers/neke.ps or .pdf), then
>send an additional message from the client that uses the private key to
>sign a random value, perhaps the negotiated key.
---------------------------------------------------
David P. Jablon
Integrity Sciences, Inc.
dpj@IntegritySciences.com
www.IntegritySciences.com
---------------------------------------------------
David P. Jablon
Integrity Sciences, Inc.
+1 508 898 9024
dpj@IntegritySciences.com
www.IntegritySciences.com
