On: Life in a post-database world: Using crypto to avo...

[limelight]

I don't really consider HMACs to be particularly arcane knowledge. They're easy to generate in any language and straightforward to work with.

While I consider myself to be a pretty good developer, I'm definitely not well-versed in crypto and math isn't my strongest skill. Despite that, I've had no problem using crypto for several of the obvious use cases (ex. password resets).

[Terr_ → limelight]

Arcane to use as the consumer of a library, or arcane to implement on your own?

The most important rule of thumb for crypto is that you'll probably mess up doing it yourself.

[tripzilch → Terr_]

You shouldn't implement HMAC yourself, of course. I repeat: you should not do this.

However, if you read Wikipedia on HMAC, you'll find that HMAC is in fact probably one of the easier crypto primitives to understand and implement (as a TOY project). As long as you do the padding thing exactly as specified.

But really, use a library.

[williamcotton → Terr_]

That rule if for like, implementing AES on your own, not just using HMAC! No one is saying roll your own HMAC!

[lvh → williamcotton]

That's a common misconception. While designing your own cipher or implementing AES is a terrible idea, it's fairly easy to produce broken systems with strong primitives like AES or HMAC, and the brokenness would not have anything to do with the implementation of those primitives.

[tomjen3 → lvh]

How will you make a broken system with HMAC? Other than exposing the key or the data inside there really isn't that much you can do wrong with HMAC.