password.ToArray() is bad, you're making an uncleared copy of the secret.

Since you have a streaming protocol, you can just use a stackalloc buffer and walk it pieces at a time. (Especially because I think you're only on .NET "Core")

const int StackAllocSize = 64;
const int SegmentSize = StackAllocSize / 2;
Debug.Assert(Encoding.ASCII.GetMaxByteCount(SegmentSize) == StackAllocSize);

Span<byte> buf = stackalloc byte[64];
ReadOnlySpan<byte> pwSpan = password.Span;

while (!pwSpan.IsEmpty)
{
    ReadOnlySpan<byte> segment = pwSpan;

    if (segment.Length > SegmentSize)
    {
        segment = segment.Slice(0, SegmentSize);
    }

    int byteCount = Encoding.ASCII.GetBytes(segment, buf);

    foreach (byte b in buf.Slice(0, byteCount))
    {
        UpdateKeys(ref key0, ref key1, ref key2, b);
    }

    pwSpan = pwSpan.Slice(segment.Length);
}

...

I believe it's always a good idea to avoid public in non-public classes, since code reviewers then have to stop and think "is this externally callable?"

Can we avoid making an array for this?

AFAICT, it just gets packed into this array then unpacked into 3 integers later. Return a struct of 3 integers... try to keep the key off the heap.

Why is this taking ReadOnlyMemory when it could take ReadOnlySpan?

Instead of returning an array, can it be given the destination span to write to?

I recommend using _aes.EncryptEcb over an ICryptoTransform, it'll allow you to work with spans instead of arrays.

Instead of 256 calls to encrypt, you could

• Fill the whole of _keyStreamBuffer with the counter values
• Call Encrypt/Transform just once, writing in-place.

This undoubtedly could be vectorized to go faster, if you expect the operation to generally be bigger than a few bytes. Even just doing something like

Span<ulong> destUL = Marshal.As<byte, ulong>(dest);
ReadOnlySpan<ulong> srcUL = Marshal.As<byte, ulong>(src);

XorUL(destUL, srcUL);

for (int i = destUL.Length * sizeof(ulong); i < dest.Length; i++)
{
    ...
}

(Though I think if src/dest isn't QWORD aligned that might do something less happy on ARM?)

Might be premature, but if we want to vectorize this, then approach with something like Vector<byte> might be better.

In general, this isn't the right approach... you've already written all of the data into the caller buffer before telling them it's bad. But the only way you can avoid that is to give up on streaming, and I assume you don't want to do that.

(With streaming enabled, even if you did buffer.Clear() on failure, someone could already have read all but the last byte on previous calls)

So, no action here, other than "be educated that this is a bad practice, and is why .NET's AES-GCM doesn't allow streaming decryption"

How many of these operations could take the password as a ReadOnlySpan (so that it could have been securely read into the stack, or native memory), or (at worst) a ReadOnlyMemory?

String is definitely friendlier, but being able to avoid a heap copy of a secret is a more secure design.

These overloads treat an empty password the same as null and throw ArgumentNullException. Since the parameter is non-nullable and empty is a different invalid value, this should be an ArgumentException (or ArgumentException.ThrowIfNullOrEmpty) rather than ArgumentNullException.

These overloads treat an empty password the same as null and throw ArgumentNullException. Since the parameter is non-nullable and empty is a different invalid value, this should be an ArgumentException (or ArgumentException.ThrowIfNullOrEmpty) rather than ArgumentNullException.

OpenAsync(string password, EncryptionMethod encryptionMethod) in Read mode currently ignores the fact that an encryption method was specified and proceeds to open for reading. This contradicts the sync Open(password, encryptionMethod) behavior (and the SR.EncryptionReadMode message), and makes the API inconsistent. In Read mode this overload should throw InvalidOperationException (SR.EncryptionReadMode), matching the other overloads.

The password overload falls back to source.Open()/OpenAsync() when the provided password is empty. Since the API contract is “extract decrypted using the specified password”, accepting an empty string and silently treating it as “no password” is inconsistent (and will also fail for encrypted entries). Prefer validating the password (throw for null/empty) and always calling the password-based Open/OpenAsync overload.

Several newly added resource strings are inconsistent with existing message style: missing trailing periods, inconsistent capitalization (“Encryption Method”), and slightly ungrammatical phrasing (e.g., “on browser”). It would be better to align with the surrounding resources (sentence case + period) to keep exception messages consistent.

ZipCryptoStream.EnsureHeader synchronously blocks on a ValueTask by calling AsTask().GetAwaiter().GetResult(), which allocates a Task unnecessarily. ValueTask supports GetAwaiter() directly; using that avoids the allocation on every write path.

ZipCryptoStream.Write allocates a new byte[] the size of the caller’s buffer on every call, which can be very expensive for typical stream copy buffer sizes (e.g., 80KB). Consider renting from ArrayPool (and returning in a finally) or chunking to a reusable buffer to avoid per-call large allocations.

WinZipAesStream allocates a new 4KB work buffer on every Write/WriteAsync call. For typical usage (CopyTo with many writes), this becomes a steady allocation stream. Consider using ArrayPool or a reusable instance buffer instead.

WinZipAesExtraField.WriteBlock allocates on the heap (new byte[TotalSize]) and WriteBlockCore uses a hard-coded size value (7) even though DataSize exists. Since TotalSize/DataSize are constants and the block is tiny, prefer stackalloc (or reuse DataSize) to avoid allocations and magic numbers.