Re: More FUD from First Virtual

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... :)

Excerpts from mail.nonpersonal: 10-Dec-95 Re: More FUD from First Vir.. "Ed Carp"@netcom.com (5360)
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
This is exactly right. In fact, it isn't even just bad programmer decisions; some of the complexity is really inherently needed for security. PGP's notion of who you trust to certify keys, for example, confuses the heck out of naive users, who want to "trust" anyone they believe is a good person, not just people they believe are sophisticated enough to sign keys. It's really hard to explain to some people why they should say, "No, I don't trust Grandma." What a lot of people don't seem to realize is that, in crypto software, there is a fundamental tradeoff between usability and security. You can simplify PGP (or similar software) to the point where it's easy to deal with key management, but it will then be far more susceptible to compromise. Key management is the Achilles heel of crypto-for-the-masses. I know there are some people who want to shoot the messenger, and who think that by stating this fact, I am declaring myself an opponent of cryptography, but the fact is that my company has been using PGP very heavily internally for almost 2 years, and we think we've managed our keys securely, but it has taken a lot of effort and user education. The experience has left us more skeptical than ever about secure key management by and for millions of non-technical customers. -------- Nathaniel Borenstein <nsb@fv.com> | (Tense Hot Alien In Barn) Chief Scientist, First Virtual Holdings | VIRTUAL YELLOW RIBBON: FAQ & PGP key: nsb+faq@nsb.fv.com | http://www.netresponse.com/zldf

