It is interesting to see that the proposed solutions to avoiding GAK hacks (URL:http://www.eskimo.com/~joelm/criteria.txt) largely revolve around certificate restrictions. Only keys signed with certificates from accepted escrow agencies can be used, and there is a "root certificate" used to authorize new escrow agencies. This is similar to some of the restrictions in the widely used Netscape web browser. It only accepts certificates from a limited number of agencies (actually only one which is public, the RSA spinoff VeriSign). This limitation is not based on escrow approval as in the GAK papers, but it ends up with something of the same results: interoperability with Netscape is only possible if you go through approved channels. And supposedly VeriSign does not make it too easy to get a certificate if you are not a straight-arrow corporate type. Maybe it would be good practice for a future GAK hack to try fixing these problems with Netscape. I could see two possibilities. One would be to create a patcher which would let you change the set of certificate authorities accepted by the browser. Currently the browser accepts at least one (an internal Netscape test CA) which is not needed by end users. Maybe its public key could be statically overwritten by the patch program with the public key of the replacement CA. This sounds simple and safe. The patch program can confirm that the data being changed matches the test CA. Another idea would be to patch the browser to emit full 128 bit SSL rather than the crippled 40 bit SSL it currently creates. This would be trickier as it requires code changes, but they may not be as bad as it seems. The 40 bit SSL is actually calculated as 128 bits internally. Then 88 bits are sent in the clear. We would need to skip sending those 88 bits, and also change the transmitted bytes which encode which encryption is being used. This shouldn't be too bad as it mostly would eliminate code or change some static values. The one thing I am unsure of is whether the 40 bit version sends the entire 128 bit SSL key in the RSA encrypted data (88 bits of which would be redundant, also being sent in the clear) or whether it sends only the 40 bits RSA encrypted. If the latter it would be somewhat more work to do the patch because now a larger value will have to be packed into the RSA record. If it is sending the 128 bits all the time then the patch would be much easier. This second patch is more advantageous for end users as it allows them to have strong encryption rather than the weak 40 bits which we have been breaking. The first would be a more direct demonstration of the difficulties of using certificate restrictions to limit functionality. The criteria.txt paper suggests checksumming the cryptographic routines to prevent patches like this, but generally I think such checksums can be defeated pretty easily. I doubt that Netscape currently has any such thing, though. Netscape says they will allow some form of user specification of certificates in a future version of the browser, but they have been saying this for quite some time and still it is not here. Hal