For an academic application, I use AES-GCM to encrypt my frames between 2 parties.

To enhance security, and reduce the possibility of replay, I'd like to use a TimeStamp in my frame exchanges. But, as I use the GCM mode, I need to tranmsit the Initialisation Vector besides the ciphertext (and the MAC).

My idea is : could it be possible to use the IV as TimeStamp as well ?

The IV would thus be used for decryption of the ciphetext, and then to check if the message is not too old.

Thus, a modification in the TimeStamp will make the ciphertext un-decryptable.

The next step wil be to produce a TimeStamp in a long form, as not to reduce security. Any ideas how to emit a TimeStamp like this ?


Each encryption mode has its requirements for the IV. For GCM, the requirements are simple (see NIST SP 800-38D for details):

  • Length should be between 1 and 261-1 bytes. It is recommended that the IV length is exactly 12 bytes (96 bits); if it is not, then GCM will need to pad and/or hash the IV first, which is not supported by all implementations, and increases the risk of spurious collision.

  • For any given key K, you shall never use twice the same IV.

In particular, in GCM (as opposed to, say, CBC), there is no need for the IV to be random and unpredictable; uniqueness only is required.

Therefore, a 96-bit value extracted from a monotonic clock (I suppose that is what you mean by "time stamp") is a nice IV, provided that you take care of the following:

  1. If you encrypt several messages in quick succession, they may end up using the same time stamp, depending on the accuracy of the system clock and the speed of the CPU. You MUST include some test to avoid such an occurrence.

  2. The system clock may vary, either automatically or through human action (the user notices that the clock is off and adjusts it). Having a really monotonic clock can be hard in all generality.

  • 1
    Well, that answer is just better than mine:) – Tobi Nary Mar 17 '16 at 16:43
  • It's also a near copy of the one I was drafting, haha – sethmlarson Mar 17 '16 at 16:43

Assuming that you choose the timestamp to change soon enough (e.g. have a reasonable precision such that it is very likely to be different each time) and all other parameters fine:

You should be fine using the current time as an IV.

For example, you could use the unix timestamp in millisecond precision. How much entropy the IV actually holds (e.g. how long is it) should not influence the security on the block cipher you are using.

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.