From: futplex@pseudonym.com (Futplex)
To: cypherpunks@toad.com (Cypherpunks Mailing List)
Message Hash: feaf97b225d1639cf7dad831c5dc08f328413e6912bd2ae166e0c412aab3cbce
Message ID: <9508110618.AA16373@cs.umass.edu>
Reply To: <8AEE4DC.0003000301.uuout@famend.com>
UTC Datetime: 1995-08-11 06:18:41 UTC
Raw Date: Thu, 10 Aug 95 23:18:41 PDT
From: futplex@pseudonym.com (Futplex)
Date: Thu, 10 Aug 95 23:18:41 PDT
To: cypherpunks@toad.com (Cypherpunks Mailing List)
Subject: Key escrow granularity (Was: If only Vxxxx Fxxxxx had used encryption)
In-Reply-To: <8AEE4DC.0003000301.uuout@famend.com>
Message-ID: <9508110618.AA16373@cs.umass.edu>
MIME-Version: 1.0
Content-Type: text/plain
Monty Harder writes:
> The details of the protocol(s) can be worked out after the basic premise:
>
> There is no reason for anyone to give up the "master key" to all
> of their business, when the minimal overhead in storage space for
> adding an escrowed =session= key will suffice.
More generally, the granularity of the chunk of data protected by each
escrowed key can be varied -- the tradeoff is between the cost of a key
loss and the cost of data storage. A few escrowed master keys are very
cheap to store and very expensive to lose. Each session key is
comparatively worthless on its own, but you could end up having to store an
avalanche of them. I suspect that something close to session granularity
makes sense in the real world; multi-GB HDs tend to be much cheaper than
asking the NSA to guess your keys for you, etc. Of course, you could also
get into escrowing project keys, dept. keys, etc., ad nauseum.
Choosing session granularity is highly recommended when permitting GAK a la
SB 974 :|
-Futplex <futplex@pseudonym.com>
Return to August 1995
Return to “monty.harder@famend.com (MONTY HARDER)”