This page is likely outdated (last edited on 03 Sep 2008). Visit the new documentation for updated content.


In the .NET framework cryptography can be found under a number of namespaces in several assemblies. Mono also has it’s own assemblies to provide missing security functionalities from the .NET framework.

In addition to the .NET compatible assemblies for cryptography, we are working on an additional stack of functionality, available in the Crimson module.

Table of contents

Assembly: mscorlib.dll

Namespace: System.Security.Cryptography

  • Thanks to the work of many people this namespace is almost complete.


  • All classes are present. Most of them have (minimal) documentation in monodoc.
  • Most classes have their unit tests. Some tests like SymmetricAlgorithmTest are generated by external tools.

Namespace: System.Security.Cryptography.X509Certificates


  • X.509 certificates are parsed using 100% managed code (using the Mono.Security.ASN1 class).
  • Software Publisher Certificates (SPC) used by Authenticode(tm) to sign assemblies are supported and minimally validated.
  • Unit tests are generated from a set of existing certificates (about a dozen) each having different properties. Another set of certificates (more than 700) are used for a more complete test (but isn’t part of the standard test suite for size and time consideration, i.e. a 7.5Mb C# source file).


  • The classes under Mono.Security.X509.* (in Mono.Security.dll assembly) are a much better alternative - and will continue to evolve to support the security tools.

Assembly: System

Namespace: System.Security.Cryptography (new in Fx 2.0)

  • New namespace (2.0) to deal with basic structures, like ASN.1 and Oid.


  • Support for ASN.1 and Oid is almost complete in Mono 1.1.x.

Namespace: System.Net.Security (new in Fx 2.0)

This new namespace add support for a SslStream class that can be used both for client and server side communication.


  • The current SSL/TLS implementation (in Mono.Security.dll assembly) is being updated and will be shortly available with this new API.

Namespace: System.Security.Cryptography.X509Certificates (new in Fx 2.0)

  • Lots of new classes (2.0) to better (than corlib) deal with X.509 certificates.


  • Partial support is present in Mono 1.1.x.
  • More work is required on importing and exporting different formats.
  • Much more work is required to build an RFC3280 compliant path and validation algorithms (i.e. the X509Chain class).

Assembly: System.Security

Namespace: System.Security.Cryptography.Xml

This namespace implements the XML Digital Signature specification from W3C. New in Fx 2.0 - This namespace now has support for the XML Encryption specification.


  • We pass the fifteen tests from Merlin’s xmldsig suite with success. Which is funny because Microsoft fails in one case where both a X509Certificate and an X509CRL are present in an X509Data. We also pass most Phaos tests.

  • Most classes have their unit tests. Some standalone tests are also in SVN to test C14N and both Merlin and Phaos test suites.

  • Partial support for XML Encryption is present in Mono 1.1.x but lacks unit tests.

Namespace: System.Security.Cryptography (new in Fx 2.0)

  • New namespace (2.0) to deal with PKCS9 cryptographic attributes and support for ProtectedData and ProtectedMemory (encrypted).


  • Support for PKCS9 attributes is almost complete in Mono 1.1.x.

  • There is partial support for ProtectedData and ProtectedMemory on Mono. On Windows Mono will use DPAPI (Data Protection API) for increased interoperability, while it will use its own implementation on other operating systems.

Namespace: System.Security.Cryptography.Pkcs (new in Fx 2.0)

  • New namespace (2.0) to deal with PKCS7 data structures (e.g. signed and/or encrypted data).


  • Partial support is present in Mono 1.1.x. More work is required on the X509Certificate classes to complete it.

Namespace: System.Security.Cryptography.X509Certificates (new in Fx 2.0)

  • New namespace (2.0) to offer UI (display, select) when using X.509 certificates.


  • Not (yet) implemented in Mono 1.1.x.

Assembly: Mono.Security

Rational: This assembly provides the missing pieces to .NET security. On Windows CryptoAPI is often used to provide much needed functionalities (like some cryptographic algorithms, code signing, X.509 certificates). Mono, for platform independence, implements these functionalities in 100% managed code.

Namespace: Mono.Security

  • Structures (ASN1, PKCS7) and primitives (PKCS1).

Namespace: Mono.Security.Authenticode

  • Code signing and verification.
  • Support for SPC (Software Publisher Certificate) files and PVK (Private Key) files.

Namespace: Mono.Security.Cryptography

  • Additional algorithms: MD2, MD4, ARCFOUR (required for SSL)
  • Convertion helpers

Namespace: Mono.Security.Protocol.*

  • Tls: An 100% managed SSLv3 and TLSv1 implementation from Carlos Guzman Alvarez.
  • Ntlm: NTLM authentication (used for HTTP and SQL Server).

Namespace: Mono.Security.X509.*

  • X.509 structures (certificate, CRL…) building and decoding.
  • PKCS#12 decoding and encoding.
  • X.509 extensions (from public X.509 to private PKIX, Netscape, Microsoft, Entrust…).


  • A big part of this assembly is also included inside Mono’s corlib. The classes are duplicated in this assembly so the functionalities can be used without a dependency on Mono’s corlib (which depends on Mono’s runtime).
  • Unit test coverage isn’t (yet) complete.
  • Most classes have minimal documentation available in monodoc.

Assembly: Mono.Security.Win32

Rational: This assembly goal is to provide maximum compatibility with CryptoAPI to application running with Mono’s runtime on the Windows operating system. This assembly should NEVER be used directly by any application (e.g. referencing the assembly from a project). The classes should only be used by modifying the machine.config configuration file (and then only if this increased compatibility is required by an application). See the file /mcs/class/Mono.Security.Win32/README for complete instructions.

Namespace: Mono.Security.Cryptography


  • A RNGCryptoServiceProvider built on top of CryptoAPI.
  • Wrapper classes for unmanaged versions of hash algorithms: MD2, MD4, MD5 and SHA1 are supported. Note: some algorithms shouldn’t be used in new design because they aren’t considered safe for some usage - this includes MD2, MD4, MD5 and SHA1. They are included to preserve interoperability with older applications (e.g. some old, but still valid, X.509 certificates use MD2, MD4 is required for NTLM authentication …).
  • Classes have minimal documentation available in monodoc.


Area Description Difficulty Time estimate Additional information
Wrapper classes for unmanaged versions of symmetric encryption algorithms

Wrapper classes for things like DES, TripleDES, RC2 and others present in default CSP.

Medium 2 weeks N/A
Wrapper classes for unmanaged versions of asymmetric algorithms Wrappers for things like DSA and RSA which persist their keypair into the specified CSP. Medium 2 weeks. N/A


  • Similar assemblies (e.g. Mono.Security.XXX) could be created for OpenSSL, NSS, crypto++, cryptlib … for improved performance and/or HSM (Hardware Security Module) support under Linux and/or Windows.


There are many tools in the .NET framework that indirectly interacts with some cryptographic classes. Unless noted the tools should work on any CLR (tested with both Mono and Microsoft).


The following tools are complete (or mostly complete):

  • secutil is a tool to extract certificates and strongnames from assemblies in a format that can be easily re-used in source code (C# or VB.NET syntax).
  • cert2spc is a tool to transform multiple X.509 certificates and CRLs into a Software Publisher Certificate (SPC) file - which is a long name for a simple PKCS#7 file.
  • makecert to create X.509 test certificates that can be used (once transformed in SPC) to sign assemblies. It’s now possible to generate SSL certificates for web servers.
  • sn is a tool to manage strongnames. Current version can create, convert, sign and verify strongnames signatures. Some configuration options are still missing, some will only work with Mono.
  • signcode and chktrust for signing and validating Authenticode(tm) signatures on assemblies (or any PE file) are now working (signature and timestamps) but some options aren’t yet supported.
  • setreg can change some cryptographic parameters of the runtime. Currently it can add or remove two root test certificates (the one used by Mono’s makecert, the other used by Microsoft’s makecert).
  • certmgr can add and remove certificates from the stores. Most common use is to add new trusted certificates or remove them.
  • gasnview is a Gtk# based ASN.1 viewer. It is available in the mono-tools SVN repository.

Somewhat usable, somewhat incomplete:

  • certview is a certificate viewer for System.Windows.Forms (right now only working on Windows), while gcertview is the same viewer implemented for Gtk# (working on both Windows and Linux).

  • Other tools like a, GUI-based, certificate manager…


  • RSA Laboratories’ Frequently Asked Questions About Today’s Cryptography, Version 4.1
  • Public-Key Cryptography Standards (aka PKCS)
  • National Institute of Standards and Technology - Federal Information Processing Standards NIST FIPS

How to Help

  • Complete any of the TODO (and feel good about it ;-).
  • Analyze the current coverage of the unit tests on the cryptographic classes and complete the unit tests. monocov does a great job at this! Now we just need to complete the missing unit tests.
  • Optimization can also be done on most algorithms as crypto is never fast enough. Just be sure to test every optimization (using the unit tests) carefully - it’s so fast to break an algorithm ;-).
  • Write some documentation or add some sample code for the cryptographic classes in monodoc.