[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re(2): Re(2): NSA weisst die US Regierung auf das GAK Beispiel PGP hin.

Du schriebst:

>Welchen Schlüsselpaars und wie und wo wird "hingesichert" ?

Ich habe mich inzwischen, siche auch Kommentare von Lutz, 
mehr informiert und haenge eine Nachricht an, die den Hintergrund
noch besser erlaeutert.

Anonymous writes:
> Let's look a little closer at the kinds of access and notice available in
> the PGP system compared to alternatives.
> As several people have pointed out, no encryption system can provide
> protection against what is done with the message after it is decrypted.
> The receiver could share it with whoever he wants to, or whoever he is
> forced to.
> Consider the following scenarios:
>  - An encrypted message is sent to someone at his workplace using current
>    systems like PGP 2.6.
>  - An encrypted message is sent to someone at his workplace, who is using the
>    message access features of PGP 5.5.  The corporation key is marked as
>    "optional", and the message is not encrypted to that extra key.
>  - An encrypted message is sent as before, but this time the message is
>    encrypted to the corporate key.

You missed one scenario, which corporates are probably going to like
better than you imagine.  The reason they will like it better than you
imagine is because you believe in privacy; they do not.  You belief in
privacy is making you unrealistically optimistic about companies
respect for privacy.

The missed scenario is:

>  - An encrypted message is sent to someone at his workplace, who is using the
>    message access features of PGP 5.5.  The corporation key is marked as
>    "non-optional", and the message is encrypted to that extra key.

If you are non-technical (which most people are not), you would then
be forced to use this.  This is because the SMTP policy enforcer will
bounce the mail if you do not.

Your expectation of privacy is respected, because you expect none.

However if the system is used for other than anticipated purposes,
such as perhaps as a GAK enforcement mechanism in
tinpotdictatorsville, it is not just expectation of privacy concerns
which will concern you.  It is civil rights issues.

You have a dual concern: you are trying to protect against big brother
and against little brother.

The way that your concerns about little brother have been transferred
into the protocol resulting in the CMR mechanism has not added
anything at all to protection against little brother; protection
against little brother are largely statement of intent issues.

However you do raise a fresh point in this debate below.

>  - An encrypted message is sent to someone at his workplace, who is using
>    a different form of corporate access which relies on key escrow
>    or automatic acquisition of cleartext.
> We agree that none of these systems can provide complete protection
> against third party access.  In any of them, the receiver could be forced
> to turn over the encrypted message.  But there is still a difference.
> In the first two scenarios, the expectation of privacy is the same.
> You are encrypting to a personal key at a business address, but you
> expect that you would know about it if the data were being provided to

> a third party.  There is no widespread installed base of software which
> provides secret access after the message is decrypted.

This is clever reasoning.  I have not seen anyone raise this objection

However, you neglect that there is something which is incredibly
highly deployed: hardly anyone is using disk encryption software.  So
the mostly widely installed user base already has the possibility for
someone else in the company to decrypt it: the plaintext is an easier
tarket than CDR recoverable data in my system.

Your second distinction then resides in the claim that the email is
still encrypted in the mail folder, and it has no recovery

True enough, it doesn't.

However what you are really saying is that the system has been
purposefully designed to respect employees rights to receive private
email.  This design decision is implemented at a higher level than the
protocol level.  This design decision is independent of the use of CMR
or CDR.

You can easily implement private email with CDR.  You can provide two
keys: one for private use and one for company use.  Or you can the
email as private or not.  Or you can give the user the ability to
control independently for each email:

is it archived (yes/no)
is the archive recoverable (yes/no)

I have been arguing for these features to be put in also, which
demonstrates that I have just as much concern for privacy as you do.

> In fact, the second scenario arguably provides slightly more privacy
> than the first, which is what we have now.  The reason is that in the
> second scenario, the company provides an optional mechanism for business
> mail to be recoverable, but also provides an explicit, sender-controlled
> escape clause.  The company is granting an explicit expectation of privacy
> by allowing the corporate key recipient to be removed.  With usage of
> older versions of PGP, there was really no way for the company to even
> inform the sender about whether it was going to be reading the mail.

I like the statement intent of plaintext handling flag.  It is
independent of the protocol level, and can be used for either system.

> In the third scenario, where you encrypt to the corporate key, there is
> no expectation of privacy.  All parties, the sender, the receiver, and
> the company, know that the data is being made available to the business.
> There is not much privacy here; what you have is business security.  This
> mode would be used for business documents and business communications