Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Encryption Books Media Security Book Reviews

Cryptography and Network Security: Principles and Practice, 2nd ed. 20

randombit has sent us a review of William Stallings' Cryptography and Network Security: Principles and Practice, 2nd ed. The book is a history of cartoons' effects on American children. Er ... rather, the book looks at applications of cryptography and in networking today. If you've read it or have comments, please add to the discussion below.
Cryptography and Network Security: Principles and Practice, 2nd
author William Stallings
pages 569
publisher Prentice Hall, 1999
rating 8/10
reviewer randombit
ISBN 0-13-869017-0
summary Cryptography and Network Security examines the practical applications of cryptography in today's networked systems
*

The Scenario

So, after reading Applied Cryptography and the Handbook of Applied Cryptography, you want to see some real systems at work. Enough with this academic stuff, you say. Cryptography and Network Security may be just the book for you. It covers Kerberos, X.509, PGP, S/MIME, IPSec, SSL/TLS, and SET, in much greater detail than you will find in books such as Applied Cryptography. This is a book for "real world" crypto. Even if this would be your first book on cryptography, Stallings provides most of the background you need to understand what's going on.

What's Bad?

There are a few rather annoying omissions in the book's coverage, including no mention of Optimal Asymmetric Encryption Padding (OAEP), which is used in many of the most important new cryptography standards, and only passing references to IEEE P1363, a very important proposed standard which has already produced copious industry and academic support.

Part 4 was less interesting, and also did not seem to delve as deeply into its topics as earlier chapters did.

What's Good?

Almost everything. Stallings' writing style makes for reasonably easy reading, though those without a good background in math and programming may have problems in the denser areas.

While the focus is on practical applications, the author gives you all the information you need. Instead of covering a large number of algorithms (most of which are never used in real applications) in a very brief manner like Applied Cryptography, Stallings examines in detail a small number of popular and commonly used algorithms, including IDEA, RC5, CAST-128, and Blowfish, and devotes a full chapter for DES. Public-key encryption is not ignored either, with coverage of RSA, Diffie-Hellman, DSA, and Elliptic Curve Cryptography.

But the really good stuff is in the second half of the book. Want a clear and thorough description of the IPSec protocols? Flip to chapter 13 and read away! Not to leave you hanging if you haven't been keeping up with the latest RFCs (for shame!), he also describes both the IPv4 and IPv6 packet formats. Similarly, in the section on S/MIME, before jumping straight into the cryptographic aspects, he helpfully first describes what MIME does, why it was invented, and how it works.

Handily enough, the book also makes a good introductory textbook. The explanations are clear, and little background is assumed. Also, there are problems at the end of each chapter which cover practical applications of and attacks on cryptographic systems.

So What's In It For Me?

If you want a good introduction to practical cryptography, get this book. It supplements the more theoretical focus of other popular books in the area, while still being fairly complete.

Purchase this book at ThinkGeek.


Table of Contents

Chapter 1: Introduction

  • Attacks, Services, and Mechanisms
  • Security Attacks
  • Security Services
  • A Model for Internetwork Security
  • Outline of this Book
  • Recommended Reading
Part 1: Conventional Encryption

Chapter 2: Classical Techniques

  • Conventional Encryption Model
  • Steganography
  • Classical Encryption Techniques
Chapter 3: Modern Techniques
  • Simplified DES
  • Block Cipher Principles
  • The Data Encryption Standard
  • The Strength of DES
  • Differential and Linear Cryptanalysis
  • Block Cipher Design Principles
  • Block Cipher Modes of Operation
  • Appendix: Bent Functions
Chapter 4: Algorithms
  • Triple DES
  • IDEA
  • Blowfish
  • RC5
  • CAST-128
  • RC2
  • Characteristics of Advanced Symmetric Block Ciphers
Chapter 5: Confidentiality Using Conventional Encryption
  • Placement of Encryption Function
  • Traffic Confidentiality
  • Key Distribution
  • Random Number Generation
Part 2: Public-Key Encryption and Hash Functions

Chapter 6: Public-Key Cryptography

  • Principles of Public-Key Cryptosystems
  • The RSA Algorithm
  • Key Management
  • Diffie-Hellman Key Exchange
  • Elliptic Curve Cryptography
Chapter 7: Introduction to Number Theory
  • Prime and Relatively Prime Numbers
  • Modular Arithmetic
  • Fermat's and Euler's Theorems
  • Testing for Primality
  • Euclid's Algorithm
  • The Chinese Remainder Theorem
  • Discrete Logarithms
