At the very least one would think that the US vendors would put thier
crypto code in one DLL and document the API so someone overseas could
replace it with somthing worth using. <sigh> I guess even that is too
much to ask.
If the US government would let us, you better believe we'd do it. We have
no vested interest in helping the NSA eavesdrop on people. We make money
by selling software that meet our customers' needs, and that includes being
secure.
The strategy you describe is called "crypto with a hole", and is explicitly
forbidden by the export regs.
I don't think so. If functional code is exported in machine-readable form and
contains no "hook" calls, and another document containing a diff is separately
exported as printed materials, and therefore protected (just like PGP's code),
then it is the receptient not the exporter that added the crypto (which was in
no way "required" by the machine-readable code).
As Ned notes: "...software which was specifically designed or modified to allow
it to be used with encryption software is itself regulated. And so is, for that
matter, software which in turn references such software." But if the
machine-readable software contains no calls which are later replaced by crypto
and can function fine w/o the crypto, this should legally circumvent the regs.
This is especially handy if the crypto routines are already available offshore
w/o EAR restraint (e.g., SSLeay), since the diff file can be quite manageable
in size, I hazard to guess even for programs the size of Navigator.
--Steve