[
  {
    "Id": "220493",
    "ThreadId": "64750",
    "Html": "<p>I need to include this in a project that will be exported to places where encryption is illegal.&nbsp; How hard would it be to make a version of the reduced DLL without encryption support?</p>\r\n<p>Thanks,</p>\r\n<p>Jamie</p>",
    "PostedDate": "2009-08-06T12:11:32.5-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "220499",
    "ThreadId": "64750",
    "Html": "<p>It depends on what you mean.&nbsp; 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?</p>\r\n<p>There is no actual <strong>strong encryption </strong>in the library, it merely uses the encryption built-in to the .NET Framework.&nbsp; The library <em>does</em> implement the Pkzip Weak encryption, but that encryption is not considered to be strong and is not export-controlled.&nbsp;&nbsp;</p>\r\n<p>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.&nbsp; So, if I am understanding the situation correctly, because there is no export-controlled logic within DotNetZip, there should be no problem distributing DotNetZip.&nbsp; &nbsp;The export-restriction issue is with the underlying .NET Framework.&nbsp; 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.&nbsp; This exception will bubble through the DotNetZip code, and go to the application, and the app can choose to handle it, or not.</p>\r\n<p>Now, that means the DotNetZip library will still expose interfaces that make it look like it does AES256.&nbsp; Intellisense, reflection, the documentation, - will all inidicate that you can use AES256 from DotNetZip.&nbsp;&nbsp; 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).&nbsp; Search for AES256 throughout the code and remove it, and then fixup the syntax.&nbsp;(It is used in AND clauses and OR clauses, etc) &nbsp;It's not a mechanical search-and-replace, but it should be obvious and simple to do it manually.&nbsp; Then rebuild.</p>\r\n<p>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.</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>",
    "PostedDate": "2009-08-06T12:25:31.92-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "824737",
    "ThreadId": "64750",
    "Html": "<p>I&nbsp;was wondering if&nbsp;your previous post&nbsp;would be&nbsp;still&nbsp;true in the current version - v1.9.</p>\r\n<p>&gt;There is no actual <strong>strong encryption </strong>in the library, it merely uses the encryption built-in to the .NET Framework.&nbsp; The library <em>does</em> implement the Pkzip Weak encryption, but that encryption is not considered to be strong and is not export-controlled.&nbsp;&nbsp;</p>\r\n<p>Thanks,</p>\r\n<p>samya</p>",
    "PostedDate": "2012-04-17T01:54:29.113-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  }
]