0
$\begingroup$

According to Wikipedia:

TLS has a variety of security measures:

Using a message digest enhanced with a key (so only a key-holder can check the MAC). The HMAC construction used by most TLS cipher suites is specified in RFC 2104 (SSL 3.0 used a different hash-based MAC).

What hash-based MAC did SSLv3.0 use? How does it compare to the ubiquitous HMAC that is used everywhere else today?

$\endgroup$
4
  • $\begingroup$ And did you up read the wiki page to the SSL 2.0/3.0 sections? $\endgroup$
    – schroeder
    Sep 23, 2020 at 14:54
  • $\begingroup$ @schroeder The section on SSL2.0 included this: SSL 2.0 had a weak MAC construction that used the MD5 hash function with a secret prefix, making it vulnerable to length extension attacks. Didn't seem to mention a specific protocol. $\endgroup$
    – Eddie
    Sep 23, 2020 at 15:04
  • $\begingroup$ And did you look up the RFC for the specifics? tools.ietf.org/html/rfc6101 $\endgroup$
    – schroeder
    Sep 23, 2020 at 15:09
  • $\begingroup$ The MAC is generated as: hash(MAC_write_secret + pad_2 + hash(MAC_write_secret + pad_1 + seq_num + SSLCompressed.type + SSLCompressed.length + SSLCompressed.fragment)) -- but this doesn't answer the second question... how does this compare to HMAC, why is one better or worse? $\endgroup$
    – Eddie
    Sep 23, 2020 at 16:04

1 Answer 1

1
$\begingroup$

The key was concatenated in SSL 3.0:

    hash(MAC_write_secret + pad_2 +
         hash(MAC_write_secret + pad_1 + seq_num +
              SSLCompressed.type + SSLCompressed.length +
              SSLCompressed.fragment));

but XOR'ed in HMAC:

    H(K XOR opad, H(K XOR ipad, text))
$\endgroup$
3
  • $\begingroup$ Brilliant. Thank you. =) Can you speak to why the XOR is more secure than the concatenation, given the result is just going to be hashed? $\endgroup$
    – Eddie
    Sep 23, 2020 at 17:07
  • $\begingroup$ en.wikipedia.org/wiki/Length_extension_attack is the vulnerability. It let attackers add extra data without invalidating the hash. Most modern hash algorithms aren't vulnerable to this, so eg KMAC doesn't need the double hashing of HMAC. $\endgroup$ Sep 24, 2020 at 2:32
  • $\begingroup$ HMAC is a construction that is generic and secure. It also takes a key in most implementations, which could make a difference e.g. if you implement it using a HSM or other hardware device. Given the construction above, I don't see any practical length extension attack - the only thing that may be changed in size is the fragment, and that's double hashed. $\endgroup$
    – Maarten Bodewes
    Jul 22, 2021 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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