-----BEGIN PGP SIGNED MESSAGE----- An entity known as "Tense Hot Alien in Barn" wrote:
This is exactly right. In fact, it isn't even just bad programmer decisions; some of the complexity is really inherently needed for security. PGP's notion of who you trust to certify keys, for example, confuses the heck out of naive users, who want to "trust" anyone they believe is a good person, not just people they believe are sophisticated enough to sign keys. It's really hard to explain to some people why they should say, "No, I don't trust Grandma."
What a lot of people don't seem to realize is that, in crypto software,
***********************************************************************
there is a fundamental tradeoff between usability and security. You can
simplify PGP (or similar software) to the point where it's easy to deal with key management, but it will then be far more susceptible to compromise.
I'm glad that you are willing to state this opinion, Nathaniel, and take the flack that you are taking. I think that as the goals of cypherpunkism (ewww... I just invented a new "ism"...) *really* pertain to the *use* of cryptography by large groups of people-- and not merely to the mathematical details of cryptography-- that this issue is going to become overwhelmingly important in the very near future. I challenge you, however, to go beyond pointing this problem out and start suggesting some approaches to alleviating it. With your experience in doing security for a successful Internet transaction system, I would hope that you have valuable insights which can benefit all of us. To get to the point, I want to know if this "fundamental tradeoff" that you refer to is in fact *fundamental*. That is to say: is the product of the "security factor" and the "usability factor" a constant? Or are there methods which can be practically implemented to make strong cryptography easier for Joe Average to use without exposing Joe to unnecessary risks? I'm sure in a trivial sense that there are some such methods. For example (to pick on everyone's favorite crypto-for-the-masses), if PGP v1 and v2 had come in a nice menu-oriented shell, or with a nice API, then a hell of a lot more people would be using PGP now, and without reducing its effectiveness as far as I can see. I'm sure that the PGP guys are aware of this problem, and I am looking forward (as I'm sure many of us are) to PGP v3 with much anticipation. But this kind of gooey "user friendliness" is not sufficient to make crypto *really* convenient to learn and to use, nor is it sufficient to make Joe Average's use of crypto really secure. (Note the extreme sparsity of the current PGP Web O Trust, and the oft-lamented weakness of Joe's passphrase.) I have made a clumsy first shot at envisioning the kind of strong, convenient crypto that could perhaps bring the capabilities that we talk about here to the masses. I submitted this article to cpunks last week entitled "My conception of the ideal encryption tool for the masses", and it was picked up Robert Hettinga and echoed to his e$pam list. Unfortunately I have not received a single response to this article either in personal mail or in public. Was my article so poorly written? Or are the cpunks failing to realize the importance of the usability/security issue? I sincerely hope that Nathaniel and others can make progress in addressing this issue. Ultimately it will be as important as any issue in cryptography. Regards, Bryce P.S. I just went and re-read "My conception of the ideal encryption tool for the masses" and I think I failed to make something clear. The crypto device that I envision is *not* just useful for buying a pack of cigarettes at the grocery store. I could imagine it being used for *every* user-authentication purpose. You sit down at a terminal, plug your pocket-crypto-box into it, and read your private e-mail. You walk into a secure building, pass your pocket-crypto-box in front of the infra-red IO device, and the door opens for you. You negotiate a million-cyber-credit deal, you plug your pocket-c'box into the Net, and sign the contract. Etc. etc. In short, for the vast majority of your crypto needs you depend *entirely* upon the pocket-c'box and not upon passphrases and floppy disks. P.P.S. I am aware that this makes a physical attack upon your c'box into one of the few remaining viable attacks. I recommend that everyone carries a handgun next to their pocket c'box. Deadman switches, good police forces and other physical security, etc. will also be important. Since this technology is empowering individuals, it is also increasing the value of loot than can be gained by robbing an individual. Alley-bash the right person and you might be able to steal a personal fortune. Another issue that we who seek a better future through technology need to address. P.P.P.S. I can see that there is a major problem with my idea regarding the IO between the pocket-c'box and the user. Perhaps the pocket-c'box will have to come with trusted IO hardware (screen, keyboard, pointer-device, audio, vox-recog... but I digress...). P.P.P.P.S. Also note that the pocket c'box should probably hold many of your pseudonyms (i.e., many of your pseudonyms' private keys) and your Chaumian pseudonym-exchangeable credentials. P.P.P.P.P.S. Remember those under-$600.00 netstations? Even if they don't pan out this year, they will soon. And then they will move into our pockets, and into our wristwatches, etc etc. The cypherpunks need to be ready to offer Joe a *secure* computer to put into his pocket, so that he is carrying new capabilities and renewed privacy in his pocket, rather than carrying a little chunk of Big Brother. signatures follow "To strive, to seek, to find and not to yield." -Tennyson <a href="http://www.c2.org/~bryce/Niche.html"> bryce@colorado.edu </a> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.01 iQCVAwUBMMyPLfWZSllhfG25AQHPRQP/fwhKqyUdOv2/t/YCc68GQrNMOhCT69KE PVE27Fp3CYnx+lGgzynnh1kr9DlH/bOOQRGf+fjqbPswr7PDHUoMaTAnBFr8gzf3 eXPd9moyixjNvHXacMpl0I5A/0tr6Lt2N/L5FUTyMf5zecMzbEbuKyiQE8pOYajx COKJyTTk794= =4spo -----END PGP SIGNATURE-----

Excerpts from mail.nonpersonal: 11-Dec-95 Re: Usability of Cryptograp.. Bryce@taussky.cs.colorad (6455)
I challenge you, however, to go beyond pointing this problem out and start suggesting some approaches to alleviating it.
Actually, this was something I was strongly considering doing as a major new venture *until* Einar Stefferud introduced me to Lee Stein and we realized that you could do payments without any cryptography at all. That, as you have seen, turned into a fairly major distraction. I'd still like to get back to usable crypto some day, however. There are about a gazillion *easy* ways to make crypto software more usable. PGP is a *great* starting point in this regard, as almost any user interface change is an improvement. :-) What's less obvious, and most critical, is how to map the complexities of key management onto a usable interface. What few ideas I have in this regard are, well, ones I'd really like to productize some day, which makes me a bit reluctant to suggest them publicly at this point..... I guess the one hint I'll drop is that the art of designing good user interfaces usually comes down to choosing the right abstractions or metaphors. -------- Nathaniel Borenstein <nsb@fv.com> (FAQ & PGP key: nsb+faq@nsb.fv.com) Chief Scientist, First Virtual Holdings VIRTUAL YELLOW RIBBON==> http://www.netresponse.com/zldf
participants (3)
-
Bryce
-
Ed Carp
-
Nathaniel Borenstein