I'm currently using strongSwan as a peer for the IKEv2 protocol. I've configured it to use HMAC SHA-256 for its pseudorandom function, and AES-256-GCM-16 for its encryption and integrity algorithm.

During the initial exchanges where strongSwan generates SKEYSEED and derives keying material, each of SK_ei and SK_er get outputted with a strange length of 36 bytes.

If I change AES-256-GCM-16 to AES-128-GCM-16, each of SK_ei and SK_er instead become 20 bytes long. With this in mind, it seems like there's an extra 4 bytes being appended to each of these derived keys.

What are the extra 4 bytes for? At first I thought it may be an initialization vector, but I hear for AES-GCM, IVs are typically 12 bytes long. According to the RFC, SK_ei/SK_er are supposed to be used as input for the encryption algorithm, but as-is, they aren't the correct length with the 4 extra bytes, and this case doesn't seem to be explained anywhere.


1 Answer 1


As specified in RFC 5282, section 7.1 (and RFC 4106, section 8.1 for ESP), these additional four bytes are allocated as salt value that AES-GCM uses in the nonce.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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