From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: a2678d8b5d7844fc689028cc70ea16ad011791d59038c9a4d56f114a5636fb5e
Message ID: <9310232111.AA03150@ah.com>
Reply To: N/A
UTC Datetime: 1993-10-23 21:18:29 UTC
Raw Date: Sat, 23 Oct 93 14:18:29 PDT
From: hughes@ah.com (Eric Hughes)
Date: Sat, 23 Oct 93 14:18:29 PDT
To: cypherpunks@toad.com
Subject: Re: ADMIN: proposed new policy on the mailing list
Message-ID: <9310232111.AA03150@ah.com>
MIME-Version: 1.0
Content-Type: text/plain
So far I have received six comments on the proposed sign-or-delay
system, two in public, four in private. All have been supportive of
concept, but there have been specific technical issues with it.
-- security of keys at machines owned by someone other than the key owner.
-- standardization and legality of software
What I left out of my first posting was the particular algorithm used
at the server to verify signatures. I was certainly going to accept
both PGP and PEM formats. However, I had toyed with not using actual
crypto at all, but just recognizing message formats.
Given the objections I've received, I now amend my proposal from "sign
your messages, or else" to "make something that looks like a
signature, or else". This has several consequences that I
particularly like.
The real goal of this plan is to change the software infrastructure so
that crypto can easily be inserted. Certainly some software module
will be the only good way to create signed-format messages, and this
software, whatever it actually is, fits in exactly the same place that
real crypto does. If, for some reason, a user does not use real
crypto but a replacement, their own system still supports crypto when
it is feasible or available or legal or whatever.
This modified plan addresses the legal issues, since a crypto-format
is not cryptographic. In fact, it is exportable, since it is not
crypto. There are no patent issues, since a crypto-format does not
use RSA. It also addresses the key security issue, since there need
be no key involved. It also implies no particular policy of key
distribution or verification, sticky issues that plague both PEM and
PGP.
Ironically, allowing pseudo-signatures _increases_ the real use of
cryptography, since no longer will there be the presumption that
because the message looks signed that it is actually signed by the
claimed signer. The whole point of digital signatures is to allow a
verification mechanism, but using a permissive format creates the need
to use that mechanism. Since no verification will be done at the
server, any verification desired will have to be done at the receiving
end.
There is the opportunity for a great rhetorical coup here. Assume
that pseudosignature software exists. Now there can be made the
argument to David Sternlight, who is nominally in favor of crypto but
who picks the least crypto-favorable interpretation of anything, to
show his support for crypto in theory but not in practice.
Comments?
Eric
Return to October 1993
Return to ““Robert J. Woodhead” <trebor@foretune.co.jp>”