Kent Crispin <kent@bywater.songbird.com> writes:
On Sat, Oct 18, 1997 at 08:48:56AM +0100, Adam Back wrote:
Jon Callas <jon@pgp.com> writes:
[...]
My reasoning is this: as PGP Inc can not justify expense on such developments, my CDR proposal would be much safer for them to implement because it requires no steganography support, or other privacy patches to provide protection against abuse of the software for uses other than PGP Inc's designers intentions.
You keep talking as if your CDR proposal is other than vaporware. So far as I have seen you don't have a proposal, you have a wish.
I have described the CDR proposal in some detail, and have been able to counter all arguments raised against it. It is vaporware, but there are people who are offering to implement it as an extension to systemics PGP capable library as a demonstrator for the OpenPGP standardisation process to show how it would work in practice. You do have a point in that I should collect my arguments and write a paper describing the tradeoffs. I am in the process of doing this, and will be interested in yours and others comments on this proposal.
However I simply posit that if you live in a scenario where everyone you would like to communicate is forced to operate under your combination: for example the local laws state all businesses and ISPs insisting that they use pgp5.5 policy enforcer and turn on strict flag.
This possibility seems to be being discounted as unrealistic, or at least as being optional, because you can by pass it.
It does seem rather unrealistic. It would essentially involve replacing the entire email infrastructure, at a significant cost, and a rather sweeping suite of further laws that restrict the use of encryption to only PGP, forbid me running sendmail on my linux box, etc, etc
I fail to follow your argument. Could you explain further? I am very interested in discussion of the realism of scenarios for ways that GAK might be enforced in various types of regimes examples being perhaps: - Singapore hi-tech, but somewhat authoritarian government - US, UK hi-tech, government interested in installing GAK (with euphamisms being used such as TTP (UK), "Key recovery"/"key escrow" (US)). - Muslim countries, some oil rich, largely I think currently - France with current position of no use of crypto without license (not typically availble), low enforcement rate (individuals use crypto with very low likelihood of prosecution), but more recent moves to allow unlicensed crypto which has mandatory access. In what way does replacing the sendmail infrastructure have relevance? You can always communicate in the clear so I am not claiming you can not commmunicate, just that there are interesting interactions between deployed software bases and different jurisdictions with different legal restrictions on cryptography (ranging from none to weakly enforced mandatory access, to heavily enforced mandatory access to ban on cryptography). If you consider this legal framework, the dynamics of the ways that you can best estimate GAK will be introduced, and the likelihood for each jurisidction, the enforcement rate, severity of penalty for failure to comply, you have a very complex system. I would be interested to see comments on these issues, and what issues this raises for protocol designers and software implementors. My GAK resistant design principles attempt to provide useful rules of thumb in making individual software systems, international standards, and the distributed system formed of the deployed user base, and enforcement rates, severities maximally resistant to GAK. http://www.dcs.ex.ac.uk/~aba/grdesign/ My claim is that software implementations, and messaging standards such as OpenPGP are not neutral in this process. I think this is a relatively obvious statement, which most would agree with. I know that PGP Inc has spent a lot of time considering alternatives on these kinds of issues, and on privacy issues.
I can not see that being able to by pass it helps you in my scenario if a) you will be detected when you do bypass it because the law enforcers will discover they can't recover plaintext;
This implies a law against using any other form of crypto, period. If such a law is passable the exemption for PGP's protocol will really be immaterial. That is, Yes, under an extremely draconian regieme, extremely draconian things are possible.
There are regimes which would like to allow the government to read all communications where it would not be practical to outlaw encryption because many people can demonstrate a business case for it. You live in one such regime: the US. I live in another such regine: the UK.
and b) you have a "choice" of not being able to communicate with anyone, because in practical terms you have a need to communicate.
Implies that *all* other forms of communication have been outlawed. Completely unrealistic.
It does not imply that at all. If you presume that you wish to communicate securely, faced with the above scenario, you are faced with the choice I described: don't communicate at all, or communicate insecurely.
Adam, it is a complete and utter waste of time to debate this.
Why? I shall continue simply because I consider I have no moral alternative, than to try to explore more GAK resistant variants of CMR, or additions to CMR. Or to explore the CDR alternative approach as a plausible alternative more resistant to GAK take over. If you have any specific objections to my technical points, or strategic analysis of usefulness of the two proposals in frustrating government mass email snooping I would be interested to have you discuss them.
What would *not* be a waste of time would be more concrete proposals. Whether PGP implements something is a separate question -- I would like to get back to the question of designing a better email encryption system.
That is a worth while endeavour independently. However PGP Inc has financial and implementational constraints (such as plugin APIs, and so forth) which it naturally must work within. Asking more than this is not reasonable; these are the laws of gravity in the problem space. To produce something which meets PGP Inc's design constraints seems much more valuable to me than independent freeware or payware attempts to explore alternative approaches simply because PGP is likely to have the largest deployed base. Increasing the resistance of PGP Inc's systems by even a marginal amount is therefore automatically valuable.
Your reencryption scheme fails because of the management of the short term encryption keys, among other things.
I presume you are here referring to my suggestion that forward secrecy would make the system more resistant to GAK take over. PGP already has a mechanism to deal with short term encryption keys: the expiry mechanism which has been available starting with pgp5.0. The only novel suggestion relating to this is to reduce the expiry period, to reduce exposure of keys. This does not seem a radical proposal. It is independently a good security improvement. Tim May has suggested that the simplest way to deal with the problems of recovery is just to store the received email in clear text. If PGP would like to enhance security of email archives by storing them in encrypted then CDR is one practical way to do that.
Here's another approach I will toss out, without thinking through:
How about formalizing superencryption, or tunneling? That is, treat CMR traffic as a transport medium for messages that are themselves already encrypted. The "key" idea here is to allow layering of non CMR traffic over CMR traffic. All the code for both is obviously already in PGP, with a little glue and perhaps some minor protocol mods...
This is a good suggestion. It would be an improvement over allowing CMR traffic to appear in the outer layer. Jon Callas, Attila T Hun, and Bill Stewart were discussing variations of this. My suggestion for forward secrecy could also be used in this way, and has similar motivation, but is not necessarily end-to-end, as I gave specific examples in my previous reply to you attempted to show. A hybrid approach like this would be somewhere between the two systems in resistance to government abuse. It is a definate improvement. Please don't give up on the debate as threatened above Kent; constructive ideas like this are useful as they explore a wider spectrum of properties in the proposed system variants. 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`