*** Victor Sudakov [2020-01-19 15:07]: >Probably this transformation should not cause any increase in payload >size because AFAIK a symmetric cipher does not increase the message >size (i.e. the encrypted message is not bigger than the cleartext).
Wrong in nearly all cases. 1) If you use *stream* symmetric cipher, then ciphertext's length is equal to plaintext. 2) If you use *block* symmetric cipher, then it has to be divisible by blocksize by definition. However that depends on used blockcipher mode of operation. For example CTR (counter) mode transforms block cipher intro stream cipher, thus requiring no padding. In CBC mode it requires padding, so as a rule it will be always greater up to blocksize. 3) ESP requires most fields to be multiple of 32-bits, so even if you use stream cipher or some kind of block cipher CTR mode, you have to pad it to be multiple of 4-bytes because of ESP. 4) You HAVE TO always use and enable ciphertext authentication. All modern protocols even forbid non AEAD (authenticated encryption) ciphermodes usage at all. For example AES-GCM is that kind of ciphermode. And always your ciphertext will have MAC tag (ICV field in ESP) filled. AES-GCM as I remember uses 96-bit MACs, others use 128-bit MACs or even larger. 5) Also ESP has IV field and most ciphers (AES-GCM, GOST ones, and so on) requires it. It takes 8 bytes in practice. >OTOH, there is added information is the 4 bytes of SPI and 4 bytes of >ESP sequence number, correct? So the payload should grow 8 bytes. Is >this enough to make the packet too large? So minimally with some kind of modern AES-GCM you have 8 bytes of IV, 12 bytes of MAC tag (ICV field), possible ESP 32-bit alignment padding, 32-bits SPI and sequence numbers. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
signature.asc
Description: PGP signature
