* Cryptography
In the .NET framework cryptography can be found under a number of
namespaces in several assemblies.
** Assembly: corlib
*** Namespace: System.Security.Cryptography
Thanks to the work of many people this namespace is almost complete.
**** Status
* All classes are present.
* Most classes have their unit tests. Some tests like
SymmetricAlgorithmTest
are generated by external
tools.
**** TODO
* Keypair persistance for RSA and DSA. This persistance must
somehow be linked with X509 certificate stores (in planning).
* PasswordDeriveBytes.CryptDeriveKey
is included
in MS BCL to provide compatibility with existing Windows
applications. The main problem is that the key derivation
algorithm can be different for every CSP (Crypto Service
Provider). However for compatibility we should provide an
implementation compatible with the MS CSP (most likely used).
**** Notes
* All cryptographic algorithms are entirely managed, including
classes named *CryptoServiceProvider
, with the
exception of RNGCryptoServiceProvider
for which
parts of the implementation resides in the runtime.
* There is a bug in the PKCS1MaskGenerationMethod
class (in both framework 1.0 and 1.1). This means our
implementation isn't compatible with MS (but is compatible with
PKCS#1 v.2.1). However we get OAEP padding for every platform!
* Look at assembly Mono.Security.Win32 if you require more
compatiblity with the Microsoft implementation (like accessing
a particuliar keypair container inside a specific CSP).
*** Namespace: System.Security.Cryptography.X509Certificates
**** Status
* 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).
**** Notes
* Except for their structure there are no validation of the
certificates done by this class (this is by design and
isn't a restriction of Mono!). This means that certificate
signatures and validity dates are never checked
(except when used for Authenticode, i.e.
CreateFromSignedFile
).
* The newer X509Certificate class included in Microsoft's Web
Service Enhancement (WSE) is a little better (as it includes
CryptoAPI's validation) when IsCurrent
is called.
See assembly Microsoft.Web.Services for more details.
* The class Mono.Security.X509.X509Certificate (in Mono.Security
assembly) is becoming a much better alternative - and will
continue to evolve to support the security tools.
* Microsoft implementation of X509Certificate
is
done by using CryptoAPI (unmanaged code). Based on the
exceptions thrown, Authenticode(tm) support is done via COM.
** Assembly: System.Security
*** Namespace: System.Security.Cryptography.Xml
This namespace implements the
XML Digital Signature specification from
W3C.
**** Status
* All classes are present but some Transforms are only stubbed.
* We now have a fully managed C14N implementation.
* Most classes have their unit tests.
**** TODO
* Complete all Transform derived classes.
** 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 independance, 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 TLS implementation from Carlos Guzman Alvarez.
*** Namespace: Mono.Security.X509
* X.509 structures (certificate, CRL...) building and decoding.
* PKCS#12 decoding.
*** Namespace: Mono.Security.X509.Extensions
* X.509 extensions (from public X.509 to private PKIX, Netsapce,
Microsoft, Entrust...).
**** Status
* 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.
** 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. referecing 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
**** Status
* A RNGCryptoServiceProvider built on top of CryptoAPI. This
allows Windows users to get around the limitation of the
runtime RNG (which requires /dev/[u]random/
).
* 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 (MD4 is broken,
MD2 and MD5 aren't considered safe for some usage). 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 ...).
**** TODO
* Wrapper classes for unmanaged versions of symmetric
encryption algorithms (like DES, TripleDES, RC2 and others
present in default CSP).
* Wrapper classes for unmanaged versions of asymmetric
algorithms (like DSA and RSA) which persist their keypair
into the specified CSP.
**** Ideas
* 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.
** Assembly: Microsoft.Web.Services
Microsoft Web Service Enhancement (WSE), known as Web Service
Development Kit (WSDK) in it's beta days, is an add-on the .NET
framework that implements WS-Security (and other WS-* specifications).
It also includes improved support for XML Signature (replacing and/or
extending System.Security.Cryptography.Xml
) and X.509
certificates classes.
Note: WSE is distributed as an add-on because some specifications,
like WS-Security, aren't yet completed by
OASIS or
other committees.
*** Namespace: Microsoft.Web.Services.Security
**** Status
* Most WSE 1.0 classes are implemented.
**** TODO
* Some classes from System.Security assembly need to be
duplicated (and somewhat fixed) in WSE for XMLDSIG.
* There are still missing classes and many missing
unit tests.
*** Namespace: Microsoft.Web.Services.Timestamp
**** Status
* This seems complete for WSE 1.0 but some new classes were
introduced in WSE 2.0.
*** Namespace: Microsoft.Web.Services.Security.X509
**** Status
* X509Certificate support is complete for both WSE 1.0 and 2.0.
**** TODO
* We need to define certificate stores (for both users and
machines). These sames stores must be linked with asymmetric
keypairs. This could also be used to store the SPC roots.
*** Notes
* Microsoft has released
a technical preview of WSE 2. Note that WSDK (the technical
preview of WSE) had A LOT of changes before it's initial
release!
** Tools
There are many tools in the .NET framework that indirectly interacts
with some cryptographic classes. Mono will eventually need these tools.
Unless noted the tools should work on any CLR (tested with both Mono
and Microsoft).
**** Status
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 clone of the sn
to manage
strongnames. Current version can create, convert, sign and
verify strongnames signatures. Some configuration options
are still missing.
* 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.
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).
* monosn
is a clone of the sn
to manage
strongnames. This tools is part of the runtime (not the class
library) and as such is written in C and won't run without Mono.
**** TODO
The following tools are still missing or largely incomplete:
* Other tools like a, GUI-based, certificate manager...
Note that many of the tools requires the class library and/or the
runtime to be ready for them. E.g. StrongName and Authenticode signatures
tools are of limited use until supported by the runtime.
** References
* RSA Laboratories'
Frequently Asked Questions About Today's Cryptography, Version 4.1
* Public-Key Cryptography Standards (
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 ;-).
* Analyse 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. Some have been done using the
Community Edition of BoundChecker (a free VisualStudio
addon) - recommanded! Just be sure to test every optimization
(using the unit tests) carefully - it's so fast to break an
algorithm ;-).
* Write some documentation on the cryptographic classes for
monodoc as I'm not a very good writer (at least in English).
Contact Sebastien Pouliot (home
, work) if you need additional
informations about the status of the cryptographic classes.
Last reviewed: December 15, 2003 (post mono 0.29)