# Why would splitting a password output be better than separate HMACs for encryption/authentication key derivation?

In a recent question I asked here on crypto.se, an answer was given that surprised me a bit.

As mentioned in the referenced question, I'm looking to derive encryption and authentication keys from the output of scrypt. Since I can use nearly any output size I'd like in generating the output from scrypt. This leaves me two options for deriving the encryption and authentication keys:

1. HMAC the output in two different ways, ie: hmac(output, "e", sha256), hmac(output, "a", sha256); the e key is for encryption and the a key is for authentication, unsurprisingly.
2. Generate a very long output from scrypt by asking for a 512-bit output, and then split it for the key derivation for encryption and authentication.

Does any one solution fare better than the other in key derivation? I personally like the idea of using an HMAC better because then both the encryption and authentication keys use the entire key output as an input.

-
The first approach you describe is quite similar to HKDF, a KBKDF (Key-Based Key Derivation Function), whereas PBKDF2 and Scrypt are PBKDFs (Password-Based). HKDF is intended to derive key material from input that is already cryptographically random and sufficiently long. Reading this, this, and this should set your mind at ease. –  hunter May 26 '14 at 15:43

In general, you need to be careful when chaining hash functions like $H_1(H_2(x))$. Both collisions in $H_1$ and those in $H_2$ lead to collisions in the combined hash. With a 256-bit hash you are still safe, however, since even doubling collisions gives you plenty of security margin.