I am looking to encrypt a piece of data using AES-GCM with a full 16-byte GCM Tag and send it over the network using UDP. Is it safe to assume using the AEAD nature of AES-GCM that performing authenticated decryption will prevent ciphertext length extension attacks with an implicit length?

In short, I want to determine the length of the ciphertext by looking at the UDP packet size and removing my app specific headers. This avoids the need for an explicit ciphertext length. Explicit length would increase the per-packet overhead, and every byte counts on the network.

Can I derive the length or must I specify it explicitly?

Section 5.3 (Page 44) of https://eprint.iacr.org/2013/144.pdf suggests while the GCM Tag includes length, it is still vulnerable to at least one weakness. But reading that, I'm not left with the impression that adding an explicit length into the AD would make a difference.

(Note: Originally asked this question on security.stackexchange.com, realised it was wrong site so re-posting here)


I did some more research and yes it does include both AD length and ciphertext length, so is not vulnerable to a length extension attack as length is part of GCM GHASH.

Based on NIST SP-800-38D (PDF) page 18 len(A) and len(C) are both part of the input into the GHASH function.

And double-checked this in an implementation gcm_finish method: both lengths are added to the hash at the very end. https://github.com/polarssl/polarssl/blob/master/library/gcm.c

| improve this answer | |
  • 1
    $\begingroup$ OK, glad you found out yourself over the X-mas period :) Same for CCM and I presume for other authenticated ciphers as well - having length extension attacks would break security of the cipher. IV verification is included as well by the way. $\endgroup$ – Maarten Bodewes Dec 29 '14 at 13:51

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.