[2084] in cryptography@c2.net mail archive
Re: statement of intent, security of CMR (Re: GAK and S/MIME)
daemon@ATHENA.MIT.EDU (Andreas Bogk)
Mon Jan 26 18:01:40 1998
To: Adam Back <aba@dcs.ex.ac.uk>
Cc: colin@nyx.net, cryptography@c2.net
From: Andreas Bogk <andreas@artcom.de>
Date: 26 Jan 1998 17:48:37 +0100
In-Reply-To: Adam Back's message of Mon, 26 Jan 1998 00:48:38 GMT
>>>>> "Adam" == Adam Back <aba@dcs.ex.ac.uk> writes:
Adam> Local key escrow is politically safer, and I argue more
Adam> secure than multiple recipients as an mechanism to allow
Adam> archived traffic to be recovered. There are less doors into
Adam> the ciphertext with local escrow, and the communicated
Adam> ciphertext is much more vulnerable than data on local disks.
Adam> If governments have to get a supeona and raid offices to get
Adam> at traffic, we are closer to the status quo.
I'm not really sure if to buy the political argument. After all, the
weak point is enforcment of the policies, and it is equally difficult
to enforce the usage of escrowed keys or CMR keys.
After all, the government could force manufacturers of MUAs with PGP
support to automatically include an additional recipient. This even
works with PGP 2.x. So CMR doesn't make access to communications any
easier.
Adam> Building systems which send session keys encrypted to third
Adam> parties over insecure communications mediums to ensure local
Adam> data availability is politically risky. The design is too
Adam> close to something which would be useful to governments.
I consider corporate key escrow to be damn close to government key
escrow.
>> And by pushing the cryptographic operation to the sender, the
>> system *must* have the sender's cooperation.
Adam> The sender is not typically aware of underlying protocol
Adam> details. Whether the implementation presents the user with
Adam> a choice is an implementation issue. The command line unix
Adam> version of one or more of the pgp5.x versions in fact does
Adam> not present this choice I think.
A program which doesn't offer a choice, and doesn't explain to the
user the result of using the feature should be considered insecure. I
don't think that a dialog box asking the user if he wishes to make the
message readable to the following additional reciepients is hard to
understand.
Of course, by that definition PGP 5.0 is not secure. Too bad their
copyright prevents anyone from distributing derivative work.
Adam> Another issue is that by-passing third party access may be
Adam> detectable and in some regimes detection could be
Adam> detrimental to your health.
But so is using un-escrowed private keys.
Adam> I think that the approaches of using locally shared keys vs
Adam> using multiple encryption compare as roughly equivalent in
Adam> the privacy stakes. You can implement roughly the same
Adam> statement of intent choices on top of either of them with
Adam> similar or identical user interfaces.
And you can turn every scheme into government suppression.
Adam> One particular problem with the CMR mechanism is that it
Adam> fails to maintain the availability of archived mail. This
Weren't you suggesting separate storage keys?
I start getting the feeling that some companies use PGP for scenarios
where, say, Lotus Notes would be better suited, if it hadn't that weak
encryption. CMR obviously gives more flexibility of building an
appropriate document flow system atop of PGP. And that system should
be responsible for automatic archiving, re-encryption etc. Merely
tweaking PGP doesn't solve the problem.
Adam> dialog box). Archiving keys are more efficient as symmetric
Adam> keys -- you don't need public key functionality. Storage
Sometimes you do. For automatic storage encryption, the key has to be
on the encrypting machine. Using asymmetric encryption gives extra
security if the encrypting machine is compromised.
Andreas
--
Top ten reasons why SGI sucks, No. 3:
"The MIPSpro C Compiler
(license FEATURE string = cc)
requires a license password." /usr/bin/cc on IRIX 6.4
