And so it begins
This came third-hand, Sandia - DOE - me "Per the Office of Diplomatic Security, Department of State, Egypt, France and Russia have instituted the following: Laptop computers with encryption capability are considered "SPY TOOLS" and will be seized or denied entry into the country." We understand that Kazakhstan has a similar position. "With encryption capability" sounds a little vague, but that's par for the course. There's also an old note on this subject wrt. Russia at http://travel.state.gov/gps.html.
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
And so it begins
Only laptops, eh? Encrypted media are not mentioned, obviously. And clearly every modern OS (IPsec, ssh, even Winders' weak encryption) has "encryption capability". Spytool Netscape, who would have thought. Matt Crawford writes: This came third-hand, Sandia - DOE - me "Per the Office of Diplomatic Security, Department of State, Egypt, France and Russia have instituted the following: Laptop computers with encryption capability are considered "SPY TOOLS" and will be seized or denied entry into the country." We understand that Kazakhstan has a similar position. "With encryption capability" sounds a little vague, but that's par for the course. There's also an old note on this subject wrt. Russia at http://travel.state.gov/gps.html.
from IP: Major University to Be Asked to Review F.B.I.'s 'Carnivore'
--- Start of forwarded message --- From: Dave Farber [EMAIL PROTECTED] Subject: IP: Major University to Be Asked to Review F.B.I.'s 'Carnivore' Major University to Be Asked to Review F.B.I.'s 'Carnivore' By DAVID STOUT WASHINGTON, Aug. 10 -- The Justice Department will ask a major university to review a government e-mail surveillance program that is seen as both a great boon to law enforcement and a serious threat to the people's privacy. Attorney General Janet Reno said the program, used by the Federal Bureau of Investigation and dubbed "Carnivore" because it can quickly gobble up and digest huge quantities of e-mail messages, will be studied in depth, and that the university's recommendations will be shared with the public. http://www.nytimes.com/yr/mo/day/late/10cnd-carnivore.html [be real interesting to see how ong the study takes dkf] --- End of forwarded message ---
