Re: Book on cryptography for programmers
At 03:38 PM 8/10/00, Michael Paul Johnson wrote: In case you haven't figured it out, yes, I am seriously contemplating writing such a book. There's certainly a need for defensive programming books oriented towards security functions, and crypto functions in particular. On the other hand, there's probably not much need to publish more source code of crypto algorithms, which is where most of the export control misery resides. In my own experience, the hard part of building secure software is to establish the right set of security requirements. Once a good programmer understands and implements the right requirements, the product should be OK, assuming that the serious implementation bugs have been found and fixed. Secure Computing builds some very strong stuff that way. Originally I intended "Internet Cryptography" as a book for programmers, and I emphasized the problem of identifying security requirements. The book has a list of requirements for just about every component choice in a crypto system. Also, one of the nasty parts of book writing is that of deciding what material to include and what to omit. I used the lists of requirements to determine what technical concepts to describe -- I tried to include everything necessary to explain and justify the individual requirements, and omitted the rest. But I found that the really important requirements applied as much to network administrators who simply bought stuff off the shelf and installed it. So the book doesn't have much of a programming flavor, especially since I didn't address defensive programming techniques. What would you like to see on the CD-ROM that looks like it would fit export license exception TSU (open source, no explicit requirement for payment, no key size limits)? A friend of mine bundled a CD with her book, and she found it to be a negative. The stuff on the CD was posted to a web site anyway, and the CD simply jacked up the cost of the book, reducing reader appeal. Check with your publisher -- the CD probably adds a few bucks to the production process which in turn adds $5-$10 to the retail cost. Rick. [EMAIL PROTECTED]
Re: Book on cryptography for programmers
At 03:02 PM 8/11/00 -0400, John R Levine wrote: All of the discussion of algorithms is fine, but it seems to me that the most important topic in such a book is how to avoid building yet another crypto system with a ten-ton steel door and a cardboard back wall. I would include some horror stories of failed crypto, and perhaps a few pages on how crypto systems are broken or subverted. A few pages? Chapters and chapters. You learn how to build stronger bridges by studying how previous ones fell down. You could write a good book without ever describing the insides of a block/stream cipher or a PK system. (Despite the obligatory and often cursory attempts in many treatises.) All a modern programmer needs to understand is what a library function does, the special properties it has. No programmer (vs. mathematically inclined student) needs to understand number theory to understand that the 'trick' or 'point' of PK methods is sending asymetric keys through insecure channels. No programmer needs to understand what a Feistel structure is, though they do need to know general properties of block ciphers, e.g., change any input bit and an unpredictable half of your output bits will change. Similarly for protocols, although its more likely your programmer will have to implement the protocols you describe, since (as was brought up recently) there aren't any protocol libraries analogous to the nicely packaged crypto-primitive libs out there. IMHO. (This is not to discourage including 'inner' details of primitives in crypto courses, but to argue that they're not *necessary* in an applied book.)
Re: Book on cryptography for programmers
In case you haven't figured it out, yes, I am seriously contemplating writing such a book. Please keep the good ideas coming. Oh, good. All of the discussion of algorithms is fine, but it seems to me that the most important topic in such a book is how to avoid building yet another crypto system with a ten-ton steel door and a cardboard back wall. I would include some horror stories of failed crypto, and perhaps a few pages on how crypto systems are broken or subverted. Also, you might develop a check list of do's and dont's, e.g.: * Don't try to invent a new crypto systems. Amateurs can't write secure crypto systems, as often as not professionals can't either. * Don't "improve" an existing system. * Do remember that "random" numbers usually aren't, and no amount of massaging them will fix that. * Don't assume that bad guys won't be able to read your source code. * Do have an explicit threat model so you understand why you're developing a crypto program in the first place. People obsess over credit card numbers being stolen in transit over the net, but the real threats are poorly secured DBMS back ends and merchant sites that are not what they appear to be. (Check out www.mcgrawhill.com, for example.) * Do be lazy. Before you try to write a network crypto package, for example, see if you can piggyback on SSL. SSL has its problems, but it's probably better than something you'll invent. * Do consider usability. If a crypto system issues 25 character random passwords every week, the passwords will all be written on post-its stuck on people's screens. If there's a rule not to do that, the post-its will move into the desk drawer. * Don't be seduced into doing something foolish for usability's sake, e.g., self-extracting executables with alleged encrypted data inside. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Sewer Commissioner Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47
Re: Book on cryptography for programmers
On Fri, 11 Aug 2000, John R Levine wrote: * Don't try to invent a new crypto systems. Amateurs can't write secure crypto systems, as often as not professionals can't either. By the way, I would extend this to include "don't try to write your own new crypto code, unless you really, really have to." Also something on how to find and use test vectors.
Re: Book on cryptography for programmers
At 04:00 PM 8/11/00 -0400, dmolnar wrote: On Fri, 11 Aug 2000, John R Levine wrote: * Don't try to invent a new crypto systems. Amateurs can't write secure crypto systems, as often as not professionals can't either. By the way, I would extend this to include "don't try to write your own new crypto code, unless you really, really have to." Also something on how to find and use test vectors. Good suggestions. Actually, I think that rather than a flat-out "don't try to write your own," a listing of what it takes to do it right, together with pointing out the existence of free or inexpensive libraries that already do what you want to do, should be most effective. The same goes for cipher design. Some people actually do it well, but only after they have studied what was done before, tried cracking a few, etc. I'd really like to get people to think about sensitive data life cycles, too. Good cryptography can be so easy to defeat with simple blunders in applications. ___ Michael Paul Johnson [EMAIL PROTECTED]http://ebible.org/mpj
