1998-09-21 - Re: ArcotSign (was Re: Does security depend on hardware?)

Header Data

From: Greg Broiles <gbroiles@netbox.com>
To: Nick Szabo <szabo@best.com>
Message Hash: 14db8f7afef287ddd13461afb3bf4ca8a91b1b889bd610c84b4cf2d5eb0d52a9
Message ID: <Pine.BSF.4.02.9809212206150.11625-100000@ideath.parrhesia.com>
Reply To: <199809220131.SAA11293@shell7.ba.best.com>
UTC Datetime: 1998-09-21 16:35:25 UTC
Raw Date: Tue, 22 Sep 1998 00:35:25 +0800

Raw message

From: Greg Broiles <gbroiles@netbox.com>
Date: Tue, 22 Sep 1998 00:35:25 +0800
To: Nick Szabo <szabo@best.com>
Subject: Re: ArcotSign (was Re: Does security depend on hardware?)
In-Reply-To: <199809220131.SAA11293@shell7.ba.best.com>
Message-ID: <Pine.BSF.4.02.9809212206150.11625-100000@ideath.parrhesia.com>
MIME-Version: 1.0
Content-Type: text/plain



On Mon, 21 Sep 1998, Nick Szabo wrote:

> I have consulted at both DigiCash and Arcot.  I am still
> under nondisclosure to Arcot, so I can't answer any
> questions about this that go beyond the publicly available 
> information.  Arcot has recently made available on their public 
> web site "Software Smart Cards via Cryptographc Camouflage", at 
> http://www.arcot.com/camo2.html.  At the end of
> this paper is referenced Rivest's "Chaffing and Winnowing"
> paper.  These give a good overview of how such a technology
> can work, and the scope of its application.

I'm certainly not a cryptographer, but I'm somewhat at a loss in trying to
understand the purpose of using public-key (or asymmetric key)
cryptography within a policy/technology system which won't allow the use
of the strengths of asymmetric key crypto. As I understand the paper you
reference above, to implement this system the public key must be kept
confidential, and signed documents must also be kept confidential, or the
system of the security as a whole is at risk. With those constraints, why
bother with the overhead (computationally/technically/legally) of
asymmetric key crypto at all? 

It seems like much of the security in the system described above comes
from the server/other party's ability to thwart brute-force attacks by
detecting and responding to multiple failed attempts at authentication;
that seems like a very good thing, but not really a strength or a weakness
of the protocol itself, but an additional practice/protocol which is
useful in many contexts.

Is it really necessary/useful to call the scheme "software smart cards"?
If it were called "An improved system for user authentication", I don't
think it would make people nearly so suspicious. From my perspective, one
of the advantages of smart card technology is that I can carry my
authentication material with me; a system which puts it on my hard disk is
less attractive. Floppies are portable, but not durable. 

I didn't understand the relationship between this scheme and Rivest's
chaffing and winnowing which you note was cited as a reference in the SSC
paper - would you (or someone else) mind explaining the connection? The
closest I can get is thinking that there's a parallel between trying to
guess which PIN in the SSC system is valid and which isn't, and the
"winnowing" part of the Rivest protocol; but that doesn't seem like an
especially meaningful or illuminating relationship. It looks like maybe a
footnote was dropped, which would've tied the Rivest paper to a particular
passage in the paper.

--
Greg Broiles
gbroiles@netbox.com






Thread