The core problem: the mathematics of RSA key size

1. Key size limits max plaintext size

2. Padding overhead reduces capacity further

Why "chunking" RSA is a bad anti-pattern

• Performance: RSA is computationally expensive—orders of magnitude slower than symmetric encryption.
  
  
• Ciphertext expansion: encrypting ten 100-byte chunks results in ten full 256-byte blocks (2560 bytes total).
  
  
• Security & integrity risks: standard RSA padding isn't designed for multi-block streaming. Reordering, dropping, or swapping individual chunks becomes trivial for an attacker unless complex custom framing is added.
  
  

The standard solution: hybrid cryptography via CMS envelopedData

How CMS EnvelopedData Works

1. Symmetric payload encryption: A unique, random symmetric key (e.g., a 256-bit AES key) is generated. The input payload—regardless of whether it is 10 bytes or 10 gigabytes—is encrypted using fast symmetric ciphers like AES-GCM or AES-CBC.
   
   
2. Asymmetric key wrapping: The small, fixed-size symmetric key (32 bytes for AES-256) is encrypted using the recipient's RSA public key (KeyTransRecipientInfo). Because 32 bytes easily fits within RSA-OAEP size constraints, payload size limitations disappear.
   
   
3. Standardized Envelope: CMS packages the encrypted payload, the RSA-encrypted symmetric key, recipient identifiers (certificate serial numbers or key IDs), and algorithm identifiers into a self-contained ASN.1 structure.
   
   

Key advantages of using CMS envelopedData

• Arbitrary length: encrypt strings or streams of any size without size checks or chunking hacks.
  
  
• Performance: high-speed symmetric algorithms handle the heavy lifting; slow asymmetric operations only run once per message on a 32-byte key.
  
  
• Multi-recipient support out of the box: The same payload can be made readable by multiple parties simply by adding extra encrypted key blocks (RecipientInfo), encrypting the underlying payload only once (this will be added in a future release).
  
  
• Interoperability: supported natively across major platforms and libraries (OpenSSL, Java Bouncy Castle, .NET EnvelopedCms).
  
  

Example

As usual, we tried to make things as simple as possible for developers. This example requires a TForm, 2 TButtons, a TEdit and a TMemo.

procedure TMainForm.GenerateCMSBtnClick(Sender: TObject);
var
  PlainText: string;
  s: string;
  CMS: TCms;

begin
  PlainText := TextEdit.Text; // the text to encrypt
  CMS := TCms.Create(nil); // the real work is done in the TCMS class
  try
    CMS.encType := TRSAEncType.oaep; // default is PKCS 1.5
    s := CMS.GenerateCMSEnvelopedData(PlainText, '..\..\Certs\MyCert.pem', '.\MyLittleCMS.pem'); // path to files
    MainMemo.Lines.Add(s); // put the result in the TMemo, in PEM format (base64 + header and footer)
  finally
    CMS.Free;
  end;
end;

procedure TMainForm.ValidateCMSBtnClick(Sender: TObject);
var
  s, IssuerDER: string;
  CMS: TCms;

begin
  CMS := TCms.Create(nil);
  try
    CMS.encType := TRSAEncType.oaep;
    s := CMS.DecryptCMSEnvelopedData(
    '.\MyLittleCMS.pem', '..\..\Certs\MyKey.pem', IssuerDER); // Issuer is not used in this version
    MainMemo.Lines.Add(s);
  finally
    CMS.Free;
  end;
end;

Conclusion