4
$\begingroup$

I'm working on a secure file storage server. This server allows users to upload and download files based on a "seed". This "seed" is a 128-bit value.

From this 128-bit seed, we run SHA512 to derive a 256-bit key, 128-bit IV and 128-bit file identifier used to find the file on the server. The key and IV are then used to encrypt the file with AES in GCM mode. Only the file identifier is sent to the server at any point, encryption is done completely client side.

The only point at which I'm concerned here is the SHA512 of the 128-bit seed. Would there be any benefit to going to an HKDF based key expansion? It seems to be designed for this purpose, but considering we're able to achieve everything we need with a single invocation of SHA512 I'm unsure of the benefit. As far as I can tell, HKDF is still relying upon hash functions to randomly distribute entropy.

I understand there may be some theoretical benefit here, I'm just looking for details on how this benefit may work, what a theoretical attack might look like and if there's anything practical which could be used to exploit this today.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
4
$\begingroup$

I'm not aware of any attacks on SHA-512 this way. I would create a small function to validate that the input size to SHA-512 is indeed identical to the seed size though, just in case. Even without that the function should be secure. Kind of related is my question about KDF1 and KDF2.

Note that implementation of HKDF-expand from a hash should be pretty easy, especially if a HMAC construction is already available. KDF1 or KDF2 would be even easier, it would probably be trickier to find test vectors for those KDF's though. So you might ask yourself why not to use HKDF-expand.

Generating a 256 bit key using a KDF over a 128 bit means that the security margin would remain at 128 bit. Basically it's fine as long as you don't claim a security margin of 256 bit. Just claiming AES-256 bit encryption would probably mean the same thing to most people.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Yes of course, we only ever say a 128-bit security margin is given. Basically just went with AES-256 because it was there and we could use 100% of the output from SHA512. $\endgroup$
    – ultramancool
    Aug 20, 2015 at 18:12
  • $\begingroup$ Anyways, the only reason to keep SHA512 is to keep compatibility with existing content and to keep our existing implementation code. $\endgroup$
    – ultramancool
    Aug 20, 2015 at 18:14
  • $\begingroup$ Maybe a bit late but it's always a good idea to use (at least) one byte to indicate the current protocol for files. That way you can switch implementations when required, without having to re-encrypt everything at the same time. $\endgroup$
    – Maarten Bodewes ♦
    Aug 20, 2015 at 18:48
  • $\begingroup$ We do that, however if we change this to HKDF it'll change the algorithm used to determine the file identifier too, breaking this. Now, we could append to prepend the seed with this information in some way, but we're trying to keep the size down there... We have some ways to do this in mind already, but they're specific to our system and irrelevant to the question here. I'm really just looking to better understand if HKDF would offer us a benefit in a theoretical or practical way. $\endgroup$
    – ultramancool
    Aug 20, 2015 at 18:52
  • 1
    $\begingroup$ Well, as this is the comment section; I would sleep pretty tight even when using the SHA-512 function "poor man's KDF" :) $\endgroup$
    – Maarten Bodewes ♦
    Aug 20, 2015 at 18:56

Your Answer

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

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