1. OMG Issue

DDSSEC12 — AES-GCM doesn't add padding

  • Key: DDSSEC12-58
  • Status: closed  
  • Source: Object Computing, Inc. - OCI ( Mr. Adam Mitz)
  • Summary:

    In remove this part:
    "Note that the cipher operations have 16-byte block-size and add padding when needed. Therefore the secure data.length (ā€œNā€) will always be a multiple of 16."

    AES-GCM doesn't add padding. The implication of this is that the CryptoContent Submessage Element may end at an arbitrary point in the stream (from the point of view of alignment). Bringing the stream "back into alignment" will depend on the usage context:

    • When encoding payload, the CryptoFooter follows directly after CryptoContent. This means that CryptoFooter's first element (common_mac) may start unaligned. Then receiver_specific_macs.length appears in the stream as a 32-bit value so it will be preceded by 0-3 padding bytes depending on the length of CryptoContent.
    • When encoding a submessage or full message, CryptoContent is followed by the start of another submessage which must be aligned to 4 per the RTPS spec.
  • Reported: DDS-SECURITY 1.1b1 — Tue, 1 May 2018 15:10 GMT
  • Disposition: Deferred — DDS-SECURITY 1.2
  • Disposition Summary:

    Defer to next RTF

    Defer to next RTF

  • Updated: Mon, 17 Jun 2024 13:36 GMT