Re: Singaporean control freaks & CMR

Adam Back writes:
> The problem is that pgp5.x is both an email encryption system and a
> file encryption system.  So PGP Inc argue that they need the recovery
> features for files.  Well OK, but for emails in transit?

Define "in transit".  Specifically, when exactly does email stop being
"in transit".  When it is received on a mail server?  Transfered to the
destination computer?  Displayed to the user?  Saved in an archive?

How long might a piece of email spend "in transit"?  Compare and contrast
with the amount of time a piece of data from an encrypted phone call
spends in transit.  Or an SSL protected HTTPS web transaction.

Do you understand the difference between transit times of a fraction
of a second and of days or weeks?  Does this suggest any differences in
the need for recovery of encrypted data "in transit"?

Not all communications are alike.  The longer data spends "in transit"
the more need there is for recovery features.

* Anonymous wrote:
>Do you understand the difference between transit times of a fraction
>of a second and of days or weeks?  Does this suggest any differences in
>the need for recovery of encrypted data "in transit"?
>
>Not all communications are alike.  The longer data spends "in transit"
>the more need there is for recovery features.

Right. Communication is 'in transit' from MUA to MUA. Stored messages on
MTAs are in transit.

Anonymous writes:
> Adam Back writes:
> > The problem is that pgp5.x is both an email encryption system and a
> > file encryption system.  So PGP Inc argue that they need the recovery
> > features for files.  Well OK, but for emails in transit?
> 
> Define "in transit".  Specifically, when exactly does email stop being
> "in transit".  When it is received on a mail server?  Transfered to the
> destination computer?  Displayed to the user?  Saved in an archive?

It is no longer in transit for the purposes of encryption when you
have decrypted it.  At that point you can store it in unencrypted
form, or in encrypted form with recovery information.

> How long might a piece of email spend "in transit"?  Compare and contrast
> with the amount of time a piece of data from an encrypted phone call
> spends in transit.  Or an SSL protected HTTPS web transaction.

One week would cover it mostly?

You can even escrow the communications-only keys if you're really
bothered about people going away for a week and forgetting their
password on return with a few encrypted messages queued up.  Even that
is much better than CMR.

You might want to implement a evenings hacking's worth of PFS
transport level security if you were going to do that to reduce the
risk.

> Do you understand the difference between transit times of a fraction
> of a second and of days or weeks?  Does this suggest any differences in
> the need for recovery of encrypted data "in transit"?
> 
> Not all communications are alike.  The longer data spends "in transit"
> the more need there is for recovery features.

Sure, I can agree with that.

The point of CDR is to make sure the attacker has to attack the
endpoints to get plaintext.  The danger with CMR is that it includes
the recovery information in the message.

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`