3

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.

joeforker
  • 561
  • 5
  • 13

1 Answers1

3

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.

Ilmari Karonen
  • 46,120
  • 5
  • 105
  • 181
  • 2
    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