Add password to ZipArchive

neridonk commented 7 years ago

can we make that happen?

ianhays commented 7 years ago

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 commented 7 years ago

We need API proposal to move it further.

ghost commented 7 years ago

Speaks something against?

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

karelz commented 7 years ago

@ianhays can you please comment if that is sufficient?

ianhays commented 7 years ago

@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 commented 7 years ago

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

mfjerome commented 6 years ago

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

karelz commented 6 years ago

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

carlossanlop commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

We need it.

adamsitnik commented 2 years ago

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

danmoseley commented 2 years ago

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

cgountanis commented 1 year ago

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

SuhasParameshwara commented 3 months ago

So we have to use third party library?

wakuflair commented 2 months ago

Can't believe this issue is still open

dos-ise commented 2 months ago

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 commented 3 weeks ago

need this, too

peter0302 commented 1 week ago

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.

cgountanis commented 1 week ago

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 commented 5 days ago

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 commented 4 days ago

@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 commented 4 days ago

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 commented 4 days ago

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 commented 4 days ago

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, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

dotnet / runtime

Add password to ZipArchive #1545