Introduction
ZIP files are everywhere in .NET applications. They are commonly used for backups, document exports, log bundles, file transfers, and application-generated reports.
Until .NET 11, developers who needed password-protected ZIP archives often depended on third-party libraries because the built-in ZIP APIs did not provide native support for creating and reading encrypted entries.
.NET 11 adds built-in support for encrypted ZIP archives, including ZipCrypto and WinZip AES encryption methods. Microsoft recommends AES-256 for new archives because ZipCrypto has known cryptographic weaknesses.
That makes an interesting performance question:
What does encryption add to ZIP creation and extraction, and how does that cost change as the archive becomes larger?
Instead of assuming that encryption is either "fast" or "slow," we can build a benchmark that measures archive creation time, extraction time, output size, memory usage, and CPU-related work.
What Changed in .NET 11?
.NET 11 adds password support directly to the ZIP APIs.
The new functionality supports:
ZipCrypto
WinZip AES-128
WinZip AES-192
WinZip AES-256
For new applications, AES-256 is the recommended choice. ZipCrypto should generally be used only when compatibility with older tools requires it.
For example, an encrypted entry can be created with AES-256:
using System.IO.Compression;
using var archive = ZipFile.Open(
"documents.zip",
ZipArchiveMode.Create);
archive.CreateEntry(
"report.txt",
"my-password",
ZipEncryptionMethod.Aes256);
The exact API surface can vary across preview builds, so when evaluating .NET 11 preview features, developers should use the API available in the SDK they are testing.
Why Encryption Changes the Workload
A normal ZIP operation involves compression and archive management.
An encrypted ZIP adds cryptographic processing.
The simplified pipeline becomes:
Input files
|
v
Read file
|
v
Compress
|
v
Encrypt
|
v
Write ZIP
During extraction, the process is reversed:
Encrypted ZIP
|
v
Read archive
|
v
Decrypt
|
v
Decompress
|
v
Write files
That additional cryptographic work can affect CPU consumption and execution time.
The actual impact depends on several factors, including archive size, number of files, compression level, encryption method, storage speed, and the characteristics of the input data.
Creating an Encrypted ZIP Archive
.NET 11 also adds encryption options to the higher-level ZIP convenience APIs.
For example:
using System.IO.Compression;
ZipFile.CreateFromDirectory(
sourceDirectory,
"backup.zip",
new ZipFileCreationOptions
{
Password = "my-password".AsMemory(),
EncryptionMethod = ZipEncryptionMethod.Aes256,
CompressionLevel = CompressionLevel.Optimal
});
This approach is convenient when the requirement is simply:
Take a directory.
Compress its contents.
Encrypt the archive.
Save the result.
The password should not be hard-coded in a real application.
For example, an application might obtain it from a secure configuration or secret-management system:
var password = configuration["ArchivePassword"]
?? throw new InvalidOperationException(
"Archive password is not configured.");
Secrets should not be committed to source control or written to application logs.
Extracting an Encrypted Archive
An encrypted archive can also be extracted using the convenience API:
ZipFile.ExtractToDirectory(
"backup.zip",
destinationDirectory,
new ZipExtractionOptions
{
Password = "my-password".AsMemory(),
OverwriteFiles = false
});
For individual entries, the password can be supplied when opening the entry:
using ZipArchive archive =
ZipFile.OpenRead("backup.zip");
foreach (var entry in archive.Entries)
{
using Stream stream =
entry.Open("my-password");
// Process decrypted content.
}
Microsoft also exposes the encryption method through ZipArchiveEntry.EncryptionMethod, allowing applications to inspect how an entry was encrypted.
AES-256 vs ZipCrypto
The encryption algorithm matters both for security and interoperability.
| Encryption Method | Security | Compatibility | Recommended for New Archives |
|---|
| None | No encryption | Very high | No |
| ZipCrypto | Weak by modern standards | Broad | No |
| AES-128 | Stronger | Depends on tool | Sometimes |
| AES-192 | Strong | Depends on tool | Sometimes |
| AES-256 | Strongest option provided | Depends on tool | Yes |
Microsoft specifically recommends AES-256 for new archives and describes ZipCrypto as a legacy option that should be used only for backward compatibility.
So a performance benchmark should not present ZipCrypto as the "better" option simply because it happens to require less work.
Security requirements come first.
Designing a Fair Benchmark
A useful benchmark should compare the same input files across several configurations.
For example:
Test A
ZIP without encryption
Test B
ZIP + ZipCrypto
Test C
ZIP + AES-128
Test D
ZIP + AES-256
Use the same:
Files
Directory structure
Compression level
Storage location
Runtime
Operating system
Machine
Benchmark configuration
Only change the encryption setting.
This makes it easier to attribute differences to encryption rather than another variable.
Measuring Archive Creation
BenchmarkDotNet can be used to isolate archive creation.
For example:
using BenchmarkDotNet.Attributes;
[MemoryDiagnoser]
public class ZipBenchmark
{
private const string SourceDirectory =
"TestData";
[Benchmark]
public void CreateUnencrypted()
{
ZipFile.CreateFromDirectory(
SourceDirectory,
"plain.zip",
CompressionLevel.Optimal,
false);
}
[Benchmark]
public void CreateEncrypted()
{
ZipFile.CreateFromDirectory(
SourceDirectory,
"encrypted.zip",
new ZipFileCreationOptions
{
Password = "benchmark-password".AsMemory(),
EncryptionMethod =
ZipEncryptionMethod.Aes256,
CompressionLevel =
CompressionLevel.Optimal
});
}
}
The exact overloads available depend on the .NET 11 SDK build being tested.
A benchmark should also avoid repeatedly using the same output file if the API or test setup causes previous results to influence the next run.
For example, clean up generated archives between iterations.
Measuring Extraction
Creation and extraction should be benchmarked separately.
They are different workloads.
A simple extraction benchmark can look like:
[Benchmark]
public void ExtractEncrypted()
{
var destination = "Extracted";
Directory.CreateDirectory(destination);
ZipFile.ExtractToDirectory(
"encrypted.zip",
destination,
new ZipExtractionOptions
{
Password =
"benchmark-password".AsMemory(),
OverwriteFiles = true
});
}
Again, the benchmark needs cleanup between iterations so that the destination directory does not grow or interfere with subsequent measurements.
What Should Be Measured?
A useful benchmark should capture more than execution time.
| Metric | Why It Matters |
|---|
| Creation time | Measures archive generation |
| Extraction time | Measures archive restoration |
| Archive size | Shows compression/encryption output size |
| Allocated memory | Shows managed allocation behavior |
| CPU usage | Shows processing cost |
| File count | Helps explain metadata overhead |
| Input size | Makes results reproducible |
BenchmarkDotNet's memory diagnoser can provide useful allocation information:
[MemoryDiagnoser]
public class ZipBenchmark
{
// Benchmark methods
}
The actual measurements should be collected from the target environment rather than invented.
Input Data Matters More Than It Looks
Two files with the same size can behave very differently during compression.
Consider:
Dataset A
Large text files
Highly repetitive content
Dataset B
JPEG images
Already compressed
Dataset C
Random binary data
Poorly compressible
The resulting ZIP behavior can be very different.
For that reason, a serious benchmark should include data representative of the application's real workload.
For example, if the application generates PDF reports and images, benchmarking only repetitive text files will not tell you much about production behavior.
Testing Different Archive Sizes
A practical test matrix can use several archive sizes:
Small
~10 MB
Medium
~100 MB
Large
~500 MB
Application-specific
Real production-like dataset
These values are examples for designing the test, not expected benchmark results.
The important part is to observe how the encryption overhead changes as the workload grows.
Compression Level Also Matters
Encryption is not the only factor affecting ZIP performance.
Compression level can change CPU usage and archive creation time.
For example:
CompressionLevel.Fastest
and:
CompressionLevel.Optimal
represent different trade-offs.
If one benchmark uses Fastest without encryption and another uses Optimal with AES-256, the result does not isolate encryption.
Keep compression settings identical when measuring encryption overhead.
File Count Can Affect Performance
Archive size is not the only variable.
Consider two archives:
Archive A
1 file
500 MB
Archive B
50,000 files
500 MB total
They have the same approximate data size but very different metadata and filesystem workloads.
The second archive may involve substantially more file-opening, metadata, and directory operations.
A useful benchmark should therefore document both total data size and file count.
Testing AES-128 and AES-256
If the application has flexibility in its encryption choice, compare the AES variants separately.
For example:
var options = new ZipFileCreationOptions
{
Password = password.AsMemory(),
EncryptionMethod = ZipEncryptionMethod.Aes256,
CompressionLevel = CompressionLevel.Optimal
};
Then repeat the test using the appropriate AES method.
Do not automatically choose an algorithm based only on benchmark timing.
AES-256 is Microsoft's recommended choice for new encrypted ZIP archives.
If compatibility requirements force a different algorithm, document that requirement clearly.
Testing Password Failures
Performance testing should not be limited to successful extraction.
An application should also test what happens when the password is incorrect.
For example:
try
{
using ZipArchive archive =
ZipFile.OpenRead("encrypted.zip");
foreach (var entry in archive.Entries)
{
using var stream =
entry.Open("incorrect-password");
stream.CopyTo(Stream.Null);
}
}
catch (Exception ex)
{
Console.WriteLine(
$"Archive could not be opened: {ex.Message}");
}
The exact exception behavior should be verified against the .NET version being tested rather than assuming that every incorrect-password scenario produces the same exception type.
Common Mistakes
Using ZipCrypto for New Security-Sensitive Archives
ZipCrypto is retained for compatibility, but it has known cryptographic weaknesses.
Use AES-256 for new archives unless an interoperability requirement prevents it.
Hard-Coding Passwords
This:
var password = "MySecret123";
is acceptable for a demonstration but not for production secret management.
Use a secure secret-management mechanism.
Benchmarking Only Archive Creation
Extraction can have different performance characteristics.
Measure both when the application performs both operations.
Using Only One Type of Data
Compression behavior depends heavily on the input.
Use realistic data.
Comparing Different Compression Levels
Keep compression settings identical when measuring encryption overhead.
Treating Archive Size as a Security Metric
A smaller archive does not mean a more secure archive.
Security and compression are different concerns.
Troubleshooting
If an encrypted archive cannot be opened, check:
The archive was actually created with encryption.
The password is correct.
The encryption method is supported.
The application is using a compatible .NET version.
The ZIP tool used to create the archive is compatible with the selected encryption format.
The entry is not using an unsupported encryption method.
Microsoft documents that unsupported encryption methods can be reported through ZipEncryptionMethod.Unknown, and attempting to open an unsupported encrypted entry can result in NotSupportedException.
If performance is unexpectedly poor, inspect:
Production Considerations
Encrypted ZIP support is useful for applications that generate archives containing sensitive information.
Typical examples include:
But password-protecting a ZIP file does not automatically solve every data-security problem.
Consider how the password is:
Generated
Stored
Delivered
Rotated
Revoked
Protected from logging
For example, avoid:
logger.LogInformation(
"Archive password: {Password}",
password);
Logging the password defeats much of the purpose of encrypting the archive.
Also consider whether sending the password through the same communication channel as the archive provides meaningful protection.
Best Practices
Prefer AES-256
For new encrypted ZIP archives, use AES-256 unless compatibility requirements dictate otherwise.
Keep Passwords Out of Source Code
Use secure configuration and secret-management mechanisms.
Benchmark Realistic Data
Include representative file types, sizes, and file counts.
Separate Compression and Encryption Tests
Measure unencrypted, encrypted, and different encryption methods independently.
Measure Creation and Extraction
Applications that support both operations should benchmark both.
Test Under Concurrency
If multiple users can generate archives simultaneously, test the effect on CPU, memory, storage, and application throughput.
Document the Exact Environment
Record the .NET SDK version, operating system, hardware, compression settings, encryption method, and test dataset.
Advantages
Provides built-in encrypted ZIP support in .NET 11.
Supports AES encryption options.
Reduces the need for third-party ZIP libraries for supported scenarios.
Integrates encryption with existing System.IO.Compression APIs.
Supports encrypted archive creation and extraction.
Allows applications to inspect an entry's encryption method.
Disadvantages
Encryption adds processing work.
Archive performance depends heavily on input data and file count.
Compatibility can vary between ZIP tools and encryption methods.
Password management becomes an application security responsibility.
Preview APIs may change while .NET 11 is still under development.
Encryption does not remove the need for secure data handling elsewhere in the application.
Conclusion
.NET 11 brings password-protected ZIP archives into the built-in .NET compression APIs, making encrypted archive workflows much easier to implement without automatically reaching for a third-party library.
The performance question is more nuanced.
Encryption adds processing work, but the actual impact depends on archive size, file count, compression level, encryption method, storage performance, and concurrency. That is why a useful benchmark should measure creation and extraction separately and should include realistic application data.
For new encrypted archives, AES-256 should be the default choice unless compatibility requirements require another method. ZipCrypto is a legacy option and should not be selected merely because a benchmark happens to show lower processing cost.
The best way to evaluate the feature is to build a controlled benchmark, keep the input and compression settings consistent, measure CPU and memory alongside execution time, and test the workload your application will actually handle.
That gives developers something much more useful than a generic claim that encrypted ZIP files are "fast" or "slow": concrete evidence about the cost of protecting their own data.