3
$\begingroup$

I'm writing a software that will be encrypting & authenticating segments of data, each 4096 bytes long. These segments are saved to disk in a sequential order that will never change. So I was thinking to encrypt each one of them using AES256-GCM, but before I code it I need to confirm a couple of points:

  1. To conserve space for saving an IV for AES-GCM encryption/decryption, I was thinking to use each of my segments' sequential number as an IV. Would that pose an issue (in cryptographic sense)?
  2. I decided to go with a 16-byte TAG (that is used by AES-GCM for authentication.) Is that an overkill for an encrypted 4096 byte segment?
$\endgroup$
  • $\begingroup$ One more question to add: should the number also be included as AD data to bind it with the tag. $\endgroup$ – eckes May 11 '17 at 2:40
  • $\begingroup$ @eckes: Are you talking about an IV? Then, yes, the IV is included with the ciphertext and the TAG and sent via an open channel. Only the key should remain private. $\endgroup$ – c00000fd May 11 '17 at 3:33
  • $\begingroup$ I am talking about including the segment number into authenticated extra data (not only sending it). I mean I know that the sequence number must be authenticated to bind the message sequence and block reordering, the question is if using it as a IV does binding or if you need to specify it additionally as AAD. $\endgroup$ – eckes May 11 '17 at 4:00
  • $\begingroup$ @eckes: Oh, sorry, that's what you meant by AD. Well, the question is why would you want to include the segment counter in associated data? The whole point of using it is that it's implied at decryption time, so it saves space. I don't think it will hurt if you included it though, but it kinda defeats the purpose. Otherwise then just use a randomly unique IV/nonce instead. $\endgroup$ – c00000fd May 11 '17 at 4:14
  • $\begingroup$ Include it to ensure it is not reordered: I guess my question is if the IV data is implicitly authenticated since it is used as a IV here as well $\endgroup$ – eckes May 11 '17 at 4:16
4
$\begingroup$
  1. To conserve space for saving an IV for AES-GCM encryption/decryption, I was thinking to use each of my segments' sequential number as an IV. Would that pose an issue (in cryptographic sense)?

No, it will not pose an issue because the (twelve byte) IV for GCM encryption is really a nonce; it is not directly used as counter for the underlying CTR encryption.

  1. I decided to go with a 16-byte TAG (that is used by AES-GCM for authentication.) Is that an overkill for an encrypted 4096 byte segment?

The security of GCM is rather dependent on the size of the authentication tag. If you can spare the few bytes I would strongly recommend keeping it set to 128 bits. You have overhead anyway and 16 / 4096 (1 / 256 if I'm not mistaken) is less than half of a percent of overhead.

And it seems like you will be handling large amounts of data, which increases the attack surface to an attacker. Better safe than sorry.

$\endgroup$
  • $\begingroup$ Thanks. Although why are you saying that IV is 12 bytes. Isn't it the block size for AES, i.e. 128 bits, or 16 bytes? $\endgroup$ – c00000fd May 8 '17 at 20:35
  • $\begingroup$ The mode of operation determines the size of the IV / nonce. This is often the same as the block size for practical reasons. GCM performs pre-computation on the given IV, which has a usual size of 12 bytes. NIST SP 800-38D: "The IV is essentially a nonce, i.e, a value that is unique within the specified context, which determines an invocation of the authenticated encryption function on the input data to be protected." and "For IVs, it is recommended that implementations restrict support to the length of 96 bits, to promote interoperability, efficiency, and simplicity of design." $\endgroup$ – Maarten Bodewes May 8 '17 at 20:42
  • $\begingroup$ Hmm. Interesting. It doesn't just use "vanilla" AES. So what you're saying is that if I provide 128-bit IV, 32 will be discarded by the algorithm, right? $\endgroup$ – c00000fd May 8 '17 at 20:59
  • 1
    $\begingroup$ It will use another pre-computation to generate a 12 byte nonce, basically. It doesn't just discard the bytes. But (1) it will be less compatible and (2) it won't buy you any security and (3) it will cost you a very small amount of performance. AES itself is still the usual block cipher, but with GCM there are definitely other calculations going on that are more than just XOR as used for CBC mode yes. $\endgroup$ – Maarten Bodewes May 8 '17 at 21:17

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.