I find it difficult to agree that Netscape is an example for anything
interesting to this discussion.
There is no ROT13.DLL, no ROT13 API, and you cannot trivially replace
the ROT13 algorithm in Netscape with a significantly better one.
There's nothing hook-like about the way Netscape does ROT13. It's very
firmly hard-coded, and due to the tiny size of the algorithm, probably
very difficult to actually _find_ in the code unless there's actually
something like "rot13_decrypt()" in the symbol table.
ROT13 (in Netscape) has no key management API, or parameters of any kind.
It's difficult to see how it could be used for practical cryptography
given a key length of zero bits. You can get export licenses for
cryptosystems that only support one key that is already known to
the general public fairly easily; easily enough that I suspect even
U.S. bureaucrats will simply waive the usual paperwork, as long as you
don't advertise your product as a cryptosystem. If this were not true,
error-correcting codes and data compression would be cryptography too, as
would an ASCII-to-EBCDIC translator.
-- I don't speak for Corel, I just work for them. Use zygob@corel.ca for work, zblaxell@furryterror.org for play, and zblaxell@feedme.hungrycats.org for PGP. PGP fingerprint: 01 94 0F B3 46 B7 71 C3 D4 98 39 99 1B 34 45 A1 PGP public key: http://www.hungrycats.org/~zblaxell/pgp-public.txt- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/