Safety of using non-encrypted hashes to identify encrypted data in a key-value store

Question

I saw posts tangentially related to this, but not this one specifically.

I'm building a content-addressable storage layer where I'd like to store the contents encrypted. The question is what is a safe 'content address'/lookup identifier that would not weaken the encryption.

In an unencrypted store, I would have some data data, and the key would be sha256(data) and the value would be data.

In a naive encrypted store, I would have some data, and the key would remain sha256(data) and the data would be, say, aes-gcm(data). But is this safe? Does knowledge of the sha256 of the cleartext data aid an attacker in figuring out how to decrypt data?

I suppose I could do a content-addressable store where key::value was sha256(aes-gcm(data)) :: aes-gcm(data), but ideally I'd like to avoid inefficiency on the client, having to encrypt a file to get a hash to determine whether the value already exists on the server would be slow with a large number of files. Simply using the hash of the cleartext data would be much more efficient.

As a followup question, should I make sure data always has some minimum length? Padded with randomness? Is it insecure to store very small values that are easily guessed?

Answer 1

In a naive encrypted store, I would have some data, and the key would remain sha256(data) and the data would be, say, aes-gcm(data). But is this safe? Does knowledge of the sha256 of the cleartext data aid an attacker in figuring out how to decrypt data?

Yesno. The attacker can guess the data, but they won't learn anything about the data otherwise as hash functions are one-way.

I suppose I could do a content-addressable store where key::value was sha256(aes-gcm(data)) :: aes-gcm(data), but ideally I'd like to avoid inefficiency on the client, having to encrypt a file to get a hash to determine whether the value already exists on the server would be slow with a large number of files. Simply using the hash of the cleartext data would be much more efficient.

So use a HMAC using a key of the client. That way neither the server nor the adversary could get any information about the plaintext as you're now using a keyed hash. HMAC has some constant overhead but it is otherwise as efficient as using a single hash over the plaintext (as that's precisely what it does).

There are otherwise pretty efficient MAC algorithms out there - GMAC is the one used within GCM mode.

As a followup question, should I make sure data always has some minimum length? Padded with randomness? Is it insecure to store very small values that are easily guessed?

Yes, you could make a structure with randomness included to avoid guessing. I would not design & use a custom padding mechanism but use something such as a CBOR or ASN.1/DER encoding. Once you find out that you are designing a protocol it is usually better to go all the way and describe it in a document.

Note that I'm not sure how and why you want to use this system so there may be practical considerations that I could be overlooking.