.NET 11 ZIP Password Support: Benchmarking Encrypted Archive Performance

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:

Compression level
Number of files
File sizes
Storage speed
CPU utilization
Encryption method
Archive size
Concurrent archive operations

Production Considerations

Encrypted ZIP support is useful for applications that generate archives containing sensitive information.

Typical examples include:

Exported reports
Customer document bundles
Backup packages
Diagnostic packages
Data exchange files

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.