Duncan Frissell <frissell@panix.com> writes:

Timothy C. May wrote:

...

But is this even possible, to make a GAK system "not interoperable" with, say, PGP? Unless the GAK system has some sort of entropy analyzer, and can recognize high-entropy sources which it presumes to be encrypted data (*), one can of course PGP-encrypt a text file and then GAK the resulting file.

I took it to mean that they were saying that an approved program on one end of a communication exchange could not exchange encrypted messages or established an encrypted session of some kind with an un approved program on the other end. Not trying to outlaw superencryption (PGP on both ends using a GAKed channel) but GAK on one end working with an unapproved system on the other end. A ringer GAK-work-alike that would defeat the intent of GAK. I don't know if the government can prevent that with a software-only system or indeed if half a secure system can be made completely secure.

The breakout session that I was in was directly charged with this issue. We talked at length about it. There were NIS&T and NSA folks at the session. The consensus was that the Government wanted to prevent a version of PGP that was export enabled (GAK and short keys) that would be backward compatible. The group stated strongly that this was a "non starter." That is, it was unacceptable. Vendors wanted "sales appeal." That means compatibility with existing software. And compatibility with existing export-approved systems. [DES has been exported to "friendly" countries with strict controls.] And criteria #2 specifically outlawed superencryption. No DES | TRAN | DES | TRAN | DES. They were serious. talk to CME, he was in that session. I believe that this criteria is stupid, or at least ill-advised. But the govies insisted. All the more justification to ignore the US rules and develop off-shore. Pat Pat Farrell Grad Student http://www.isse.gmu.edu/students/pfarrell Info. Systems & Software Engineering, George Mason University, Fairfax, VA PGP key available on homepage #include <standard.disclaimer>