
Attila T Hun <attila@hun.org> writes:
There is one all important consideration in this debate:
would you rather have PGP, Inc. with its preeminent stature in the defense of freedom, freeware, and privacy as well as an established, TRUSTED product defining THE system which meets the need of the free world business, but is not selling out to GAK or CAK?
or, would you rather see IBM, HP, TIS and others with their GAK products and potentially even backdoors? are any of these vendors even planning to give us source code so we might have a warm and fuzzy feeling until someone blows a hole in it 10 years from now?
_Of course_ we all agree that it is much better to have PGP Inc implement a CAK system than IBM, HP, TIS or other GAK-sellout'ers. Attila, I generally liked your rant, and agreed with pretty much most of it. However I would repeat what I said to Jon Callas with his nicely written rant which started this thread on `attitude' (modified for Attila rant relevance): : [bucko big snip] : : Well, it was a nice rant, Attila. Most of it was even crypto-correct :-) : : But the problem is you didn't address the point causing PGP's perceived : hostilities. Not once. Now as you say above, if there was no choice on how to implement CAK, well we'd all be forced to agree that PGP Inc hard no alternative but to do what they have done and implement something which can be directly used as a fully functional GAK system, because of the requirement for company availability of data. We'd feel unhappy about it, as Jon Callas himself admitted of the CMR design but acknowledging the user requirement and inevitability, in similar ways that you have been arguing for. We'd then be acknowledging the nice balances which PGP have put in as expressed by PGP's Jon Callas and Jon Seybold respectively: the principle of transparency: that PGP is recommending that companies flag mail addresses which are "company use" mail boxes where the company may be reading; and Jon Seybold's point about decentralised company escrow designs being much better than centralised ones. Both are very good points. The point is that, _of course_ we acknowledge these points; that is a complete no-brainer. _This_ is the point I am trying to get across: - If you (as a crypto software company) have users who have a requirement for data recovery of stored email (and there is a pretty reasonable business case for this), then as a company which claims to be against the dangers of mandatory GAK, you should do everything you can to make your system non-useful to the GAKkers purposes. PGP has done somethings in this direction (the two points I list above for example). But they could do more: - I have laid out a perfectly feasible design for providing a fully functional non-GAK compliant "Commercial Data Recovery" (CDR) system. I have not seen any PGPers anonymous or otherwise who have come up with any flaws in this design; nor even with any functionalities which it is not capable of meeting with similar degrees of weak tamper resistance to the GAK compliant CMR design. Did you miss that argument? I'll use the term "data recovery" to describe it to highlight the key differences between PGP's method which is Commercial _Message_ Recovery, because the "message recovery" design philosophy is a fallacy adopted by swallowing the GAKkers "key escrow" arguments. The argument that you somehow need to escrow transient communications keys to allow governments access to information stored on disks. That people swallow this argument never ceases to amaze. You will notice that there have been no technical refutations of my CDR design. I and others have I think been able to demonstrate that it is just as flexible, and to boot more secure.
[bucko huge snip]
I agree with the rest of Attila's points. 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`