3

I want to sync blobs over the network and the most frequent change will be appending to blob. To minimize data amount sent I would prefer to encrypt appended data, send it over the network, append to encrypted blob and then decrypt whole blob at once when needed. Changes are very frequent and small, so storing each change independently possibly will have some performance issues.

Can I store counter along with blob and append to encryption using GCM with stored counter value (assuming it won't overflow/reset counter, which is obviously insecure)? Would GCM still provide authentication? Will this construction be secure (assuming correct implementation and key/IV selection)? What other options do I have?

P. S. I imagine this is easy done with CTR mode or any stream cipher, but they won't provide authentication.

evgeniuz
  • 231
  • 2
  • 5

1 Answers1

5

I don't see any obvious way to do this without violating the security of GCM; at least, if you are at all concerned with an evesdropper (and if you're not, why are you encrypting at all?)

Here is a distallation of your requirements: you want to have the sender send the ciphertext (including nonce, ciphertext and tag). Then, you want the sender to be able to send the edits to the ciphertext; the receiver applies these edits to its copy of the ciphyertext. Then, the receiver decrypts this editted ciphertext, it gets an editted plaintext (and the editted tag authenticates if nothing was modified by a third party). In your case, the edits to the plaintext are appending arbitrary texts; that's not important for this analysis.

However, one of the requirements for GCM is that you never allow an attacker access to two different ciphertexts generated with the same nonce/key pair.

So, if the modified ciphertext uses the same nonce (and key), then this is an obvious violation; someone listening into the exchange will gain the original ciphertext, and the editted version; that allows him to deduce the internal 'H' value (and thus allow him to generate his own ciphertexts).

On the other hand, if the modified ciphertext uses a different nonce (or key), the keystream used to encrypt the plaintext changes; the two keystreams are (one hopes) computationally indistinguishable from random, and so any edit will not be more efficient than just producing a new ciphertext to replace the old one. Obviously, this would not meet the spirit of your requirements.

So, it appears that what you're trying to achieve would not be doable with GCM.

However, it turns out that, if you are not concerned with evesdropper, you could actually incrementally recompute the tag; I won't go into the details (in part because, as I said above, it generally is a bad idea).

poncho
  • 147,019
  • 11
  • 229
  • 360
  • But isn't the nonce looks like (nonce + counter)? And I will keep counter value on both sender and receiver and use that to encrypt each successive change (i. e. data will only be added, with new counter value each time, no data that already sent will be sent again). Does this still pose security threat? Can you please elaborate? What about OCB, from description it looks like more suited for this thing (http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#describe-ocb)? Thanks in advance. – evgeniuz Sep 05 '13 at 11:11
  • @Shark: again, the issue is giving the authentication tag for two different encrypted messages (it doesn't matter if one is a prepend of the other); the fact that this is easy to compute isn't relevant. – poncho Sep 05 '13 at 12:42
  • I guess that instead of a GCM tag you could send a HMAC over just the authentication tag of the incremental messages? I guess that it makes more sense to define message "fragments" and HMAC those though - that would also allow verification of the fragments at the receiving end. – Maarten Bodewes Aug 07 '14 at 08:58