commercial data recovery

[Note-- I am not subscribed to ietf-open-pgp at this time.  My
 apologies if this submission from a non-subscriber is 
 unwanted.  I will be brief.  --Zooko]


Adam, I applaud your effort to steer discourse toward 
productive work re: GAK, CMR, CDR.  I haven't thought about 
your idea enough to have a definite opinion, but at first blush
it seems a promising strategy to design high-security and 
forward-secrecy for communication but recovery/sharing features
for stored data.


I wonder if it is too much early-days to start talking about
advanced protocols e.g. secret-splitting in IETF-Open-PGP?  
Probably so.  Better just punch out a standard with current
tech...



Hm.  What about the idea of storing your data remotely (for
cost-efficiency, safety, etc.) using encryption to maintain 
your privacy?  In that case, the distinction between comms and
storage keys is blurred.  A company may choose to e.g. store 
all long-term data at Zooko's Backup Server, encrypted in such
a way that some combination of corporate keys (controlled by 
individual employees and/or departments) is necessary to 
decrypt each package of data.  This would open the door, as you
fear, for a government to mandate that _its_ key be added to 
each set, with authority to open any package even without the 
cooperation of any corporate keys.


I'm not sure how to weigh the relative risks and benefits.  
I (ever so humbly) think that Zooko's Backup Server would be a
great value for businesses, and that part of that value would
be the ability to make data unlockable by various keys, both
for administrative/internal security purposes and for 
robustness against accidents and saboteurs.


Zooko's Backup Server can be physically located in a country 
free of such intrusive organizations, but of course it is the
intrusive organizations of the _client's_ country that become
important with that kind of protocol...


Regards,

Zooko

P.S.  There is already a company whose name I have forgotten 
that offers hard-drive backups over TCP/IP.  They use some 
encryption but I don't know how strong.

On Tue, 14 Oct 1997, Zooko Journeyman wrote:

> Zooko's Backup Server can be physically located in a country 
> free of such intrusive organizations, but of course it is the
> intrusive organizations of the _client's_ country that become
> important with that kind of protocol...

How about also having Alex' Backup Server, and using some
shared-secret/whatever tech to ensure that you need to contents of _both_
servers to actually reconstruct the data. This would be a 'Distributed
Encrypted Backup Sysyem'.

This might make it very hard for anyone to access your data without your
knowledge/cooperation.

And if you use something like Onion Routers, it might even be quite
impossible for some lawenforcement agency to actually find out which one
of those encrypted files on the servers contains your backup.

Alex

---
I dabble in techno-house and sometimes,
I do that badass hip-hop thang...
But the F U N K gets me every time!

Zooko Journeyman <zooko@xs4all.nl> writes:
> Adam, I applaud your effort to steer discourse toward 
> productive work re: GAK, CMR, CDR.  I haven't thought about 
> your idea enough to have a definite opinion, but at first blush
> it seems a promising strategy to design high-security and 
> forward-secrecy for communication but recovery/sharing features
> for stored data.

Thank you.  I would encourage others to read the proposal, and
provide criticisms of it.

> I wonder if it is too much early-days to start talking about
> advanced protocols e.g. secret-splitting in IETF-Open-PGP?  
> Probably so.  Better just punch out a standard with current
> tech...

I agree entirely.  The motivation for attempting to formalise the CDR
design principles, and for exploring designs which are non-GAK
compliant is based on these lines of reasoning, that we should:

1. Persuade PGP Inc that there are less GAK friendly ways of
   implementing data recovery

2. If that argument fails, and in the event that PGP were to try to
   influence the IETF OpenPGP forum to adopt any features relating to
   pgp5.5 GAK compliant functionality into the OpenPGP standard that we
   have an alternate proposal well enough thought through to compete
   with PGP's CMR proposal with sound technical arguments.

3. Of improving the state of the technology by working to include
   forward secrecy as much as possible into secure email messaging.
   This is a very effective method of giving the bird to the
   GAKkers, by purposefully destroying communications keys as soon as
   possible after the fact.  This is consistent with the CDR design
   goal: make the GAKkers job as difficult as possible.  Frustrating the
   GAKkers is a fun, morally satisfying activity.

> Hm.  What about the idea of storing your data remotely (for
> cost-efficiency, safety, etc.) using encryption to maintain 
> your privacy?  In that case, the distinction between comms and
> storage keys is blurred.  A company may choose to e.g. store 
> all long-term data at Zooko's Backup Server, encrypted in such
> a way that some combination of corporate keys (controlled by 
> individual employees and/or departments) is necessary to 
> decrypt each package of data.  This would open the door, as you
> fear, for a government to mandate that _its_ key be added to 
> each set, with authority to open any package even without the 
> cooperation of any corporate keys.

The application you describe has very interesting implications for the
CDR vs CMR debate.

I think that one way that you could implement remote backup in a way
which is sympathetic to CDR design principles like this:

- The communications security aspect could be acheived via the normal
  design for securing communications derived from the CDR design
  principles.  That is using short lived communications keys with no
  third party access to communications in transit without access to
  hard disks at either end.

- The data would be super-encrypted to the companies backup recovery
  storage key(s).

This technically violates the CDR design goal and principles of not
allowing third party access to communicated data, super encryption
doesn't negate this, it is just more structuring.

However, super-encryption does minimise the damage by preserving CDR
principle that recovery of data should require physical compromise of
one or both end points, which I think is an important principle, and
a useful property in this case.

This lesson leads to the corollary to the CDR principles that:

- if you can't keep to the principle of not transmitting data with third
  party recovery information attached,

that:

- super-encryption of the transmitted recoverable data can be
  used to at least preserve the requirement for one or both ends of
  the communication to be compromised to effect third party access.



But still, the remaining way that this system could be perverted would
be as you say for the GAKkers to demand to be one of the storage
accessors for the encrypted disk backup, and for the GAKkers to then
attempt to coerce the remote storage service provider to hand over the
ciphertext, or for the government to set themselves up as a central
provider of off site backup services.

The GAKkers desire for automatic access to communicated storage data
is frustrated to the maximal extent possible by those CDR design
principles we have managed to retain.  To achieve automated access the
GAKkers must start replacing software, and we have prevented automatic
snooping of our backup data whilst it is in communication, with
software we have fielded.

- CDR design principles do not prevent someone modifying software, but
  as we all know deployed systems are additional obstacles to overcome:
  they have to coerce some company in to implementing the new software
  with built in GAK, and they have to coerce everyone into replacing
  their existing software with this unpopular new software.

