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: What would you like to see in a book on cryptography for programmers?
On Thu, 10 Aug 2000, Michael Paul Johnson wrote: What would you like to see covered in a practical book on cryptography for programmers? - Some fundamentals of groups and fields. - Provide all your code examples on the web. At 03:37 PM 8/10/00 -0400, dmolnar wrote: * Discussion of crypto libraries available (say an updated version of Shostack's comparisons), with attention to licensing issues. Discussion of multi-precision integer libraries available for various languages. Also their performance on various OS and chip combinations. * What is and is not provided by a library. What should a programmer expect to write? what should he or she certainly not try to write? - A general discussion of ways of moving data through programs : besides the standard "read N more bytes, call crypto function, output", it's worth looking at Raph Levien's stream-oriented libraries, as well as OpenSSL and other packages. - Environments crypto applications will be used - batch file applications, real-time speech/video, file system drivers, browser plugins, TCP/UDP daemons - differences in handling data flows and memory management, ways to screw up. - A discussion of parameter negotiation techniques - obviously different for batch and interactive connections. - Threat scenarios for everything - the Photuris papers have some good discussion on designing protocols to avoid resource-burning DOS's. * Practical details of encoding schemes which may come up in practice (such as what ASN is, how to use it, whether you need it, etc). - Not just ASN and how to avoid it, but also portability, representation of simple numbers and strings (e.g. the benefits of PGP's ugly compressed number approaches and why you shouldn't use them :-) Stealthy vs. non-stealthy representations, etc. * Lots of examples of how to screw up in subtle ways. Either cryptographically (e.g. not verifying that a particular element is a member of a subgroup or something else sneaky) or with the language (buffer overflows). Especially examples of tempting, but wrong, things to do. Some theoretical focus on snake oil - particularly material about combining algorithms, and about combinations of LFSRs or other simple PRNG algorithms not being any stronger than the basic algorithms, since this is a popular snake oil approach. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
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
What would you like to see in a book on cryptography for programmers?
What would you like to see covered in a practical book on cryptography for programmers?
Re: What would you like to see in a book on cryptography for programmers?
On Thu, 10 Aug 2000, Michael Paul Johnson wrote: What would you like to see covered in a practical book on cryptography for programmers? * Practical random number generation -- /dev/random, entropy gathering daemon, Yarrow, etc. Some examples of bad random number generation to put the fear of JHVH-1 into the reader. Places to find code for doing practical random number generation. Places to look for updates and bug reports. * How to design a program in such a way that it's easy to upgrade crypto involved. * Quick rundown on what crypto primitives exist, the most common kinds used in each application, and "how to decide between primitives." Mention the controversy over key sizes (c.f. cryptosavvy.com and last RSA Bulletin for starters). * "War stories," as in Skiena's _Algorithm Design Manual_ may be worth looking at, but may be too informal for some tastes. Certainly real-world examples of a project started and finished using crypto would be relevant (for an extreme example of this, _Clouds to Code_ focuses on a single project for the whole book). Preferably projects which address common applications like logging in (although logging in already has ssh and so on, so maybe something else). * Writing your own code vs. using a crypto library. * Discussion of crypto libraries available (say an updated version of Shostack's comparisons), with attention to licensing issues. Discussion of multi-precision integer libraries available for various languages. Also their performance on various OS and chip combinations. * What is and is not provided by a library. What should a programmer expect to write? what should he or she certainly not try to write? * Memory management for paranoids. General discussion of swap files and so on, then specific examples of how to do Windows and/or linux memory management. * Practical details of encoding schemes which may come up in practice (such as what ASN is, how to use it, whether you need it, etc). * Explanation of the PKCS standards, what they are, how to find them, whether you need to conform to them, etc. Ditto for IEEE 1363 standards, ISO, whatever. Some real world perspective on which parts of the standards make sense and which don't. (e.g. "safe primes") * Information on "where to find standards" and "where to look for new information on breaks in systems." Some idea of how to find and interpret results like the ISO-9796 padding breaks. * Speaking of which, it should cover padding. OAEP would be neat. Briefly mentioning the security proof for OAEP would be very cool, but I suppose it's not strictly necessary. * All the _Handbook of Applied Cryptography_ type material on good ways to generate prime numbers and other encryption parameters. Maybe in smaller scope than the HAC (you might not need to include provable prime generation for instance), but explicitly specified at each step. * Fast algorithms for common operations, like modexp. Precomputation algorithms. Source code for such things. Ditto for things like DES; explain what bitslicing is and how it works. * Lots of examples of how to screw up in subtle ways. Either cryptographically (e.g. not verifying that a particular element is a member of a subgroup or something else sneaky) or with the language (buffer overflows). Especially examples of tempting, but wrong, things to do. * Real-world examples of systems which screwed up due to protocol or programming errors. * Some discussion of "speed vs. security" tradeoffs, with specific reference to such things as using e=3 for RSA, moduli of the form n = p^2 q, and so on. Try to distinguish tricks which almost certainly don't affect security from those which might from those tricks which certainly do. -David Molnar
Book on cryptography for programmers
Thank you for the good comments, so far. In case you haven't figured it out, yes, I am seriously contemplating writing such a book. Please keep the good ideas coming. I need someone who is crypto-literate to help review what I write, to help keep me honest, point out stuff I may have missed, and generally help me be clear and accurate. If you (or someone you know) would like to be a technical editor, my publisher would like to talk to you. Email me for details. The benefits include: * Helping spread GOOD crypto-knowledge to programmers in general, thus reducing the average snake oil concentration in applications they write. * Contribute to exercising First Amendment rights (lest they atrophy), and contribute to a book/CD-ROM set for international distribution. * Fame and glory, and your name mentioned in genuine ink-on-wood-pulp print. * A preview of a cryptography book and a free copy of the finished work. * My publisher may even pay you some token amount for these services. Is anyone interested in technical editing? 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)? ___ Michael Paul Johnson http://ebible.org/mpj
