Why Corporate Message Recovery isn't Key Escrow

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A number of people have asserted that the Corporate Message Recovery
feature is
key escrow. From where I sit, the difference is easy to see. My definition of
"key escrow" is that another person or organization keeps a copy of the user's
secret key.

Here's an example, based on actual customers who use key escrow to manage
their
data:

This corporation uses PGP for a number of things. Email, engineering plans,
CAD
drawings, and so on. They've done so at least since the days when we were
Viacrypt, and I believe they even used PGP 2.x.

When an employee arrives at this company, they create a key pair for the new
employee, hand it to them on a floppy, keeping a duplicate floppy with the
keypair on it, which they toss into a safe. Literally. This is key escrow.
They
do this because they can't afford to lose their files and messages. Their
policies require them to keep the secret keys, as if they were the same as
keys
to offices or file cabinets.

I don't know about you, but I'm appalled. Nonetheless, they're our
customers. In
spite of inheriting them, we have a responsibility as businesspeople to at
least
listen to their concerns. 

- From our standpoint, the issue gets even touchier. They don't like what
they're
doing, and they want us to give them a better way to manage their data. Does
anyone really believe that only moral response is to flinch and turn away?

I'd like to be in a situation where I didn't have to deal with this. Wanna
trade
positions? I'll sit over there and cluck my tongue about how adding an extra
recipient weakens security while you figure out how to help these folks out of
the mess they're in. While you're at it, I'll pen a few lines about how giving
clean needles to addicts undermines society, and handing out condoms
encourages
kids to have sex. Trust me, it's less nerve-wracking than what we have to
do to
solve this problem, which involves running through hypothetical scenario after
hypothetical scenario, balancing the user's privacy against the organizations
property rights, the privacy and property rights of one organization against
that of another, and so on.

Corporate Message Recovery isn't key escrow for a number of reasons. First, it
doesn't involve keeping a copy the end-user's secret key. I hope that's
obvious
now. Second, the system behaves very differently. 

With a key escrow system, there is a superb McGuffin (which is what Alfred
Hitchcock called the crux of a mystery, like the falcon in The Maltese
Falcon) -
 it's the safe. Break into the safe, or lend its contents out, and all Hell
breaks loose. Whoever has those keys (which easily fit on a single Zip
disk) has
the company at its mercy. They can decrypt or sign anything they care to.
There
is a great thriller to be written here.

It isn't so with a CMRK. The worst possible way to use the feature is to
have a
single, company-wide CMRK. If that gets lost, the thriller you can write isn't
nearly as interesting. Yup, you can steal any of the plans, read all the mail,
and so on. That's bad. It's deplorable, actually. But it isn't a difference
that
makes no difference. At least there isn't a gang of keys out there that can
sign
anything with anyone's ID.

This is not the only way to use Corporate Message Recovery, it's just the
worst
way. Remember, it's just a notation in the self-signature that states,
"When you
encrypt to me, encrypt to X." That's any X. You can have a different CMRK for
every department, every workgroup, or even every user.

A sophisticated policy might be that every user sets their supervisor's key to
be their CMRK. Another is that everyone in Department X sets their office
mate,
or lab partner, or other person. You can have anything that suits your group,
from Recovery Central, to Recovery Hierarchy, to Recovery Buddy System.

The significant improvement that PGP's web of trust has over a traditional
hierarchical system is that you can set up a top-down system for validity, but
you don't have to (and in our opinion, shouldn't). Analogously, the
significant
improvement that Corporate Message Recovery has over key escrow is that you
can
tailor a recovery system to your needs (including and especially deciding it's
not for you). 

	Jon



-----BEGIN PGP SIGNATURE-----
Version: PGP for Business Security 5.5

iQA/AwUBND6j8H35wubxKSepEQI58gCfQuiMZCyfe7cD1F2nNgFtluQqGXMAoJUh
yHFMApAlDjzwRTCspBi7p9t3
=a2Zo
-----END PGP SIGNATURE-----


-----
Jon Callas                                         jon@pgp.com
Chief Scientist                                    555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                          Suite 570
(415) 596-1960                                     Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)

Jon Callas <jon@pgp.com> writes:
> A number of people have asserted that the Corporate Message Recovery
> feature is key escrow. From where I sit, the difference is easy to
> see. My definition of "key escrow" is that another person or
> organization keeps a copy of the user's secret key.

