Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The third-party Apache plugin mod_auth_tkt uses a tragically-not-HMAC construction:

digest0 = hash(
    encode_ip_timestamp(ip, timestamp) + secret + userid + '\0'
    + tokens + '\0' + user_data).hexdigest()
digest = hash(digest0 + secret).hexdigest()

How bad is it? Clearly the performance is worse than HMAC.

share|improve this question
up vote 3 down vote accepted

At a glance, I see no obvious weaknesses. Obviously, the security proof of HMAC won't apply to this construction, but that doesn't necessarily make it insecure — it just means that we can't prove its security (given appropriate assumptions on the underlying hash function), or at least that we'll need different methods to do so. Certainly, none of the (practical) attacks in section 6 of the original HMAC paper seem to apply.

Ps. Why do you say that the performance is worse than HMAC? Both involve two calls to the hash function, one for arbitrarily long (but in this case, poribably fairly short) input and one for only fixed-length input. Indeed, in some cases (keys longer than one hash input block) this scheme could be faster than HMAC.

share|improve this answer
With HMAC you can feed key+ipad and key+opad to two instances of the hash function, and then clone the hash function state to sign any number of messages. So you only have to hash the key twice to sign any number of messages. – joeforker Sep 18 '12 at 23:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.