3
$\begingroup$

I am trying to understand the variant of Encrypt-then-Authenticate (EtA) that is used in IPsec. For this I have looked at this chapter.

What I got so far is that the integrity and confidentiality computations cover different parts of the EPS packet. What I don't understand is what exactly is done and how this is different from the general EtA composition (i.e. what is modified in comparison to the general EtA composition).

| improve this question | |
$\endgroup$
  • $\begingroup$ What do you consider a "general EtA composition"? EtA, in my understanding, describes the order of operations and isn't a protocol description (how the encryption/authentication is performed). $\endgroup$ – Maarten Bodewes♦ Jan 3 '16 at 12:17
  • $\begingroup$ Yes, I agree. I meant the combination of an encryption scheme and MAC in an EtA fashion. $\endgroup$ – Lemon Jan 4 '16 at 6:28
3
$\begingroup$

This is standard Encrypt-then-Authenticate. The only difference is that when doing EtA, it actually isn't necessary to encrypt everything. This strategy makes sense when there is some part of the message that needs integrity and not privacy. In IPSec, the ICV (which is a counter to prevent replay) does not need privacy. Furthermore, by not encrypting it, it is possible to not have to decrypt in order to check if a packet is being replayed (rather, it suffices to check the MAC).

It is important to note that it is possible to use IPSec incorrectly, and do MAC-then-encrypt. This is achieved by computing the IPSec authentication header, and then encrypting. Despite being recommended by some experts, this is BROKEN! So, if you want privacy and integrity, then it should all be done inside the ESP, as is described here.

The fact that AtE is broken in IPSec is not theoretical. See, for example, the paper On the (In)Security of IPsec in MAC-then-Encrypt Configurations by Degabriele and Paterson.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Have added the link. $\endgroup$ – Yehuda Lindell Jan 3 '16 at 15:09
  • $\begingroup$ So encryption does not encompass the ICV field. But what's the integrity part? Computing a new ICV over the EPS packet (minus the ICV field) after encryption (as described in part 4 of the chapter? Furthermore, since you mentioned security: My overall goal is to answer the question whether the EtA construction in IPsec is IND-CCA secure provided that the used block cipher is a PRF. So according to your words I guess it is, as long as I proceed as described in the linked chapter? $\endgroup$ – Lemon Jan 4 '16 at 9:50
  • $\begingroup$ It should be fine. However, I don't want to make recommendations on actual implementations and configurations since I'm not an expert on the specifics of the fine details of the standard. $\endgroup$ – Yehuda Lindell Jan 5 '16 at 7:37

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.