At 06:48 PM 9/27/00 -0400, Tim May wrote:
There is no real reason for crypto to be built into complex products, at least not when those products are well-suited for handling text (and even files).
...
To wit, who really cares whether Netscape 4.08 or 4.07 has crypto built in so long as a robust, non-trapdoored crypto program is available/
We lose a lot of the advantages of orthogonality (independent programs, modules) when we seek "all in one" solutions. And we make the job of the NSA and SDECE and GCHQ spooks a lot easier when we adopt all-in-one solutions.
Yes but many potential users of crypto will not put up with too many extra actions, e.g., going to a command prompt, running pgp, opening the ciphered file, cutting and pasting. You can argue that, e.g., they should all be shot :-), but isn't the goal to get more traffic (even uninteresting traffic) encrypted? Modularity *is* useful for keeping things simple enough to analyze, but isn't a library with a well-defined API sufficient? [If your OS supports it, there might be slightly more decoupled ways (vs. linking) to talk to the crypto process, e.g., pipes, clipboards, rpc. Is this more in line with what you're thinking?] How would you modularize SSL? Distribute a proxylike program that an app talks to when it wants to go secure? How do you modularize PGPfone? PGPdisk? Even in a bloated integrated app, clean modular design can keep the analysis tractable. If the app talks to the crypto module, you'll likely have to trust the app whether the crypto is linked-in or whether it is an secure isolated process (after all, the app is capturing/rendering the plaintext..) It does create a single-point-of-failure if everyone uses the same library (or other independent 'module'), but on the other hand, everyone rolling their own is likely to introduce more fatal flaws. Curious what the alternatives are, dh