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
Using signature-only certs to authenticate key exchanges
If I use a signature-only cert to authenticate a D-H key exchange (e.g., in IPSEC, or SSL with ephemeral DH ciphersuites) am I in violation of any licensing condition and/or, when applicable, export regulation? I'm asking because MS seems to suggest that for Win2K's IPSEC stack a signature-only cert would suffice: http://www.microsoft.com/WINDOWS2000/library/planning/security/ipsecsteps.as p [...] Here are the requirements for the certificate to be used for IPSec: Certificate stored in computer account (machine store) Certificate contains an RSA public key that has a corresponding private key that can be used for RSA signatures. Used within certificate validity period The root certificate authority is trusted A valid certificate authority chain can be constructed by the CAPI module [...] Cheers -- Enzo
