Issues Regarding the Protection of Assemblies

.NETZ does not offer any protection against reverse-engineering.

.NETZ does not support any out-of-the-box method for encrypting, or protecting the compressed assemblies. However, .NETZ offers a generic interface to implement custom compression providers that could be used to implement encryption, or other protection related functionality.

.NETZ does not offer any out-of-the-box protection because theoretically it is impossible to do safe decryption in an unsafe environment (thanks to Dr. Ulrike Meyer for explaining this). All the tools that pretend to offer such methods, only try to make it hard to guess what is going on, but cannot warranty protection, despite any other casual claims.

If .NETZ were to offer a generic protection mechanism, it is very likely that it would attract attention and would be soon broken. Custom solutions tend to last longer, because they contain features fitted to each special case, but can be sometimes expensive to develop.

If you decide to build your own protection schema, then start with the default compression provider source code and add various security checks to the files. Partial assembly encryption based on DES, combined with RSA for the key distribution (for unique client IDs) has been tested to work fine and without any noticeable time and performance delays with .NETZ.

If you feel that your custom .NETZ compression provider is generic and can be used also by the others, then please write an email and it will be linked in this site. Officially, .NETZ will not support any out-of-the-box compression provider that offers security features.

See also: Compression | Support