Add password to ZipArchive

[neridonk]

can we make that happen?

[ianhays]

It's certainly possible to add encryption support to ZipArchives. There are a few competing standards for which encryption and accompanying header definitions, but I think the AES one used by 7-zip is one of the more popular ones. There's also basic passwords included in the zip format but iirc those are easily crackable.

The format also has some strong encryption support but it's copyrighted so out of bounds for us.

[karelz]

We need API proposal to move it further.

[ghost]

Speaks something against?

namespace System.IO.Compression
{
    public static class ZipFile 
    {
        public static ZipArchive Open(String archiveFileName, ZipArchiveMode mode, Encoding entryNameEncoding, string password)
    }
}

[karelz]

@ianhays can you please comment if that is sufficient?

[ianhays]

@lburkovsky take a look at this issue for a good example of the kind of API proposal that we're looking for. In general, the more implementation details, the better. You can also look at our API Review process doc for more info on the process.

For Zip password support specifically, an API proposal should include analysis on the different methods of password support in Zip, the pros and cons of each, and which you think should be officially supported in .NET.

[danmoseley]

@neridonk perhaps you would like to make the proposal for us to formally review? as above.

[mfjerome]

Any news or plans about this feature? Would be very useful!

[karelz]

@mfjerome we are open to API proposal and contribution. Are you interested?

[carlossanlop]

What do we need this feature for? Is it for reading password-protected files or producing or something else?
@bartonjs can you please chime in?

[bartonjs]

I'm not quite sure what's being asked of me here. So here are words.

• The PKZIP encryption seems to require a license to implement.
• The WinZip encryption scheme does not.

All further comments relate to the WinZIp version:

• Technically speaking, I think each entry could be encrypted with a different password. In practice, it seems unlikely; so asking for a single decryption password seems reasonable.
• Key generation uses PBKDF2, which is the algorithm used by System.Security.Cryptography.Rfc2898DeriveBytes.
• Encryption is done using AES-CTR. We currently don't expose AES-CTR as public API.
  • There are ways to cheat and get it... and people have asked for it... so we might just add it this release with some of the new API.
• For creating new encrypted ZIP files you probably want to accept an encryption algorithm/mode value. This allows for callers to change from Aes256 to whatever algorithm replaces Aes256 in the future without creating compatibility/tool-interop concerns.

The preference in cryptography API is to never have a default algorithm choice, so creating new encrypted ZIP files would require using a method that took that as an input. That might mean that instead of

public static ZipArchive Open(String archiveFileName, ZipArchiveMode mode, Encoding entryNameEncoding, string password);

You want

public enum ZipEncryptionMode
{
    Unknown,
    Aes128,
    Aes192,
    Aes256,
}

public static ZipArchive OpenRead(string archiveFileName, Encoding entryNameEncoding, string password);

public static ZipArchive OpenCreate(string archiveFileName, Encoding entryNameEncoding, string password, ZipEncryptionMode encryptionMode);

public static ZipArchive OpenUpdate(string archiveFileName, Encoding entryNameEncoding, string password, ZipEncryptionMode encryptionMode);

Or, you could combine them:

public enum ZipEncryptionMode
{
    Unknown,
    Aes128,
    Aes192,
    Aes256,
}

// Update/Create modes will throw if newFileEncryptionMode is default
public static ZipArchive Open(string archiveFileName, Encoding entryNameEncoding, string password, ZipEncryptionMode newFileEncryptionMode = default);

This is all unfortunate that you're holding the password string in memory. Being able to take it as a ReadOnlySpan would be nicer, but requires moving the encrypt/decrypt to verbs on ZipFileEntry (which may be useful anyways, for degenerate files that use multiple different passwords).

So, short form:

• Prefer a mode where you don't persist the password to a field.
  • If you feel you need it for high-level usability, well, I guess. So try for "in addition"
• The encryption mode must be an input for new content. Prefer a parameter input (explicitly specified) over a property (with a default value)... because we're almost never willing to change defaults for choices that apply to persisted files.

[soroshsabz]

I think this issue can resolve my feature needed in https://developercommunity.visualstudio.com/idea/368318/add-password-protected-zip-file-to-systemiocompres.html

