Почему PasswordRecipient CMS использует KEK?

Когда используешь openssl cms -encrypt -pwri_password, следует процесс, описанный в RFC 3211, который передает предоставленный пользователем пароль в KDF, но затем вместо того, чтобы использовать выходные данные этого KDF для шифрования содержимого, он вместо этого использует этот ключ в качестве KEK для шифрования фактического ключа шифрования содержимого (CEK), который затем в комплекте с контентом:

ПОСЛЕДОВАТЕЛЬНОСТЬ (2 элемента)
  ИДЕНТИФИКАТОР ОБЪЕКТА 1.2.840.113549.1.7.3 конвертированные данные (PKCS #7)
  [0] (1 элемент)
    ПОСЛЕДОВАТЕЛЬНОСТЬ (3 элемента)
      ЦЕЛОЕ 3
      КОМПЛЕКТ (1 элемент)
        [3] (4 элемента)
          ЦЕЛОЕ 0
          [0] (2 элемента)
            ИДЕНТИФИКАТОР ОБЪЕКТА 1.2.840.113549.1.5.12 pkcs5PBKDF2 (PKCS #5 v2.0)
            ПОСЛЕДОВАТЕЛЬНОСТЬ (2 элемента)
              СТРОКА ОКТЕТОВ (8 байт) D81093AEE45462EE
              ЦЕЛОЕ ЧИСЛО 2048
          ПОСЛЕДОВАТЕЛЬНОСТЬ (2 элемента)
            ИДЕНТИФИКАТОР ОБЪЕКТА 1.2.840.113549.1.9.16.3.9 pwriKEK (алгоритмы S/MIME)
            ПОСЛЕДОВАТЕЛЬНОСТЬ (2 элемента)
              ИДЕНТИФИКАТОР ОБЪЕКТА 1.2.840.113549.3.7 des-EDE3-CBC (алгоритм шифрования RSADSI)
              СТРОКА ОКТЕТОВ (8 байт) BB96EE7A71BA5792
          СТРОКА ОКТЕТОВ (32 байта) 569E1E845BA33D24D4243ED28B265B0974C486B813E6B9582B014D7E53DD01B9
      ПОСЛЕДОВАТЕЛЬНОСТЬ (3 элемента)
        ИДЕНТИФИКАТОР ОБЪЕКТА 1.2.840.113549.1.7.1 данные (PKCS #7)
        ПОСЛЕДОВАТЕЛЬНОСТЬ (2 элемента)
          ИДЕНТИФИКАТОР ОБЪЕКТА 1.2.840.113549.3.7 des-EDE3-CBC (алгоритм шифрования RSADSI)
          СТРОКА ОКТЕТОВ (8 байт) 05AD3B1BDCB767CC
        [0] (16 байт) 7FA32912ECCCD7C421D4F122FD1ED172

В спецификации указано (выделено мной):

§1.2.1 Обоснование

Упаковка ключей на основе пароля является двухэтапный процесс: на первом этапе вводимый пользователем пароль при необходимости преобразуется в KEK, а на втором этапе KEK используется для шифрования CEK.

Но мне непонятно Почему шифрование CMS на основе пароля выполняется с помощью этого двухэтапного процесса. Защищает ли это как-то от будущих уязвимостей в KDF, которые еще предстоит обнаружить?

В KDF уже реализована соль, поэтому его вывод явно уже защищен, например, от радужные таблицы — так в чем преимущество этой модели KEK на основе пароля с зашифрованным CEK в комплекте? над просто используя вывод KDF непосредственно как CEK?

CMS просто следует стандартному дизайну.

CMS позволяет шифровать сообщение для нескольких получателей. шифрование контента использует случайно сгенерированный ключ CEK. Объект CMS содержит Зашифрованный ключ blob для каждого получателя. Каждый большой двоичный объект EncryptedKey содержит CEK, зашифрованный с помощью метода, который может различаться для каждого получателя.

Этот двухуровневый механизм является стандартным для шифрования сообщений с несколькими получателями.Существует единый ключ шифрования содержимого (CEK): если содержимое шифруется отдельно для каждого получателя, это умножает размер сообщения и работу, проделанную для шифрования, на количество получателей. Каждый получатель должен каким-то образом получить CEK, но, как правило, разные получатели имеют разные наборы заранее установленных секретов (например, они знают разные пароли или имеют разные закрытые ключи). Итак, сообщение с Н получатели содержит Н большие двоичные объекты, каждый из которых может быть прочитан разными получателями.

Кроме того, этот двухуровневый механизм также является стандартным, когда речь идет о паролях, даже если предполагается, что один пользователь расшифровывает данные. Пользователи часто хотят сменить пароль. Если бы CEK был получен из пароля, изменение пароля потребовало бы повторного шифрования данных. Поэтому вместо этого пароль используется только для шифрования CEK.