SharpDevelop Community

Hi all

I have used ICSharpCode.SharpZipLib.Zip successfully before on zip-files that were not protected by a password. Now, I'm suppose to open a password protected zip-file.

When I try to read this zip-file using the ICSharpCode.SharpZipLib.Zip i get the following error message:

"Compression method not supported"

The mehod is of the type WinZipAES and a password is inserted. The same file is unziped successfully through WinRAR (also by inserting the password)

Code:

try
            {
                ZipInputStream zipStream = new ZipInputStream( inStream );

                // get password, if supplied
                if ((_password != null) && (_password != ""))
                    zipStream.Password = _password;

                // this algorithm demands that the zip archive contain exactly one file
                ZipEntry entry = zipStream.GetNextEntry();
                if (entry == null)
                    throw new ApplicationException( "Input ZIP archive does not contain any files - expecting exactly one file" );
                if (entry.IsDirectory)
                    throw new ApplicationException( "Input ZIP contains a directory - expecting exactly one file" );

                // copy the compressed stream into the output stream
                outStream = new MemoryStream();
                byte[ buffer = new byte[4096];
                int count = 0;
                while ((count = zipStream.Read(buffer, 0, buffer.Length)) != 0)
                    outStream.Write( buffer, 0, count );

                // make sure that was the one and only file
                entry = zipStream.GetNextEntry();
                if (entry != null)
                    throw new ApplicationException( "Input ZIP archive contains multiple files and/or directories - expecting exactly one file" );

                zipStream.Close();

#if DEBUG
                outStream.Seek( 0, SeekOrigin.Begin );
                Microsoft.Samples.PipelineUtilities.FileStreamReadWrite.DumpStreamToFile( outStream, outFile );
#endif

                outStream.Seek( 0, SeekOrigin.Begin );
            }
            catch (Exception ex)
            {
                System.Diagnostics.Debug.WriteLine(ex);
                throw;
            }

I hope you guys can help me on this one since this will become a very critical issue for me.

Regards

A.H.

Hi Allan

AES is not yet supported in ZipInputStream.

Use ZipFile instead - there are some code samples in the wiki if this helps.

The only thing you can't do with Zipfile that you with ZipInputStream is read an unseekable stream.

hope that helps,
David

Thank you David. It worked.

You are a lifesafer:)

David,

What would be needed to have AES support in ZipInputStream ?

David,

Is the main issue with the AES implementation that you require to seek back limited number of bytes back in the input stream? If that is the case you can implement "partial seek" wrapper over the input stream, which allows seek back up to limited amount of bytes. I can send you c# class which implements the idea.

Nekobul,

Thanks but that is not the issue, there is no seekback required. It is that the code structure around streams and crypto streams was completely different, meaning that the aes stream did not simply plug in.

At the time there was intense pressure to get a new cut out with a lot of fixes and new features. End of the day you have to draw a line. This post has been the first or maybe second one to my recollection wanting zipinputstream aes, so it is good to see some demand. We could use it where I work too, so I will get onto it.

Thanks for your interest!

David

Hi David,

Thank you for your reply! I have analyzed the code base and I think I now have better understanding what needs to be done. Check below:

1. We don't need ZipAESStream class. It doesn't fit properly in the current design as you have found.

2. The 16 byte processing logic has to be part of ZipAESTransform class. You can pass as many bytes as you need to the TransformBlock method, but internally it will process in 16 byte crypto-blocks.

3. Verification of authentication code has to be done in the TransformFinalBlock method. This means that the ZipAESTransform class has to make sure it doesn't accidently try to decrypt the last 10 bytes of authentication code data.

4. I think InflaterInputStream class implementation is somewhat incomplete because it doesn't use TransformFinalBlock method at all. This has to be fixed.

What do you think about this plan? I would like to help , but I have the feeling you might be able to get this new code implemented much faster than me.

Hi,

ZipAESStream does the job that would otherwise be referred to as a seekback. It effectively reads ahead a few bytes to detect end of stream. This concept needs to remain like this, wherever it is implemented, because we cannot go back in time. Once we have output to the decrypted stream it is too late to take it back. Readahead is the only option. Seekback is too late.

The CryptoStream was where i hit a roadblock. Will have to look again but it didn't fit neatly. We do need a stream to deal with the buffering, and getting it to fit in was the challenge IIRC.

Feedback welcome as always. Will have a look soon - good time for me time-wise ATM.

David,

You can do the read ahead alike logic in the ZipAESTransform class. Let's say you are passed 1024 bytes to process in TransformBlock method. You will process 63 blocks of 16 bytes (1008 bytes in total) and buffer the other 16 bytes. Now if you still have more data coming lets say another 1024 bytes for processing, you will first process the leftover 16 bytes from the previous batch. And then continue the regular logic processing the rest of the bytes.

If you did have however reach the end of processing by receiving a call of TransformFinalBlock method, then you will process the 6 bytes left from the previous batch. And you will have your 10 bytes left where you have the authentication code. That's why it is so important to include TransformFinalBlock method use in the appropriate classes because this is your knowledge you have reached the end of processing.

David,

I've got ZipInputStream working with AES. Would you have time to go over my changes? Let me know where I should send you the package.

Excellent news. Send me an email via the forum and I will email you back with an address.

David, I have sent you an email.

I cannot get this to work.

The problem is that when I do

Stream s = "myZipFile".GetInputStream(myzipentry) it breaks.

Can someone post some sample code for making WinZipAES compression to work? Thanks.

allanhouston:

Thank you David. It worked.

You are a lifesafer:)

Can you please post some sample code?

Sure. Have a look at the code samples at http://wiki.sharpdevelop.net/SharpZipLib-Zip-Samples.ashx

Let us know how it goes.

Dave