[3355] in cryptography@c2.net mail archive
RE: ArcotSign
daemon@ATHENA.MIT.EDU (Anonymous)
Wed Sep 23 15:59:44 1998
Date: Wed, 23 Sep 1998 19:34:19 +0200
From: Anonymous <nobody@replay.com>
To: cryptography@c2.net
> The difference between this scheme and a shared-secret scheme (if I
> understand this scheme correctly) is that Arcot's infrastructure gives
> you non-repudiation -- the central server can't forge authenticated
> messages from you -- and so it's suitable for transactions of value
> in a way that a shared-secret scheme isn't.
Not necessarily. Recall that in the Arcot system, the private key
file is not particularly sensitive. The passphrases are unguessable,
so users will probably not protect the file the way they would in
another system.
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.