[NgocThachThai]

We need it.

[adamsitnik]

@jeffhandley @danmoseley I think it's a good .NET 7 candidate for the "Bottom Up" initiative

[danmoseley]

Could well be. That's what the 7.0 milestone is for.

[cgountanis]

So... can we extract Zips with passwords yet? .NET6-8+

[SuhasParameshwara]

So we have to use third party library?

[wakuflair]

Can't believe this issue is still open

[dos-ise]

dotnetzip is now no longer maintained. And this feature is still not implemented.
This missing feature is still blocking us from using System.IO.Compression.

https://github.com/haf/DotNetZip.Semverd

[tts-sdrissen]

need this, too

[cgountanis]

Best I can think of is that, there's just too many compression and encryption methods. We ended up just using SharpZipLib, wasn't really too bad.

[sladecurtis]

Need this also!
So basic a concept.. please implement in near future.
My use case: SOC junior analysts attempting to take potentially malicious files off a machine that threw an endpoint alert in Azure. We want them to zip and password protect the malicious file and download from a Defender Live Response Session. Currently this cannot be done. Zip is a good start, but all potentially malicious files should be password protected too (standard malware handling procedures). We've tested and cannot even install other modules from a live response session, so it needs to be native to powershell cmdlets. Thanks.

[StarWars999123]

@SteveL-MSFT Is there any update to put it on the roadmap by Microsoft?
What about implementations for the legacy .net framework support for NET472, NET48, and NET6 that could previously rely on the maintained DotNetZip library? IMHO this isn't something to be planned for NET9 or whatever, but something that needs to support even the old frameworks asap.

I don't wanna express my honest thoughts regarding this issue, but lets say @peter0302 kept it very polite...

[peter0302]

I don't wanna express my honest thoughts regarding this issue, but lets say @peter0302 kept it very polite...

LOL they marked my comment as abuse. Imagine if I'd expressed my honest thoughts.

The format also has some strong encryption support but it's copyrighted so out of bounds for us.

First it's a patent not a copyright:

https://ppubs.uspto.gov/dirsearch-public/print/downloadPdf/11461487

Priority date is July 16, 2003 with a 242 day administrative extension, plus a 20 year term. That's March 14, 2024, meaning the patent is expired.

Patent gone, carry on. Time to implement this.

[chosh-capa]

You have to be freakin kidding me. I just was about to add password support and started looking for ZipArchive constructor overloads that took a password, and not finding one, Googled it. This is the last thing I expected to see. What on earth is wrong with you people? How can this not be part of .NET's built-in Zip support? I don't even know what to say.

Absolutely the same feeling.
The support for compressed archive formats is probably the worst part of the .Net experience.

I hope they can prioritize these fundamental experiences that have been missing for decades, so that we can love the .NET ecosystem even more.

[sladecurtis]

So that means we might actually get this feature added in future??? [Hopeful] Sent from Proton Mail Android

…

-------- Original Message --------

On 2024-07-19 11:50 a.m., peter0302 wrote: > I don't wanna express my honest thoughts regarding this issue, but lets say ***@***.***(https://github.com/peter0302) kept it very polite... LOL they marked my comment as abuse. Imagine if I'd expressed my honest thoughts. > The format also has some strong encryption support but it's copyrighted so out of bounds for us. First it's a patent not a copyright: https://ppubs.uspto.gov/dirsearch-public/print/downloadPdf/11461487 Priority date is July 16, 2003 with a 242 day administrative extension, plus a 20 year term. That's March 14, 2024, meaning the patent is expired. Time to implement this. — Reply to this email directly, [view it on GitHub](#1545 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BHIU6D4Q7IVAHCP3VWWD7T3ZNEOBRAVCNFSM4KE7AGG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRTHEZDSMBVGMZA). You are receiving this because you commented.Message ID: ***@***.***>

[PracticalCode]

Above, and almost 8 years ago, ianhays commented [on Nov 3, 2016] @lburkovsky take a look at this issue for a good example of the kind of API proposal that we're looking for. In general, the more implementation details, the better. You can also look at our API Review process doc...

