Measure encrypted Queue Storage messages after their envelope is encoded

Source facts

Client-side Queue Storage encryption adds encryption metadata that counts toward the 64 KB message limit. The encrypted message is Base64-encoded, which expands the transmitted content. A plaintext-size check therefore does not establish that the completed encrypted message fits.

Microsoft no longer recommends client-side encryption v1 because of a CBC implementation vulnerability. Migration requires a v2-capable client. For short-lived queue messages, Microsoft says separate decryption and re-encryption should not be necessary: older messages rotate through normal consumption. For most scenarios, Microsoft recommends service-side encryption for simpler operation. Microsoft Learn.

Applicability

Identify why client-side encryption is required, the producer and consumer library versions, and the actual message format. This brief does not recommend introducing legacy encryption or invent a universal safe plaintext limit.

DSE recommendation

DSE recommends validating the complete encoded envelope before sending a message. Test realistic payload variation and establish explicit handling for oversized messages rather than relying on a fixed estimate of overhead. Coordinate v2-capable producer and consumer changes, and review older messages’ normal consumption rather than assuming a separate bulk-conversion step is required.

Verification

In an approved test queue, send harmless representative messages around the application’s intended size boundary using the actual supported library. Confirm both service acceptance and successful consumer decryption. Record encoded size, library version and result without logging plaintext secrets or key material. Treat rejection or decryption failure as an unresolved contract mismatch before increasing the production payload allowance.

Official references

Microsoft Learn: Client-side encryption for queues. Source retrieved September 9, 2026.