Hi Pieter, On 29-10-18 13:55, Pieter Hulshoff wrote: > Thank you for the links. How should I interpret this? > > /GCM IV format:/ > |[ - packet ID - ] [ - HMAC key data - ]| > > This would be a 4 byte packet ID combined with 8 byte HMAC key data to > form a 12 byte IV? Does the TLS negotiation deliver an 8 byte HMAC key > in this mode or is only part of the HMAC key used (and if so: which part)?
That is correct. The implicit part of the IV contains the first 8 bytes of the 'hmac key' as calculated by the data channel key derivation. We can do that because that key isn't used in AEAD mode. See key_ctx_update_implicit_iv() in ssl.c for the implementation in openvpn. > /P_DATA_V1 GCM data channel crypto format:/ > |[ opcode ] [ - packet ID - ] [ TAG ] [ * packet payload * ]| > > I read this as 1 byte opcode, 4 byte packet ID, 16 byte TAG, payload > data (no padding, contrary to AES-CBC mode), and where AES-CBC encrypts > the packet ID, AES-GCM only authenticates this field. Is this correct? Correct. > /P_DATA_V2 GCM data channel crypto format:/ > |[ - opcode/peer-id - ] [ - packet ID - ] [ TAG ] [ * packet payload > * ]| > > This is the same as V1, with the 3 byte peer-id field added? Correct. -Steffan _______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
