2
$\begingroup$

Assume 256 bit keys are randomly generated and data is encrypted using AES-GCM-256 prior to being sent to a server.

The goal is to enable the server to determine uniqueness of data it receives without actually revealing the plaintext data.

Would it be safe to use SHA-256 where the input to the hash function is the key in addition to the plaintext data -- so SHA-256(key + plaintext)? By safe I mean does doing this reduce the safety properties of the key by a significant margin?

If not safe, how large of a random byte string is needed to make the SHA sufficiently difficult to brute force?

$\endgroup$
2
  • $\begingroup$ Will the AES-GCM encryption be done using different keys, or will it have a static key? $\endgroup$
    – rlee827
    Aug 23, 2019 at 13:37
  • $\begingroup$ It'll be done using a static key (but with a new IV each time data is encrypted, even if data is the same) $\endgroup$
    – jberm
    Aug 23, 2019 at 23:37

1 Answer 1

5
$\begingroup$

I'd split the key into two 256 bit keys using HKDF, and use one key for the GCM mode, and the other for the hash over the plaintext. However, I then would use HMAC rather than SHA-256 as it accepts and the key as a separate entity in the application.

The advantages of the HKDF key derivation function is that there is more "distance" between the keys used for the authenticated encryption and hash function. That said, just reusing the key is not likely to introduce direct vulnerabilities. It's also more "neat" using a KDF to derive other keys for other purposes, from a single shared secret key.

The advantage of using HMAC is that you are protected against length extension attacks. Furthermore, HMAC explicitly accepts a key rather than just data, so the key may be better protected against attacks, depending on the system that it is used on of course.

Otherwise, yes, using a hash over the shared secret and data may be used to determine uniqueness (well, with a high degree of certainty in the case of cryptographic hashes, of course), assuming that the key doesn't change during the time that this property is required. So yeah, I don't see how this would not work (but please don't view that as scientific proof).

$\endgroup$
6
  • $\begingroup$ Awesome, thanks for this answer. One thing, in my example, I don't see how a length extension attack applies because the server has no way of authenticating the hash without revealing the plaintext anyway. Therefore I couldn’t even use HMAC to authenticate the message server-side, so all an attacker has to do is to replace the hash entirely to succeed regardless of what hash algorithm is used. There's no notion of authenticated hashes from the server's perspective (only unique ones). Am I misunderstanding? $\endgroup$
    – jberm
    Aug 24, 2019 at 0:56
  • $\begingroup$ Using HMAC means you need not even consider the question of whether length extension is relevant. $\endgroup$ Aug 24, 2019 at 1:23
  • $\begingroup$ Sure, I'm just curious to make sure I understand the attack and potential weaknesses in the approach I described $\endgroup$
    – jberm
    Aug 24, 2019 at 1:34
  • 1
    $\begingroup$ Well, let's imagine that you send M and then M' where M' is already an extension of M, then the attacker could perform a length extension attack on M to find out that this relation is true. That leaks information about M and M', as their relation is shown. Now this seems a remote possibility, but note that in the normal attack scenario for a cipher an attacker can even propose different messages to try and retrieve information about another message (chosen plaintext attack of CPA). See, not very easy to see at all, but still an attack; all the more reason to be carefull. $\endgroup$
    – Maarten Bodewes
    Aug 24, 2019 at 10:54
  • 1
    $\begingroup$ If CPA is possible, but note that length extension attacks require the user to insert the old length encoding and padding, so you cannot just extend the key to the key + any message. $\endgroup$
    – Maarten Bodewes
    Aug 24, 2019 at 19:52

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.