Compression
Deflate before encryption, why it often pays for itself, and the three bounds that stop a decompression bomb.
Turn it on, usually#
options.Security.CompressionAlgorithm = SaveFileFormat.CompressionDeflate;Compression is applied before encryption (compressing ciphertext achieves nothing). Measured end to end on a representative 2000-object model, Deflate was faster than no compression — 2.41 ms against 2.80 ms — because a 15× smaller payload (91 KB → 6.1 KB) costs less to hash, encrypt and write. On a slow disk the gap widens. Verified Numbers are shape, not promises: Performance.
Three bounds, enforced before and during expansion#
| Bound | Default | Stops |
|---|---|---|
| Declared size | from the header | A payload that claims to be enormous |
Limits.MaxSaveSizeBytes | 256 MB framework, 32 MB in the settings asset | A payload designed to exhaust memory |
Limits.MaxDecompressionRatio | 512 (framework) / 64× (settings asset) | A decompression bomb |
The expansion ratio is checked while decompressing, not afterwards: a crafted file is stopped mid-expansion rather than allocated and then measured. That ordering is the whole point — measuring after allocating is the attack working.
The validation report checks both ends#
A ceiling nothing can fit under, and a ceiling so high it protects nothing, are both reported. Security settings that look strong and are not are worse than settings that are obviously loose.
Next#
- Encryption — the step that follows it.
- Corruption handling — the other refusals.
- Large saves — what to do when the payload is legitimately big.
Something wrong on this page? Every page here describes behaviour that is checked in the repository. If a page and the package disagree, the package wins.
Report a documentation problem · Frequently asked questions · Troubleshooting