From: Matt Blaze <mab@crypto.com>
To: cypherpunks@toad.com
Message Hash: f0789c54600444fb93f036de54bbb9667ed591c4f56d7ac0b30b63362c07be6a
Message ID: <199407292048.QAA20091@crypto.com>
Reply To: <9407291841.AA03054@ah.com>
UTC Datetime: 1994-07-29 20:42:51 UTC
Raw Date: Fri, 29 Jul 94 13:42:51 PDT
From: Matt Blaze <mab@crypto.com>
Date: Fri, 29 Jul 94 13:42:51 PDT
To: cypherpunks@toad.com
Subject: Re: No SKE in Daytona and other goodies
In-Reply-To: <9407291841.AA03054@ah.com>
Message-ID: <199407292048.QAA20091@crypto.com>
MIME-Version: 1.0
Content-Type: text/plain
> A technical question about the proposed SKE schemes: are they a
> proper superset of non-escrowed pgp/ripem type systems
>
>I'm not sure what you mean by superset, but I suspect that however you
>interpret it, the answer is no.
>
> As a previous
> poster mentioned, users could select null or locally controlled key
> escrow agents, and effectively have a non-escrowed system.
>
>The system I've seen (Whit's recollection of Steve Walker's) did not
>allow a cooperating party to interoperate with a non-cooperating
>party. In other words, both correspondents must comply with gov't key
>surrender, or neither.
>
>Matt or Whit can comment better, since they've seen it first hand.
>
>Eric
I just looked over the viewgraphs from the Karlshrue meeting; short of
breaking the signature scheme used to certify the "package instance"
public escrow key, there doesn;t appear to be any unilaterial action that
one party can take to interoperate with a "legal" recipient without
escrow.
Others have pointed out, however, that you can re-use other people's
public escrow keys (that you learned, for example, by communicating with
them) to thwart traffic analysis. Of course, traffic analysis is not
one of the stated requirements of the system anyway.
Also, the TIS proposal involves "software" tamper resistance in the form
of code checksums that the verified at run time. This is intended to
discourage bi-laterial escrow circumvention. Of course, any software-
only scheme can be thwarted, but patches to disable it may be a bit
involved, depending on how well obfuscated the code is.
-matt
Return to July 1994
Return to “tcmay@localhost.netcom.com (Timothy C. May)”