Future for PGP?
xganon
be coming out. How is this going to effect re-mailers, using
Quicksilver, JBN and Mix-master chaining. Generally will we not be
using PGP any more in the future?
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Zax
>I see from the Network Associates man page no more versions of PGP will
>be coming out. How is this going to effect re-mailers, using
>Quicksilver, JBN and Mix-master chaining. Generally will we not be
>using PGP any more in the future?
My personal feeling is that PGP will be around for a long time to
come. It's unique in terms of concept and quality.
Network Associates only marketed PGP and never really played a major
part in it's development. In fact they damaged a great application by
making it closed source. Now that PGPi have some control of it, I'm
hopeful that it will continue to be regarded as the industry standard
for mail signing and encryption.
frog51
> come. It's unique in terms of concept and quality.
>
> Network Associates only marketed PGP and never really played a major
> part in it's development. In fact they damaged a great application by
> making it closed source. Now that PGPi have some control of it, I'm
> hopeful that it will continue to be regarded as the industry standard
> for mail signing and encryption.
Of course, there is no open source replacement for the ADK and key
management tools which were present in NA's version.
Would be nice to think this will be developed for one of the open
source implementations, but I'm not relying on it.
Johan Wevers
> Of course, there is no open source replacement for the ADK and key
> management tools which were present in NA's version.
> Would be nice to think this will be developed for one of the open
> source implementations, but I'm not relying on it.
I doubt the open source community is interested in ADK's. Fortunately,
GnuPG developer Werner Koch has already stated he won't implement it.
I don't know how the key management tools from NAI work so I can't
comment on that.
--
ir. J.C.A. Wevers // Physics and science fiction site:
joh...@iae.nl // http://www.xs4all.nl/~johanw/index.html
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html
Adam Back
Beretta <no_...@please.com> writes:
> On Wed, 10 Apr 2002 14:20:52 GMT, Johan Wevers <joh...@iae.nl> wrote:
> >I doubt the open source community is interested in ADK's. Fortunately,
> >GnuPG developer Werner Koch has already stated he won't implement it.
> >I don't know how the key management tools from NAI work so I can't
> >comment on that.
>
> potential user base.. No corporation in its right mind would use an
> encryption system without ADK's.. People die, people forget
> passwords/phrases, people quit thier job without advance notice, etc
> etc etc..
So store the plaintext emails and backup the disks. Storage key
escrow is far less of a danger than communications key grabbing.
This was all discussed long ago on the IETF-OpenPGP list where the ADK
was excluded from the IETF draft. Take a look at this link for some
arguments put forward at the time about why communications key escrow
is a *bad idea*.
http://www.cypherspace.org/adam/cdr/
Also take a look at "The Risks of Key Recovery, Key Escrow and Trusted
Thir-Party Encryption":
http://www.counterpane.com/key-escrow.html
and since that paper was written it turned out PGP suffered a pretty
bad security vulnerability due to a bug in the ADK code -- the ADK was
not signed so anyone could add an ADK to other keys and the client
wouldn't notice. (This was of course fixed immediately, but it shows
that the risks of key recovery paper was quiet prescient).
Robert J. Hansen
I must seriously disagree here. :)
> That defeats the whole purpose of encryption. If your adversary knows
> you store unencypted copies (which you'd have to if you use GPG in a
> corporate setting) they'd simply go after those. This isn't paranoia..
Only if they could. If the threat model is unencrypted data flowing over
an untrusted network, then storing plaintexts locally makes sense. There
are quite a few places which consider the local network to be trusted, and
thus, does not necessitate securing.
> An ADK is NOT KEY ESCROW. Argh.. Sorry, but I want to scream every time
This much I agree with. In fact, I don't even think the term ADK is
correct, given that it's not an additional decryption key at all--it is a
request to encrypt to another recipient. I'd much prefer it to be called
ARR (Additional Recipient Request) instead of ADK, just to make it clear
that there's no hanky-panky going on with keys... but, ah well.
> GPG is shooting themselves in the ass on this. It will never be adopted
> by corporations / institutions, because there is no way to insure DATA
The German government has already adopted GPG. So much for "it will never
be adopted by corporations / institutions".
GPG is also open source. ADK support in GnuPG is, most likely, a weekend
hack. If you really want ADK support in GnuPG, the source is there for
you to hack it in place yourself. Your GnuPG implementation will still be
RFC2440 conformant, your GnuPG implementation will still interoperate with
PGP/GPG. It'll just support ADKs.
Werner Koch and the rest of the GPG team have never, not once, not -ever-,
said ADKs would not, could not, be introduced into GPG. What they have
said is that they won't code ADK support themselves, and as long as they
control the source tree, ADK functionality will never make it into the CVS
repository or official GPG releases.
They have never said that other people are forbidden from making the
necessary patches. If you want to see ADK support in GPG, Beretta, by all
means--write your own patch and put it up on a webpage. The code is
GPLed. Share and enjoy. :)
Robert J. Hansen
> installer to build versions of PGP where the ADK use is mandatory. In
Wait, where generation of keys with ADKs is mandatory, or when encrypting
traffic to an ADK-enabled key, use of the ADK is mandatory? If the
former, fine, no big deal--if the latter, I'd be somewhat cautious.
Johan Wevers
> GPG is shooting themselves in the ass on this. It will never be adopted by
> corporations / institutions, because there is no way to insure DATA RECOVERY.
Perhaps they don't care? In these matters, the interests of people who need
an encryption product for the privacy of secrec communication and those of
big corporations and governments who want to be able to still check it differ.
The GnuPG developers just make it clear on whose site their main interests
are.
> Keeping an unencrypted backup is moronic, it defeats the whole purpose of
> encryption.
Keeping a backup that can be encrypted to someone out of your control is
moronic too. For business communication, just encrypt it to 2 keys. But
then it's an explicit decision to use 2 keys, not a hidden "feature".
Adam Back
Beretta <no_...@please.com> writes:
> On 10 Apr 2002 18:35:20 -0400, Adam Back <ad...@localhost.localdomain> wrote:
> >So store the plaintext emails and backup the disks.
>
> knows you store unencypted copies (which you'd have to if you use
> GPG in a corporate setting) they'd simply go after those.
The obvious solution to that is encrypt your disk -- all of it (which
was the main point of the URL on my CDR proposal:
http://www.cypherspace.org/adam/cdr/
). If you're truly worried about espionage, it's much safer to use a
driver level disk encryption tool that encrypts and decrypts things on
the fly.
By breaking the artificial dependency between storage encryption keys
and communications encryption keys which you seem to be assuming, you
can then move on to get even better security by having shorter lived
communication encryption keys.
See for example:
http://www.cypherspace.org/openpgp/pfs/openpgp-pfs.txt
(I am co-author)
> >Storage key
> >escrow is far less of a danger than communications key grabbing.
>
> An ADK is NOT KEY ESCROW.
I don't think it matters too much what you call it CMR, GAK, CAK,
key-escrow, KRA, these schemes went through multiple name changes by
government and by NAI/PGP and were all basically PR moves.
Fact is you don't want third parties having access to your
communications, and building systems which facilitates this on the
part of governments is socially irresponsible.
Take for example this argument from Schneier making the same point:
http://www.privacy.nb.ca/cryptography/archives/cryptography/html/1997-10/0040.html
Adam Back
Beretta <no_...@please.com> writes:
> >was the main point of the URL on my CDR proposal:
> >
> > http://www.cypherspace.org/adam/cdr/
>
> encryption. I've seen too many people mount thier various disks
> (PGP, BestCrypt, etc) and then completely forget about
> them.. Sometimes for days and days upon end (until the next reboot)
This is an obviously already solved problem: most storage and
communication encryption products provide a password time-out,
password protected screen lock etc.
A complete non-issue, and anyway the same technqiue applies equally to
both communication and storage encryption.
> Sure, someone can forget to reencrypt a decrypted file they're
> working on, but that's only 1 single file.. Not all of them.
People do not remember to encrypt individual files on the disk. The
OS, and the application scribbles plaintext copies of them everywhere.
Encrypting the entire disk is the most secure way to deal with this by
a big margin.
> >> >escrow is far less of a danger than communications key grabbing.
> >>
> >> An ADK is NOT KEY ESCROW.
> >
> >I don't think it matters too much what you call it CMR, GAK, CAK,
> >key-escrow, KRA, these schemes went through multiple name changes by
> >government and by NAI/PGP and were all basically PR moves.
>
> It does matter. Message recovery is not key recovery.
>
> One cannot use an ADK to create forged messages. One cannot use an
> ADK to recreate / retrieve a private key. One cannot use an ADK to
> sign other keys as being trusted (Provided the ADK is not the
> corporate signing key of course)
Neither can one use key escrow to forge messages. No key-escrow
schemes propose to escrow signature keys, only encryption keys.
Keys are big random numbers, there is no inherent privacy gained by
claiming that your key was not escrowed. ADK has precisely the same
effect as key escrow.
> Calling Message Recovery "Key Recovery" is FUD.
No. It's calling a spade a spade.
> >Fact is you don't want third parties having access to your
> >communications, and building systems which facilitates this on the
> >part of governments is socially irresponsible.
>
> I fully agree with that statment. But I fail to see how private / corporate
> message recovery has anything to do with the goverment.
Well the relationship is obvious surely: the government can simply
publish an ADK key and mandate that everyone use corporate key escrow
products.
> Besides, foks always have the option to not use an ADK. At least in the
> non-corporate installer builds of PGP they do.
More obviata: the relationship with mandatory government key escrow is
non-escrowed software products get out-lawed. Guess you weren't
paying attention over the last 5 years.
> >
> >Take for example this argument from Schneier making the same point:
> >
> > http://www.privacy.nb.ca/cryptography/archives/cryptography/html/1997-10/0040.html
> >
>
> I have a lot of respect for Bruce, but in this one instance I think he is
> talking out of his ass
>
> "But PGP's system certainly is key escrow. PGP, Inc. is splitting hairs,
> claiming that their system isn't key escrow because they don't keep copies
> of any keys. This may be true, but it's a difference that makes no
> difference."
>
> It sure in the hell does make a difference. As I mentioned above, key escrow
> gives someone access to your KEYS. Impersonation then becomes a lot easier. So
> does false authentication.. among a crapload of other problems.
It makes not one iota of difference. Your arguments about signatures
are a red-herring. The non-escrow of signature keys has years ago
been debated and it was acknowledged by USG and other governments
proposing key escrow that they would not escrow signature keys, only
encryption keys.
Anyway at this point this is mostly old history. ADK is not in GPG,
and they're not going to add it. ADK is not in IETF-OpenPGP because
the working group killed that idea. And the USG and other western
governments have largely given up on the idea.
Corporate storage key escrow and corporate security is best provided
as I described.
Robert J. Hansen
> communication encryption products provide a password time-out, password
> protected screen lock etc.
It's not a solved problem by any stretch of the imagination. I've seen
the exact same thing (and even been guilty of it a couple of times), even
with software which supports password timeouts, locked screensavers, etc.
What happens? People disable the timeouts, screensaver locks, etc., all
in the name of convenience.
Until the solution to the problem becomes convenient, the problem hasn't
been solved at all.
> Neither can one use key escrow to forge messages. No key-escrow schemes
> propose to escrow signature keys, only encryption keys.
Of course they don't propose to escrow signature keys; that would get an
enormous hue and cry from the civil libertarians, even moreso than
encryption key escrow does. But once an encryption key escrow system is
in place, and widely tolerated by the populace, a signature key escrow
system is not far behind. Assaults on individual liberties are just like
taxation: the hard part is getting people to tolerate them in their very
early stages, and the easy part is expanding them later.
> Keys are big random numbers, there is no inherent privacy gained by
> claiming that your key was not escrowed. ADK has precisely the same
I must respectfully ask what planet you're from. If your key is not
escrowed, then you exert control over your key and an attacker has to find
some way to deprive you of your key (which usually isn't too hard, but
leave that for now). If your key is escrowed, then your key is already
out of your direct control--which, in my book (and the books of many
others), is a game-over state. If I ever lose direct control of my key, I
issue a revocation certificate. Doesn't matter how I lose it, doesn't
matter who I lose control of it to. Loss of direct control equals
untrusted key.
>> Calling Message Recovery "Key Recovery" is FUD.
>
> No. It's calling a spade a spade.
Please show me how an ADK allows you to recover my secret key. Until such
time as you do, I'm going to have to consider your statement to be
ill-informed and wrong.
Please note that I do not like the ADK `feature'. My dislike of it,
though, is not so strong that I'm willing to malign it without regard to
the truth of the situation.
> Well the relationship is obvious surely: the government can simply
> publish an ADK key and mandate that everyone use corporate key escrow
> products.
Bernstein v US gives a very strong suggestion that such a law would be
unconstitutional. I'm not at all worried about the Individual v
Government battle in the crypto war; we've won that one (at least here in
the US). I'm far more worried about the Individual v Corporation v
Government crypto battle. Things were much simpler before corporate
interests became as prominent as they are; now that it's a three-way
match, everything's up in the air.
> More obviata: the relationship with mandatory government key escrow is
> non-escrowed software products get out-lawed. Guess you weren't paying
> attention over the last 5 years.
Guess you weren't paying attention to Bernstein v US. Non-escrowed open
source/Free Software crypto cannot be outlawed because it's
Constitutionally protected speech. Even in the absence of Bernstein v US,
the Wassenaar Agreement protects open source and Free Software crypto
code.
Adam Back
"Robert J. Hansen" <rjha...@inav.net> writes:
> > This is an obviously already solved problem: most storage and
> > communication encryption products provide a password time-out, password
> > protected screen lock etc.
>
> It's not a solved problem by any stretch of the imagination. I've seen
> the exact same thing (and even been guilty of it a couple of times), even
> with software which supports password timeouts, locked screensavers, etc.
> What happens? People disable the timeouts, screensaver locks, etc., all
> in the name of convenience.
Security is generally a tradeoff between security and convenience to
some extent. People _can_ disable most security features. If people
disable the security features you can hardly use that as an argument
for key escrow in GnuPG.
> Until the solution to the problem becomes convenient, the problem hasn't
> been solved at all.
It is convenient, and it has been solved. Other measures include USB
key fobs that store the keys. Perhaps that might suit you better if
you then attached it with some cord to a belt clip to avoid
accidentally leaving yourself logged in.
> > Keys are big random numbers, there is no inherent privacy gained by
> > claiming that your key was not escrowed. ADK has precisely the same
>
> [...] If your key is not
> escrowed, then you exert control over your key and an attacker has to find
> some way to deprive you of your key (which usually isn't too hard, but
> leave that for now). If your key is escrowed, then your key is already
> out of your direct control--which, in my book (and the books of many
> others), is a game-over state. If I ever lose direct control of my key, I
> issue a revocation certificate. Doesn't matter how I lose it, doesn't
> matter who I lose control of it to. Loss of direct control equals
> untrusted key.
As I already said the key itself is a meaningless bit string -- what
rational people care about is untrusted third parties reading their
messages. I'm not sure how much more control you think you have to
avoid the designated 3rd party reading your messages with a mandatory
and enforced ADK mechanism. The fact that your key -- a meaningless
bit string inside an application -- is not escrowed is irrelevant.
> >> Calling Message Recovery "Key Recovery" is FUD.
> >
> > No. It's calling a spade a spade.
>
> Please show me how an ADK allows you to recover my secret key. Until such
> time as you do, I'm going to have to consider your statement to be
> ill-informed and wrong.
>
> Please note that I do not like the ADK `feature'. My dislike of it,
> though, is not so strong that I'm willing to malign it without regard to
> the truth of the situation.
I suppose you're getting hung up on the fact that the key is not
per-se escrowed with ADK. Key-escrow historically has been a term
invented by government spin doctors, there were a whole raft of fresh
names issued over the years by the government's spin doctors.
It's been traditional for those opposing key escrow to just keep
referring to the scheme by it's original name to avoid confusion and
keep focussing on the aspect that it is bad for governments to try to
impose a-priori ability to read messages written by individuals.
Another popular term was GAK -- Government Access to Keys.
The issue that you should care about is whether a third party can read
your plaintext, and whether there is software which enforces that this
is the case, and the additional risk that readily available software
which provides such features may increase chances that governments
will try to enforce GAK.
> > Well the relationship is obvious surely: the government can simply
> > publish an ADK key and mandate that everyone use corporate key escrow
> > products.
>
> Bernstein v US gives a very strong suggestion that such a law would be
> unconstitutional.
I don't think historically that it was at all clear that the courts
would have prevented GAK. It took a lot of concerted effort from
lobbyists to kill it.
> I'm not at all worried about the Individual v
> Government battle in the crypto war; we've won that one (at least here in
> the US). I'm far more worried about the Individual v Corporation v
> Government crypto battle. Things were much simpler before corporate
> interests became as prominent as they are; now that it's a three-way
> match, everything's up in the air.
So recall it was you who was arguing for extra ADK support to make it
easier for corporations and governments to adopt and enforce
oppressive policies.
> > More obviata: the relationship with mandatory government key escrow is
> > non-escrowed software products get out-lawed. Guess you weren't paying
> > attention over the last 5 years.
>
> Guess you weren't paying attention to Bernstein v US. Non-escrowed open
> source/Free Software crypto cannot be outlawed because it's
> Constitutionally protected speech.
That could get overturned easily.
> Even in the absence of Bernstein v US,
> the Wassenaar Agreement protects open source and Free Software crypto
> code.
Wassenaar is not that clear. Individual governments have a lot of
lattitude over how they interpret it. For example France was a
signatory at the time it was illegal to own or use crypto in France
(even 40-bit crypto -- recall the no-crypto version of netscape.) I
wouldn't place much hope that Wassenaar is going to protect individual
liberties.
Adam
Adam Back
Beretta <no_...@please.com> writes:
> On 12 Apr 2002 10:34:28 -0400, Adam Back <ad...@localhost.localdomain> wrote:
> <snip>
> >This is an obviously already solved problem: most storage and
> >communication encryption products provide a password time-out,
> >password protected screen lock etc.
>
> disk if there are still open files on said disk. For example, if you
> are working on a Word document, or perhaps a CAD file. And besides,
> any that did sever open file handles and force a dismount wouldn't
> be acceptable anyhow.
Who said anything about dismounting the disk, as I said:
> >password protected screen lock etc.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >More obviata: the relationship with mandatory government key escrow is
> >non-escrowed software products get out-lawed. Guess you weren't
> >paying attention over the last 5 years.
>
> Yes, I have been. And every single goverment key escrow attempt has
> been shot down. Have you been paying attention?
At the time it was far from obvious that the lobbying groups would
succeed at shooting down the escrow attempts. Are you suggesting that
we are now safe, and there is no remaining danger any government will
again try to introduce laws trying to introduce key escrow?
Adam
Robert J. Hansen
> some extent. People _can_ disable most security features. If people
> disable the security features you can hardly use that as an argument for
> key escrow in GnuPG.
... Which I wasn't. I was merely pointing out the correctness of
Beretta's claim, that these are not solved problems. If they were solved
problems, we would not be confronted with these problems time and time
again.
That is what it means for a problem to be "solved". That means it is no
longer a problem. Given that what Beretta spoke of is very clearly an
ongoing problem, you have to present me with some pretty serious proof
that the problem is solved. So far, all I've seen is a "... well, if
people would just do /this/."
Great, and if people would just get a PhD in cryptology they'd be able to
tell the snake-oil from the treasures. But guess what? People aren't
going to get a PhD in cryptology. And they aren't going to make use of
password timeouts or screensaver locks (at least, nowhere near the degree
that they should).
Hell, /I/ don't use password timeouts or screensaver locks as much as I
should. And I'm not exactly a dummy.
> It is convenient, and it has been solved. Other measures include USB
Prove it. Unless you can prove it, don't waste our time.
> As I already said the key itself is a meaningless bit string -- what
Great. Prove it, please. If your key is a meaningless bit string, then
please post it to the net for the world to see.
What, you -don't- want to post your secret key for the world to see? Guess
it's not a meaningless bit string, then.
> rational people care about is untrusted third parties reading their
Having sole control over the key is the only way, cryptographically
speaking, to keep untrusted third parties from reading their mail.
> I suppose you're getting hung up on the fact that the key is not per-se
> escrowed with ADK. Key-escrow historically has been a term invented by
I'm getting hung up on the fact that words have meanings, and these
meanings are not subject to arbitrary redefinition. ADK is not key
escrow. It is a similar process, yes, but it is not key escrow and it is
extremely disingenuous for you--or for anyone, Schneier included--to
equate the two.
Describe things accurately, please: we're trying to have an informed
discussion and those require facts, not the key escrow boogieman, when
even you admit that ADK does not involve key escrow.
> Another popular term was GAK -- Government Access to Keys.
ADK is not GAK. If ADK were to be adopted nationwide, we would have GAPT
(Government Access to Plaintext), not GAK.
> The issue that you should care about is whether a third party can read
Strange. I seem to recall other people in the past telling me what I
"should" care about. Most of them were telling me I should care about
clothes, beer, and getting laid... but then I graduated from high school.
> So recall it was you who was arguing for extra ADK support to make it
> easier for corporations and governments to adopt and enforce oppressive
> policies.
You're misremembering things in a manner that's hilariously wrong. I am a
strong advocate against ADK being introduced into products. I just refuse
to make strawman arguments against ADK, particularly by bringing up the
key-escrow boogieman.
>> Guess you weren't paying attention to Bernstein v US. Non-escrowed
>> open source/Free Software crypto cannot be outlawed because it's
>> Constitutionally protected speech.
>
> That could get overturned easily.
Apparently, you didn't hear the Ninth Circuit affirmed Judge Patel's
decision. Believe the three-judge panel went 3-0, and I believe it went
en banc with a spectacular supermajority affirming.
The Supreme Court is now the only entity which can overturn Bernstein v
US, and of the nine justices, six are clearly in favor of Bernstein
I suppose it could be overturned `easily', for an arbitrary redefinition
of `easily'.
Adam Back
> should. And I'm not exactly a dummy.
It hardly takes a PhD in cryptology to realise that disabling security
features will reduce your security. (Your complaint about current
solutions).
> > It is convenient, and it has been solved. Other measures include USB
>
> Prove it. Unless you can prove it, don't waste our time.
Your only argument against the efficacy of the widely used solution of
having a screen lock / application lock on time-out so far has been
that stupid people disable it! What should the application do?
Prevent you from disabling the time-out? Would you then consider it a
solved problem?
> > As I already said the key itself is a meaningless bit string -- what
>
> Great. Prove it, please. If your key is a meaningless bit string, then
> please post it to the net for the world to see.
>
> What, you -don't- want to post your secret key for the world to see? Guess
> it's not a meaningless bit string, then.
Well duh. Clearly I'm not going to post my private key. The point is
that sharing a private key with a third party has _exactly_ the same
end-effect as using software which prevents you from removing a
feature which encrypts the message with that same third parties public
key.
Your and Berretta's arguments that ADK is somehow different and
preferable are what I was attempting to explain the fallacy of.
> > rational people care about is untrusted third parties reading their
>
> Having sole control over the key is the only way, cryptographically
> speaking, to keep untrusted third parties from reading their mail.
It's a first step for sure. But it's not sufficient. As the ADK
design shows it's equally possible to break security in the same way
by using software that encrypts everything you send and receive to the
same third party.
My point is I consider these things as the same effect. The actual
point is protecting the plaintext. Berretta's argument seems to be
that the key is safe, so it doesn't matter that the plaintext is
leaked because at least he has sole control of his key!
> > I suppose you're getting hung up on the fact that the key is not per-se
> > escrowed with ADK. Key-escrow historically has been a term invented by
>
> I'm getting hung up on the fact that words have meanings, and these
> meanings are not subject to arbitrary redefinition. ADK is not key
> escrow. It is a similar process, yes, but it is not key escrow and it is
> extremely disingenuous for you--or for anyone, Schneier included--to
> equate the two.
If it makes you feel better call it whatever you want. The USG
spin-doctors coined the term key-escrow as a high-level description.
The actual _aim_ obviously is to have access to your plaintexts.
> Describe things accurately, please: we're trying to have an informed
> discussion and those require facts, not the key escrow boogieman, when
> even you admit that ADK does not involve key escrow.
Doh.
I explained my generic use of the term key-escrow as a phrase which
has historically been used to cover the whole saga of governments
attempts to effect access to individuals plaintext.
> > Another popular term was GAK -- Government Access to Keys.
>
> ADK is not GAK. If ADK were to be adopted nationwide, we would have GAPT
> (Government Access to Plaintext), not GAK.
Call it GAP if you like.
> > So recall it was you who was arguing for extra ADK support to make it
> > easier for corporations and governments to adopt and enforce oppressive
> > policies.
>
> You're misremembering things in a manner that's hilariously wrong. I am a
> strong advocate against ADK being introduced into products. I just refuse
> to make strawman arguments against ADK, particularly by bringing up the
> key-escrow boogieman.
Is GAK ok but GAP -- your term -- evil then in your view? I think
you're attempting to derail arguments with definitional quibbling.
I'm perfectly aware of the intricacies of all the GAK schemes and the
technical definitions of all the terms.
> >> Guess you weren't paying attention to Bernstein v US. Non-escrowed
> >> open source/Free Software crypto cannot be outlawed because it's
> >> Constitutionally protected speech.
> >
> > That could get overturned easily.
>
> Apparently, you didn't hear the Ninth Circuit affirmed Judge Patel's
> decision. Believe the three-judge panel went 3-0, and I believe it went
> en banc with a spectacular supermajority affirming.
>
> The Supreme Court is now the only entity which can overturn Bernstein v
> US, and of the nine justices, six are clearly in favor of Bernstein
>
> I suppose it could be overturned `easily', for an arbitrary redefinition
> of `easily'.
In the post Sept 11th political climate I wouldn't be quite so proud
and certain of one court decision's irreversibility -- it took the EFF
a lot of effort to achieve that decision. The US still has the ITAR
regulations, as far as I understand it I think all it takes is a civil
servants definitional decision to bring about a change for the worse.
And US presidents have a history of enacting presidential decrees --
and the US is and has been for years inexplicably in an official state
of national emergency which allows this kind of thing.
Here's hoping GAK, GAP, mandatory ADK, CAK, etc. doesn't get
re-introduced whatever y'all decide you'd like to call it.
Adam
Robert J. Hansen
> features will reduce your security. (Your complaint about current
> solutions).
No, it doesn't. And people do it anyway. The fact that the problem still
exists is ample proof that the problem is not solved.
> Your only argument against the efficacy of the widely used solution of
> having a screen lock / application lock on time-out so far has been that
> stupid people disable it! What should the application do? Prevent you
No. My argument against the efficacy of the widely-used `solution' is
that we still have the _problem_, because people are unwilling to use the
`solution'. A solution that people are unwilling to use is no solution at
all.
> Well duh. Clearly I'm not going to post my private key. The point is
In that case, your key is not a meaningless bit string.
> that sharing a private key with a third party has _exactly_ the same
> end-effect as using software which prevents you from removing a feature
> which encrypts the message with that same third parties public key.
... This much, I agree with. And in fact, if you look at my prior USENET
posts, you'll find I've said the same thing.
> Your and Berretta's arguments that ADK is somehow different and
> preferable are what I was attempting to explain the fallacy of.
Please RMFP (Read My Fine Posts). Beretta is claiming the ADK is
different and preferable to key escrow. I'll agree that, for the general
case, it's different--but not preferable. I am claiming the ADK is
different and preferable to key escrow -in those deployments where the
user can override the ADK-.
In PGP 7, if one of my receipients is flagged as having an ADK, I don't
have to encrypt to that key. It's not required. It's not mandatory. This
is why I favor calling optional ADK use `ARR', for Additional Recipient
Request. That last word, -request-, is what makes it not just different
from key escrow, but preferable to key escrow. If I have a choice as to
whether or not to facilitate GAPT, then all the civil libertarian
arguments against ADK fly right out the window. It's my -choice-.
I don't make use of ADKs, but as long as I have the free, uncoerced
-choice- as to whether or not to use them, there's no Libertarian argument
against it. Uncoerced ADK use is different from key-escrow, and
preferable to it.
Note that I still wouldn't use them. :)
> It's a first step for sure. But it's not sufficient. As the ADK design
> shows it's equally possible to break security in the same way by using
> software that encrypts everything you send and receive to the same third
> party.
The ADK design is not a broken one. The design goals of the ADK happen to
not coincide with your design goals. The ADK design has a different goal,
and with optional ADK use I'd even say it substantially meets its goal.
Remember: he who writes the code gets to decide what the design goals are.
If you don't like it, then write your own code with your own different
design goal.
> Is GAK ok but GAP -- your term -- evil then in your view? I think
GAK is evil. Optional GAPT is absolutely acceptable. People ought to
have the freedom to speak privately, without question... and people ought
to have the freedom to let someone listen in. Every freedom is a
double-edged sword; the trick is persuading people to exercise their
freedoms responsibly.
> you're attempting to derail arguments with definitional quibbling. I'm
No, I'm attempting to get you to focus your argument and use correct
terminology, so that we can have an actual argument.
> regulations, as far as I understand it I think all it takes is a civil
> servants definitional decision to bring about a change for the worse.
You understand incorrectly.
> And US presidents have a history of enacting presidential decrees -- and
> the US is and has been for years inexplicably in an official state of
> national emergency which allows this kind of thing.
Oh, God. You're not one of those who believes we've been in a declared
state of emergency since World War Two, have you?
If so, do yourself a favor. Take the President to court and petition for
a Writ of Mandamus demanding that it be overturned. If you're right (and
you aren't), any Federal judge in the nation would just love, absolutely
love, to issue that Writ. Executive orders are just that--executive--and
the Judicial Branch is, (a), not bound by them, and (b), capable of
overturning them.
And if you're not willing to take the President to court, then all I can
believe is that either (a) you don't really believe what you're saying,
or (b) you don't care enough to try and change things.
Robert J. Hansen
> saying it..) In my original post.
Oh, I think I understood your original post pretty well. The only thing I
was hazy on was whether you'd have a problem the government to issue an
ADK and make its use mandatory (which I didn't think you would, but you
weren't totally clear), or whether you'd just rather prefer that if the
government were to issue an ADK its use would be purely optional.
I agree that corporations have a vested interest in having their email
traffic accessible. I can easily see how a corporation could in fact be
held in contempt of court if they failed to have an ADK policy in place.
("I'm sorry, Your Honor, but we can't comply with this court's subpoena,
because we don't have a key to decrypt that" won't go over well with a
judge). To meet the legal requirements of Corporate America, ADKs are--if
not quite necessary--really nice.
> I just wanted the option in GPG.. (I realize now I'm never going to get
Interestingly, vedaal sent me (in email) a way to do ADKs in GPG. It's
such a mind-bogglingly obvious thing to do that I'm embarassed I didn't
see it before.
In the user's options file ("options" on UNIX, "OPTIONS" on Win32), change
the file ownership to root and set the global permissions to read-only.
Inside the options file, "default-recipient <corporatekey>". Presto: GnuPG
will work just fine, and all traffic it encrypts will also be encrypted to
your corporate decryption key. And since the user has no write
permissions to the file, it makes it harder to routinely circumvent. (You
can pass GnuPG a commandline option to make it read from an alternate
options file, but most casual users would probably be totally unaware such
an option exists.)
I haven't tried this yet, but it seems like it should work just fine. Of
course, a truly dedicated person will still find a way around it, but the
same can be said for PGP ADKs.
> <sigh> Maybe I need to learn how to express myself better or something..
> I dunno...
I understood you just fine. :)
Adam Back
> don't have to encrypt to that key. It's not required. It's not
> mandatory. This is why I favor calling optional ADK use `ARR', for
> Additional Recipient Request.
In some versions of PGP the use of the ADK is mandatory. There is a
network based policy enforcer which examines the header and rejects
mail incoming and outgoing without this header. I suppose you didnt
know that.
> That last word, -request-, is what makes it not just different
> from key escrow, but preferable to key escrow. If I have a choice as to
> whether or not to facilitate GAPT, then all the civil libertarian
> arguments against ADK fly right out the window. It's my -choice-.
Yes, but the danger is not so much in the voluntary additional
recipients as in the fact that software exists which allows the
enforcement of the additional recipients.
> > regulations, as far as I understand it I think all it takes is a civil
> > servants definitional decision to bring about a change for the worse.
>
> You understand incorrectly.
No you understand incorrectly. ITAR is still in effect. Do some web
searches.
> > And US presidents have a history of enacting presidential decrees -- and
> > the US is and has been for years inexplicably in an official state of
> > national emergency which allows this kind of thing.
>
> Oh, God. You're not one of those who believes we've been in a declared
> state of emergency since World War Two, have you?
I suppose you're ignorant of the use of national emergency powers in
relation to crypto export regulations too:
http://www.inet-one.com/cypherpunks/dir.1998.08.10-1998.08.16/msg00211.html
Adam
Adam Back
Beretta <no_...@please.com> writes:
> >At the time it was far from obvious that the lobbying groups would
> >succeed at shooting down the escrow attempts. Are you suggesting that
> >we are now safe, and there is no remaining danger any government will
> >again try to introduce laws trying to introduce key escrow?
>
> government mandated ADK precipice..(okay, I think that is mispelled)
> Wherein as soon as the private use of ADK's gain acceptance by the
> general populace the Government is going to leap in and mandate
> them.
Well it's debatable about whether the US for example will plunge back
into the key-escrow, crypto export regulations craziness. But the
chances of that happening again got a whole lot higher since the sept
11th incident.
> I might be coming across as being a bit naive.. But you are coming
> across as a fear monger.
Also bear in mind the US is not the only country in the world. For
example readily available key-escrow (in the high-level intent sense
not the technical sense) software may increase the chances of it being
deployed in China, Iraq, etc, etc.
On your other post about voluntary key escrow in your company. Why
even bother: I already explained how to get better storage and
communications security.
Adam
Adam Back
Beretta <no_...@please.com> writes:
> Well, I still fail to see where an ADK (as implemented in PGP) is an
> "inherint" risk.
I made a number of arguments about why communications key-escrow is
inherently more dangerous than storage key-escrow in:
http://www.cypherspace.org/adam/cdr/
particularly:
| The CDR proposal on the other hand focusses on recovery information
| of stored information only, and as a design principle avoids sending
| recovery information over open networks. Whilst governments may bbe
| interested to obtain storage keys, they have much less value,
| because the ciphertext is much harder to obtain. Also
| non-compliance is much harder to detect: a government law
| enforcement agency would not know if an individual was actually
| using storage software with government backdoor key access without
| physically obtaining the storage media. For most individuals the
| point at which governments executes a dawn raid is a point at which
| the individual is already in trouble. The CDR proposal is much
| closer to the status quo in political terms.
So to explain the danger with communications key-escrow is your enemy
can archive the ciphertext. (Whether the enemy is your corporate
espionage scenario, or a repressive government). Then the ciphertext
is kind of secret-split between you -- the holder of the private key
-- and the enemy -- who has archived your ciphertexts. Because you
have mistakenly entangled the requirement for long-lived storage
private keys with the need for short-lived communications private-keys
you have introduced a vulnerability. You can't change your
communications private-keys essentially ever because you're using them
as long term storage keys. So there remains a perpetual threat that
someone manages to obtain your communications private-keys. In
addition by using ADKs you have introduced a central vulnerability for
your entire organisation in the form of the ADK master private key --
if someone gets that key they can read all archived ciphertexts from
any messages sent or recieved by anyone in your company for the
life-time of that key.
Clearly separating storage encryption and communication encryption
fixes this problem. You no longer need communication private-keys to
access stored information so you can periodically expire and delete
old private keys. OpenPGP already supports a way to have multiple
private decryption keys which expire at staged intervals. The RFC I
posted proposes to take it a couple of stages further with automated
temporary private keys per message recipient for more immediate
forward-secrecy.
Adam
Robert J. Hansen
> network based policy enforcer which examines the header and rejects mail
> incoming and outgoing without this header. I suppose you didnt know
> that.
No, I did know that. And the existence of such software doesn't bother me
one bit. I don't like it, and I don't have to use it. So I don't. And as
Beretta (correctly) pointed out, there are occasions in which a
corporation is legally required to have a decryption key. If your company
archives its mailspool, then that mailspool is available for subpoena. If
your company can't provide the plaintext of messages on its mailspool,
then that's a significant legal liability.
You're allowed to destroy your mailspool, sure. You're not allowed to not
comply with a subpoena.
> Yes, but the danger is not so much in the voluntary additional
> recipients as in the fact that software exists which allows the
> enforcement of the additional recipients.
Horse hockey. This argument has been refuted many times in the past. "The
danger is not so much in the fact that we human beings are willing to kill
each other, as in the fact that nuclear weapons exist."
"The danger is not so much in the fact that we human beings are foolish
and do stupid things, as in the fact that guns are still used to play
Russian Roulette."
I have never, never, seen the logic in blaming *things* for the failings
of *ourselves*.
>> > regulations, as far as I understand it I think all it takes is a
>> > civil servants definitional decision to bring about a change for the
>> > worse.
>>
>> You understand incorrectly.
>
> No you understand incorrectly. ITAR is still in effect. Do some web
> searches.
No, you understand incorrectly. The executive branch does not get to
overturn the Ninth Circuit Court of Appeals. Export controls on crypto
have been found unconstitutional in the Ninth Circuit. Any executive
order which tries to enforce them is going to be null and void /ab
initio/.
Like many governmental paranoids, you seem to hold the belief that the
government acts in sync with each other. It doesn't. The government is
composed of three totally separate institutions which are simultaneously
dependent upon the other branches for power, and constantly trying to
hoard power for themselves.
> I suppose you're ignorant of the use of national emergency powers in
> relation to crypto export regulations too:
Please find me the published executive order _neither overturned nor held
in abeyance_ which pertains to this. Keep in mind that for an executive
order to be binding on me, it must be published.
And once you find a published executive order _neither overturned nor held
in abeyance_ which declares us to be in a state of emergency, take it to
court. Get a Writ of Mandamus. Make a difference. Show the courage of
your convictions.
Or else stop wasting my time.
Robert J. Hansen
> you think it would be a lot easier for him / his thugs to march in,
> shoot the receptionist and then say "Okay, anyone who doesn't turn over
> his crypto keys / password(phrase) is going to share this persons fate"?
I'd recommend they haul in the receptionist's family and start executing
them. Given the way most CEOs tend to handle their network secrets, the
receptionist probably has every password in the place, and you wouldn't
want to cap the person who knows all the secrets first off. :)
Sam Simpson
reasons Adam and others argued about many years ago.
My most compelling arguments against it are:
1) It's GAK waiting to happen: you're providing "the government" with a
pre-built, ready to roll GAK solution waiting to be enabled if they ever
decide it's in "the peoples interest".
2) Mere inclusion of this feature adds complexity in core code - see
e.g. the ADK bug in NAI PGP Builds.
Functional equivalents of ADK can be achieved without this feature being
available.
Beretta wrote:
> On Sat, 13 Apr 2002 19:16:56 GMT, "Robert J. Hansen" <rjha...@inav.net> wrote:
>
> <snip>
>
>>In PGP 7, if one of my receipients is flagged as having an ADK, I don't
>>have to encrypt to that key. It's not required. It's not mandatory. This
>>is why I favor calling optional ADK use `ARR', for Additional Recipient
>>Request. That last word, -request-, is what makes it not just different
>
>>from key escrow, but preferable to key escrow. If I have a choice as to
>
>>whether or not to facilitate GAPT, then all the civil libertarian
>>arguments against ADK fly right out the window. It's my -choice-.
>>
>
> <snip>
>
> My final post on this subject.
>
> THAT is exactly what I was saying, (Maybe I didn't do a good job of saying it..)
> In my original post.
>
> I just wanted the option in GPG.. (I realize now I'm never going to get it from
> the "official" GPG) but that is irrelevant. I was just stating that I wanted it.
>
> In the course of this thread, as you may have noticed, I said that my company
> enforces LOCAL ADK's, but not EXTERNAL.. I couldn't care less about other guys
> ADK policies.. They are of no concern to me. (zero, zip, nada) I have no
> problem with other folks (external to the organization I work for) having the
> same views about OUR ADK's. I don't want any ADK to be mandatory for someone who
> doesn't like them.
>
> In our organization people are paid a wage to produce a product, that product
> belongs to the organziation. Thus, the RIGHTFUL owner of said product is
> enforcing the ADK on its own property. Employees create the product on hardware
> (computers) that are paid for and owned by the company, using software paid for
> by and license to the company, and encrypted with software paid for by and
> licensed to the company.
>
> So, at no time is anyone being forced to encrypt anything they own to an ADK.
> Every step of the process is APPROVED by the organization that OWNS the property
> that is being encrypted.
>
> That's what kept bugging me about this "Third Party" crap I kept hearing..
>
> There is NO third party in the scheme I use. Nobody has access to the data who
> isn't authorized.
>
> <sigh> Maybe I need to learn how to express myself better or something.. I
> dunno...
>
>
--
Regards,
Robert J. Hansen
> pre-built, ready to roll GAK solution waiting to be enabled if they ever
> decide it's in "the peoples interest".
Nonissue, given that retrofitting ADKs into GnuPG is no more than a
weekend hack--there's already a pre-built, ready-to-roll ADK solution. But
ADK != GAK. GAPT, yes, GAK, no.
> 2) Mere inclusion of this feature adds complexity in core code - see
> e.g. the ADK bug in NAI PGP Builds.
Agreed, and that's the reason why I advocate against the inclusion of ADK
functionality into GnuPG. If you desperately need it for yourself, go
right ahead; I won't complain one bit. But ADKs do not belong in the
source tree for exactly this reason: the source tree needs to be as small
and lightweight as possible, in the interest of security.
Of course, for real security I'd prefer if GnuPG was written in pretty
much any language other than C... but I'll take what I can get. (GnuPG in
Ada95 would be particularly beautiful, given the SPARK tools available to
prove program correctness. GnuPG in Scheme or ML would be similarly
lovely. Heck, I'd even take GnuPG in C++, if it was well-designed with
few pointers. C is just about the most dangerous language I've ever seen,
securitywise.)
> Functional equivalents of ADK can be achieved without this feature being
> available.
Also agreed.
Robert J. Hansen
> might be for actually using it in favor of PGP, or for someone to
> switch from PGP to GnuPG, if any? That I'm a bit unclear on.
(Note: many of these arguments do not apply to the CKT builds.)
1. Open codebase.
PGP's codebase is closed source; GPG's is open. That by itself is reason
enough to make the switch. While a limited source release has been made
for the PGP 7 codebase, that source was released under a policy so
restrictive as to make it not open at all.
2. Conformance to RFC2440bis.
RFC2440bis is the latest draft of RFC2440. PGP didn't conform until
7.1.1, if memory serves.
3. Active development.
GnuPG is actively developed in an open, community-oriented environment.
PGP development has died. *This also means future bugs in PGP will not
be fixed.*
4. Small footprint.
As a very rough rule of thumb, bugs increase to the square of the
codebase size. GnuPG is, on my system, 560k. Just the compressed PGP
7.1.1 file alone is 12mb.
5. It's fun.
GnuPG is fun. It's hard for me to give an empirical test for fun, but
... if you find yourself using it, and /liking/ that you're using it,
then it's fun. :)
Paul Rubin
> Maybe.. But that's not my threat model. (Don't take that as a statement that I
> don't care, but it's not what concerns me in the context of my original request
> for an ADK function in GPG)...
>
>... I only want ADK's in a customized version
> that I can deploy on MY machines, on my MY hardware, on MY network.
I don't understand what you're arguing about. If you only want ADK's
in a customized version of GPG, then put them in. The source is
freely available and nothing stops you from installing ADK's.
My understanding of PGP ADK's, by the way, is that even if a public
key has an ADK attached, the person encrypting the message to that
public key can choose whether or not to also encrypt to the ADK.
There's no means of making encrypting to the ADK mandatory if a normal
version of PGP is available.
Robert J. Hansen
> helpful to have them pointed out to me, even if they were already
> obvious to others.
No problem. Reasonable questions get reasonable answers. I don't
guarantee the answers will be -right-, but they will be reasonable. :)
> The last 2 are actually qualities I look for and appreciate in any
> application, and while some people might say fun is irrelavant in a
> security program I have to agree with you. :-)
Oh, fun is always relevant. There's a Leonard Cohen song in which he
laments that "Jesus is taken seriously by many, but Jesus is taken
joyously by few"--when I heard that line from "Jazz Police", it made me
stop and think for a while. Finally, I decided that if something is
important enough to take seriously, it should also be important enough to
take joyously.
Do I think crypto is important? Absolutely. I think it's serious as the
grave, honestly. But I really think people who are all doom and gloom
over it should lighten up and have some fun with it, too. :) Life's too
short to be morose.
Adam Back
Beretta <no_...@please.com> writes:
> My argument wasn't so much about ADK's in GPG. (Altho, I would like
> the option) it was against the notion that ADK's are inherently
> dangerous and /or have no real place in the crypto community. I also
> disagreed with Adam over his "solutions", that he kept insisting
> were better than ADK's. I am very aware of what solutions are right
> for me and for the organization that employs me.
It depends what right means to you. It seems clear to me that what
you propose is far from the most secure, most convenient or most
reliable approach.
You mentioned industrial espionage. What do you think the chances are
that if someone in the company that employs you loses a laptop to
industrial espionage that there will be no traces left of typical
office software files (word processed files, spread-sheets etc)?
It's fairly obvious that driver encryption is much more secure than
manually encrypting individual files with PGP (or anything else).
I gave you a few examples of why this is the case:
- typical applications leave clear text copies and backups of the
files written in various places
- the swap file may also end up containing copies of your plaintext
A number of companies use the driver encryption approach as a more
secure alternative to manual encryption utilities. Your choice of
course -- but be advised and aware of the above risks.
Adam
Adam Back
Beretta <no_...@please.com> writes:
> >You mentioned industrial espionage. What do you think the chances are
> >that if someone in the company that employs you loses a laptop to
> >industrial espionage that there will be no traces left of typical
> >office software files (word processed files, spread-sheets etc)?
>
> files are kept at fixed sizes on separate hard drives. Temp files
> are deleted and the free and slack spaces are wiped regularly.
Presumably you mean separate partitions. Anyway in summary your
answer in reality is "not very sure".
> Hard drive encryption is not the answer for us. Because at any time
> said drive / partition / virtual partition is in use, everything on
> it is available. I canot start mandating that if someone goes to use
> the restroom, or goes to eat lunch, or goes to the supply cabinet
> they must dismount the drive. Nobody would do it because it's a
> hassle.
Uh, wasn't it you who admitted earlier that you had misread what I
said about screen-locks that activate after time-out? People do not
dismount the drive, they just walk away from the terminal and the
screen-lock kicks in after inactivity time-out. Or they press a
hot-key combination and it locks. Hardly "dismount drive" and hardly
killer inconvenient and certainly less risky than your current
approach.
Also the hardware token things are pretty cheap and make it natural to
remove the token to avoid pulling the machine off the desk by it's
belt-clip attached token.
Really I think you need to update your information about what is
available.
> With PGP, only the file in use is actually available. Thus, my risks are
> minimized already.
Wrong. If someone were interested beyond the ethical considerations
I'm pretty confident I could recover a number of files and file
snippets off your supposedly secure setup.
> >It's fairly obvious that driver encryption is much more secure than
> >manually encrypting individual files with PGP (or anything else).
>
> It isn't obvious. You don't know my organizations needs, even tho
> I've tried to explain it. I'm not going to continue with this debate
> on this subject.
You explained that you are concerned about usability. I've pointed
out to you a number of times that encrypting the entire disk with
driver level encryption products is both more convenient and more
secure. There are lots of companies using these products many of them
doubtless larger and with more complex environments and less
inconvenience tolerant users than your employer.
I wonder did you even try to use one of the multitude of free-ware and
commercial driver-level encryption products available? Some of them
even include features such as convenient integration of hardware
tokens, network based installs, commercial storage key escrow and
recovery from password forgetting on the part of users.
Adam