Should I stretch the secret key in a secure cookie protocol implementation?

Question

I'm building an api authentication layer that basically works like the secure cookie protocol, where instead of a cookie I give the api client a token which they must provide on subsequent requests. That token is signed via HMAC using a secret key kept in memory on the server. The key is a 64 character random hex string. Currently I'm signing the tokens with the key directly, but based on what I've seen in the source code for ruby on rails, they sign their cookies with a secret key that is derived by stretching the secret key base with pbkdf2. What threat vector is this defending against? As I understood it, key stretching is supposed to help prevent offline brute force attacks against stored passwords. I'm not clear what it's purpose is here and if its something I should implement.

Answer 1

Key stretching basically gives a key with low entropy more strength, by deriving a hash from it created by multiple iterations.

A 64 character hex string, assuming it is completely randomly generated will have 256 bits of entropy. When authenticating a string with a HMAC, anything 128 bits or greater is considered "unbreakable".

Key stretching mitigates the risk of having a weak key, because the only way an attacker can find the key is via an offline password guessing attack. With key stretching with say 1024 iterations, this effectively makes the password 10 bits "stronger" because for each password the attacker tries they have to run the hash function 1024 times (the equivalent of having more entropy in the password itself - it makes up for the extra keyspace a stronger password would have).

So with Ruby on Rails, this is protecting against the site owner choosing a weak key (< 128 bits). If you can control your key and you make it strong enough, there is no need for any key stretching.