I agree that I wouldn't treat the HAC as a "discovery" reference, for lack of a better term. Like you point out, there are modern-day concerns and constructions that are omitted. But I argue that if you are designing a protocol or choosing a primitive, you shouldn't have to consult a book to figure out which encryption mode to use or how to use a MAC. If you do, then you probably aren't qualified to be designing a protocol in the first place!

The HAC really excels as a specific, targeted reference for a cryptography-aware audience. For instance, if you're wanting a good, standard notation for something, the HAC is a great place to look. Or maybe you'd like to give a specific definition in a paper. (For instance, what is a precise definition of a MAC?) Then the HAC is a great place to look.

So, I agree that a designer shouldn't use the HAC as a sole reference, especially if they're unfamiliar with cryptography. This goes doubly so if what you're trying to do is estimate the security of a construction. But really, to know much about the cryptographic security of a scheme or construction, you really need to be up-to-date with the current research, not just looking at books. A book is a good first pass filter, if you will, but if you're judging security, you really want more.

> a designer could be forgiven for reading Menezes and not including explicit integrity checks at all.

Section 9.6.5 goes to great lengths to ensure the reader is fully aware that encryption doesn't provide integrity. Also, Menezes does present (an albeit brief) note on encrypt-then-MAC. I don't see the HAC as a teaching text, though. Anyway, I doubt there are many people who have "read" the HAC. It's a pretty thick book.

> It's not true that robust cryptography appreciates maturity. The ~twenty years since Menezes wrote HOAC haven't just been spent inventing whizz-bang new toys, but also in finding new ways to break the old toys. You're not always OK if you eschew the new stuff for the "mature" stuff; some of the mature tools are perilous to work with now.

I think robust cryptography absolutely appreciates maturity. But don't mistake me saying that for me saying that maturity is the only desired trait: far from it. scrypt was not recommended as highly as bcrypt for a few years after its release, and still one of the major selling points of bcrypt is "it's been around a while." And let's not forget the four-year period that the SHA3 competition spanned. Some minimum amount of maturity is required of all schemes that are considered secure.

So, maturity isn't a decision-making factor, no. But a construction that's been around for a long while and has seen virtually no attacks (but is widely studied) is essentially the gold standard. See AES. On the other hand, I think you'd have a hard time arguing that a relatively new construction that's seen virtually no attacks isn't less impressive, even if it has some improvements over an older scheme.

But again, I agree entirely that "mature" isn't always better. But it's definitely a factor, although whether it's a large or small factor mostly depends on the circumstances.

> what parts they need to hold off on, like homomorphic encryption

If you mean fully homomorphic encryption, then sure. However, we already have practical partially homomorphic schemes which are pretty good. But this area especially requires a cryptographer's assistance in design, even moreso than a typical "confidentiality/integrity" application.

---

Anyway, I guess ultimately, if you're just looking for a good text that's useful in learning cryptography, the HAC isn't the first place I'd look. But if you'd like an encyclopedic reference, it does a great job (IMO). If you're looking to build up a cryptography reference, though, it definitely needs to be supplemented with many other texts.

Edit: Also, another thing I find myself using the HAC for is to get a certain sort of historical context (regarding attacks and constructions) in an area before moving on to more advanced, more modern texts. Those more modern texts tend to leave out such details for brevity's sake, but I like knowing them all the same.