On Wed, Nov 01, 2000 at 03:56:56PM -0500, David Honig wrote: | At 12:13 PM 10/31/00 -0500, Tim May wrote: | >How about: | > | >-- no key escrow, no split keys, no trusted third parties | | I don't see any way around the fact that some companies will want to have | key escrow of some form for employees who disappear, e.g., car accident, | pickpocket stole the key-carrier, etc. I think companies will want this | because of the risks of financial damage to the company. | | Although its hazardous if done wrong [cf recent PGP problems], is | tarnished by the Fedz/Denning/etc, and might have no use in a personal | privacy tool (your diary dies with you), isn't it too dogmatic to rule out | key escrow for tools intended for use by groups? | | Are there equivalent methods which don't use escrowed keys, which I | am unaware of? Matt Blaze did some work on non-subvertable key escrow, where you escrow keys with random folks, and when you, or Uncle Sam, want the key, you announce that, and hope to get the key back. Let me be clear that this also is not what we're doing. :) | Strong crypto means the employee can put an invincible lock on the | corporate file cabinet. This might mean that invincible locks are | not used in corporations. A corporation might require that any | invincible physical locks be used in series, so the corp can get into the | files if the first lock stays locked. That doesn't seem wrong | to me; and in meatspace two locks in series is obvious and no compromise | is made to either lock's design. | | Maybe no escrow per se, but corp. data is duplicated and each copy is | encrypted by a person's bizkey and the corporate shared key for that person. | Locks in series. | | (Now, it may be 'sad' that ZKS has changed its bizmodel to service | businesses that need locks in series, but I'm only interested in | whether its rational to universally denounce any locks-in-series | architectures.) Thats not really it. We're much more focused on layered locks than series locks. I would worry a lot about the architecture you outline above being vulnerable to a whole slew of attacks on any one key, which means an N key system is at least N times as vulnerable. | >The "relevant legislation" language is the real kicker. | | Though this was elaborated on in a later reply, they really do need to | specify what they mean exactly (re Canada & 'consumer privacy') when | they say the nasty l-word in their public literature. Any mention of the | law in crypto lit turns the stomache, puts the scanners on highest | sensitivity. When we say 'nasty l-word' you can assume we're refering to CALEA, RIP, and that sort of thing. When we talk about legislative compliance, we mean complying with that whole slew of privacy laws. As to the hypothetical that Tim will ask, we'll work very hard to prevent laws requiring key escrow from coming into being. We spend time and energy maintaining relations with law enforcement in a lot of places, explaining to them why we don't build in back doors. And, suprisingly, when you go and talk to them, rather than hissing and shouting, they listen. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume