* Every classes are present.
* Most classes have their unit tests. Some tests like <code>
- SymmetricAlgorithmTest</code> are generated by an external
- tool.
+ 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 OID using the
- <code>machine.config</code> configuration file (algorithms
- are done).
-
* 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
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).
-
- * 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!
</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 in a CSP).
+ a particuliar keypair container inside a specific CSP).
</ul>
* 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.
* 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
+ 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).
+ size and time consideration, i.e. a 7.5Mb C# source file).
</ul>
**** TODO
certificates from PE files but cannot validate the signature
nor the certificate chain (and we're still missing some trust
anchors). See Tools section for more information.
-
- * Integration with CryptoAPI (on Windows) isn't possible as
- long as the <code>X509Certificate(IntPtr)</code> constructor
- isn't completed.
</ul>
**** Notes
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 (unmanaged code). From the exceptions
thrown Authenticode(tm) support is done via COM.
**** Status
<ul>
- * All classes are present but some (most Transforms) are only
- stubbed.
+ * All classes are present but some Transforms are only stubbed.
+
+ * We now have a fully managed C14N implementation.
* Most classes have their unit tests.
</ul>
**** TODO
<ul>
- * All the transforms needs to be done. But this requires far
- 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.
+ * Complete all Transform derived classes.
</ul>
<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).
+ 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>
**** Status
<ul>
- * Work has been under way for quite some time - and should
- start hitting CVS soon.
+ * 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 class are duplicated in this assembly so the
- functionalities can be used with a dependency on 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
+ <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
* 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 and
- MD2 isn't considered safe). They are included to preserve
- interoperability with older applications (e.g. some old, but
- still valid, X.509 certificates use MD2).
+ 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
* 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
<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.Timestamp
+*** Namespace: Microsoft.Web.Services.Security [*]
+*** Namespace: Microsoft.Web.Services.Timestamp [*]
**** Status
<ul>
**** Status
<ul>
* Nothing (yet) commited in CVS. However the classes in this
- namespace are outside WS-Security scope. So development
- could be done without signing any agreements.
+ namespace are outside WS-Security scope. So development, for
+ those classes, could be done without signing this agreement.
</ul>
**** TODO
keypairs. This could also be used to store the SPC roots.
</ul>
+*** Notes
+ <ul>
+ * Microsoft has <a href="http://microsoft.com/downloads/details.aspx?FamilyId=21FB9B9A-C5F6-4C95-87B7-FC7AB49B3EDD&displaylang=en">released</a>
+ a technical preview of WSE 2.
+ </ul>
+
<hr>
** Tools
**** 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
* <code>cert2spc</code> 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.
+
+ * <code>makecert</code> 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.
</ul>
-**** TODO
- The following tools are still missing or incomplete:
+ Somewhat usable, somewhat incomplete:
<ul>
+ * <code>certview</code> is a certificate viewer for
+ <code>System.Windows.Forms</code> (right now only working on
+ Windows), while <code>gcertview</code> is the same viewer
+ implemented for GTK# (working on both Windows and Linux).
+
+ * <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 and won't run without Mono.
+ </ul>
+
+
+**** 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).
- * <code>makecert</code> to create X.509 test certificates that
- can be used (once transformed in SPC) to sign assemblies.
-
* 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 ;-).
-
- Add missing unit tests to classes or methods.
-
- 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 good writer (at least in English).
+ <ul>
+ * Complete any of the TODO (and feel good about it ;-).
- 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 ;-).
+ * Analyse the current coverage of the unit tests on the
+ cryptographic classes and complete the unit tests. <b><code>
+ monocov</code> does a great job at this! Now we just need to
+ complete the missing unit tests.</b>
+
+ * 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
+ <b>monodoc</b> 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: March 4, 2003 (post mono 0.21)
+Last reviewed: August 9, 2003 (post mono 0.25)
projects / mono.git / blobdiff