From: "Ed Carp" <ecarp@netcom.com>
Date: Sun, 10 Dec 95 12:33:36 PST
To: Adam Shostack <cypherpunks@toad.com (Cypherpunks Mailing List)
Subject: Re: More FUD from First Virtual
Message-ID: <199512102134.PAA19064@khijol>
MIME-Version: 1.0
Content-Type: text/plain


> From:          Adam Shostack <adam@homeport.org>
> Subject:       Re: More FUD from First Virtual
> To:            khijol!netcom.com!ecarp@homeport.org
> Date:          Sun, 10 Dec 1995 13:08:29 -0500 (EST)
> Cc:            cypherpunks@toad.com (Cypherpunks Mailing List)

> Ed Carp wrote:
> 
> | Adam Shostack <adam@homeport.org>
> | > jim bell wrote:
> | > 
> | > [Good points about cost of transactions deleted]
> | > 
> | > | The answer, I think, it that there would be no problem finding people to
> | > | take that risk in exchange for the return, ESPECIALLY if they have some
> | > | input into the design (level of security) of the system.  They might insist
> | > | on 2048-bit RSA keys, instead of 1024-bit, for example.
> | > 
> | > 	(I know its only an example, but...)
> | > 
> | > 	Key length is not what is needed for better security; more
> | > solid code and better interfaces are needed.  (I might also argue for
> | > hardware keys that are more difficult to steal..)
> | 
> | Nonsense.  The code is pretty solid, the interfaces aren't very 
> | difficult.  What is needed is better human management of keys.  Why 
> | brute-force, why look for weak keys, why bother calculating how much 
> | safer 2047-bit keys are rather than 1024-bit keys when someone can 
> | look on your HD and find your secret key, when they can open your 
> | desk drawer and find your pass phrase or password, when they can 
> | guess that you used your wife's maiden name as your password?
> |
> | Adam, I don't understand why you wrote nonsense in the first 
> | paragraph, then followed it up with textbook attacks such as:
> 
> 	I use PGP becuase its pretty good, but if I was going to trust
> all my money to it, I'd want better code (especially in key
> management.  And the Mac port needs a few man months of work. ;) I
> don't know how solid the code is in the ecash client.  I do know that
> Netscape & Microsoft can't seem to ship decent code.   (This is a
> reflection of the way the industry has evolved; the first system to
> require a bigger processor due to creeping featuritis gets the most
> market share.   Quality of code seems to be unimportant.)  No flame at
> Netscape here; they're doing what the market, conditioned by MS to
> never expect bug free code, seems to want.

As I understand it, the problems in the code aren't the result of the 
underlying algorithm being flawed, but a flawed implementation, 
especially in the areas of key management, RNG, and the amount of 
information revealed in the final encrypted product.  As far as 
anyone can tell (unfortunately, as BS pointed out, we don't have the 
mathematical tools to prove one way or the other that RSA or BBS or 
any of that algorithmical "stuff" is secure or not) the algorithms 
are secure.  The problem can almost always be traced back to either a 
poor implementation or poor QA/QC, something that TQM and all the 
current management buzzwords are going to do nothing to fix.

> 	Further, the interfaces are not decent.  Ever tried teaching
> your mother to use PGP?  I have a lot of smart freinds; a lot of them,
> while understanding how easy it is to read mail in transit, haven't
> found a PGP front end thats easy enough to use that they will use it.

I wasn't referring to the user interface, I was referring to the code 
interface, but I'll comment on the user interface.

For most people, crypto is *hard* to understand.  If it's easy to 
understand, you're probably making a LOT of assumptions about key 
management for your user, and some of those are almost certainly 
going to be bad ideas - that's why PGP gives you such flexibility.  
If you want to shoot yourself in the foot with PGP, Phil will 
certainly let you, but not without warning you first.  IMO, taking 
the complexity out of the key management process will almost 
certainly lead to designers and programmers making bad decisions 
about how the process should work, and that's going to lead to a 
whole host of problems, most of which will come home to roost at PZ's 
doorstep.  Yes, you and I and most people on this list know that this 
is bullshit, but you'd be amazed at what people will believe - 
witness the "ASCII virus" crap we all had to endure a few months 
back.  There were a lot of people who actually believed it.

I haven't found *any* PGP code that was well-integrated into anyone's 
mailer (including my own).  Maybe the code for Pegasus is different - 
I certainly hope so.

I, as well as many people, have got wrapper scripts around vi and 
emacs and pico that will do automatic encryption/decryption/signing 
for elm and pine, but that's not Windows.  If I could get my mother 
to use UNIX, she'd find that she can send and receive 
encrypted/signed email as easily as she can unencrypted/unsigned 
email - the back-end work has all been done for her.  The problem is, 
she'd rathet "do Windows" - the overall OS interface (if one can all 
Windows an OS) is a *lot* easier to work with and understand than 
UNIX is.  So, she's stuck with Pegasus and Eudora and such - and no 
way to do encryption and signing without having to go to a lot of 
trouble.

> (This is not an invitation to send me your favorite GUI to PGP
> (although if anyone has a web page of all/most of them, with reviews &
> comments and maybe even screen shots, I'd like the URL.)

I would, too... :)