[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    RE: ArcotSign
From:       David Jablon <dpj () world ! std ! com>
Date:       1998-09-25 12:33:19
[Download RAW message or body]

The trust relationships in the "secret public key" model
are stronger and more complex than a shared-secret scheme.

The model does not prevent brute-force attack by a service
provider which gains access to the clients stored keys.
But nobody else who gets the stored keys can do this attack.
This seems to be a desirable feature, and reflects a
"real world" model of trust that we place in many providers.

I trust my bank to not forge ATM transactions from me.
At the same time, I am _not_ willing to trust everyone
else in the world with the data on my bank card
and my hashed PIN.

At 07:34 PM 9/23/98 +0200, Anonymous wrote:
>If a server has seen a user's private key file (say, because the user
>stored it in an insecure way), then it can guess the passphrase because
>the server knows the public key.  This allows the server to forge
>messages which appear to be from the user.
>
>The point is that the security boundary needs to be drawn clearly.
>Based on the Arcot description, the public key is within the boundary
>(must be kept secret) and the passphrase-encrypted private key file
>is outside it (may be exposed).  Given this situation, the trust
>relationships are essentially the same as in a shared-secret model.
>
>What is distasteful is to have a fuzzy boundary.  It is sloppy to say
>that the private key file is inside the security boundary, that users
>should try to keep it secret, while at the same time saying that if the
>boundary is breached and the key file stolen, the security of the system
>is preserved.  This leaves the status of the private key file ambiguous.
>We are tempted to claim the advantages of saying that it doesn't matter
>if it is stolen, as though it were outside the boundary, while still
>doing the security analysis as though it were within the boundary.

Distasteful?  This is the essence of layered security.
The descriptions posted so far may exaggerate the
benefits of the model, but it does make sense.

Users should strive towards goals, like keeping keys secret,
and choosing a "good" password -- yet we still want
to protect them in case they don't reach these goals.

-------------------------
David P. Jablon
dpj@world.std.com
<http://world.std.com/~dpj/>

[prev in list] [next in list] [prev in thread] [next in thread]