Jump to navigation

Poupou's Corner of the Web

Looking for perfect security? Try a wireless brick.
Otherwise you may find some unperfect stuff here...


What's New in System.Security.Cryptography v2

I guess most people are too busy at PDC to be blogging. So let me fill the empty electrons with my own enoisetm ;-)

From time to time I'll blog, positively or negatively, about the new v2 framework using both available information and my own imagination - I'll try to limit the later part (but I make no promise). Let's start with a (really) quick analysis of the new classes included in System.Security.Cryptography namespace of the .NET framework v2 (PDC release) and compare them with what Mono:: already has it's Mono.Security assembly.

DISCLAIMER: Like most of you, my access to information is limited to the MSDN's Longhorn web site. I don't (yet) have to the actual framework v2 installed so this is only my limited understanding of what's new and how it relates to Mono.

New classes

Seems to be a container for ASN.1 data. Unlike Mono.Security.ASN1 and ASN1Convert there seems to be no way to manipulate the ASN.1 data (other than a RawData property).
Expose a lot of properties about CryptoAPI keys. The properties are mainly applicable to asymmetric keypairs, like RSACryptoServiceProvider and DSACryptoServiceProvider, so the class isn't used for symmetric key algorithms, like DESCryptoServiceProvider, RC2CryptoServiceProvider and TripleDESCryptoServiceProvider.
Previously the only HMAC avaiable was HMACSHA1, which was required for Xml Digital Signature, and inherited KeyedHashAlgorithm. Mono.Security.Cryptography already as a similar class for handling HMAC with any hash algorithm.
HMAC using MD5. Easy as we have both managed HMAC and MD5.
HMAC using RIPEMD160. We'll need a RIPEMD160 implementation.
HMAC using SHA256. Easy as we have both managed HMAC and SHA256.
HMAC using SHA384. Easy as we have both managed HMAC and SHA384.
HMAC using SHA512. Easy as we have both managed HMAC and SHA512.
ASN.1 encoded object identifiers. All cryptographic algorithms got one, so here's the way to keep your hands clean. Mono.Security.ASN1 already has methods for converting OID to/from strings.
A collection of OIDs.
The OID's enumerator. No big surprise here ;-).
Wrapper into CryptoAPI CryptProtectData. An easy and secure way would be to use P/Invoke on Windows (XP+) and something similar on Linux. But I would much prefer a managed implementation - or maybe with just a little help from the runtime...
Wrapper into CryptoAPI CryptProtectMemory. Same comment.
Password-based key derivation using PKCS#5 version 2 PBKDF2. The current PasswordDerviceBytes is also based on PKCS#5 (version 1) with some modification at extends the key size when required.
Abstract base class for all RIPEMD160 implementations. RIPEMD-160 is an european hash algorithm optimized for 32bits processors. More informations are available here.
A managed implementation of RIPEMD160.

New interface

Defines two methods ExportCspBlob and ImportCspBlob and one property CspKeyContainerInfo. The two methods are probably very similar to Mono.Security.Cryptography.CryptoConvert class.

New enumerations

Scope of data protection: CurrentUser and LocalMachine
Not quite numbers but it should match the same CryptoAPI definitions for Exchange and Signature.
Scope of memory protection: SameProcess, CrossProcess and SameLogon.

Of interest

DSACryptoServiceProvider, RSACryptoServiceProvider
Both classes now implements the new ICspAsymmetricAlgorithm interface. It should be easier to exchange keypairs between managed and unmanaged code.
The constructor of the abstract class DSA is no more internal. It should now be possible to create derived implementation of DSA (like a DSAManaged class).
No new mode of operation but no symmetric algorithms implemented the CFB or CTS cipher mode in v.1.0 and v.1. I'm curious to see if this has changed...
Also of interest, two new padding mode ANSI X9.23 and ISO 10126. I wonder if one of them is the padding used by XmlEncryption which is (just a little) different than PKCS #7 and cause some interoperability problems with Microsoft WS-Security implementation.

There are probably many other changes insides the existing classes. Eventually I'll investigate them further... but for the time being I prefer quick surfing to deep diving :-)

10/28/2003 20:37:29 | Comments

The views expressed on this website/weblog are mine alone and do not necessarily reflect the views of my employer.