Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Do in all the use cases, if I have to encrypt and authenticate, encrypt-then-authenticate or authenticate-then-encrypt, like in IPSEC, SSL or SSH or others, if I were to do these operations to a packet, do I always know that the cipher offset will be greater than authentication offset i.e that authentication length will always be greater or equal to cipher length. For example in IPSEC, we add an esp header and trailer, we need to start encrypting after ESP but need to authenticate starting from ESP.

share|improve this question
Small note: I would expect the data that is protected against integrity and authenticity to start before or at the location of the ciphertext in a structure (as for the reasons that Poncho gave). Note that it is technically possible for authentication tags to cover data present before, between and after the confidential data. However some authenticated ciphers such as GCM prefer to have the AAD (additional authenticated data) to be present in advance; CCM even requires this as it specifies a packet format itself. Those authenticated ciphers may already protect data included in the IV as well. – Maarten Bodewes Apr 19 '15 at 14:42
@MaartenBodewes: minor note: while the obvious method of implementing GCM has you processing the AAD before the encrypted data, it's not that hard to process them in a different order. – poncho May 26 '15 at 12:53

When we have regions of the packet that we only authenticate but not encrypt, that happens because we have data that we want to bind to the encrypted region, but we don't need to include within the encrypted region. Examples of this are:

  • For IPsec, we include the sequence number (as a part of the ESP header). We include that within the authentication (otherwise someone in the middle could change that arbitrarily), however we don't want that to be encrypted (otherwise, the decryptor would have to decrypt the packet before processing the sequence number).

  • For TLS, we include the sequence number. We include that to prevent someone from replaying a TLS record; however this is different from the IPsec case, as we don't actually include the sequence number in the packet; both sides are expected to include that implicitly.

Now, the question is: does the opposite make sense? Do we ever have a case where we care about the privacy of a field (so we need to encrypt it), but we don't care about its integrity (so if someone changes it, we don't really care)?

Personally, I'm having problems thinking of a scenario where this makes sense; if we have an encrypted region, one would expect that we do authentication over that entire region, and not pick and choose.

I also can't think of a protocol which attempts to take advantage of that (other than protocols which don't do integrity checking on anything - we try to discourage that, but they do exist).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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