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`