Does anyone know if this was completed?.. (or still relevant in MS processes?) ... while I disagree this should be the reason why this is held up; it's also kinda sad if no one's completed it in almost 8 years. (I'm willing to.. presuming it's still a relevant process.)

[sladecurtis]

Super bummed. This not even possible then? Sent from Proton Mail Android

…

-------- Original Message --------

On 2024-07-19 12:02 p.m., 張 wrote: > You have to be freakin kidding me. I just was about to add password support and started looking for ZipArchive constructor overloads that took a password, and not finding one, Googled it. This is the last thing I expected to see. What on earth is wrong with you people? How can this not be part of .NET's built-in Zip support? I don't even know what to say. Absolutely the same feeling. The support for compressed archive formats is probably the worst part of the .Net experience. — Reply to this email directly, [view it on GitHub](#1545 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BHIU6D35JS3DDME4DFOWTMTZNEPPRAVCNFSM4KE7AGG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRTHEZTCNZXGQYQ). You are receiving this because you commented.Message ID: ***@***.***>

[peter0302]

Super bummed. This not even possible then?

It's 100% possible. Ionic supported it. The only understandable reason it appears MS didn't initially support it was the patent, which is now expired. So there's no reason not to do it now.

[sladecurtis]

Oh excellent. Effort to implement? Estimate? Sent from Proton Mail Android

…

-------- Original Message --------

On 2024-07-24 9:26 a.m., peter0302 wrote: > Super bummed. This not even possible then? It's 100% possible. Ionic supported it. The only understandable reason it appears MS didn't initially support it was the patent, which is now expired. So there's no reason not to do it now. — Reply to this email directly, [view it on GitHub](#1545 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/BHIU6D4DOALGDUP22RSVYR3ZN6I5JAVCNFSM4KE7AGG2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRUG43TENBRGU4A). You are receiving this because you commented.Message ID: ***@***.***>

[NerLOR]

I would suggest an API like this:

public enum ZipEncryptionMode { Unknown, WinZipAes128, WinZipAes192, WinZipAes256 }

public class ZipFile
{
    // current
    public ZipArchiveEntry? GetEntry(string entryName);
    public ZipArchiveEntry CreateEntry(string entryName);
    public ZipArchiveEntry CreateEntry(string entryName, CompressionLevel compressionLevel);
    // suggestion
    public ZipArchiveEntry? GetEntry(string entryName, string? password, bool failIfUnencrypted = false);
    public ZipArchiveEntry CreateEntry(string entryName, ZipEncryptionMode encryptionMode, string password);
    public ZipArchiveEntry CreateEntry(string entryName, CompressionLevel compressionLevel, ZipEncryptionMode encryptionMode, string password);
}

public enum ZipCompressionMethod { Unknown, Store, Deflate, ... }

public class ZipArchiveEntry
{
    // suggestion
    public ZipEncryptionMode EncryptionMode { get; }
    // additional suggestion
    public ZipCompressionMethod CompressionMethod { get; }
}

This allows for each entry to have a different (or no) password (which the WinZip standard allows). The enum values ZipEncryptionMode.WinzipAes256 and so on allow to implement encryption modes other than WinZip in the future.

When decrypting the password alone should be enough (because the encryption mode is saved in the zip archive). When failIfUnencrypted is true GetEntry should throw an exception if the entry is not encrypted. GetEntry should also throw an exception when the wrong password is provided (or the encryption method is unknown).

I think it would be beneficial to allow users to check the EncryptionMode or CompressionMethod used in a ZipArchiveEntry. This would allow for (simple) security checks (like to prohibit unsafe encryption modes or compression methods).

Any comments on my suggestions are appreciated.

http://www.winzip.com/aes_info.htm

[StarWars999123]

I would really appreciate your idea to encrypt each entry with a different password/method as DotNetZip also did.

[StarWars999123]

Regarding this API approach (#1545 (comment)), I would like to add, that the support of BasicEncryption would be useful and would like to add it to ZipEncryptionMode.
Reason: It's the only encryption, that the WindowsExplorer supports so far, and as thus, it can be useful for files that should not be accessible for everyone immedeatly, but can be opened with the default tools.

[Matthias-Heinz]

Any estimate, when this feature will be implemented? Passwords are a pretty common use-case for zip archives in my opinion.