No Encrpytion Distribution

Aug 6, 2009 at 8:11 PM

I need to include this in a project that will be exported to places where encryption is illegal.  How hard would it be to make a version of the reduced DLL without encryption support?

Thanks,

Jamie

Coordinator
Aug 6, 2009 at 8:25 PM

It depends on what you mean.  I am not well-informed about this stuff, but my understanding is that the AES encryption may be export-protected - in particular the 256-bit keystrength only, right?

There is no actual strong encryption in the library, it merely uses the encryption built-in to the .NET Framework.  The library does implement the Pkzip Weak encryption, but that encryption is not considered to be strong and is not export-controlled.  

I am not familiar with how the .NET Framework is distributed in export-restricted countries, but I would guess the underlying .NET runtime might throw exceptions when applications try to do things that rely on restricted function.  So, if I am understanding the situation correctly, because there is no export-controlled logic within DotNetZip, there should be no problem distributing DotNetZip.   The export-restriction issue is with the underlying .NET Framework.  Applications will work just fine, unless they try to use the 256-bit encryption from DotNetZip, in which case the underlying .NET library will throw an exception.  This exception will bubble through the DotNetZip code, and go to the application, and the app can choose to handle it, or not.

Now, that means the DotNetZip library will still expose interfaces that make it look like it does AES256.  Intellisense, reflection, the documentation, - will all inidicate that you can use AES256 from DotNetZip.   If you wanted to prevent this - to NOT expose AES256 for use in a restricted deployment, then you need to do a cusom build of the code (and maybe doc).  Search for AES256 throughout the code and remove it, and then fixup the syntax. (It is used in AND clauses and OR clauses, etc)  It's not a mechanical search-and-replace, but it should be obvious and simple to do it manually.  Then rebuild.

If, on the other hand you want NO encryption in the library, neither PkZip nor AES encryption, that is more involved, and I guess you'd need to do more surgery on the library.

 

 

Apr 17, 2012 at 9:54 AM

I was wondering if your previous post would be still true in the current version - v1.9.

>There is no actual strong encryption in the library, it merely uses the encryption built-in to the .NET Framework.  The library does implement the Pkzip Weak encryption, but that encryption is not considered to be strong and is not export-controlled.  

Thanks,

samya