De ce CMS' PasswordRecipient folosește un KEK?

Atunci când se utilizează openssl cms -encrypt -pwri_password, urmează procesul descris în RFC 3211, care transmite parola furnizată de utilizator într-un KDF, dar apoi, în loc să folosească rezultatul acelui KDF pentru a cripta conținutul, folosește acea cheie ca KEK pentru a cripta cheia reală de criptare a conținutului (CEK), care este apoi împreună cu conținutul:

SECVENȚA (2 elemente)
  IDENTIFICATOR DE OBIECT 1.2.840.113549.1.7.3 envelopedData (PKCS #7)
  [0] (1 element)
    SECVENȚA (3 elemente)
      INTEGER 3
      SET (1 element)
        [3] (4 elemente)
          INTEGER 0
          [0] (2 elemente)
            IDENTIFICATOR DE OBIECT 1.2.840.113549.1.5.12 pkcs5PBKDF2 (PKCS #5 v2.0)
            SECVENȚA (2 elemente)
              ȘIR DE OCTET (8 octeți) D81093AEE45462EE
              INTEGER 2048
          SECVENȚA (2 elemente)
            IDENTIFICATOR DE OBIECT 1.2.840.113549.1.9.16.3.9 pwriKEK (algoritmi S/MIME)
            SECVENȚA (2 elemente)
              OBJECT IDENTIFIER 1.2.840.113549.3.7 des-EDE3-CBC (RSADSI encryptionAlgorithm)
              ȘIR DE OCTET (8 octeți) BB96EE7A71BA5792
          ȘIR DE OCTET (32 de octeți) 569E1E845BA33D24D4243ED28B265B0974C486B813E6B9582B014D7E53DD01B9
      SECVENȚA (3 elemente)
        IDENTIFICATOR DE OBIECT 1.2.840.113549.1.7.1 date (PKCS #7)
        SECVENȚA (2 elemente)
          OBJECT IDENTIFIER 1.2.840.113549.3.7 des-EDE3-CBC (RSADSI encryptionAlgorithm)
          ȘIR DE OCTET (8 octeți) 05AD3B1BDCB767CC
        [0] (16 octeți) 7FA32912ECCCD7C421D4F122FD1ED172

Specificația afirmă (sublinierea):

§1.2.1 Motivare

Încheierea cheii bazată pe parolă este un proces în două etape, o primă etapă în care o parolă furnizată de utilizator este convertită într-un KEK dacă este necesar și o a doua etapă în care KEK este utilizat pentru a cripta un CEK.

Dar nu sunt clar De ce Criptarea CMS pe bază de parolă se realizează prin acest proces în două etape. Protejează cumva împotriva vulnerabilităților viitoare care urmează să fie descoperite în KDF?

KDF are deja sare așa cum a fost implementată, astfel încât producția sa este în mod clar deja sigură împotriva de ex. tabelele curcubeu… deci care este avantajul din spatele acestui model KEK derivat din parolă cu pachetul CEK criptat peste pur și simplu folosind ieșirea KDF direct ca CEK?

CMS urmează doar un design standard.

CMS permite criptarea unui mesaj pentru mai mulți destinatari. The criptarea conținutului folosește o cheie generată aleatoriu, CEK. Obiectul CMS conține un EncryptedKey blob pentru fiecare destinatar. Fiecare blob EncryptedKey conține CEK criptat cu o metodă care poate fi diferită pentru fiecare destinatar.

Acest mecanism pe două niveluri este standard pentru a cripta mesajele cu mai mulți destinatari.Există o singură cheie de criptare a conținutului (CEK): dacă conținutul a fost criptat separat pentru fiecare destinatar, aceasta ar multiplica dimensiunea mesajului și munca depusă pentru a cripta, cu numărul de destinatari. Fiecare destinatar trebuie să poată obține cumva CEK, dar, în general, diferiți destinatari au seturi diferite de secrete prestabilite (de exemplu, cunosc parole diferite sau au chei private diferite). Deci un mesaj cu N destinatarii conţine N blob-uri, fiecare dintre acestea putând fi citit de către diferiți destinatari.

În plus, acest mecanism pe două niveluri este, de asemenea, standard ori de câte ori sunt implicate parole, chiar și atunci când un singur utilizator ar trebui să decripteze datele. Utilizatorii doresc adesea să schimbe parolele. Dacă CEK a fost derivat din parolă, o schimbare a parolei ar necesita recriptarea datelor. Deci, în schimb, parola este folosită doar pentru a cripta CEK.