Timothy C. May writes:
Yes, I read your proposal. The "hooks" term is not my coinage, but refers to this general idea. I urge you to read what others, including companies, have had to say on this matter. Much of the debate on "interoperability" revolves around details of entry points to crypto modules and such hooks.
No point in arguing with Jim on this anymore, so I won't.
I agree. It does bring to mind an idea, though. Netscape builds an exportable system by choosing a random 128 bit number and then just including 88 bits of it in plaintext. This means one of two things. Either there's a field which holds the "key", but the export version stores 88 bits plain + 40 bits cipher, and knows this structure, or there's a field which holds the 128 bit enciphered key, and a second field which holds the 88 bits of plaintext key. In the latter case, a patch which modifies the code which stores the 88 bit plaintext field to write all zeros would be almost trivial. Just over-write the store instructions with noops, most likely. In the former, the patch would be more significant, but still possible. You'd disable the "write the plain" part and extend the "decode the cipher" part to decode all 128 bits --- probably just a loop test. Either patch for a given system should require less than a page of explanation. I wonder how the ITAR would view this.