Widely deployed systems can be large obstacles.  The mess the US IRS
in with their millions of lines of hard to modify source attest to
this fact.

The IRS scenario has some lessons for us, for possible additional CDR
design principles:

- keep the source code out of reach of GAKkers so that they can not
  coerce us so easily to modify it.  Off shore backup might be useful;
  destroy the backup recovery key if GAK comes in.

- make systems non-interoperable where this does not interfere with
  functionality

- have mandatory GAK company contingency plans such as moving the
  company to Switzerland.

That first suggestion costs so much in the loss of user access to
source code to assure ourselves that there is no backdoor that we
probably can't employ it.  The other two look like sound principles to
me.


> Zooko's Backup Server can be physically located in a country 
> free of such intrusive organizations, but of course it is the
> intrusive organizations of the _client's_ country that become
> important with that kind of protocol...

One comfort which can be drawn from the above design using super
encryption inside a communications envelope protected with short lived
non-escrowed communication keys, is that the fielded software could
not be used as-is to prevent the practice of jurisdiction shopping.

Another comfort is that companies can, even if forbidden from using
offshore remote backup facilities, simply stop using remote backup
facilities at all, unless the GAKkers really go overboard and demand
that all citizen units will run this government remote backup software
to upload diffs of their disks to government run backup services.  I'm
sure they would love to do that, and charge you for the "service" too.

Also I expect there would be significant political hurdles for the
GAKkers to overcome in mandating government run remote backup services
for citizen units, or even for companies in our countries.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

While I think that a variety of robust and successful products will proably
emerge that support various types of key recovery, I strongly agree with
Tim on engineering grounds: Keep It Simple, Stupid.

When it comes to deciding on the contents of a standard, let's keep in mind
that we're working with a relatively new technology. We'll make more
progress by standardizing proven concepts, and these integrated key
recovery hacks don't have the operating history that vanilla PGP has. If
anything, my experience with Guard keying suggests that the proposed
mechansims aren't enough. The problem has more hair than our sheepdog.

I don't think the protocol standard needs to take a political statement
about key recovery mechanisms, but it *must* outline the protocol's
traditional security objectives pretty much the way Tim outlined them. That
sets the context for a robust protocol that has a successful history.

Now I need to shut off my mailer and go pack my suitcase.

Rick.
smith@securecomputing.com           Secure Computing Corporation
"Internet Cryptography" now in bookstores http://www.visi.com/crypto/

I have an even simpler solution to the problem of how the OpenPGP committee
should solve the key recovery/message recovery/corporate/GAK problem: Don't.

Just decide and announce that neither plaintext nor key recovery will be
part of the OpenPGP spec. This is a cleaner and simpler approach, and the
functions of encryption are placed front and center.

(Let some other task force deal with building some kind of "OpenGAK" or
"OpenSnoopware" program!)

That is, OpenPGP need only worry about providing a robust, secure, etc.,
open standard for end-to-end encyption (communication) and local encryption
(storage). Don't try to solve the "disaster planning" problem ("Alice hit
by a truck") by building snoopware/escrow into the core cryptosystem, and
don't try to solve the snoopware ("What is Alice saying to Bob?") desires
of companies either.

For comparison, we certainly don't see the world's telecommunications
bodies, committees, and companies working on a "conversation recovery" mode
to make the job of enforcing the U.S. Digital Telephony and similar
wiretapping desires.

Dealing primarily with communication and file security is what PGP has
historically focussed on, in all versions from 1.0 to 5.0 (not counting the
anomaly of ViaCrypt). Sounds fine to me. The "mission" of PGP and other
public key cryptosystems (until now) has been to secure communications and
files, not to provide mechanisms for corporations to monitor
communications. (Disaster planning, for "what if Alice gets hit by a
truck?" scenarios, are of course handled by having Alice lock up her
private keys in her safe, or perhaps her department manager's safe,
whatever. This is a dangerous security flaw, if the key is released, but
has the advantage that it's a fairly conventional recovery approach, and is
not built into the cryptosystem itself. Trying to solve this problem, that
of "backup keys" or "spare keys" floating around, is not easy in any
case...OpenPGP would do well to just avoid the issue and let conventional
disaster planning measures deal with the problem.)

If corporations, agencies, governments, etc., want to have access to
Alice's files, to Alice's communications to Bob, this is really a file
managment and archiving strategy problem, not something OpenPGP has to
concern itself with.

Keep it Simple, Stupid. KISS. Often the simplest approach to dealing with
complex specifications and conflicting desires is to just ignore them.

Let Big Brother and Little Brother try to get snoopware deployed when
OpenPGP is widely available.

Whether PGP, Inc. will go along with this is unlikely, but this doesn't
change the reasons for keeping OpenPGP true to the original aims of PGP.

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

* Tim May wrote:
>OpenPGP needs to stick to basics.

Done.

>And PGP, Inc. needs to get back to basics.

Still waiting...

At 12:14 PM -0700 10/15/97, Rick Smith wrote:
>While I think that a variety of robust and successful products will proably
>emerge that support various types of key recovery, I strongly agree with
>Tim on engineering grounds: Keep It Simple, Stupid.
>
>When it comes to deciding on the contents of a standard, let's keep in mind
>that we're working with a relatively new technology. We'll make more
>progress by standardizing proven concepts, and these integrated key
>recovery hacks don't have the operating history that vanilla PGP has. If
>anything, my experience with Guard keying suggests that the proposed
>mechansims aren't enough. The problem has more hair than our sheepdog.
>
>I don't think the protocol standard needs to take a political statement
>about key recovery mechanisms, but it *must* outline the protocol's
>traditional security objectives pretty much the way Tim outlined them. That
>sets the context for a robust protocol that has a successful history.

Thanks for the comments, and the support is nice, too.

As Rick notes, the whole "foobar recovery" (where foobar may be plaintext
messages or keys) technology is untested, besides being dangerous in
various ways.

It represents an escalation of complexity, both for the users and the
developers. (My message is being directed at the OpenPGP folks trying to
figure out what features to support, not to PGP, Inc., which can make its
own decisions about how to spend its engineering and marketing
resources...though I hope they are taking the reactions of many of us to
heart.)

At this stage, where governments of the world are planning to make foobar
recovery mandatory (either GAK or GAP), it's a bad time to launch an
untested and potentially dangerous technology. As others have noted,
Congress is already using PGP's support of message recovery as evidence
that industry can rise to the challenge of providing message recovery for
law enforcement.

