[strongSwan] AES-GCM-16: payload length is not multiple of a blocksize
andreas.steffen at strongswan.org
Fri Aug 13 09:03:46 CEST 2010
according to GCM ESP RFC 4106
esp=aes128gcm16 packs an 8 octet IV in front of
the ciphertext which has the same size as the plaintext
padded to the next 4 octet boundary, followed by
the 16 octet ICV. Since AES-GCM is a stream cipher
the plaintext data does not have to be padded to
a 16 octet block size. Therefore it is normal that the
size of the ciphertext is not a multiple of 16 octets.
Paragraph 3.2 of RFC 4106 explicitly states:
Implementations that do not seek to hide the length of the plaintext
SHOULD use the minimum amount of padding required, which will be less
than four octets.
It might be that OpenBSD is padding up to the next 16 octet boundary,
On 08/12/2010 06:24 PM, Mike Beloppauhov wrote:
> I'm sorry if this is a wrong place to ask, but I hope I'll get some
> hints as I'm not a Linux guy.
> So I'm using strongswan-4.4.1 on ubuntu server 10.4 with an updated
> kernel: linux-image-2.6.33-02063305-generic (with fixed SHA2) on one
> end and OpenBSD with isakmpd on the other.
> This is a strongswan config:
> conn aesgcm-test-ikev1
> Now the problem is that 90% of packets sent by Linux box in the
> quick mode (after establishing an IPsec connection) have a
> payload which is not multiple of a cipher blocksize (16).
> OpenBSD detects this early on and drops such packets (this
> happens before the actual crypto processing).
> Funny enough I don't see this happening with neither AES-CBC nor
> Any opinions/hints/advices?
> Users mailing list
> Users at lists.strongswan.org
Andreas Steffen andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
More information about the Users