Kingsley Idehen's Blog Data Space

I've been talking a lot about Mono.Security but until today I didn't realize that it was never officially introduced - at least in my blog.

The only existing introduction is the Mono's Crypto status page - which BTW is a great place to learn what's in and/or out Mono's cryptography.

<lazy-geek:copy-n-paste>
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.
</ lazy-geek:copy-n-paste>

The most important piece of information is 100% managed code. This means that Mono.Security isn't tied to the Mono runtime and/or specific class library - you're free (really it's MIT X11 licensed) to use it on any runtime you choose.

• ASN1 decoding, encoding and type conversions;
• PKCS #7 structures - used for Authenticode and SPC support and currently being updated for implementing System.Security.Cryptography.Pkcs in .NET 1.2;

• PVK - Private Key files. Files that contains the private part of a public key. The format is mostly used by makecert.exe. Keys can be encrypted with RC4^tm using a user supplied password. Not very secure;
• SPC - Software Publisher Certificates. Files that contains a collection of X.509 certificates and/or CRLs. This is the format required by signcode.exe to append an Authenticode� signature to a PE file.
• [recent] PKCS #8 class to protect private keys (for the soon included PKCS #12 support);

• ARCFOUR - A managed implementation of the alleged RC4 compatible stream cipher from RSA. Required for PVK file format and for SSL/TLS;
• MD2 - A managed implementation of the RFC1319 MD2 hash algorithm. Note: MD2 is deprecated and shouldn't be used in new designs. It is included into Mono.Security because many old, but still valid, X.509 certificates (mostly roots) have signatures based on MD2.
• MD4 - A managed implementation of the RFC1320 MD4 hash algorithm. Note: MD4 is BROKEN and shouldn't be used. It is included into Mono.Security because NTLM challenges require MD4. However this doesn't mean that NTLM is broken.
• MD5SHA1 - The concatenation of a MD5 and SHA1 hash required to implement TLS.

• StrongName support - AFAIK the only open source implementation capable of signing/verifying strongnames on assemblies;
• Authenticode� support for both signing, countersigning (timestamps) and verifying PE files (including .NET assemblies);

• TLS - Carlos Guzm�n �lvarez has given his TLS (successor of SSL3) implementation to Mono! He's currently working on server side support and SSL compatibility - with an eye on the new .NET 1.2 API;
• [recent] NTLM authentication. Now used for SQL Server authentication, soon to be used for HTTP.

• X.501 names decoding/encoding;
• X.509 certificate decoder with full support for X.509v3 extensions;
• X.509 certificate builder to create your own certificates!
• Very basic (planned to improve) chaining and validation.

So the big, anticipated, questions were:

• "is Mono.Security complete?" - No, but does it need to be to be useful ? Not to me ;-)
• "is Mono.Security mature?" - No, it's not old enough to have been well tested.
• "is Mono.Security totally safe?" - No, supporting undocumented features is never safe - but it's almost as convenient as an AC in hell.

but Miguel's question was subtler "How mature are Mono Security classes?" There's no quick answer to that one.

• Most of the APIs will continue evolve to match new challenges like newer frameworks, WSE... - at least until the Mono 1.0 release. Interface stability is not yet a big priority at this stage (but I won't break it just for fun - at least not more than twice ;-)
• ASN.1 support has been very stable for the last year - but it's clearly not designed for everyone. PKCS7 is more recent and still incomplete (wrt to 1.2);
• File formats are stable (as they don't change often ;-) and well tested because it's generally easy to find/generate test cases;
• Cryptography is very stable because the interfaces are normalized and test vectors are available for testing. Most of them could easily be optimized without too much effort - maybe I'll do another optimizathon for Christmas vacations;
• Code signing is still experimental. It works but it's difficult to test and heavily undocumented. More independent tests would be welcomed!
• Protocols, both TLS and NTLM, are recent and still incomplete wrt to the specifications (when available). But they do the work that is currently required of them;
• X.509 classes, has been somewhat on hold before the preview release of .NET 1.2. This is because the current framework uses the features but do not expose them (like certificate stores, chaining...). In this case waiting for the (preview) release made more sense that starting a complete implementation from scratch.

So there's still a lots of stuff to do! Luckily I expect most of it to be pure fun :-).

Please report to me if you're using the classes in your own projects - I know may do ;-). I'd like bug reports and/or comments about your experience with Mono.Security. Kittens would also appreciate for sure...