Chapter 8: Message Authentication and Hash Functions
  • Authentication Requirements
  • Authentication Functions
  • Message Authentication Functions
  • Hash Functions
  • Security of Hash Functions and MACs
  • Appendix: Mathematical Basis of the Birthday Attack
Chapter 9: Hash and MAC algorithms
  • MD5
  • SHA-1
  • RIPEMD-160
  • HMAC
Chapter 10: Digital Signatures and Authentication Protocols
  • Digital Signatures
  • Authentication Protocols
  • Digital Signature Standard
  • Appendix: Proof of the DSS Algorithm
Part 3: Network Security Practice

Chapter 11: Authentication Applications

  • Kerberos
  • X.509 Directory Authentication Service
  • Appendix: Kerberos Encryption Techniques
Chapter 12: Electronic Mail Security
  • Pretty Good Privacy
  • S/MIME
  • Appendix: Data Compression Using ZIP
  • Appendix: Radix-64 Conversion
  • Appendix: PGP Random Number Generation
Chapter 13: IP Security
  • IP Security Overview
  • IP Security Architecture
  • Authentication Header
  • Encapsulating Security Payload
  • Combining Security Associations
  • Key Management
  • Appendix: Internetworking and Internet Protocols
Chapter 14: Web Security
  • Web Security Requirements
  • Secure Sockets Layer and Transport Layer Security
  • Secure Electronic Transaction
Part 4: System Security

Chapter 15: Intruders, Viruses, and Worms

  • Intruders
  • Viruses and Related Threats
Chapter 16: Firewalls
  • Firewall Design Principles
  • Trusted Systems
Appendix A: Projects for Teaching Cryptography and Network Security
  • Research Projects
  • Programming Projects
  • Reading/Report Assignments
This discussion has been archived. No new comments can be posted.

Cryptography and Network Security: Principles and Practice, 2nd ed.