OpenPGP needs to stick to basics. And PGP, Inc. needs to get back to basics.

--Tim May


The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

On Tue, 14 Oct 1997, Tim May wrote:
> (Disaster planning, for "what if Alice gets hit by a
> truck?" scenarios, are of course handled by having Alice lock up her
> private keys in her safe, or perhaps her department manager's safe,
> whatever. This is a dangerous security flaw, if the key is released, but
> has the advantage that it's a fairly conventional recovery approach, and is
> not built into the cryptosystem itself.

Tim,
The system above you are proposing is [C,G]AK, plain and simple. This is
what some companies are doing already. And it is a Bad Thing.

[Sidetrack: which is of course why PGP had to find another solution to
present to those customers already using GAK. IMHO, and I can't help but
be a bit surprised that I find myself in the minority on this
issue, at least as far as the list is concerned. What PGP did was
_elegant_.]

-- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred.
   "Tonga? Where the hell is Tonga? They have Cypherpunks there?"

Lucky Green <shamrock@cypherpunks.to> writes:
> On Tue, 14 Oct 1997, Tim May wrote:
> > (Disaster planning, for "what if Alice gets hit by a
> > truck?" scenarios, are of course handled by having Alice lock up her
> > private keys in her safe, or perhaps her department manager's safe,
> > whatever. This is a dangerous security flaw, if the key is released, but
> > has the advantage that it's a fairly conventional recovery approach, and is
> > not built into the cryptosystem itself.
> 
> Tim,
> The system above you are proposing is [C,G]AK, plain and simple. This is
> what some companies are doing already. And it is a Bad Thing.

It is GAK pervertable, but it is much more resistant to GAK perversion
than PGP Inc's CMR system.  I think Tim can reason pretty well without
cribbing from the anti-GAK principles, but that he could present
marginally more GAK-hostile systems by using the anti-GAK principles.
(Or perhaps he would figure them out anyway but figures them to be too
complex... my only real claim is that by working to these principles
that it helps clarfiy what you are trying to defend against, and
trying to avoid in your systems).

The reason that you are right that what Tim suggests is GAK
pervertable is that it partly violates one of the anti-GAK design
principles I have been trying to hone.

It violates the principle that recovery information should not be
communicated (via sneaker net on a floppy to the company safe).

It does however obey the corollary that: if you figure you must move
recovery data, you should at least make it inconvenient, avoid
electronic communicated recovery data, and generally require the
recovery data to be as localised as possible.  (Also the principles
state that you should use forward secret comms keys, but I think that
might be pushing it for sneaker net between machines and a laptop in
the safe for ergonomics reasons :-)

Here is how use of the anti-GAK design principles can help to provide
a more GAK hostile system:

It is better to use recovery rather than escrow.  (Encryption of
Alice's private key with a companies recovery key).  This allows you
then to store the recovery information more locally to the data,
closest possible locality to data being another anti-GAK design
principle.

Now how is this harder than GAK?  Heh well you need to use your
imagination and try to make a system designed to fuck with the GAKkers
minds at this point.  Remember not only do you design the system to
not communicate the key automatically, you try your best to prevent it
being removed from the system.

Here's a few ideas:

You store the recovery info on the users disk only, but you do your
damnest to obfuscate it.  Encrypt it with keys hidden in the
executable, obfuscate the code to hell and back, and don't provide
source for that module.  (Obfuscation tricks like interpreter of
encrypted instruction streams ought to take a little bit of
unwinding).

You also hide the recovery data inside the keyrings, and obfuscate
them to hell and back around the file system in slack space etc.  This
is to make it harder to copy to a floppy.

So now the GAKkers can still get your recovery info, because they
could theoretically unwind that problem.  But it is sure a lot harder
than requiring every one to email them a copy of the key they just put
on a disk.  The software doesn't give you any help obtaining your key
in a mailable form, or in a form to stick on a floppy either.  In fact
it does it's damnest to prevent it.

This is the kind of monkey-wrenching PGP should be investigating,
rather than investing time in designing `elegant' GAK implementations.

Combine with forward secrecy with as quick update time as you can
manage without interfering with ergonomics issues, and the GAKkers
have got to come back every 5 minutes, and grab a copy of your entire
disk, or reverse engineer the obfuscation, to grab the next obfuscated
key.

> [Sidetrack: which is of course why PGP had to find another solution to
> present to those customers already using GAK. IMHO, and I can't help but
> be a bit surprised that I find myself in the minority on this
> issue, at least as far as the list is concerned. What PGP did was
> _elegant_.]

Wow, Lucky! I usually consider you to be spot on most such things, but
I think you failed to hit the bulls-eye there; in fact I think you
missed the dartboard entirely!

I thought it was you who was pointing out earlier the fallacy induced
by the key escrow meme (escrowing transient communicatoins keys with
governments or companies to recover data stored on frigging disks!)
(Actually you applied it just to goverments but the argument extends
to companies perfectly).

The only way that it's elegant is that it is an elegant fully ready to
roll GAK implementation.

(Notice Bruce Schneier's forward of a case of a GAKker already
starting to crow about the demonstration of GAKware feasibility in
PGP).

There are plenty of less GAK compliant things you can do than what
they are doing.  The anti-GAK design principles help to clarify
thought in designing a full spectrum from mildly GAK resistant through
to rabidly GAK-hostile.  I would hope that PGP (and you lot at C2Net)
will crank the setting up to mad dog rabid anti GAK mode with nested
obfuscated interpreters interpreting each other interpreting
instruction sequences to recover keys.  And busting your butts to make
your systems ergonomic and slick to the extent that the competitors
GAKware products look like dried up turds in comparison.  Deployment
being probably the most important anti-GAK principle of all!

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

On Wed, 15 Oct 1997, Adam Back wrote:

> 
> Lucky Green <shamrock@cypherpunks.to> writes:
> 
> > [Sidetrack: which is of course why PGP had to find another solution to
> > present to those customers already using GAK. IMHO, and I can't help but
> > be a bit surprised that I find myself in the minority on this
> > issue, at least as far as the list is concerned. What PGP did was
> > _elegant_.]
> 
> Wow, Lucky! I usually consider you to be spot on most such things, but
> I think you failed to hit the bulls-eye there; in fact I think you
> missed the dartboard entirely!

So I am told. Which is surprising to me, since usually I am told that that
I am too "paranoid" and "uncompromising".
 
> I thought it was you who was pointing out earlier the fallacy induced
> by the key escrow meme (escrowing transient communicatoins keys with
> governments or companies to recover data stored on frigging disks!)
> (Actually you applied it just to goverments but the argument extends
> to companies perfectly).

I can't help but see a difference between enforcing to encrypt to a
default key and storing the user's key outright. IMHO, the former entails
less potential for abuse.

> (Notice Bruce Schneier's forward of a case of a GAKker already
> starting to crow about the demonstration of GAKware feasibility in
> PGP).
> 
> There are plenty of less GAK compliant things you can do than what
> they are doing.  The anti-GAK design principles help to clarify
> thought in designing a full spectrum from mildly GAK resistant through
> to rabidly GAK-hostile.  I would hope that PGP (and you lot at C2Net)
> will crank the setting up to mad dog rabid anti GAK mode with nested
> obfuscated interpreters interpreting each other interpreting
> instruction sequences to recover keys.  And busting your butts to make
> your systems ergonomic and slick to the extent that the competitors
> GAKware products look like dried up turds in comparison.  Deployment
> being probably the most important anti-GAK principle of all!

Amen to the latter. I honestly don't see what PGP could have done better
and still achieved deployment in companies that keep copies of all
employees keys *today*. And yes, I think what PGP is doing is
better than keeping copies of the keys of all employees. Anyway, I now
have access to the entire PGP 5.5 system and will subject it to thorough
analysis. Methinks many people arecurrently rendering opinions on a design
they haven't even seen yet.

Certainly, the part of PGP's SMTP agent that prevents you from  screwing
up by accidentaly sending sensitive email unencrypted stands a good chance
of being installed at my site. [Can we all agree that this is a useful
feature]? More than once, I failed to encrypt an email that I meant to
encrypt.

As for C2 and GAK: as Lucky Green, I speak _only_ for myself. And I can
therefore say that if my employer was to imlement GAK, I would quit the
day I found out about it. It isn't going to happen.

 -- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred.
   "Tonga? Where the hell is Tonga? They have Cypherpunks there?"

> > I thought it was you who was pointing out earlier the fallacy induced
> > by the key escrow meme (escrowing transient communicatoins keys with
> > governments or companies to recover data stored on frigging disks!)
> > (Actually you applied it just to goverments but the argument extends
> > to companies perfectly).
> 
> I can't help but see a difference between enforcing to encrypt to a
> default key and storing the user's key outright. IMHO, the former entails
> less potential for abuse.

Tim covered that pretty well.  Inconvience is significant.  If we can
redesign the protocols or backup procedure so that the GAKker must
modify software before GAK is even possible we have largely won.  If
we can accomplish subversion of the OpenPGP standard we may be on to a
winner too...  if PGP can't implement their beloved GAK functionality
without being a non-conforming application.

All it takes is for the standard not to accept the pgp5.5 CMR key
extension.  It really is too new and experimental to include says all.

Let's include it as a may says Callas.  No thanks says all, we don't
want any of it; too new too experimental.

If it comes to it, and I figured I could get away with it from a sales
perspective I would toss out encrypted email data recovery altogether
in preference to implementing GAK for the GAKkers.

Implementing GAK for GAKkers has similar immorality to blowing away
freedom fighters in foreign countries for sport -- it results in dead
freedom fighters, and dead thought criminals (say boo to some
governments, and they'll have your head on a platter within hours).

The effect is not quite as direct, but it is surely the effect.

Even for selfish reasons we don't want GAK for ourselves, and this
eventuality is far from impossible in our respective countries.

> > There are plenty of less GAK compliant things you can do than what
> > they are doing.  The anti-GAK design principles help to clarify
> > thought in designing a full spectrum from mildly GAK resistant through
> > to rabidly GAK-hostile.  I would hope that PGP (and you lot at C2Net)
> > will crank the setting up to mad dog rabid anti GAK mode with nested
> > obfuscated interpreters interpreting each other interpreting
> > instruction sequences to recover keys.  And busting your butts to make
> > your systems ergonomic and slick to the extent that the competitors
> > GAKware products look like dried up turds in comparison.  Deployment
> > being probably the most important anti-GAK principle of all!
> 
> Amen to the latter. I honestly don't see what PGP could have done better
> and still achieved deployment in companies that keep copies of all
> employees keys *today*. 

Sure they could.  Just simply switching from CMR to CDR:

Store encryption key encrypted to a company recovery key on their
disk.  Or on a floppy in the safe even.

No enforced second recipient necessary.  Recovery of archived messages
possible.

Enforced second recipients are worse than straight forward escrow.

This kind of thing is better for the reasons Tim listed in his defense
of storing the keys in the safe on a floppy as opposed to second
recipient.


How about forward secrecy?  You could make it even less GAK friendly
if the keys only lasted for seconds.  Then what are you going to do?
Send a constant stream of keys to NSA HQ?  What if the software tried
it's hardest to not allow recovery or access to it's keys (it's hardly
likely to given the desire for forward secrecy).  So how can that be
perverted for GAK?

Does PGP investigate these?  Hell no!  They whinge: ergonomics, too
complicated, not possible, you are having a group halucination, you
don't understand software design.

Yeah, that's right ain't it, we're group hallucinating, and Schneier
-- bah they ain't listening to him -- he's just not understanding it
right.

> And yes, I think what PGP is doing is better than keeping copies of
> the keys of all employees. Anyway, I now have access to the entire
> PGP 5.5 system and will subject it to thorough analysis. Methinks
> many people arecurrently rendering opinions on a design they haven't
> even seen yet.

You could have a point there.  Could you investigate and let us know
what it does?

important questions which I think are unclear:

- does it provide message screening functionality (human reading mail
  prior to delivery in both directions?)

- is pgp5.0 able to generate GAK compliant keys (CMR keys)?

- how much control does the SNMP remote configuration provide in
  restricting user

- can you have multiple CMR keys attached to a public key (like one
  for your company and one for the NSA?)

> Certainly, the part of PGP's SMTP agent that prevents you from  screwing
> up by accidentaly sending sensitive email unencrypted stands a good chance
> of being installed at my site. [Can we all agree that this is a useful
> feature]? More than once, I failed to encrypt an email that I meant to
> encrypt.

That part is a truly excellent feature.  I do this myself manually,
the mechanism I use that I read offline and use linux, so my mail is
sitting in /usr/spool/mqueue waiting to go when the connectivity comes
up.  So I go check the files I care about prior to actually
connecting.

However that's not the controversial SMTP policy enforcer property.
PGP Inc employees described that it rejects mail which is not CAK
compliant.

> As for C2 and GAK: as Lucky Green, I speak _only_ for myself. And I can
> therefore say that if my employer was to imlement GAK, I would quit the
> day I found out about it. It isn't going to happen.

I wasn't suggesting C2 was GAK friendly.  I was attempting to suggest
that there are things you can do to be even more rabidly GAK-hostile
than you already are.  Think: monkey wrench GAKkers who might put this
product to a work in a GAK setup.  Make the product be awkward about
the types of functionalities which they will want, make it drag it's
feet, make it hide data which it doesn't want transmitted, make it
cease to function when servers aren't local (eg. local LAN servers,
make them refuse to work for IP#s not on the same sub domain).  Be
imaginative.

PGP are at very best GAK neutral.  It doesn't try hard to stop GAKkers
deriving use from it.  It tries somewhat to prevent users hacking
around it's GAK features.  It coincidentally (if you believe GAK
neutral design philosophy) happens to be pretty useable to the
GAKkers.  It implements a method for a company which doesn't turn on
the GAK feature to advertise that keys are read by company.  Yeah
nice, but big deal right?

Contrast with trying to do all you can to ensure the product can not
be used for GAK without a protocol modification, or without software
recall, or non-backwards compatible widely fielded international
standard rewrite.  They do not appear to have tried any of these.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

I hate to insert a modicum of realism into an otherwise wonderful debate
currently taking place on the Cypherpunks list in regard to the saints
or sinners (depending on the angle that one is pissing from) at PGP,
Inc.(arcerated, if PRZ hadn't folded his hand).
However, my Bullshit Meter indicates that bullshit is currently 'en
vogue' as the preferred 'opiate of the masses' and that the ultra-fine
distinctions between GAK and CMR that are being hotly debated on the 
list are likely to be largely ignored by the huddled masses, yearning 
to be monitored.

SURVEILLANCE==SECURITY
Call it Double Speak or Spin Doctoring, it doesn't really matter. The
citizen-units have bought into the 'America's Funniest Home Videos of
Law Enforcement Agents Busting Dark Skinned Threats To Decent Americans
On Prime-Time TV Thanks To Total Video Surveillance of the Citizenry'
message being promulgated by the mainstream entertainment/news media.

This is why nobody even blinked when legislation was recently passed
which criminalized the possession of toilet plungers, except for those
involved in meeting the legitmate needs of law enforcement to shove
toilet plungers up the citizens' assholes.
(Hell, I usually pay extra for that...)

OK, so I just made that stuff up. Nonetheless, it *could* be true at
some point in the near future, if DoubleSpeak, NewSpeak, SpinSpeak
and I'mTooTiredToFightItAnymoreSpeak become the unchallenged rule
of the day (which is not far from becoming a total reality).

However, the point which I am not terribly concerned about making
is this:
  The great sin of ViaCrypt/PGP is that they are failing to maintain
standards of integrity that are far above that of the large mass of
humanity that they are counting on to comprise the bulk of their
customer base.

What is the quote...??? 
"Nobody ever went broke underestimating the intelligence of the
public." (?)

I would very much prefer that ViaCrypt separate their 'Corporate Message
Recovery' software from the PGP name/reputation-capital, but I would
rather the situation remain as it is than to see PGP/ViaCrypt go under
and leave the encryption software field to those with *no* history of
'doing the right thing.'
I sincerely hope that the CMR software is the result of those designing
it getting caught up in the erronius security concepts being promulgated
by those with a fascist axe to grind, and that it is not the result of
people of integrity 'consciously' averting their gaze from reality in
order to increase their bottom line.

If the current form of PGP/CMR is the result of normal diversion of the
optimum design, due to the time/monetary pressures of everyday business,
then the flaws in the product can be rectified in the future.
If this is not the case, then it will be incumbent upon those who are
aware of the dangers the technology presents, in its current form, to
develop viable methods of circumventing the technology's flaws and/or
weaknesses.

To tell the truth, my main concern with the direction that PGP/CMR has
taken is that there are not many role models left in life, and it would
be a shame to lose yet another one due to lack of the character and
perserverance that is needed to go against the grain of everyday
business reality.
The posts to the Cypherpunks list surrounding the issues involved in
the current release of corporate PGP have been very enlightening to
those of us who count on those such as Peter, Adam, William and others
to 'shake it down' from a technical perspective. However, the pros and
cons being debated on the list will have little meaning in the long
run if those of us who are capable of understanding the issues involved
do not take the time, and make the effort, to fully understand the
implications involved, and to use whatever influence we have in society
and the computer industry to rail against the dangers and work toward
optimum solutions to the weaknesses and shortcomings in the technology
which can threaten privacy, liberty and freedom.

The fact of the matter is, although a company does indeed have a right
to exercise control and supervision over their business affairs, they 
have no right to exercise the same amount of control and supervision 
over an employee's phone call or email to his or her spouse, or family
members, or their communications with the cable company over when they
can be present at home to have their cable TV hooked up.
If a company has set up a system whereby an employee needs to ask
permission to make an unmonitored phone call, or send a personally
encrypted email during the course of the business day, then the
company and the employee have become adversaries.

Governments and Corporations become fascist dictators 'by default.'
When they remain conscientious, humanitarian institutions over a long
period of time, it is the result of the efforts of those within the
governments and corporations to 'make' it so.
If man does not rule the machine, then the machine will rule the man.
[Women rule *both* (;->)------(<-;)]

There is a far cry of diffenence between:
1) "Boss, can I have permission to talk privately, without supervisory
  monitoring, to my child's doctor, since he/she is sick and the doctor
  needs to speak frankly and privately to me?"
and
2) "Boss, I needed to speak privately to my child's doctor, so I 
  bypassed the monitoring mechanisms and informed my supervisor
  as to my reasons for doing so."
and
3) "Boss, I damn glad I work in one of the few remaining companies
  where I am trusted to act in the best interests of both myself
  and the company, and not be spied on over every minor detail out
  of a sense of mistrust."

I realize that we live in a world where the company president (of
Borland?) can steal company secrets and take them with him/her to
his/her new place of employement. And janitors can go through the
garbage to gain access to company secrets that they can sell to
the competition.
However, I truly believe that TOTAL SECURITY is an impossible goal,
and that internal company security should be geared toward making
it necessary for outside forces to attack the system in order for
the corporate information system to be compromised.
The situation within a company is much the same as the situation
within a country. Even the most fascist and draconian of rules 
and regulations will not prevent the anti-fascists and anti-
draconians from playing the secrecy/security game better than
one's own players. (Or prevent the janitor from inadvertently
leaving valuable corporate information lying on the top of the
garbage pile.)

Corporate Security is not a far cry different from National 
Security or Private Security.
All involve an elliptical curve beyond which 'security' becomes
our oppressor, rather than our savior.

I have listened closely to both sides of the debate over corporate
interests versus government shenanigans, and do not disagree too
strongly with either side of the debate.
I believe what may be understated is the reality that any government,
any philosophy or psychology, any devised system of democracy or
security, is dependent upon the knowledge, wisdom and integrity of
those who are involved in upholding the concepts underlying it.

It matters little whether the Supreme Court is 'stacked' with
liberals or conservatives, it is still 'stacked.'
It matters little whether we are 'pretending' to listen to the
arguments of our 'liberal' or 'conservative' foes, we are still
'pretending' to be men and women of reason.

The great danger that exists is that men and women of high intellect
and reason will make the mistake of assuming that their fellow
primates are working off of the same game sheet as they are.
If the same party takes all of the steps backward, as the other
party keeps stepping forward, then the word 'compromise' is being
misused. Buy a clue...

I have no more desire to live in a world full of Dimitri Vulis's 
than I do to live in a world full of Tim C. Mays.
I want to live in a world full of CypherPissers who shoot themselves
in the foot as often as they shoot each other in the head, so that
the Universe maintains its natural balance.
Ignorant incompetence is a far less troubling manifestation than is 
that of conscious evil. Yet we live in a world that 'condemns' the
former and 'compromises' with the latter.

What I find troubling is the fact that 'evil' seems to have a game
plan, while 'good' seems to be locked in an endless argument over
how to proceed so that every aspect of life remains unequivocably 
'equal,' no matter whether nature itself cries out against it.
In effect, 'evil' is in agreement, and advances, while 'good' is
locked in battle with itself, arguing over how many angels can 
stand on the head of a pin.

The longer we refrain from speaking out against the evils of Waco,
the more we will be faced with OKC bombings. If all of us had
protested loud and long over the Waco injustice, then there would
have been no need for the universe to balance it out with OKC.
The turbulence and/or violence of our future is dependant upon
where we draw the line, as individuals and as a society, where 
we say, "This far, and no further."

The end result of the government's promotion of GAK, or PGP's
implementaion of CMR, will not be dependent upon the aims and
goals of those promoting and developing the concepts and the
underlying methodologies behind them, but upon the willingness
or unwillingness of you and I to 'go gently into the night'
when we are faced with an opponent who steps across the line
we have drawn in the sand to represent our own beliefs and
level of personal integrity.
The more of us who are willing to compromise by 'moving' that
line, the more that Doom closes quickly around us, and we are
hung on the cross, with Nine Inch Nails.

Bianca
~~~~~~

>  -- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred.
>    "Tonga? Where the hell is Tonga? They have Cypherpunks there?"

  "Alice? Alice? Who the fuck is Alice? Is she a Cypherpunk?"

I'll try a different way of making my points...

At 9:12 PM -0700 10/14/97, Lucky Green wrote:

>I can't help but see a difference between enforcing to encrypt to a
>default key and storing the user's key outright. IMHO, the former entails
>less potential for abuse.

All other things being equal, maybe the former is slightly less intrusive
than the latter. But maybe not even this, as the two give the same results.
After all, what's the real difference between "all mail, incoming and
outgoing, must also be encrypted to a CMR key" and "you must deposit a copy
of your key with us"?

And things are most definitely not equal, in the "all other things being
equal" sense.

To wit, with the "storing a user's key outright" approach, if thousands of
companies and whatnot are doing this, there will be a mishmash, a welter,
of confusing, conflicting, byzantine arrangements. Some employees will
store their mandated spare keys in the department safe, some will put them
in "open upon my death" envelopes, some will "forget" to update the files
with their latest keys, and so on.

With this chaotic and anarchic approach, of "let a thousand solutions
bloom," Big Brother will have the devil of a time forcing GAK/GMR
(_Government_  Message Recovery_).  It's essentially the chaotic, anarchic,
non-system being used today. (And I've seen little evidence corporations
are collapsing; as noted in several messages, very few pieces of e-mail are
terribly critical, and even fewer can't be recovered from local files...the
market for CMR is for law enforcement and e-mail snoopers.)

By contrast, a CMR system BUILT INTO PGP (!) will potentially become
widespread, especially if support of the non-CMR-compliant version
languishes. Or, God forbid, CMR is mandated (perhaps by "Standard
Accounting Practices" sorts of pseudo-mandates).

I'll take the chaotic and anarchic solution.

And no matter how "elegant" PGP Inc.'s solution is--which I reserve
judgement on, not having studied in as much detail as, say, Adam Back
has--no matter how "elegant," it is still building a dangerous tool for
surveillance into a widely-deployed product.

--Tim May




The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Tim May <tcmay@got.net> writes:
> I'll try a different way of making my points...
> 
> At 9:12 PM -0700 10/14/97, Lucky Green wrote:
> 
> >I can't help but see a difference between enforcing to encrypt to a
> >default key and storing the user's key outright. IMHO, the former entails
> >less potential for abuse.
> 
> All other things being equal, maybe the former is slightly less intrusive
> than the latter. But maybe not even this, as the two give the same results.
> After all, what's the real difference between "all mail, incoming and
> outgoing, must also be encrypted to a CMR key" and "you must deposit a copy
> of your key with us"?

CMR keys are the root of all evil in pgp5.5.  Without them almost any
permutation of recovery care to construct would be less useful to the
GAKkers, for all the organisational, and inconvenience reasons Tim
describes.  Governments have problems handling complexity.  

So make their job complex.  If you were one of the people writing the
IRS tax software back in the 60s, and you were in deep cover, a
proto-cypherpunk, and were bright enough to see the future
possibilites you would have done all you could to fuck up the IRS
system.  You would have obfuscated the code.  You would have put logic
bombs in it.  You would have destroyed the source code
surreptisiously.  (Destroying source code has analogies to destroying
keys at earliest opportunity, you are destroying something which your
enemy needs).

Any bets as to if any of this actually happened on purpose?  I reckon
so.

So, do you all reckon we can make task of fielding GAK impossibly
complex for such a big disorganised government?

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

At 4:48 PM -0700 10/14/97, Lucky Green wrote:
>On Tue, 14 Oct 1997, Tim May wrote:
>> (Disaster planning, for "what if Alice gets hit by a
>> truck?" scenarios, are of course handled by having Alice lock up her
>> private keys in her safe, or perhaps her department manager's safe,
>> whatever. This is a dangerous security flaw, if the key is released, but
>> has the advantage that it's a fairly conventional recovery approach, and is
>> not built into the cryptosystem itself.
>
>Tim,
>The system above you are proposing is [C,G]AK, plain and simple. This is
>what some companies are doing already. And it is a Bad Thing.

Maybe it's a bad thing, maybe it's not. But at least it isn't built into
the cryptosystem itself. (As noted, building it into the infrastructure is
very dangerous.)

(Personally, I keep a diskette containing a copy of my secret keys, and a
"hint message to myself" reminding me of my passphrases, in a Safe Place
(tm). If I had a lawyer, I might seal an envelope with such a diskette in
it and ask him to hold it for me. And if I had a company, I might insist
that employees using crypto as part of their everyday jobs make similar
arrangements. Such has it always been with crypto, right?)

Building the options into a cryptosystem make it entirely too easy to
government to mandate GMR (Government Message Recovery).

>[Sidetrack: which is of course why PGP had to find another solution to
>present to those customers already using GAK. IMHO, and I can't help but
>be a bit surprised that I find myself in the minority on this
>issue, at least as far as the list is concerned. What PGP did was
>_elegant_.]

No, PGP Inc. did not "have" to do anything. Any more than Schlage Locks has
to develop a strategy for dealing with customers who leave spare keys under
rocks, or with their neighbors, etc. Or that telephone switch companies
have to develop a strategy for delivering phone surveillance products, even
though some companies make it a practice to monitor or snoop on employee
calls.

You are a minority for the reasons Phil Zimmermann, Bruce Schneier, Peter
Trei, and many other people have expressed: what the New PGP Inc. is doing
is not in keeping with the personal privacy goals formerly espoused.

And as Schneier noted yesterday, the support by PGP for "message recovery"
is already being used by Congress as an arguing point that it is indeed
practical and should be made mandatory.

Snooware is snoopware. PGP should stay out of this can of worms.

(I can't resist another possible parallel. It's a fact that some companies
use video surveillance, and microphones, to monitor employees. For drug
use, for theft of produced goods, etc. And this is usually legal, except in
some circumstances (restrooms, break rooms, and so forth).  So, suppose a
CRT maker decided to "meet this need" for employee surveillance by building
a small video camera into each of its "Monitors for Monitors" line of CRTs?
Would you still say that this is _elegant_? Me, I'd harshly criticize the
company making the monitors, not because it is illegal, but because
building in a surveillance state infrastructure is very dangerous and even
immoral.)

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

On Tue, 14 Oct 1997, Tim May wrote:
> 
> And as Schneier noted yesterday, the support by PGP for "message recovery"
> is already being used by Congress as an arguing point that it is indeed
> practical and should be made mandatory.

I missed that one. [Just spent four days at an intensive training
improving my fail-safe skills].

-- Lucky Green <shamrock@cypherpunks.to> PGP encrypted email preferred.
   "Tonga? Where the hell is Tonga? They have Cypherpunks there?"

Lucky Green <shamrock@cypherpunks.to> writes:
> On Tue, 14 Oct 1997, Tim May wrote:
> > 
> > And as Schneier noted yesterday, the support by PGP for "message recovery"
> > is already being used by Congress as an arguing point that it is indeed
> > practical and should be made mandatory.
> 
> I missed that one. 

They're right too that it is possible (though less secure).

That's the purpose of the anti-GAK design principles, see [1] below.
They codify a design process for how to fuck with:

- protocol designs
- standardisation processes
- implementations

to make them as GAK-hostile as possible.

There is a scale from:

pro-GAK: (USG, NSA, TIS, IBM) (give me video cams in all bedrooms)

GAK neutral: (implementer who just implements ignoring political argument of
  whether or not GAK will come in believing it irrelevant)

GAK-hostile: (implementer who is rabidly anti-GAK, and wants to stop
  the GAKkers at all costs; he wants to manipulate protocol standards
  settings processes to ensure what results is not just `not GAK' if
  implemented in one way, he wants to make sure that it is impossible to
  be both conformant to the standard and implement GAK, then he wants to
  implement to that anti-GAK-infiltrated standard and deploy as many
  of his units as possible all implemented as GAK-hostily as possible,
  with user ergonomics, functionality and presentation m$ would die for).

I really truthfully am completely puzzled as to PGP.  They make nice
pro-privacy rants (eg Jon Callas), but yet they are implementing a GAK
compliant system, and one which can also be used to itself fullfill
full GAK requirements without any software modifications.  It could
literally be plugged in tommorrow.  This is inconsistent.

Then myself, Tim May, Peter Trei, Bruce Schneier, Peter Gutmann, and
most of the rest of cpunks, and OpenPGP, go over and over what is
wrong with it, how to do it in non-GAK pervertable ways, or not to do
it at all.

And pgp _doesn't get it_.

I am non-plussed.

Are we suffering group hallucination here and are we all totally
confused?  Or is something very strange going on insde pgp's building?

What _is_ going on in there?  Are they arguing?  Are they blissfully
ignorant that the GAKkers are applauding their efforts?  Has the
corporate mind set take over?  Have they done a deal with the Feds?
Have they got $ signs in front of their eyes and forgotten that they
were once pro-privacy (those that ever were; I guess some of the are
just various suits).

I thought they were supposed to be on our side?

> [Just spent four days at an intensive training improving my
> fail-safe skills].

`fail-safe'?  As in blowing holes in cardboard cutouts with `fed'
written across them at 50 yds with a large bore weapon full of
hollow-points?  Sounds phun :-)

Another form of backup plan is to get the fuck out when GAK hits.  Go
move to switzerland, or anguilla or somewhere from which to continue
your after the fact monkey wrenching.  (Is switzerland any good?  Only
place other than UK I have citizenship -- actually not true have US
two through wife dual nationality, but I'm not sure about US right
now -- may get to GAK before UK lot do).

(pls excuse if `fail-safe' means something entirely unrelated, I'm not
familiar with the euphamism/technical term).

Adam

[1]
======================================================================
Date: Tue, 14 Oct 1997 10:37:21 +0100
From: Adam Back <aba@dcs.ex.ac.uk>
To: ietf-open-pgp@imc.org
Cc: cypherpunks@cyberpass.net
Cc: cryptography@c2.net
Subject: proposal: commercial data recovery

If we take the design goal of designing a commercial data recovery
system which is not GAK compliant, we can most succinctly state this
design goal as the task of ensuring that:

- at no point will any data transferred over communications links be
  accessible to anyone other than the sender and recipient with out
  also obtaining data on the recipient and/or senders disks


I think we can distill the design principles required to meet the
design goal of a non-GAK compliant Corporate Data Recovery (CDR)
system down to ensuring that:

1. no keys used to secure communications in any part of the system are
   a-priori escrowed with third parties

2. second crypto recipients on encrypted communications are not
   used to allow access to third parties who are not messaging
   recipients manually selected by the sender

3. communications should be encrypted to the minimum number of
   recipients (typically one), and those keys should have as short a
   life time as is practically possible

Included in 2) is the principle of not re-transmitting over
communication channels keys or data re-encrypted to third parties
after receipt -- that is just structuring -- and violates design
principle 2.


With these three principles you still have lots of flexibility because
you can escrow storage keys, do secret splitting of storage keys, and
store keys encrypted to second storage accessors on the local disk for
stored data recovery purposes.

As an additional bonus, principle 3 adds extra security against
attackers gaining access to encrypted traffic after the fact -- the
recipient no longer has the key -- this is a form of forward secrecy.


Systems designed to the CDR design principles are of significantly
less use to GAKkers than PGP Inc's GAK compliant Commercial Message
Recovery (CMR) design.  The CDR design significantly hinders the take
up of GAK if widely deployed.  

Design principle 3 -- forward secrecy -- is inherently hostile to
GAKkers, and is the strongest statement you can make against GAK: you
are purposelly _destroying_ communications keys at the earliest
possible moment to ensure that GAKkers can not obtain the keys by
legal and extra-legal coercion, black mail, and rubber hose
cryptanalysis.

The whole system translates into the Feds having to come and
physically take your disk to obtain information about you, which is
much better than GACK, and not what the GAKkers are interested in at
this point.  The GAKkers would like to install themselves, and coerce
companies into installing for them (via GAKker/USG/NSA/NIST organised
efforts such as the 56 bit export permit for companies installing key
escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)).
I fear that PGP Inc's CMR proposal inadvertently meets most of the
NIST/NSA specified KRAP requirements.

What the GACKers want is systems where they can perform routine key
word scanning and fishing expeditions into your communications from
the comfort of their offices, without your knowledge.  This is push
button Orwellian government snooping.

Within the constraints imposed by the CDR design principles, there is
plenty enough flexibility to acheive the commercial data recovery
functionality to similarly weak levels of enforcability as achieved by
the CMR design.  Weak levels of enforceability are appropriate because
there are other exceedingly easy bypass routes: super-encryption, and
walking out of the office with a DAT tape.


I would like to organise a collaborative effort to write a white paper
discussing how to implement various functionalities using the CDR
design principle.

Then I would like to see discussion of which set of these
functionalities which best acheive the user requirement for company
data recovery.

Lastly I would like to see a collaborative development effort to
provide a example implementation of a CDR system which can be used as
a discussion point for the OpenPGP standardisation process.

I suppose the best place to discuss this process is the IETF forum for
discussion of the OpenPGP standard, the OpenPGP mailing list
(subscribe by sending message body "subscribe ietf-open-pgp" to
"majordomo@imc.org").

I have already had people express in email to me their interest in
doing this.  Those people can speak up if they want to.  Technical
input is sought from people opposed to GAK compliant software, and
from PGP Inc, and others defending PGP's GAK compliant CMR proposal.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----

>[Sidetrack: which is of course why PGP had to find another solution to
>present to those customers already using GAK. IMHO, and I can't help but
>be a bit surprised that I find myself in the minority on this
>issue, at least as far as the list is concerned. What PGP did was
>_elegant_.]

Actually, I think you'll find that most people on the list think PGP's method 
is better than a lot of other things.  It is elegant.  But, as Adam has been 
pointing out, there are better methods. :-)




-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBNEQquDc3ytqHnNyNAQGHvwP+JYTOg5IhciQ9Evm7W9jrmwxx8DNb7oww
n2KTeveEIj6K2lHksLZHvbT7//zfTXcol7IiPoHSnoHL6Z6Q6af6+7O5I9VwPNWo
+jGOLpbCFtdpvniaeugLCaji5/oQTx9HMu05n5Gj+iERShesCiXJaSU7CBq6qRi5
4iFmn7nxNkU=
=Ej6P
-----END PGP SIGNATURE-----


-----------------------------------------------------------------------
Ryan Anderson - <Pug Majere>     "Who knows, even the horse might sing" 
Wayne State University - CULMA   "May you live in interesting times.."
randerso@ece.eng.wayne.edu         
PGP Fingerprint - 7E 8E C6 54 96 AC D9 57  E4 F8 AE 9C 10 7E 78 C9
-----------------------------------------------------------------------

-----BEGIN PGP SIGNED MESSAGE-----

G'day all.

Zooko Journeyman wrote:

> I wonder if it is too much early-days to start talking about
> advanced protocols e.g. secret-splitting in IETF-Open-PGP?  

One list member has encouraged me to write an internet-draft for a key
quorum system, so I am.  The trouble is that my proposed implementation
needs some info that isn't in the current IETF draft (the format of the
"string to key" object).

Is it actually documented anywhere that we can access?

Cheers,
Andrew Bromage

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQCVAwUBNEQHMBF7J5ORR6ohAQEtJQP/XlunlxxrKDwh0zlTBiWeURSvUbo3Lvup
vp+Ex9gyraWuX+eaIoioQw+iQ7uLlWxeCRPVlVrpsnYG4YJF7vO1QKVxHuTZEbXj
wUZyS8WXv+3TRjakCfKf2nNP6lDgYs2W67eZhmYzuwC/2uNn078DbAWg8TLcy1ji
GvKEy0n4pLI=
=4Ypn
-----END PGP SIGNATURE-----