CDR: Re: Lions and Tigers and Backdoors, oh, my...

[David Honig]

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