Comments Filter:
  • by Anonymous Coward
    it seemed to imply that one could use mathematics to obfuscate your data as it travels across a network. This obfuscation is then undone at the receiving end, again using mathematics. The trick is, mathematically you need a very specific number (I think he called it a koy?) in order to deobfuscate the data. Attempting to calculate or guess this koy takes a long, long time. It's a nice concept, but I'm not sure how practical it is. Sounds more like a fairy tale, I'll wait for someone to actually try it.
  • I recieved this book for free from Cisco about 4 months ago. I'm sure there are a few Cisco users out here that could point out a URL to signup for the free books. I think the only requirement is that you or the company you work for is a Cisco customer, but that might be wrong.

    dennis
  • Come on, let's have some journalistic integrity here. This is like the upteenth book in a row to get an 8 out of 10.

    As far as reviews are concerned, they might have journalistic integrity. Story selection might a different issue altogether.

    I have no idea how many reviews they get sent, so it's hard to estimate what it they get bad reviews. It is rather disappointing, though, to see a trend developing lately:

    • ThinkGeek adds another book in their selection
    • ThinkGeek does not carry books that sucks (a brief look at their catalog proves this)
    • Someone reviews the book and sends the review to Slashdot.

    I'm not claiming that there is a conspiracy at work here, but since ThinkGeek is also an Andover.net company, it is sad to see the Slashdot book review section become ThinkGeek book reviews.

  • at
    www.booksnow.com

    $58.80!
  • This book is OK - we used it as the text in our graduate level (Data Security & Cryptography class). I'm a computer scientist, not a mathematician (believe me, I read Chapter 7 a lot) and I found that many of the examples glossed over small yet critical details, especially modular arithmetic, that often stumped me for hours. I resorted to using Schneier's book as a counterpart for some of the more basic stuff. Also the section on Elliptic Curve Cryptography was difficult and again, other texts were referenced frequently.All in all this is a good book, but the math-weary beware - other texts may be required to really understand what's going on.
  • I selected this book for my undergraduate class in crypto and security this semester, and have been mostly happy with it. I think everyone can find nits to pick with any book, but you've got to determine how well it served your particular purpose.

    My purpose was a good gentle introduction to crypto and security issues, and it was mostly ok for that. Personally, I would have like some other security issues discussed such as protocol failures in basic TCP/IP (SYN flooding and consequences, like how you can spoof IP addresses between mutually trusting systems, etc.), but it seems like if it didn't involve crypto it wasn't in the book (there's a lot to network security beyond crypto, after all).

    I also would have liked some system security issues discussed at least a little bit -- basics of Bell-Lapuda or BAN logic, or something like that. But again that wasn't really the author's goal here -- so I can just supplement with outside material.

    The omission of OAEP is a little more troublesome. He does talk about HMAC, but glosses over the idea of using crypto primitives to make higher-level functionality, and the proofs associated with it. With the direction of crypto research these days, I would hope that maybe in the 3rd edition he'd devote a chapter to such issues.

    Anyway, my bottom line is that it served my purpose as a textbook very well, and I simply supplemented with outside material when necessary. For the purpose of a textbook, frankly I think Schneier's book would be terrible -- very little substance on the "whys" and the "hows", and too much on the cookbook approach. That's certainly not what I want to teach -- I want to teach the thinking behind the ideas, not recipes. I'm not sure if I'd use Stallings' book for a grad course because even it doesn't go too much into the whys and the current research topics. Or perhaps I'd just supplement with more research papers and outside material...
  • Seems like everytime there is a book review here, someone is slamming ThinkGeek for being more expensive.


    It appears that by brevity may well be the soul of wit, it doesn't make for a good price comparison. Your point is the reason I did what I did. While ThinkGeek's discount was not great, I was pointing out that the other's either weren't discounted, or in one case had a trivial discount.
  • ...and I'm told you can often judge a book by its cover.
  • Do you want to shoot him now, or wait until you get home?

    I INSIST that you shoot me now! (nyaaah!)
  • Seems like everytime there is a book review here, someone is slamming ThinkGeek for being more expensive. Is that really the point? Slashdot only has a couple of ways of making money - banner ads and affiliate fees. Considering the incredible service they are for our community, I'd rather support slashdot than save a few bucks at an unrelated website.

    If you do want to save money, try bestbookbuys [bestbookbuys.com]. You can price shop for any book. I suggest we leave price comparisons to these guys and keep the discussions to the books in question.

    Disclaimer: Pinball Wizard is not affiliated with slashdot in any way and does not speak for them.

  • The effects of CARTOONS on American children sounds more interesting.

    Daffy Duck from the 30s to the late 40s was the best.

    THE BEST DAMNIT!!!!!


  • I agree with your subject line...and not much else in your post. We do need more crypto, but key-escrow is not the way to go. Neither is keeping publicly available crypto so weak that any government agency, and hence any dark lurker with sufficient processing power and inclination, could break it. I'd rather run the risk of letting a few bad guys get away than having even ONE more Richard Joule fiasco. Yes, terrorists could keep their activities clandestine. Yes, child pornographers could keep pumping out their volumes of smut (not nearly as much as you seem to think, btw). Yes, that Canadian script-kiddie who was arrested for DDOS-ing a bunch of sites could run around unchecked. But you forget - most of these lowlife scumbags you mention are so ecstatic that they've "gotten away with it" that they can't shut the hell up for fifteen seconds about it. The Canadian kid - blabbed all over AOL chat rooms about it. Chat rooms which ARE LOGGED. The terrorists who took out the World Trade Center six years ago - kept freakin' talking about it. That's how the FBI found them. The most important flaw in your logic is that it's unprovable. In a perfectly secret net, you'd have no way of proving who traffics what.
  • Hardcorebit, you appear to have done a good bit of research on the matter, and know a lot of the questions that need answering. All you have to do now is find the answers and write out explanations of the answers.

    RJH, since you'e an INFOSEC professional, you have field experience in implementing these protocols and desinging systems for security. You must have tales to tell about design and implementation decisions that were made, which ones failed and which ones haven't failed, yet.

    I say you two ought to get together and write this book that you're wishing was written. After all, "scratching your own itch" is the Free Software way.

  • Schneier has a long and very distinguished history of breaking protocols. He discovered attacks against IPSec and Microsoft VPN; I believe I saw his name on a couple of papers breaking various cellular phone protocols.

    If you scoff when you hear Schneier called a "security expert", then you don't understand what his credentials are. Is he God? No. In fact, Schneier's been flat-out wrong before (anybody here remember MacGuffin, and his latest campaign against elliptical curve cryptography?).

    But to say that Schneier is a crypto expert and not a protocol expert flies in the face of Schneier's body of published work.

    How many protocols and ciphers have -you- broken?
  • I checked ThinkGeek and noticed that the discount wasn't very much. I checked around. Fatbrain, Borders and Amazon have it listed at full price. Barnes and Noble is selling it at (I am not making this up) $.25 off.
  • by rjh ( 40933 ) <rjh@sixdemonbag.org> on Thursday April 20, 2000 @06:11AM (#1121364)
    Standard disclaimers apply, as always. (I hate living in a lawsuit-happy culture.)

    What also might be good is to include protocols which, while working today, are not scalable to future systems. Right now I'm employed by a company working in the electronic publishing market, and it's surprising how many otherwise-good ideas are completely impracticable. (The good news is, the worst offenders are all proprietary. The open systems have fared the best.)

    Last year during CRYPTO99, some IBM researchers released a paper which was lauded as having provable security. Caused a minor media uproar, up until it was broken. Turns out that if you can create an environment where just one of the assumptions behind the protocol is no longer valid, the entire protocol fell apart. I can't think of the name of it for the life of me, though. It didn't exactly impress me as being the Holy Grail, and I wasn't exactly surprised when it was broken.

    Another good example is Microsoft's Virtual Private Networking. Version 1.0 was horribly broken; version 2.0 was a considerable improvement, but since it was (is) downwardly-compatible with 1.0, it's also bug-compatible with 1.0.

    Then there's Netscape's SSL difficulties from version 3 (?). Although the SSL protocol was implemented correctly, Netscape's random number generator was deterministic.

    Then there was the telco which was using the standard C rand() function to create random session keys (company name withheld, but yes, it's a big one).

    A major credit-card company (you probably have one of their cards in your wallet) depends on nobody being able to break repeated-XOR encryption and having enough knowledge of IBM's SNA in order to eavesdrop on their network.

    ... I don't know as much about academic protocols being broken through the standard literature as I do about brain-damaged implementations of protocols. I'm a practical cryptographer, not a theoretical one. But good God, if you were to make a top ten list of the stupidest protocols (and implementations thereof), you'd spend years just trying to whittle the list of thousands of candidates down to the ten worst.

    I don't know. I'd have to think about it for a while to come up with my own list of candidates for the Provably Stupid award. Ask me again tomorrow and I might have a better idea. :)
  • by hardcorebit ( 167299 ) on Thursday April 20, 2000 @05:48AM (#1121365) Homepage
    Violent agreement on the idea of a book on
    failed protocols. I think protocol design one of the areas which is needed most and understood least in cryptography. We're a long way from Bellare's "a cryptographer is a machine which turns primitives into protocols"...

    Can we start compiling some examples of protocols, exercises, and material
    which would go into such a book?

    Avi Rubin and Matt Franklin had a course on "Protocol Design" at NYU
    http://cs.nyu.edu/cs/dept_info/course_home_pages /fall96/G22.3033.02/

    which has an list of references and some problem sets. In particular, there's a reference to
    some papers like
    J. Moore, "Protocol Failures in Cryptosystems," Proceedings of the
    IEEE, 5(76), 1988, 594-602.

    and

    P. Syverson, "Limitations on Design Principles for Public Key
    Protocols," IEEE Symposium on Security and Privacy, Oakland, CA, 1996, 62-72.

    which look very interesting.

    The differences between SSL 1.0, 2.0 and 3.0
    should be in such a book as well. Especially the
    attacks in which an adversary can force use of a weaker cipher.

    You'd probably also want a discussion of "security proofs" and "definitions of security."
    In particular, pointing out limitations in such things as BAN logic. I don't know much about specific failures here; anyone have an example?

    A while back I asked on sci.crypt about "provably stupid protocols" -- protocols where the proofs were _correct_, but according to misguided definitions. Looking that up in Deja would produce some possible examples (though maybe not protocols in the sense you may be using).

    What else?
  • by Haplo ( 6441 ) on Thursday April 20, 2000 @05:36AM (#1121366) Homepage
    I took a data security class last semester, and our books for it were this one and Applied Cryptography. AC was a better book, hands down. It seemed that everything that was in the Stallings book was also in Applied Crypto, and more. Maybe AC was just easier for me to read, or something, but if you are going to buy a book on cryptography I would recommend Applied Cryptography over Cryptography and Net Security.

    Just my $.02
  • by rjh ( 40933 ) <rjh@sixdemonbag.org> on Thursday April 20, 2000 @05:34AM (#1121367)
    I am an InfoSec consultant in real life, but I am not speaking in any professional capacity here.

    First, I've got to say that I'm glad that someone has come out with a companion to Applied Cryptography; where Applied Cryptography talks about ciphers in some detail, it's woefully light on protocols--and most of the interesting security attacks out there are protocol attacks, not cipher attacks. If the review posted is accurate, then we can use it as an adjunct to Menezes and Schneier, not as a replacement. This is a Good Thing(tm).

    Second, for all that I'm looking forward to buying this book, I think that it ignores a very rich and informative part of the subject. Why not take a book of the same size and cover failed protocols, and explain where the protocols failed and why? I like to joke that there are only three or four different protocol attacks; software authors just insist on renaming them for every new system. An awful lot of good could be done by educating software engineers about what has failed, in the hopes that people will learn and not make those same mistakes again.

    I'm grateful to Bruce Schneier and Alfred Menezes for their introductory works in crypto (and compared to graduate-level mathematics, Schneier's and Menezes' books are introductory), but I sometimes fear that they lull software engineers into a false sense of security; people think that "well, since Schneier says 3DES is secure, I can just use that and be safe". It's very tempting to do that, but security is not something which can be added into a piece of software like you can add salt to a recipe. It is a mistake to take a cookbook approach to security, which is the unintended consequence of books such as these.

    What I'd really love to see is a book which shows failed protocols, and the dangers of cookbook security.

    Having a cookbook available doesn't guarantee that what you cook will be edible.
  • by hardcorebit ( 167299 ) on Thursday April 20, 2000 @05:34AM (#1121368) Homepage

    It's a shame, but not too surprising, to hear that the book doesn't
    cover OAEP. Especially as Coron, Naccache, Joye, and Pailler have a paper in EUROCRYPT '00 about
    "New Attacks on PKCS #1 v1.5 Encryption"
    abstract at :
    http://www.eleves.ens.fr:8080/home/coron/science .html#8

    I have not read the paper yet, but the abstract is scary.

    Some background : the RSA function x^e mod n
    should not be used directly for encrypting data.
    For one thing, it's deteministic; the same x produces the same x^e always. An adversary can use this to look for common plaintexts (consider what happens if you encipher a message letter-by-letter this way...). For another, there are all kinds of clever attacks which can recover messages which are related, or can break the scheme if you send too many messages, and so on.

    Dan Boneh has a cool overview of these attacks and others in his "Twenty Years of Attacks on RSA" paper
    http://crypto.stanford.edu/~dabo/abstracts/RSAat tack-survey.html

    Some kind of padding scheme is necessary. Some padding schemes are better than others. The scheme which pads with random garbage at the end of the message, for instance, is not very good.
    The Public Key Crypto Standard (PKCS) #1 specifies the padding scheme used for RSA encryption. Version 1.5 had this scheme which was kind of thought to be sort of OK but nobody knew really. Now we are finding that it wasn't quite
    as good as we thought...

    Optimal Asymmetric Encryption Padding (OAEP)
    is another padding scheme. It is specified in version 2 of PCKS #1 because it seems to resist the attacks which killed version 1.5 . The neat thing about it is that you would expect it to resist these attacks and others because there is a "proof of security" which relates breaking the padding to breaking the RSA problem.

    That is, there's a proof which shows that extracting *any* information from the encrypted padded messages is just as hard as breaking the RSA problem on random instances. The scheme may still fail, but only if the RSA problem "underlying it" happens to be easy...like if we chose a too short modulus. We don't have to worry about stupid things like sending the wrong kind of messages any more.

    Is it important that OAEP was omitted in a "practical" handbook? In my opinion, yes and no.
    There's no need for the proof of security to be included. But the *reason* for the proof, that is, the existence of these really subtle and weird attacks which can leak information when you're not expecting it...that seems quite important in practice. Along with an explanation of how to use schemes like OAEP to cut out as many of these attacks as possible.

    It's worth noting, however, that OAEP *is* described in the _Handbook of Applied Cryptography_, which is available for download at
    http://cacr.math.uwaterloo.ca/hac/

    No proofs here, just a straightforward diagram and "how to implement." For the actual proof, you can check out Bellare and Rogaway's paper at
    http://www-cse.ucsd.edu/users/mihir/papers/pke.h tml

    OAEP is also specified in the IEEE P1363 standard, which has its website here :
    http://www.manta.ieee.org/groups/1363/

    the standard covers other algorithms and protocols as well. The website's worth checking out.

    While we're at it, does anyone know of a good treatment/introduction to the proofs of security involved in OAEP and similar?

"May your future be limited only by your dreams." -- Christa McAuliffe

Working...