<ul>
* Every classes are present.
- * Most classes have their unit tests.
+ * Most classes have their unit tests. Some tests like <code>
+ SymmetricAlgorithmTest</code> are generated by external
+ tools.
+
+ * MACTripleDES is compatible with the implementation shipped in
+ framework 1.0. Version 1.1 gives different results when the
+ MACed data is a multiple of BlockSize (8 bytes).
</ul>
**** TODO
<ul>
- * Support for adding/modifying algorithms and OID using the
- <code>machine.config</code> configuration file (in progress).
+ * The current implementation of <code>CryptoStream</code> is
+ very limited and contain known bugs (<a
+ href="http://bugzilla.ximian.com/show_bug.cgi?id=40689">
+ 40689</a>). The class need to be re-designed.
* RNGCryptoServiceProvider is currently only working on Linux.
The current implementation reside in Mono's runtime and use
the <code>/dev/[u]random</code> device (which do not exists
- under Windows). A Windows alternative is in the work...
+ under Windows). A Windows specific alternative is available
+ using the Mono.Security.Win32 assembly.
* Keypair persistance for RSA and DSA. This persistance must
somehow be linked with X509 certificate stores (in planning).
- * <code>PasswordDeriveBytes</code> is currently limited to
- generating keys with the maximum length equals to the hash
- output (as specified in PKCS #5). However the framework
- implementation allows for longer keys to be generated. Also
- the algorithms used by CryptDeriveKey (used by Windows
- applications) are unknown.
-
- * Analyse the current coverage of the unit tests on the
- cryptographic classes and complete the unit tests.
-
- * Optimizations (performance) on most class are possible. Some
- have been done using the Community Edition of BoundChecker
- (a free VisualStudio addon) - recommanded!
+ * <code>PasswordDeriveBytes.CryptDeriveKey</code> 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).
</ul>
**** Notes
* All cryptographic algorithms are entirely managed, including
classes named <code>*CryptoServiceProvider</code>, with the
exception of <code>RNGCryptoServiceProvider</code> (which
- resides in the runtime).
+ implementation resides in the runtime).
+
+ * There is a bug in the <code>PKCS1MaskGenerationMethod</code>
+ 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).
</ul>
**** Status
<ul>
- * X.509 certificates are parsed using 100% managed code.
+ * 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 (extraction from PE
- files) but <b>not</b> validated.
+ files) but <b>not yet</b> validated.
- * Tests are generated from a set of existing certificates
+ * Unit tests are generated from a set of existing certificates
(about a dozen) each having different properties. Another
- set of certificates (more than 300) are used for a more
- complete test (but isn't part of the test suite for size
- and time consideration).
+ 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).
</ul>
**** TODO
* Authenticode(tm) support is incomplete. We can extract the
certificates from PE files but cannot validate the signature
nor the certificate chain (and we're still missing some trust
- anchors).
-
- * Integration with CryptoAPI isn't possible as long as the
- <code>X509Certificate(IntPtr)</code> constructor isn't
- completed.
+ anchors). See Tools section for more information.
</ul>
**** Notes
<ul>
- * <b>There's no validation of the certificates</b> done in this
- class (this isn't a restriction of Mono!). This means that
- certificate signatures and validity dates are never checked!
+ * Except for their structure <b>there are no validation of the
+ certificates</b> done by this class (this is by design and
+ isn't a restriction of Mono!). This means that certificate
+ signatures and validity dates are <b>never</b> checked
+ (except when used for Authenticode, i.e.
+ <code>CreateFromSignedFile</code>).
* The newer X509Certificate class included in Microsoft's Web
Service Enhancement (WSE) is a little better (as it includes
- validation).
+ CryptoAPI's validation) when <code>IsCurrent</code> is called.
+ See assembly <b>Microsoft.Web.Services</b> 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 <code>X509Certificate</code> is
- done by using CryptoAPI. From the exceptions thrown
- Authenticode(tm) support is done via COM.
+ done by using CryptoAPI (unmanaged code). From the exceptions
+ thrown Authenticode(tm) support is done via COM.
</ul>
<hr>
*** Namespace: <b>System.Security.Cryptography.Xml</b>
- This namespace implements the XML Digital Signature specification from
- W3C.
+ This namespace implements the <a href="http://www.w3.org/TR/xmldsig-core/">
+ XML Digital Signature</a> specification from
+ <a href="http://www.w3.org/">W3C</a>.
**** Status
<ul>
- * All classes are present but some are only stubbed.
+ * All classes are present but some (most Transforms) are only
+ stubbed.
* Most classes have their unit tests.
-
- * This assembly is present in CVS but isn't (yet) part of the
- build.
</ul>
**** TODO
<ul>
* All the transforms needs to be done. But this requires far
- more XML knowledge than crypto.
+ more XML knowledge than crypto. Note: Most tests runs because
+ the feeded XML is pre-c14n (by hand in the code) before
+ signing (not because the transforms works). In the short
+ term <code>libxml2</code> could be used to provide C14N, but
+ in the long term a fully managed class would be much better.
+ </ul>
- * Fix the tests (see notes) then include the assembly into the
- build process.
+<hr>
+** Assembly: Mono.Security
+
+ <b>Rational: </b>
+ 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
+ <ul>
+ * Structures (ASN1, PKCS7) and primitives (PKCS1).
+ </ul>
+*** Namespace: Mono.Security.Authenticode
+ <ul>
+ * Code signing and verification.
+ * Support for SPC (Software Publisher Certificate) files and
+ PVK (Private Key) files.
+ </ul>
+*** Namespace: Mono.Security.Cryptography
+ <ul>
+ * Additional algorithms: MD2, ARCFOUR (required for SSL)
+ * Convertion helpers
+ </ul>
+*** Namespace: Mono.Security.X509
+ <ul>
+ * X.509 structures (certificate, CRL...) building and decoding.
+ </ul>
+*** Namespace: Mono.Security.X509.Extensions
+ <ul>
+ * X.509 extensions (from public X.509 to private PKIX, Netsapce,
+ Microsoft, Entrust...).
</ul>
-**** Notes
+**** Status
<ul>
- * Many current tests fails because the XML generated by Mono
- isn't exactly the same as the one produced by the Microsoft
- implementation (but 100% equivalent). We'll either have to
- change the XML code or the tests.
-
- * Testing is difficult because the classes use CryptoConfig
- to create the required cryptographic objects. When running
- the unit tests the CryptoConfig executing is the one in
- mscorlib (not Mono's one) so it doesn't return the expected
- objects. This results in InvalidCastException.
+ * Some part of the work has not yet been commited (still cleaning up).
+
+ * 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.
</ul>
<hr>
** Assembly: Mono.Security.Win32
- This assembly is to provide maximum compatibility with CryptoAPI to
- application running with Mono's runtime on the Windows operating
+ <b>Rational: </b>
+ This assembly goal is to provide maximum compatibility with CryptoAPI
+ to application running with Mono's runtime on the Windows operating
system.
- <b>This assembly should NEVER be used directly by any application</b>.
+ <b>This assembly should NEVER be used directly by any application</b>
+ (e.g. referecing the assembly from a project).
The classes should only be used by modifying the <code>machine.config
</code> configuration file (and then only if this increased
compatibility is required by an application).
+ See the file <code><a href="http://cvs.hispalinux.es/cgi-bin/cvsweb/~checkout~/mcs/class/Mono.Security.Win32/README?rev=1.1&content-type=text/plain&cvsroot=mono">/mcs/class/Mono.Security.Win32/README</a></code>
+ for complete instructions.
+
*** Namespace: Mono.Security.Cryptography
**** Status
<ul>
- * A RNGCryptoServiceProvider built on top of CryptoAPI.
-
- * Not (yet) commited in CVS.
+ * A RNGCryptoServiceProvider built on top of CryptoAPI. This
+ allows Windows users to get around the limitation of the
+ runtime RNG (which requires <code>/dev/[u]random/</code>).
+
+ * Wrapper classes for unmanaged versions of hash algorithms:
+ MD2, MD4, MD5 and SHA1 are supported. <b>note</b>: 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).
</ul>
**** TODO
<ul>
- * Unmanaged versions of hash algorithms (SHA1 and MD5).
- * Unmanaged versions of symmetric encryption algorithms
- (like DES, TripleDES, RC2 and others present in CryptoAPI).
- * Unmanaged versions of asymmetric algorithms (like DSA and
- RSA) which persist their keypair into the specified CSP.
+ * 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.
</ul>
+**** Ideas
+ <ul>
+ * Similar assemblies (e.g. <code>Mono.Security.XXX</code>)
+ could be created for <a href="http://www.openssl.org">OpenSSL</a>,
+ <a href="http://www.mozilla.org/projects/security/pki/nss/">NSS</a>,
+ <a href="http://www.eskimo.com/~weidai/cryptlib.html">crypto++</a>,
+ <a href="http://www.cryptlib.orion.co.nz/">cryptlib</a> ... for
+ improved performance and/or HSM (Hardware Security Module) support
+ under Linux and/or Windows.
+ </ul>
<hr>
** Assembly: Microsoft.Web.Services
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 <code>System.Security.Cryptography.Xml</code>) and X509
- certificates.
+ extending <code>System.Security.Cryptography.Xml</code>) and X.509
+ certificates classes.
- Note: WSE is distributed as an add-on because the WS-Security
- specification isn't yet completed by OASIS.
+ Note: WSE is distributed as an add-on because some specifications,
+ like WS-Security, aren't yet completed by
+ <a href="http://www.oasis-open.org/committees/wss/">OASIS</a> or
+ other committees.
- <b>There are some licensing issues to consider before stating to
+ <b>[*] There are some licensing issues to consider before starting to
implement WS-Security. All contributors must sign an agreement with
Microsoft before commiting anything related to WS-Security into CVS.
</b>
-*** Namespace: Microsoft.Web.Services.Security
+*** Namespace: Microsoft.Web.Services.Security [*]
+*** Namespace: Microsoft.Web.Services.Timestamp [*]
**** Status
<ul>
- * Nothing (yet) commited in CVS.
+ * Nothing (yet) commited in CVS <b>[*]</b>.
</ul>
*** Namespace: Microsoft.Web.Services.Security.X509
**** Status
<ul>
- * Nothing (yet) commited in CVS.
+ * Nothing (yet) commited in CVS. However the classes in this
+ namespace are outside WS-Security scope. So development, for
+ those classes, could be done without signing any agreements.
</ul>
**** TODO
</ul>
<hr>
-** Other stuff
-
- There are other, not so visible, uses of cryptography both inside and
- outside the class library - such as:
-
- <ul>
- * SSL/TLS for secure communication (investigation under way).
-
- * Assembly signing (and verification) using StrongNames.
-
- * Assembly signing (and verification) using Authenticode(tm).
- </ul>
-
-
-*** Tools
+** 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:
+ The following tools are complete (mostly complete):
<ul>
* <code>secutil</code> 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).
* <code>cert2spc</code> is a tool to transform multiple X.509
- certificates (a chain) into a Software Publisher Certificate
- (SPC) - which is a long name for a simple PKCS#7 file.
+ certificates and CRLs into a Software Publisher Certificate
+ (SPC) file - which is a long name for a simple PKCS#7 file.
+
+ * <code>makecert</code> to create X.509 test certificates that
+ can be used (once transformed in SPC) to sign assemblies.
</ul>
-**** TODO
- The following tools are still missing or incomplete:
+ Somewhat usable, somewhat incomplete:
<ul>
+ * <code>sn</code> is a clone of the <code>sn</code> to manage
+ strongnames. Current version is limited to creating new keypairs
+ and converting values.
+
* <code>monosn</code> is a clone of the <code>sn</code> to manage
strongnames. This tools is part of the runtime (not the class
- library) and as such is written in C.
+ library) and as such is written in C and won't run without Mono.
+ </ul>
- * <code>signcode</code> and <code>chktrust</code> for signing
- and validating Authenticode(tm) signatures on assemblies.
- * <code>makecert</code> to create X.509 test certificates that
- can be used (once transformed in SPC) to sign assemblies.
+**** TODO
+ The following tools are still missing or largely incomplete:
+ <ul>
+
+ * <code>signcode</code> and <code>chktrust</code> (in progress)
+ for signing and validating Authenticode(tm) signatures on
+ assemblies (or any PE file).
* Other tools like a, GUI-based, certificate manager...
</ul>
Note that many of the tools requires the class library and/or the
- runtime to be ready for them.
+ runtime to be ready for them. E.g. StrongName and Authenticode signatures
+ tools are of limited use until supported by the runtime.
+
+<hr>
+** Other stuff
+
+ <ul>
+ * SSL/TLS for secure communication (a prototype is under way).
+ Some work is already visible in Mono.Security assembly (e.g.
+ RC4, RSAManaged ...).
+ </ul>
+
<hr>
** How to Help
- Complete any of the TODO (and feel good about it ;-).
+ <ul>
+ * Complete any of the TODO (and feel good about it ;-).
- Add missing unit tests to classes or methods.
+ * Analyse the current coverage of the unit tests on the
+ cryptographic classes and complete the unit tests.
- Write some documentation on the cryptographic classes for MonkeyGuide
- (as I'm not a good writer - but you must be a good reader if you got to
- this part).
+ * 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 test) carefully - it's so fast to break an
+ algorithm ;-).
- Optimization can also be done on algorithms as crypto is never fast
- enough. Just be sure to test every optimization (using the unit test)
- carefully - it's so fast to break an algorithm ;-).
+ * Write some documentation on the cryptographic classes for
+ the <a href="http://go-mono.com/tutorial/html/en/index.html">Mono
+ Handbook</a> as I'm not a very good writer (at least in English).
+ </ul>
Contact Sebastien Pouliot (<a href="mailto:spouliot@videotron.ca">home</a>
, <a href="mailto:spouliot@motus.com">work</a>) if you need additional
informations about the status of the cryptographic classes.
+<hr>
+Last reviewed: June 11, 2003 (post mono 0.24)
projects / mono.git / blobdiff