You are adopting a narrow technical meaning of key escrow.  Key escrow
also has another meaning in common parlance: third party access to
communications.  Now I know this common parlance isn't technically
accurate, but "key escrow" itself is a piece of newspeak, a clever
term coined by secret service / government spin doctors.  It has
entered the language like it or not (I don't like it).  This common
parlance meaning is probably more widely understood and used than the
technical meaning you are using.

With that in mind, you may start to see why people, such as Schneier,
and others over the last few days have been telling you "you're
picking nits".

Point is pgp 5.5 allows other people to have access to your
communications.  Your SMTP policy enforcer even attempts to enforce
this.  You also described a feature whereby an administrator could
remotely configure and restrict functionality in pgp 5.5 mail client
(I am unclear as to whether this allows the admin to enforce snoop
access or not).

Your own term CMR (Corporate Message Recovery) isn't that accurate a
description itself, it's a bit of a euphamism at best.  What you're
recovering is transient communications which don't need recovering
anyway.  What PGP is really up to is enforcing capability for
Corporate Message Snooping.

[line breaks were _all over_ the shop, I've reformatted]

> Here's an example, based on actual customers who use key escrow to
> manage their data:
> 
> This corporation uses PGP for a number of things. Email, engineering
> plans, CAD drawings, and so on. They've done so at least since the
> days when we were Viacrypt, and I believe they even used PGP 2.x.

First point, which I'm getting bored of repeating: keys have different
uses.  Storage keys, transient communications keys, signature keys.
You're using one key for all 2 functions; that is the root of your
problems and dilemmas.  You're using what should be a storage key to
receive transient communications, then you're proceeding to wonder why
this causes you to have the undesirable situation of having a GAK
compliant system (or more properly trying and failing to argue that
you don't have one).

> When an employee arrives at this company, they create a key pair for
> the new employee, hand it to them on a floppy, keeping a duplicate
> floppy with the keypair on it, which they toss into a
> safe. Literally. This is key escrow.  They do this because they
> can't afford to lose their files and messages. Their policies
> require them to keep the secret keys, as if they were the same as
> keys to offices or file cabinets.

You know, what they're doing: it's not so bad for data encrypted on
their disks.  They can acheive the departmental level escrow to
distribute risk just the same with this form of escrow.

You don't need to escrow transient communications keys at all anyway.

Your pgp 5.5 isn't going to help recover the actual data of value, all
those stored CAD files...  You know why?  Because they're on the disk,
not in transit in the email system.  So you haven't solved the claimed
problem.

If you want to do something about the claimed problem work out some
secret splitting solutions to better distribute trust for escrowed
storage keys.  (Now this is a real use for escrow: the company is safe
guarding it's own encrypted data on disks and tapes for it's own
benefit).

> - From our standpoint, the issue gets even touchier. They don't like
> what they're doing, and they want us to give them a better way to
> manage their data. Does anyone really believe that only moral
> response is to flinch and turn away?

Nope, your responsibility should be to solve their problems.  (Which
as I show above you have not done.)  Actually your responsibility to
live up to the reputation PRZ transfered to PGP Inc dictates that you
should also do what you can do not build systems which help GAKkers.

Instead your responsibility appears increasingly to produce systems
which smooth the way for coming mandatory GAK by implementing systems
which are GAK ready.

Or if you deny that one, at least you are weakening your
communications security for practically no gain.

> I'd like to be in a situation where I didn't have to deal with
> this. Wanna trade positions? 

Yeah, OK, you don't seem to be managing very well :-)

(Sorry, you asked for it.  I don't actually mean to be rude, I would
just like to get the points across, and to influence PGP to recover
gracefully from this tactical and reputational mistake.)

> It isn't so with a CMRK. The worst possible way to use the feature
> is to have a single, company-wide CMRK. If that gets lost, the
> thriller you can write isn't nearly as interesting. Yup, you can
> steal any of the plans, read all the mail, and so on. That's
> bad. It's deplorable, actually. But it isn't a difference that makes
> no difference. At least there isn't a gang of keys out there that
> can sign anything with anyone's ID.

This is why I was asking above about separate signing keys.  They
surely don't need to stick the signature keys in the safe!!!  In fact
it is counter-productive even for hard-nosed corporate lawyers, and
$$$ driven scruple-short company execs: if they can't prove an
employee penned something they can't use this to prove a case against
him.  If they've got a copy of the signature key, they can forge
signatures which makes signatures useless in litigation involving
company and employee.

> This is not the only way to use Corporate Message Recovery, it's
> just the worst way. Remember, it's just a notation in the
> self-signature that states, "When you encrypt to me, encrypt to X."
> That's any X. You can have a different CMRK for every department,
> every workgroup, or even every user.

It's all screwey because you've got key functionality which belongs in
different keys mixed up.

You should have 3 types of key:

1. signature keys
2. transient encryption keys
3. storage keys

The signature keys you never escrow.  You certify.  If something goes
wrong you re-issue, release revocation cert, and re-certificate.

The transient encryption keys are for communications, you delete them
immediately after use.  Yes I'm talking forward secrecy here.  If you
don't like forward secrecy, well at least don't escrow the encryption
keys.

Storage keys you make damn sure you can recover.  You escrow these for
real.  Company safe sounds about right.  Secret splitting could be
nice also.

> The significant improvement that PGP's web of trust has over a
> traditional hierarchical system is that you can set up a top-down
> system for validity, but you don't have to (and in our opinion,
> shouldn't). Analogously, the significant improvement that Corporate
> Message Recovery has over key escrow is that you can tailor a
> recovery system to your needs (including and especially deciding
> it's not for you).

There is no advantage; the systems are approximately equivalent in
flexibility of architecture.  You can acheive the exact same
architecture with key escrow; just escrow the keys with your backup
czar.

You shouldn't be recovering transient messages, you should be
recovering stored data.

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-----

In <199710110112.CAA06510@server.test.net>, on 10/10/97 
   at 08, Adam Back <aba@dcs.ex.ac.uk> said:

Ok Adam here is a challenge for you:

- -- Explain why Corporations do not have the right to access *their*
documents in whatever form they may be in.

- -- Failing that explain how PGP 5.5 furthers the cause of GAK and PGP
2.6.x does not when I can get my network to do the same thing in a weekend
and a couple of scripts using PGP 2.6.x.

- -- Failing that explain why there were no great outcries that PGP 2.6.x is
GAKware???

Now if you agree that Corporations *do* have a right to access their
documents but you disagree with the technical aspects of how PGP 5.5
achieves this then drop the fearmongering and spell out how you think this
can be better achieved.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBND8CqI9Co1n+aLhhAQGoJwP+P5InFFnaH5svFrdnlREW08lOlYKrLjHH
95/X669e3RK+l9Oaj0svN8DxMV53GnRj+4spb8c7UpYLmUV0ZGvf+mORog6rwYaP
65Gl+wgNTdkJefENxAr6aofTU+zwYUgklUSPfl6+y5Hn8xlwftpuRxNjs4W2muGz
VR1RYTQKQIE=
=Z81q
-----END PGP SIGNATURE-----

At 2:41 AM -0700 10/11/97, Adam Back wrote:
>
>5. The IETF process should be accepting proposed designs and deciding
>on the best ones, which PGP Inc, and the other suppliers would then go
>and implement.  As it is now, as William Allen Simpson just pointed
>out, PGP Inc is cruising ahead implementing, and deploying things
>without bothering with the OpenPGP process.

Just a quick reality check here.  Frequently implementations have proceeded
IETF standards.  That is one of the strengths of the IETF process (as
compared with e.g the CCITT.)



-------------------------------------------------------------------------
Bill Frantz       | Internal surveillance      | Periwinkle -- Consulting
(408)356-8506     | helped make the USSR the   | 16345 Englewood Ave.
frantz@netcom.com | nation it is today.        | Los Gatos, CA 95032, USA

Bill Frantz <frantz@netcom.com> writes:
> At 2:41 AM -0700 10/11/97, Adam Back wrote:
> >
> >5. The IETF process should be accepting proposed designs and deciding
> >on the best ones, which PGP Inc, and the other suppliers would then go
> >and implement.  As it is now, as William Allen Simpson just pointed
> >out, PGP Inc is cruising ahead implementing, and deploying things
> >without bothering with the OpenPGP process.
> 
> Just a quick reality check here.  Frequently implementations have proceeded
> IETF standards.  That is one of the strengths of the IETF process (as
> compared with e.g the CCITT.)

I must admit some ignorance of the IETF processes due to my only
understandings being gained from intermittent following of the IPSEC
standardisation process, and in that respect I thank you for the data
point...

However, I would defend that my understanding is, and my point was
more that proposals with trial implementations should be used as
discussion points, and as competing draft proposals rather than being
used as arguments for it being necessary to build compatibility with
just because someone has rushed off and sold copies of them, prior to
ratification of those proposals by the standardisation process.  And
that independently of the technical merits of those proposals, or
arguably even in the face of evidence that there are more secure
alternatives to these proposals.

The IETF standardisation process is supposed to make decisions based
on technical merit.  Not based on marketing clout.  Nor even based on
reputation capital, something which PGP surely has in abundance, as
transferred to it by Phil Zimmermann with his virtual net.god status.

I also take exception to PGP's Will Price's attempt at silencing
negative discussion of the security and political aspects of PGP's
GAKware, in his rhetoric on this being an inappropriate forum for
discussion of political aspects of CMR.  If Will Price thinks that we
should just lie down and accept PGP fielding inferior security GAKware
systems, and accept PGP trying to impose them on the standard, he can
think again.  Crypto politics can't help but play some part in
discussion of crypto standards.  

As Tim May pointed out in an earlier post, we gave the same roasting
to companies participating in the Key Recovery Alliance Program, and
to companies like TIS, and IBM for various GAK sell out deals.  In
fact, Netscape got worse roastings for far lesser crimes than PGP's
crimes in attempting to architect GAKware into the OpenPGP standard,
or if that fails, in PGP's death wish in attempting to commit
reputational suicide by implementing and widely deploying GAKware.

My concern specifically is that some of the less desirable aspects of
the way that PGP have implemented CMR should not be adopted into the
standard for interoperability reasons alone.  I am worrying that PGP
Inc will shortly be using this line of reasoning, for backwards
compatibility with pgp5.5 functionality for similar reasons as one
might reasonably argue for backwards compatibility with pgp2.x.

I noticed that Ian Grigg (Systemics) also expressed this point about
standards process manipulation well in his article.

Systemics has a much better track record for open development, and
openness of design decisions than PGP Inc since it's incorporation, or
before that than the pgp3.0 development team of two in beetling
themselves off in a room at Sun or wherever and taking ages to develop
software.  (No offense intended to said developers technical ability,
which I respect immensely, the error was organisational.)

Systemics is also outside of the US and for that reason better placed
to compete internationally.  PGP Inc is losing reputation capital to
Systemics and other such small companies in eroding it's support from
netizens by fielding GAKware systems.

(I have no affiliation with Systemics).

Adam

On Oct 13, 12:40pm, Adam Back wrote:
> Subject: Re: IETF policy on refusing to allow politics to weaken protocols
>
> Bill Frantz <frantz@netcom.com> writes:
> > At 2:41 AM -0700 10/11/97, Adam Back wrote:
> > >
> > >5. The IETF process should be accepting proposed designs and deciding
> > >on the best ones, which PGP Inc, and the other suppliers would then go
> > >and implement.  As it is now, as William Allen Simpson just pointed
> > >out, PGP Inc is cruising ahead implementing, and deploying things
> > >without bothering with the OpenPGP process.
> >
> > Just a quick reality check here.  Frequently implementations have proceeded
> > IETF standards.  That is one of the strengths of the IETF process (as
> > compared with e.g the CCITT.)
>

	The reality is that standards generally drag long behind the need for
new technology. In any standards org worth thier weight in salt, the group will
look at existing implementations (not trial implementations but ones that have
been in use for some time). This is called 'Prior Art'. Without prior art, it
is not easy to determine which features or schemes work and which do not.

	The problem we are running into here is that PGP Inc. is marketting
about the only prior art available for this technology. In addition, business
needs will not stand still waiting for a standard to come out in 1-2 years.
This creates a somewhat dangerous situation as Adam has pointed out (Note: I am
NOT PGP-Inc.-bashing. This is merely an outcome of what happens when a vendor
tries to take their technology and 'open' it up).

	I would be concerned if this relatively new addition were being added
to the internet-drafts currently being produced by the group. I know they have
tried to wrestle with all of the issues. I just think we need some more
'experiential' evidence that it is the correct solution. In general, standards
only describe the 'bare-minimum' that an implementation must do to be
'compliant'. There is nothing wrong with leaving certain bells-and-whistles out
of the first pass at a standard. Vendors are always free to add proprietary
features to thier product. That is where the market competition comes in. PGP
Inc. implements thier CMR feature on top of the OpenPGP standard. Another
company attacks the problem a different way and adds a different 'extension'.
In about 5 years, a new standards group updates the 'OpenPGP' standard, argues
over the different schemes and adopts the one with the best technical merit.

> I must admit some ignorance of the IETF processes due to my only
> understandings being gained from intermittent following of the IPSEC
> standardisation process, and in that respect I thank you for the data
> point...
>
> However, I would defend that my understanding is, and my point was
> more that proposals with trial implementations should be used as
> discussion points, and as competing draft proposals rather than being
> used as arguments for it being necessary to build compatibility with
> just because someone has rushed off and sold copies of them, prior to
> ratification of those proposals by the standardisation process.  And
> that independently of the technical merits of those proposals, or
> arguably even in the face of evidence that there are more secure
> alternatives to these proposals.
>
> The IETF standardisation process is supposed to make decisions based
> on technical merit.  Not based on marketing clout.  Nor even based on
> reputation capital, something which PGP surely has in abundance, as
> transferred to it by Phil Zimmermann with his virtual net.god status.
>

	To Adam and others, I would say, work like mad to develop pgp-like
implementations (based on available documents of 2.6 or 5.0 formats) and add in
alternative mechanisms to do the same function (as per Adam's discussion of the
3-key system : signature, transit-encryption, and storage). To others in this
group, I would say keep it simple...especially on a first pass at a standard.

	I have noticed an interesting phenomena in a number of IETF groups. One
group develops a standard that is huge and nearly unimplementable. Another
group comes along and says "We can do it simpler than that". They start
designing and writing documents, run into the same issues the first group did
and eventually start solving them the same way leading to another large
unimplementable standard. Witness: X509 -> PKIX -> SPKI -> OpenPGP. OpenPGP was
supposed to be different because it had a large established user base. Then,
all of a sudden, everyone is arguing over the same issues as the first three
groups...global naming problems, certificate flexibility, key recovery, policy
enforcement...


>...
>
> Adam
>-- End of excerpt from Adam Back

--
Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
mione@nbcs-ns.rutgers.edu                 W3: http://www-ns.rutgers.edu/~mione/
PGP Fingerprint : E2 25 2C CD 28 73 3C 5B  0B 91 8A 4E 22 BA FA 9F
Editorial Advisor for Digital Systems Report   ***** Important: John 17:3 *****

Williams title being: `Why Adam Back keeps politicizing technical
issues'

I would like to comment that the reason politics are arising in
discussion of communications security issues is a natural consequence
of the fact that it's a damn political topic.  Ignore the politics and
you may implement a mandatory GAK system, or at least a GAK compliant
one.  Actually I also argue that there are technical security reasons
why the CMR approach offers weaker security.  I've gone over these
reasons already in this thread, so I won't repeat them.

IETF I think has a stated policy (at least this is the case for the
IPSEC standardisation discussions I have been intermittently
following) to not allow politics to weaken it's protocols and
algorithm choices.  PGP Inc introducing GAK compliance at the cost of
security is a clear case where this policy should be kicking in.

William Geiger <whgiii@invweb.net> writes:
> In <199710110112.CAA06510@server.test.net>, on 10/10/97 
>    at 08, Adam Back <aba@dcs.ex.ac.uk> said:
> 
> Ok Adam here is a challenge for you:
> 
> -- Explain why Corporations do not have the right to access *their*
> documents in whatever form they may be in.

You will note that I didn't say this.  In fact I spent half of last
night detailing alternate less GAK friendly ways for PGP Inc to
provide corporate message snooping, the very functionality which is
the motivation for their CMR.  Perhas you were not reading.

What I did say, and it appears to be a meme which didn't stick with
you as I'm sure I raised this in a previous post replying to you is:

Key functionality should be separated: in the same way that you have
separate signature and encryption keys, because of the differences
between appropriate backup policies, security implications, and
life-times, you should have separate email receipt encryption keys and
storage keys.  Transient email receipt keys should not be escrowed,
but for security reasons perhaps should even be securely wiped after
use.

As an additional security bonus: storage keys can be symmetric (where
they are for your own use) which avoids the more less certain and
more quickly sliding target of public key lengths.

I will guess that the reason this meme doesn't suit you is that it's
not the way your OS/2 pgp mail client plugins work, and therefore not
yet part of your mindset.  So perhaps it's not the status quo for your
and some other apps to use separate storage keys for archiving and
receiving encrypted mail; but there are clear security advantages to
doing it this way.

> -- Failing that explain how PGP 5.5 furthers the cause of GAK and
> PGP 2.6.x does not when I can get my network to do the same thing in
> a weekend and a couple of scripts using PGP 2.6.x.

There is are some clear differences: 

1. You can visually see multiple crypto recipients in most PGP enabled
MUAs, as they usually correspond to email CC fields.

2. PGP Inc is attempting to weakly enforce this special purpose
message snooping recipient embedded into the key certificate.

3. PGP Inc even has (less clear on details here) I think from Jon
Callas first post: pgp 5.5 client which enforces inclusion on sent
mail as controlled by a remote company message snooping czar &
enforced inclusion on received mail by the SMTP policy enforcer.

4. There is a difference between what you or I may knock up in
scripts, and what PGP Inc attempts to persuade the IETF include as
conformancy requirements, and what PGP does implement ahead of the
standardisation process.

5. The IETF process should be accepting proposed designs and deciding
on the best ones, which PGP Inc, and the other suppliers would then go
and implement.  As it is now, as William Allen Simpson just pointed
out, PGP Inc is cruising ahead implementing, and deploying things
without bothering with the OpenPGP process.


Your point about using normal multiple recipient to provide snooping
is a good one.  It would be a much less GAK friendly solution for PGP
Inc to encrypt to a second recipient without any message snooping
flags encoded into the PGP standard.  That way email clients won't
reply to this second recipient, and users won't have an automated
snooping feature embeded in their PGP for personal privacy, or
competitor re-write of the same compliant OpenPGP app, for someone
else's benefit (recipient company, or government).

To snoop received email, it provides similar amounts of snooping
enforcement if the recipient's PGP 5.5 for business client when the
user decrypts re-encrypts to a storage key that the company does have
escrowed, or where there is a second crypto recipient in the storage.
(Talking mail folders here.)

> -- Failing that explain why there were no great outcries that PGP
> 2.6.x is GAKware???

See above.  The objectionable new feature in PGP5.5 (and apparently
pgp5.0 too without our realisation to this point) is enforcement in
senders clients to support message snooping, in a form which can
easily be used to interoperate with GAK, and thereby prepares
everyones OpenPGP compliant email client to enforce GAK against them.

At the very most the maximum acknowledgement that it seems reasonable
to me for OpenPGP to have of the GAK compliancy feature is to flag
this key and allow the user to send to this recipient at their option.

In addition I am arguing that PGP Inc are doing the Internet community
a major disservice by choosing to implement message snooping in this
way.  Much better, less controversial, and more secure to do the
snooping in the pgp5.5 client after decryption.  That doesn't need to
involve changes to the message spec.  PGP Inc's SMTP policy enforcer
could then be changed in functionality to stripping off the company
snooping crypto recipient field before it leaves the LAN for security
reasons.

> Now if you agree that Corporations *do* have a right to access their
> documents but you disagree with the technical aspects of how PGP 5.5
> achieves this then drop the fearmongering and spell out how you
> think this can be better achieved.

I already did this half a dozen times.  I'm not fear mongering, I'm
attempting to point out the dangers of including GAK compliancy.  And
to point out the opportunity to make PGP non-GAK compliant, and
thereby frustrate mandatory GAK proponents.  PGP is trying to discard
this opportunity, when there are clear alternate methods which can be
argued are more secure, better meet PGP's Jon Callas's stated user
requirements, don't support GAK, and don't require modifications to
the standard.

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-----

At 02:12 AM 10/11/97 +0100, Adam Back wrote:

>You should have 3 types of key:
>
>1. signature keys
>2. transient encryption keys
>3. storage keys

>
>The signature keys you never escrow.  You certify.  If something goes
>wrong you re-issue, release revocation cert, and re-certificate.
>
>The transient encryption keys are for communications, you delete them
>immediately after use.  Yes I'm talking forward secrecy here.  If you
>don't like forward secrecy, well at least don't escrow the encryption
>keys.

Huh?   Okay, PGP uses IDEA for transit keys.  These are encrypted to two 
different PGP public keys.   

These are only used once.  (Well, you make that assumption, but with even a 
decent PRNG it's a reasonably safe assumption)

The signature keys (in the proposed method) are the PGP keys (either RSA or 
DH, it's not important) are the personal keypairs of each person.  The 
company doesn't keep a copy of these.  They can sign with this in an 
unforgable manner.  (Well, in practice I doubt that's true, because I've seen 
very few places that have even mild local-workstation security, but that's 
besides the point)

Is there a problem here?

- From the description Jon gave of the system, you can designate anyone as
the 
other key-id to encrypt to in your signature block.  (Or whatever that part 
of the key is called).  The guy in the next cube, your boss, one company-wide 
key, etc.

So yes, in theory this could be used to implement GAK.  Supposedly in the 
version of PGP in use it's trivial to remove this extra recipient from the 
list of encryption keys.  It's not even needed if you don't have that key on 
your ring.  (From what Jon said)

When you compalin about use of storage keys/communication keys your clouding 
the issue.

The storage keys can be (and probably are in some cases) simply pgp encrypted 
files, as if they were in transit.  I tend to encrypt some files on my hard 
drive with pgp, by encrypting to myself and signing  so that onyl I can 
decrypt them, and I've got record that I did create the archive.  I can see 
this being done in a company to simplify shared storage usage without 
security problems.  Using the multiple recipient option your recovery key-id 
can be used to decrypt these files.  Of course, if they're modified, they 
can't be resigned, so you'd know, but...

This is a *simple* solution that eliminates problems with encrypting hard 
drives, etc. 

Where is the problem with this system?  This is software that (according to 
Jon's claim) at least one company has decided they need for their security, 
and it keeps the number of pass phrases that employees need to memorize at 
one - their PGP key.

>Storage keys you make damn sure you can recover.  You escrow these for
>real.  Company safe sounds about right.  Secret splitting could be
>nice also.

Why not just encrypt it to yourself with PGP?  Isn't that simpler?  Add a 
recipient of the recovery id.  Boss, coworker, person's key in another 
division, whatever.  Everybody gets different storage keys.  No need to worry 
about accidently compromising one of the storage keys (IDEA symmetric keys, 
of course).  You then just need to keep the secret  halfs of the public keys 
secure.  Not a big deal if you have the rest of the system working.

>You shouldn't be recovering transient messages, you should be
>recovering stored data.

What the hell is the difference?  Speed of recovery?

Give an example of the difference between what he's doing and what you would 
propose. Otherwise you're just rejecting this system blindly.
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBND/agDc3ytqHnNyNAQExygP/fjl70OenYyTLc86OgFNZf5fkM+b3RUxw
WFsYNme/thDSdsnmfTCTTqE63b3ZRoj/mR0jjb4aloXw83TxWuEY9j9sQql8yTBt
SoRQAxPnP33bWlCTbQrOBPFvMw2lyfCrL307mXnfBpnW3h0cngRxjfu7IBBBPzVF
/5TzMK47WBY=
=RLoK
-----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
-----------------------------------------------------------------------

Ryan Anderson <randerso@ece.eng.wayne.edu> writes on cpunks:
> Adam Back <aba@dcs.ex.ac.uk> writes:
> >You should have 3 types of key:
> >
> >1. signature keys
> >2. transient encryption keys
> >3. storage keys
> >
> >The transient encryption keys are for communications, you delete them
> >immediately after use.  Yes I'm talking forward secrecy here.  If you
> >don't like forward secrecy, well at least don't escrow the encryption
> >keys.
> 
> Huh?   Okay, PGP uses IDEA for transit keys.  These are encrypted to two 
> different PGP public keys. [...]  These are only used once.

The security principle I am referring to is that by doing as PGP
currently does, and using encryption keys in place of separate
communications and storage keys you are exposing your past traffic to
undue risk.

I am not at all referring to symmetric keys, because the fact that
they are randomly generated and used once doesn't protect them from
recovery via the compromise of your long encryption key and your
attackers copy of your encrypted communications.  The reason for
randomly generating IDEA session keys is a separate one.

The argument for having separate storage and communication keys is a
similar one to the now accepted argument that it is a good idea to
have separate signature and encryption keys.  The obvious advantage of
separating signature keys from encryption keys (introduced in pgp5) is
that if you escrow keys you don't want to escrow signature keys as all
this enables is forgery.

> The signature keys (in the proposed method) are the PGP keys (either
> RSA or DH, it's not important) are the personal keypairs of each
> person.  The company doesn't keep a copy of these.  They can sign
> with this in an unforgable manner.
> 
> Is there a problem here?

No.  I wasn't discussing signature keys.

> - From the description Jon gave of the system, you can designate
> anyone as the other key-id to encrypt to in your signature block.
> (Or whatever that part of the key is called).  The guy in the next
> cube, your boss, one company-wide key, etc.

Yes.  That's half of the story.  The other half of the story is that
PGP went ahead and implemented a SMTP snoopware policy enforcer which
could just as easily be used to enforce GAK.

> So yes, in theory this could be used to implement GAK.  Supposedly
> in the version of PGP in use it's trivial to remove this extra
> recipient from the list of encryption keys.  

I'm not sure that the fact that the pgp5.0 client doesn't attempt to
force you to use the GAK compliancy key adds much to my comfort level
that the whole thing won't end up being used for mandatory GAK.  My
scepticism is derived from the fact that the enforcement of the GAK
compliancy key is provided by another marvelous PGP Inc big brother
innovation: the SMTP snoopware/GAK compliancy policy enforcement app.

The argument doesn't really become apparent until you consider the
effects of lots of people (say 80% of companies) using PGP's GAK
compliancy enforcement.  A few more thin edge of the wedge moves on
the part of the USG GAK proponents (eg deputising service providers as
GAK compliancy enforcers, something which has already been discussed
in the past with the Clipper series), and you will suddenly be unable
to exchange mail with anyone without using GAK.  Sure you have a
"choice", you can send email to people that will bounce 100% of the
time, whoever you send to due to lack of GAK compliance field.
(Except for perhaps a few die hard cypherpunks).

> It's not even needed if you don't have that key on your ring.  (From
> what Jon said)

I'm not sure what you mean here.

> When you compalin about use of storage keys/communication keys your
> clouding the issue.

It might appear complex, but actually adding the distinction between
communications and storage keys greatly simplifies things, and it
allows you to make more appropriate security decisions about key life
times, and escrow.  It also allows you to implement the message
snooping function in a more secure way, and with less big brotherish
overtones.

Using separate storage keys allows you to:

- escrow storage keys within your company without including GAKware
  compliancy

- discard communications keys often (by giving them short life-spans)
  which greatly enhances your security

> The storage keys can be (and probably are in some cases) simply pgp
> encrypted files, as if they were in transit.  

Storage keys could be symmetric keys if they are for your own use
only, or you could escrow them if you want to share access, or your
company wants the extra assurance of data availability that storage
key escrow brings.  There might be some security advantages to using
symmetric keys even.  (Public key sizes are a faster sliding and more
uncertain target than symmetric key sizes.

> I tend to encrypt some files on my hard drive with pgp, by
> encrypting to myself and signing so that onyl I can decrypt them,
> and I've got record that I did create the archive.

You can sign and encrypt with symmetric keys also. "pgp -cs."  Quite a
useful combination.

I used to do the opposite of what you do... I used to use pgp -cs,
because I explicitly didn't want the public key baggage, and danger
that 1024 bit keys might be readable in 10-20 years, the then maximum
key size.

> I can see this being done in a company to simplify shared storage
> usage without security problems.  Using the multiple recipient
> option your recovery key-id can be used to decrypt these files.  Of
> course, if they're modified, they can't be resigned, so you'd know,
> but...

It's probably simpler to just escrow storage keys.  That is just give
management a copy to put in the fire proof safe.  Or secret split or
whatever.

You could use multiple crypto recipient if you wanted to -- it's
basically just another way of acheiving the same thing.

There is one (quite practical) reason, however, to use symmetric
storage keys.  Speed.  If you're encrypting lots of files (perhaps
using an encrypted parition driver such as Peter Gutmann's SFS), you
won't have time to encrypt to public keys, never mind multiple public
keys.

If the company keeps it's employee's storage keys in escrow, the fact
that you're using a symmetric key works fine.

> This is a *simple* solution that eliminates problems with encrypting
> hard drives, etc.

I don't see that it's any more difficult to do as I outline above,
which is better security practice in any case.

> Where is the problem with this system?  This is software that
> (according to Jon's claim) at least one company has decided they
> need for their security, and it keeps the number of pass phrases
> that employees need to memorize at one - their PGP key.

Don't confuse key functionality with user ergonomics.  PGP or other
vendors could easily implement a unified interface to a secured
private key database containing all of your persistent private keys.
You need only have one key.  Or perhaps no keys -- in a secured
environment, or with keys stored on smart cards.

> >Storage keys you make damn sure you can recover.  You escrow these for
> >real.  Company safe sounds about right.  Secret splitting could be
> >nice also.
> 
> Why not just encrypt it to yourself with PGP?  Isn't that simpler?
> Add a recipient of the recovery id.  Boss, coworker, person's key in
> another division, whatever.  Everybody gets different storage keys.
> No need to worry about accidently compromising one of the storage
> keys (IDEA symmetric keys, of course).  You then just need to keep
> the secret halfs of the public keys secure.  Not a big deal if you
> have the rest of the system working.

I'm not really fussy beyond the fact that it will be less efficient in
space (extra public key packets would be significant for a disk block
level partition encrypter), and the performance issues with using
public key crypto to encrypt lots of files to multiple people. 

> >You shouldn't be recovering transient messages, you should be
> >recovering stored data.
> 
> What the hell is the difference?  Speed of recovery?

Nope speed of recovery is not the issue.

> Give an example of the difference between what he's doing and what
> you would propose. Otherwise you're just rejecting this system
> blindly.

I'm sure I've given these reasons earlier in the thread, but I'll
summarise them again:

1. It is more secure to use short lived communications keys because
communications keys are more sensitive than storage keys.  This is
because with communications your attacker has copies of your
ciphertext as you're sending it over an insecure open communications
medium.  Your storage data is on your hard disk, possibly in a secured
environment.

2. People shouldn't be able to recover the data from communications
because for security reasons it should be encrypted with transient
communication keys.  You are purposelly securely wiping the key after
some period.  Keeping extra doors into the communication weakensn this
protection.

3. given that secured communications are now defined as transient in
nature, for security reaons: the natural way to archive such
communicated data is to re-encrypt it for a storage key.

4. people don't really want access after the fact to their transient
communications, they want access to their archived email.

5. you can still implement corporate snooping, and I acknowledge that
businesses have a right to do this (though personally I may not choose
to work for a company which does this).  But you can implement message
snooping, by implementing key escrow of the storage key used to secure
your email archives.  To enforce this to the extent that you can, you
build in automatic archiving in a way which is hard to defeat in the
mail client to decrypt communication with the comms key, and then
re-encrypt with the escrowed storage key.

6. Given the marked difference in life time, security requirements,
and data availability requirements between stored data and transient
communications keys is it any wonder that you can achieve a more
flexible, more secure system by separating functionality of your keys
-- it really is a very similar argument as to the argument over why
you should have separate storage and communications keys.

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-----

At 11:31 PM 10/11/97 +0100, Adam Back wrote:

>to exchange mail with anyone without using GAK.  Sure you have a
>"choice", you can send email to people that will bounce 100% of the
>time, whoever you send to due to lack of GAK compliance field.
>(Except for perhaps a few die hard cypherpunks).

My reading of Jon's post was that the SMTP policy enforcer only worked for 
outgoing messages.  Perhaps that's wrong, but that needs to be double-
checked.  See below as well...

>> It's not even needed if you don't have that key on your ring.  (From
>> what Jon said)
>
>I'm not sure what you mean here.

The snooping key.  If it doesn't exist on *my* keyring.  (Say I have your 
key, but not the key designate as your snooping key...)  [BTW: Forgive the 
English, I'm tired and speaking in choppy sentences]

If I have your key, but not the other key that I'm also supposed to encrypt 
to, PGP (whichever versions, I'm not entirely sure how the feature set breaks 
down, but I believe this applies to all versions of 5.x)  will not even 
mention that there was another key it would've have offered to encrypt to.

>> When you compalin about use of storage keys/communication keys your
>> clouding the issue.
>
>It might appear complex, but actually adding the distinction between
>communications and storage keys greatly simplifies things, and it
>allows you to make more appropriate security decisions about key life
>times, and escrow.  It also allows you to implement the message
>snooping function in a more secure way, and with less big brotherish
>overtones.
>
>Using separate storage keys allows you to:
>
>- escrow storage keys within your company without including GAKware
>  compliancy
>
>- discard communications keys often (by giving them short life-spans)
>  which greatly enhances your security

Greatly complicating the "web of trust" method, but..  You can only chain 
signatures so far before you run into problems, and getting people to 
continuosly recertify could be a major pain, but I can see the point you are 
making.   It got clearer.


>> The storage keys can be (and probably are in some cases) simply pgp
>> encrypted files, as if they were in transit.  
>
>Storage keys could be symmetric keys if they are for your own use
>only, or you could escrow them if you want to share access, or your
>company wants the extra assurance of data availability that storage
>key escrow brings.  There might be some security advantages to using
>symmetric keys even.  (Public key sizes are a faster sliding and more
>uncertain target than symmetric key sizes.

Well, at least with RSA keys, I believe the memory requirements to handle 
current factoring algorithms are quite untenable for 2048 bit keys.  I think 
768 is out of the range of current systems.  I think this came up on the RC5 
(Bovine) mailing list, and the figures for the required server was something 
absolutely ridiculous.  To distribute the job using the more efficient 
algorithm required machines with 128 meg of ram, but the slower one was a bit 
more doable.

In short, I don't think 2048 RSA keys are reasonable target in the forseeable 
future.  [Remember, Moore's law is only applicable for another 12 years or 
so.  Then quantum mechanics starts to be a serious problems, and electrons 
start switching channels in the chips.]

But this is a bit of a wandering topic now.  Let me continue...

>You can sign and encrypt with symmetric keys also. "pgp -cs."  Quite a
>useful combination.

Hmm.. I must've missed that.  

>I used to do the opposite of what you do... I used to use pgp -cs,
>because I explicitly didn't want the public key baggage, and danger
>that 1024 bit keys might be readable in 10-20 years, the then maximum
>key size.

Well, I wasn't really encrypting anything I really cared about.  It was 
backups of autoexec.bats and config.syss, I just wanted another copy that I 
*knew* when it was made, it wouldn't get overwritten, and it wouldn't get 
modified without me knowing.   And I needed something to use PGP for, so...

In all honesty, the public key baggage is 512 bytes ( I think, possibly bits. 
 I've forgotten now )  Quite insignificant if you're dealing with CAD 
drawings.  The added benefit of reducing passphrase uses is quite significant 
(with current PGP versions, the database of keys is a better idea actually).  
Possibly more portable across a range of users as well.

>> I can see this being done in a company to simplify shared storage
>> usage without security problems.  Using the multiple recipient
>> option your recovery key-id can be used to decrypt these files.  Of
>> course, if they're modified, they can't be resigned, so you'd know,
>> but...
>
>It's probably simpler to just escrow storage keys.  That is just give
>management a copy to put in the fire proof safe.  Or secret split or
>whatever.

I was actually thinking something along the lines of creating a file - 
encrypting it to your whole workgroup, and leaving it on a server.  Now you 
have the advantage of not having any security problems even if the server is 
compromised [without workstation compromise, of course], and all the 
important people can access it.  Of course, the last person to modify it 
resigns it, and it gets dropped into your RCS system.

you get the added advantage of being able to rotate your keys here as well, 
so even if one key is compromised, and the server is compromised, you don't 
lose the whole system.  Identical argument as for communications keys.

>You could use multiple crypto recipient if you wanted to -- it's
>basically just another way of acheiving the same thing.
>
>There is one (quite practical) reason, however, to use symmetric
>storage keys.  Speed.  If you're encrypting lots of files (perhaps
>using an encrypted parition driver such as Peter Gutmann's SFS), you
>won't have time to encrypt to public keys, never mind multiple public
>keys.

That's a different problem.  For that you're [in this ultra-theoretical 
world] probably going to want something along the lines of this:  Symmetric 
encryption for speed on the partition, and that key stored with several 
recipients in the same place as the Secure Partition Driver (SPD).  (This 
falls in the, "If you're going to build a system, make sure you think of 
everythign you want and make sure it fits in the framework somewhere" method)

>If the company keeps it's employee's storage keys in escrow, the fact
>that you're using a symmetric key works fine.

I'm not sure you need to escrow anything, as long as there is a way to share 
things among certain groups of people.  Jon's ideas of non-hierarchical 
recovery systems seem a lot more secure anyway, especially with the rest of 
this thread.

Oh - for the situation with Andy Grove (Intel CEO) describe earlier on this 
thread - let me give this suggestion:
	AG's key w/extra encryptions to CFO (or Pres. of Board, or someone else with 
significant influence and a close working relationship.  Backup for problems 
with intransit e-mail.)
	Similar setups for everyone else in the company.  Probably the top-level 
executives all have AG as the backup.  This elminates snooping entirely in 
the company, on the top level execs.  This partially hierarchical method 
wouldn't be horrible, and limits snooping to the level above you, or to 
peers, depending on setup.

>> Give an example of the difference between what he's doing and what
>> you would propose. Otherwise you're just rejecting this system
>> blindly.
>
>I'm sure I've given these reasons earlier in the thread, but I'll
>summarise them again:

Yeah, you covered them fairly well, and cleared up the issues where I 
honestly thought it was a fear-mongering problem.  I still don't completely 
agree with you, but we've clarified the problem areas.  Thanks.  (Too many 
wars get *way* too religous on the net.  Let's try and avoid that here, ok?)


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

iQCVAwUBNECnJDc3ytqHnNyNAQGzAAP/bnYQQKdBnTY5HKc2fNlMYefYwZhdNXZo
aYNDhmybGM8756SIp0uuKaaf1t2f22is1/XdxaN2aHO+5qyHSc/EwgV4tWeQ1SXt
zBhMBM4phbTFSHl8FJUdRI9qcMxfoIfdoyJ5/CuYo83gJBwsrov6NZQylAlRR66K
VUAohcY/BxM=
=t0mO
-----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
-----------------------------------------------------------------------

Ryan Anderson <randerso@ece.eng.wayne.edu> writes:
> At 11:31 PM 10/11/97 +0100, Adam Back wrote:
> 
> >to exchange mail with anyone without using GAK.  Sure you have a
> >"choice", you can send email to people that will bounce 100% of the
> >time, whoever you send to due to lack of GAK compliance field.
> >(Except for perhaps a few die hard cypherpunks).
> 
> My reading of Jon's post was that the SMTP policy enforcer only worked for 
> outgoing messages.  Perhaps that's wrong, but that needs to be double-
> checked.  See below as well...

I'm fairly sure this is not the case.  The reason I think that this is
not the case is because Jon described two flags which go in the GAK
compliancy sub-packet:

Flag1:  this flag is an advisory note to the person who obtains a
	public key which has the GAK compliancy self signature
	sub-packet; it tells the person about to use the key that the
	company the person who owns this public key works for would
	like it if you would "please" encrypt to the contained
	corporate snoopware master key.

Flag2:	this flag is the same as the flag1 above plus it is a big
	brotherish/little brotherish warning that if you _don't_
	encrypt to the GAK compliancy key also, that the recipient
	will not receive the message.

I understood the reason that the recipient will not receive the
message when you don't honour keys with flag2 to be that the SMTP
policy enforcer would either bounce the message, or eat it, or send it
to the company snoopware czar to who can take due note in his employee
dossier collection that this employee is receiving email from
suspicious cypherpunk persons who don't believe in snoopware.

The above functionality is the reason I'm arguing that PGP's method of
implementing corporate snoopware is GAK compliant: clearly the whole
system is ready tailored for GAK.  The only thing left to do is plug
in the governemnts key in the GAK compliancy field, and for the
government to mandate that companies, and deputised ISPs use the
software and the GAK master key.

If/when this GAK compliancy gets used as the architecture for real
live mandatory GAK, the SMTP policy enforcer may be set up to narc out
the suspicious person who doesn't believe in GAK to the Feds/NSA, and
they will then come and lock you up if they can trace your SMTP From
field to you.

This will make a mockery out remailers, because the remailer chain
will also be forced to have the GAK master key in it as enforced by
deputised ISPs running PGP's SMTP policy enforcers with GAK keys
installed as the GAK master key. 

> >> It's not even needed if you don't have that key on your ring.  (From
> >> what Jon said)
> >
> >I'm not sure what you mean here.
> 
> The snooping key.  If it doesn't exist on *my* keyring.  (Say I have your 
> key, but not the key designate as your snooping key...)  [BTW: Forgive the 
> English, I'm tired and speaking in choppy sentences]

Oh, I see what you mean.  The reason I didn't understand is that this
is not how I thought it works.  I think the key is provided right
there in the GAK compliancy field in an inseparable way.  (I could be
wrong on this, but this is the way I read Jon's message).

Even if have misunderstood the way that this key is bundled, it
doesn't really alter the fact that by "choosing" not to encrypt to
messages with the flag2 flag you will know that this is a waste of
time, because your message will not get past the SMTP policy enforcer.
So purposely stripping the key from your key ring, or separating the
key pair when someone sends you them together would just be another
way of exercising the choice PGP is claiming you have in "choosing" to
have your message bounced back at you.  A fairly meaningless "choice".

I would be interested to have this point about the way GAK compliancy
key is bound/bundled with the GAK compliancy sub-packet clarified by a
PGPer, or someone with more understanding of the draft docs, if this
much information is available yet.

> If I have your key, but not the other key that I'm also supposed to
> encrypt to, PGP (whichever versions, I'm not entirely sure how the
> feature set breaks down, but I believe this applies to all versions
> of 5.x) will not even mention that there was another key it would've
> have offered to encrypt to.

I don't think this is so because that would invalidate the semantics
of the flag1 and flag2 flags, which are what instructs PGP to warn you
of this requirement for this key.  The flag is an attribute of the key
itself, though I do suppose you might be able to strip off the
attribute in much the same way as you can remove signatures from keys
with pgp -krs.

> >Using separate storage keys allows you to:
> >
> >- escrow storage keys within your company without including GAKware
> >  compliancy
> >
> >- discard communications keys often (by giving them short life-spans)
> >  which greatly enhances your security
> 
> Greatly complicating the "web of trust" method, but..  

I don't think it complicates web of trust.  The only certification you
need of communications keys is for you to sign them with your
signature key.  Your signature key semantics, and the web of trust is
unchanged.

> You can only chain signatures so far before you run into problems,
> and getting people to continuosly recertify could be a major pain,

It will be automatic .. you won't notice because all the OpenPGP
compliant application which supports this proposed (strongly
encouraged MAY, please!) feature will do when it creates a new
communications key is to sign the communications key with your
signature key.  It won't involve third parties re-issuing
certificates.

It is the same way that certification and WoT interacts with
potentially shorter life-span dual use encryption keys at the moment.
The WoT certificates go on your longer life signature key, and it is
you who signs your encryption key.  Same argument, though now applied
to encryption keys marked as "communications only".

> >There might be some security advantages to using
> >symmetric keys even.  (Public key sizes are a faster sliding and more
> >uncertain target than symmetric key sizes.
> 
> Well, at least with RSA keys, I believe the memory requirements to
> handle current factoring algorithms are quite untenable for 2048 bit
> keys.  I think 768 is out of the range of current systems.

512 bit I think is reckoned to be feasible for an academic crack of
similar scale to the recent RSA challenge DES break.  The memory for
the final matrix crunching phase might be the only arguable point.

However, this doesn't really give me 20 years worth of assurance
because, well Rivest and friends encrypted the message "squeamish
ossifrage" back in 1977 or thereabouts, firm in the belief that it
would not be broken for 1000s of years.  Factoring advances have meant
that that ~380 bit keys (squeamish ossifrage was RSA129 digits
decimal) is now relatively easy.  Paul Leyland and friends broke a 384
bit blacknet key as a private attack without massive internet
collaboration.

I'm not sure anyones promising, or has any mathematical proof that new
factoring algorithms won't provide similar factoring speedups.  How
many years are 1024 bit RSA keys good for?  All you can use as
estimators is the current factoring algorithms.  I'm not sure how
certain these estimates are for long term purposes.

In contrast if there is nothin wrong with 3DES nor IDEA, the key space
protects you, modulo Moore's law which is easier to predict.  (Also
modulo quantum computing break-throughs, in both cases, erk!)

> I think this came up on the RC5 (Bovine) mailing list, and the
> figures for the required server was something absolutely ridiculous.
> To distribute the job using the more efficient algorithm required
> machines with 128 meg of ram, but the slower one was a bit more
> doable.

Yes.  But memory on workstations is increasing in leaps and bounds.
It is very common now for personal PCs and even laptops to have 32Meg.
A few years ago we were living below the 640k barrier.  Leave it a few
years, and people will have the required memory levels.  A few more
years on from that people will be grizzling about living below the 4Gb
barrier (restriction from using 32 bit addresses).

Anyway, one of the factoring gurus may come up with another novel
implementation or algorithm tweak to tune down memory requirements.
Or a newly discovered faster factoring alorgithm may have huge memory
advantages over current alogirthms.

> In short, I don't think 2048 RSA keys are reasonable target in the
> forseeable future.  [Remember, Moore's law is only applicable for
> another 12 years or so.  Then quantum mechanics starts to be a
> serious problems, and electrons start switching channels in the
> chips.]

The future is uncertain.  But it is marginally less uncertain for
well tried and tested symmetric keys ciphers.

> But this is a bit of a wandering topic now.  Let me continue...
> 
> >You can sign and encrypt with symmetric keys also. "pgp -cs."  Quite a
> >useful combination.
> 
> Hmm.. I must've missed that.  

Don't think it says it anywhere, but you can combine flags in lots of
logical ways which aren't documented as such, and most of which work
as you might reasonaly extrapoloate them to.  There are single letter
flags for most letters of the alphabet, the full number of
combinations must be quite large.  Quite a few of them mean
*something*.  Some of them are even phonetically pleasing: -feast etc :-)

> Well, I wasn't really encrypting anything I really cared about.  It
> was backups of autoexec.bats and config.syss, I just wanted another
> copy that I *knew* when it was made, it wouldn't get overwritten,
> and it wouldn't get modified without me knowing.  And I needed
> something to use PGP for, so...

Signature only might've been enough for backups of stuff in plaintext
on the disk like autoexecs.

> In all honesty, the public key baggage is 512 bytes ( I think,
> possibly bits.  I've forgotten now ) Quite insignificant if you're
> dealing with CAD drawings.  

Sure.  But you were also talking about autoexecs and other small files
where it could get significant.  The significant lose howver is the
performance -- say you recursively encrypt all the files in a
directory, each to 2 or 3 multiple crypto recipients.  It'll crawl.

> >It's probably simpler to just escrow storage keys.  That is just give
> >management a copy to put in the fire proof safe.  Or secret split or
> >whatever.
> 
> I was actually thinking something along the lines of creating a file
> - encrypting it to your whole workgroup, and leaving it on a server.
> Now you have the advantage of not having any security problems even
> if the server is compromised [without workstation compromise, of
> course], and all the important people can access it.  Of course, the
> last person to modify it resigns it, and it gets dropped into your
> RCS system.

I see.  Sounds reasonable.  You should be able to achieve that with
the current dual use PGP keys, or with the new "storage only" keys via
crypto recipients.

If your document is on the Internet, on the web perhaps, you'd need to
be aware of the reduced security in using long term storage keys as
opposed to short term communications keys, but other than that I can't
see a problem.

The point is that where you have a directional communication, you
should treat those keys as sensitive.  Where it is not a directional
communication, you can't, so you lose that extra security; for
applications where this is acceptable, I wouldn't argue for
restricting your ability to do it.

> you get the added advantage of being able to rotate your keys here
> as well, so even if one key is compromised, and the server is
> compromised, you don't lose the whole system.  Identical argument as
> for communications keys.

I think I understand what you're saying for shared storage keys.  But
I don't think it's an identical argument at all for communications
keys.

If you define communications keys as short lived highly sensitive
keys, as perhaps in SSL, or SSH (both of which use some forms of
forward secrecy), you can't retain the ability to recover the message
after the fact for security reasons.

However I posit that people don't really want access to the plaintext
stored inside encrypted communications for their own purposes for the
simple reason that they don't have a sendmail log including all the
message bodies.

Together with the security advantages of not being able to decrypt
communications traffic yourself after the fact, this argues that
people who do want full email archives for company legal or snooping
purposes, or just folder for their own use (I know I keep lots of
email in folders) can either store in the clear, or store encrypted
with a storage key, or store with an escrowed storage key, or store
encrypted to multiple storage keys as crypto-recipients as you
suggest.

> >There is one (quite practical) reason, however, to use symmetric
> >storage keys.  Speed.  If you're encrypting lots of files (perhaps
> >using an encrypted parition driver such as Peter Gutmann's SFS), you
> >won't have time to encrypt to public keys, never mind multiple public
> >keys.
> 
> That's a different problem.  For that you're [in this ultra-theoretical 
> world] 

I don't think it's that theoretical.  Don't PGP have such an encrypted
disk driver for the MAC?  I think this is the way forward for simpler
storage encryption: encrypt the lot.  Saves arguments about forgetting
to encrypt stuff, or forgetting you did decrypt and leaving plaintext
copies around in /tmp or whever as well.

> probably going to want something along the lines of this: Symmetric
> encryption for speed on the partition, and that key stored with
> several recipients in the same place as the Secure Partition Driver
> (SPD).

Your suggestion is one reasonable way of acheiving this.  You can also
acheive the same flexibility with an extra indirection with symmetric
storage keys (optionally held in escrow).  In fact I think this is
what later versions of Peter Gutmann's SFS do.  The reason he uses for
this is that it allows you to change your passphrase without
re-encrypting the whole disk, because the _actual_ disk encryption key
is encrypted itself with the hash of your passphrase, rather than
using the hash of the passphrase directly as the key.

> (This falls in the, "If you're going to build a system, make sure
> you think of everythign you want and make sure it fits in the
> framework somewhere" method)

Well I agree, I think it's reasonable for us to consider the major
uses, plaintext recovery demands, and security aspects of the
different types of uses for keys: transient communication keys,
storage keys, and signature keys.

> >If the company keeps it's employee's storage keys in escrow, the fact
> >that you're using a symmetric key works fine.
> 
> I'm not sure you need to escrow anything, as long as there is a way
> to share things among certain groups of people.  Jon's ideas of
> non-hierarchical recovery systems seem a lot more secure anyway,
> especially with the rest of this thread.

It doesn't really matter one way or the other.  You can build
non-hierarchical recovery systems with either method.  (You can escrow
storage keys in your department, just as easily as add second crypto
recipient within your department.  I think the security is basically
the same for escrow or multiple recipient when we're talking about
storage.

The same security equivalence argument applies if you accept the
premise that you need access to transient communications.  I don't
accept this premise.  This premise is a fallacy promulgated by the
likes of Freeh.  If you don't escrow communications keys at all you
gain extra security for the same reason that it is less secure
actually to escrow storage keys, or use multiple recipient as another
way to achieve storage key escrow than to not use storage key escrow.
However with storage you live with this because a) data availibility
is important, and b) the risk isn't as great with storage because your
attacker has to breach physical security to obtain the data from your
disks and tapes.

> Oh - for the situation with Andy Grove (Intel CEO) describe earlier on this 
> thread - let me give this suggestion:
> 
> 	AG's key w/extra encryptions to CFO (or Pres. of Board, or
> someone else with significant influence and a close working
> relationship.  Backup for problems with intransit e-mail.)
> 
> 	Similar setups for everyone else in the company.  Probably the
> top-level executives all have AG as the backup.  This elminates
> snooping entirely in the company, on the top level execs.  This
> partially hierarchical method wouldn't be horrible, and limits
> snooping to the level above you, or to peers, depending on setup.

The suggestions about snooping heirarchy -- who can read who's mail
within the company -- are independent of which architecture you choose
to use to allow access to the mail (escrow storage keys or use
multiple crypto recipient for storage keys).  (This can all be
enforced with similar levels of resistance to bypass by building the
archive and snooping features into the mail client to do this after
decryption).

Where you start to get argument from me is when you start unduly
exposing what should be transient communications keys to construct
this corporate snooping pecking order.

> >I'm sure I've given these reasons earlier in the thread, but I'll
> >summarise them again:
> 
> Yeah, you covered them fairly well, and cleared up the issues where
> I honestly thought it was a fear-mongering problem.  I still don't
> completely agree with you, but we've clarified the problem areas.
> Thanks.

That's what it's all about -- meaningful discourse so that we can
collectively improve each others understanding of the problems at
hand, pointing out flaws in each others arguments until we reach
agreement, eliminating misunderstanding.  With that a clarified
picture of the security issues and best architecture, we can then go
on to design suitable security protocols which best reflect this.

> (Too many wars get *way* too religous on the net.  Let's try and
> avoid that here, ok?)

Hey, as long as we steer clear of PGP arguments about mandatory GAK
compliancy, this is all friendly discourse :-) 

On religious arguments: I must admit to strong negative feelings about
PGP Inc or the OpenPGP standard using weaker security methods to
enable GAK compliancy.  My reason for expressing these opinions is the
hope that we can talk PGP out of this big brotherish SMTP policy
enforcer, and associated GAK compliant fields, and to give my input to
try to steer the OpenPGP process away from incorporating said GAK
compliancy field into the standard.

Also as I hope I have explained relatively clearly in my other post
titled:

	Subject: negative security aspects of GAK compliance

that GAK compliancy is independently from political arguments a
security design flaw.  And so I think that we should be able to reject
it on technical grounds alone as a design with weaker security.

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`