1

For context, I'm making a non-production grade reference implementation of the balloon hash function using the Web Crypto API. In order to make it less susceptible to certain attacks on common memory hard KDFs, the number of memory blocks should be reduced, meaning their size should increase. I am however restricted in the choice of cryptographic functions to the functions defined in the SubtleCrypto interface of the Web Crypto API. And that leads to the question:

Can HKDF be used in place of a cryptographic hash function? None of the SHA1 or SHA2 hash functions have large enough outputs for this application. Would a longer output, say 2048-4096 bits, from HKDF-SHA512 have near equivalent security properties to plain SHA512, or would they differ in some aspect?

n-l-i
  • 445
  • 3
  • 9

1 Answers1

3

Can HKDF be used in place of a cryptographic hash function?

Yes.

HKDF is defined (there) from HMAC and a hash. $H(M)$ computed as $$\operatorname{HKDF-Expand}(\operatorname{HKDF-Extract}(\mathrm{salt},M),\mathrm{info},512)$$ for fixed small (possibly empty) constant bytestrings $\mathrm{salt}$ and $\mathrm{info}$, and SHA-512 as the underlying hash for HMAC, will behave essentially as a 4096-bit hash about as strong as SHA-512 is.

Arguably, there is a little loss in the possible number of possible outputs, and the number of values possible for each 512-bit output segment, but it's computationally impossible to observe, and arguably within 2 of 512 bit anyway by arguments on the tune of this.

Problem is that each HKDF producing 8×512 bits costs 20‡ SHA-512 compression functions (for small $M$). In a Balloon (or other memory-hard function) context, I'm afraid this relatively high cost shifts the balance in favor of adversaries that can implement SHA-512 at blazing speed. I'd rather cut corners quite a lot on the cryptographic security of the hash in favor of a faster hash, so that more of the computing power goes to memory accesses.

‡ That's assuming a careful implementation caching the first block in HMAC whenever possible; otherwise I get 36. Both counts need cross-checking.

fgrieu
  • 140,762
  • 12
  • 307
  • 587
  • Yes okay, I understand that then and HKDF does not sound like the most efficient then. A cheaper hash sounds better for this application. – n-l-i Mar 15 '23 at 17:19
  • I cross checked the counts and I get 18. I count 2 hashes for the extraction and 2*n for the expansion, n being 8 in this case. – n-l-i Mar 15 '23 at 17:22
  • 1
    @n-l-i: There are 18 SHA-512 for sure; but each hashes 2 blocks (hence my 36 without caching). When we count compression functions of SHA-512 as I do, even with caching (and precomputation for $\mathrm{salt}$), we must account for the compression of $\mathrm{PRK}\oplus\mathrm{ipad}$ in the first SHA-512 of the HMAC producing the first output block, and the compression of $\mathrm{PRK}\oplus\mathrm{opad}$ in the second SHA-512 of the same HMAC. Both can be cached for the 7 HMAC producing the next output blocks. Whatever, we agree on the order of magnitude, and that it is an issue. – fgrieu Mar 15 '23 at 17:28