Poupou's Corner of the Web

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

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

AsnEncodedData

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).

CspKeyContainerInfo

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.

HMAC

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.

HMACMD5

HMAC using MD5. Easy as we have both managed HMAC and MD5.

HMACRIPEMD160

HMAC using RIPEMD160. We'll need a RIPEMD160 implementation.

HMACSHA256

HMAC using SHA256. Easy as we have both managed HMAC and SHA256.

HMACSHA384

HMAC using SHA384. Easy as we have both managed HMAC and SHA384.

HMACSHA512

HMAC using SHA512. Easy as we have both managed HMAC and SHA512.

Oid

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.

OidCollection

A collection of OIDs.

OidEnumerator

The OID's enumerator. No big surprise here ;-).

ProtectedData

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...

ProtectedMemory

Wrapper into CryptoAPI CryptProtectMemory. Same comment.

Rfc2898DeriveBytes

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.

RIPEMD160

Abstract base class for all RIPEMD160 implementations. RIPEMD-160 is an european hash algorithm optimized for 32bits processors. More informations are available here.

RIPEMD160Managed

A managed implementation of RIPEMD160.

New interface

ICspAsymmetricAlgorithm

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

DataProtectionScope

Scope of data protection: CurrentUser and LocalMachine

KeyNumber

Not quite numbers but it should match the same CryptoAPI definitions for Exchange and Signature.

MemoryProtectionScope

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.

DSA

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).

CipherMode

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...

PaddingMode

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 :-)