1
$\begingroup$

I need to encrypt and authenticate a stream of data so that it is resilient against unexpected power loss, so I cannot write authentication data at the end of the stream.

I am currently using AES-GCM, just for encryption, as my understanding is that the authentication tag for GCM must be written at the end of the stream.

What I have in mind to do instead is to buffer the stream into fixed-size blocks, the SHA512 sum of each block, and then encrypt the block and n bits of the SHA512 sum and write them out. (My understanding is that truncating the SAH512 sum to save space is okay.)

My thinking is that, if an attacker wishes to tamper with the data in any given block, there will be a 2^-n chance that the hash calculated on decryption will match the one on-disk, (2^-n chance of the tampering going undetected). I also imagine that tampering with the hash won't improve the chances.

  1. Is my thinking correct?
  2. Is this scheme secure?
  3. Is there a better/more established/more convenient way to do this?
$\endgroup$
  • 3
    $\begingroup$ Why not divide into fixed-size blocks and encrypt with GCM and store it's authentication tag? As for the security properties of an encrypted hash, take a look here. $\endgroup$ – mikeazo Oct 31 '16 at 17:49
  • 2
    $\begingroup$ @mikeazo Some care needs to be taken with that. In particular, you need to use sequence numbers to ensure data hasn't been reordered. The STREAM construct is, I believe, currently considered best for such a thing. $\endgroup$ – Stephen Touset Oct 31 '16 at 21:27
4
$\begingroup$

I need to encrypt and authenticate a stream of data so that it is resilient against unexpected power loss, so I cannot write authentication data at the end of the stream.

This is a fairly confusing question you're asking, and I needed to read the whole thing over and over to come to a point where I felt I understood it. What you want is to authenticate the data you're sending incrementally so that the recipient can establish the authenticity of chunks or prefixes without having to wait for the end of the whole stream.

The solution to this is to move the authenticated encryption inside the protocol that you're using to send data over the stream. Instead of globally encrypting and authenticating a stream of plaintexts, you probably should send a stream of individually encrypted and authenticated ciphertexts. AES-GCM will work fine for that—don't play around with homebrew ideas like what you're proposing. You do have to be very careful about IV reuse. (And about writing your own cryptography—are you sure you want to do this?)

One nuance here is whether you're trying to authenticate individual messages or stream prefixes. This is related to the question of what should the recipient do if one message in the stream is adulterated:

  1. Skip it and carry on processing the subsequent ones;
  2. Abort the whole thing and don't process any more messages.

What's the correct thing to do depends on the application. I'd put a bit of thought into that question. But for case #2, there are tricks that can be done to cause the authenticity of later messages to depend on that of earlier ones.

I am currently using AES-GCM, just for encryption, as my understanding is that the authentication tag for GCM must be written at the end of the stream.

There is no logical requirement to write the authentication tag at the end of the stream. It's just a very convenient way of doing it, since:

  1. It allows you to write the ciphertext into the stream incrementally as you compute it;
  2. You can't emit the tag until you've encrypted the whole message anyway.

If you buffer the whole ciphertext and tag into memory before writing them to the stream you could write them in the opposite order if you so preferred. I figure some specific AES-GCM implementations may be hardcoded to write the tag at the end, though.

My understanding is that truncating the SHA512 sum to save space is okay.

If you're truncating to 256 bits, there's a newer SHA-2 variant called SHA-512/256 which already does that. But the larger issue is that SHA-2 is not a message authentication code, so it's not a substitute for GCM's authentication.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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