Is "Bit Independence" of SHA-2 hashes secure? I know bit independence is good in SHA2 function output, but is it truly 100% secure?  For example:


Y = SHA512(secretKeyNonce256bit)
A = first 32ytes / 256bits of Y, used as message encryption key
B = next 16bytes/128bits used as authentication HMAC key for message
C = next 16bytes/128bits used as access code. NON-SECRET, and known to message carrier. If user provides this code, he is given the encrypted message by the carrier.


Does having knowledge of C yield some insight into A,B?  Would it be better to instead use C2=first 16 bits of SHA256(C) ?

One weakness, which extra SHA does not prevent, is if secretKey were derived from a crummy password [not the case here], C would be valuable to whoever attempted brute-like password guessing, because if a tried password produces C, it is likely that the password is correct &amp; can produce correct A, B.  Some people may mention 128bit HMAC is on a weaker side, but I think 128 / 64bit collision resistance is sufficient for my application.
There is no known exploitable relationships between the words (32/64 bit "chunks") of SHA-2 but this is always a source of cryptanalysis.  There are some academic weaknesses against reduced round variants of SHA-2 but nothing against the full cipher.  Still hashes are cheap so why not just use multiple hash functions?

Seed = HASH(secret)  &lt;- This should be a KDF instead see below
A = HASH(Seed)
B = HASH(A)
C = HASH(B)


If you need less bits you can just chop them down (it is good enough for NIST). Here is another option.

&gt; Seed = HASH(secret)  &lt;- This should be a KDF instead see below 
&gt; A = HASH(Seed XOR ConstantA)
&gt; B = HASH(Seed XOR ConstantB)
&gt; C = HASH(Seed XOR ConstantC)


Keep the constants the same same length as the output of HASH to avoid a biased result.

Use a KDF

I am assuming "secretKeyNonce256bit" is really a human generated password.  Using a simple unsalted hash to derive a key from a low entropy secret is a bad practice. You say "not the case here" but it is unclear if you mean it is not a password or not a "weak password". If "secretKeyNonce256bit" is a 64 byte random value from a CSPRNG then ignore this but if it is the result of any human selection you really should be using a true KDF (like PBKDF2, Bcrypt or Scrypt).