[Mono-dev] BouncyCastle C# port under Mono

[Sebastien Pouliot]

Hello Carlos,

On Mon, 2006-08-21 at 12:04 -0400, Carlos J. Muentes wrote:
>     I don't mean to plug my software in this list, but I built a
> wrapper library for the .NET FCL encryption libraries.  

Are you sure about that ? ;-)

> It compiles in mono with no changes (I use it in a text editor app I
> built to provide encryption).  It's extremely simple to use, and I
> started building support for certificates, but haven't had time to
> finish it (it's licensed under the GPL, so changes are very welcome).
> Check it out here:
> http://www.rockwithme.org/index.php?option=com_remository&Itemid=37&func=fileinfo&id=3

You're right that the framework isn't easy to use, even for the most
simple things. Having a wrapper class for some common scenarios, like
yours, makes a lot of sense (but, as Miguel said, a GPL one may be a
little restrictive).

I had a very quick look at your library. It looks mostly correct except
for the following:


First, you're not using the power of the Fx design to help you. 

E.g. you should be able to have a single class accepting a
SymmetricAlgorithm instance (or, with a different ctor, an
AsymmetricAlgorithm and/or an X509Certificate ...) and hide all
difference inside your code.

This would reduce code duplication and make any (existing or future)
cryptographic algorithm usable by your library (without any more
work/code).


Second, you should also take care about non-portable API.

E.g. des.Key = pdb.CryptDeriveKey("RC2", "MD5", 128, /*Add a little salt
*/ new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64});

In this case this is not even 100% portable within Windows - because the
code will call the default CSP, which can be different from machine to
machine (and implement a different key derivation algorithm).

Note: Of course using a static salt isn't a good idea.


Finally (well from my quick look ;-) you should use "using" for
IDispose-able types. This will ensure that all the critical data will be
zeroize as soon as possible. This is "less" a problem when you're
dealing with strings (because of the way the VM deals with them) but a
good idea nevertheless (e.g. if you want to deal with private keys
later).

> 
> 
> On Mon, 2006-08-21 at 08:37 -0400, Sebastien Pouliot wrote: 
> > Hello Peter,
> > 
> > On Mon, 2006-08-21 at 16:17 +1000, Peter Dettman wrote:
> > > Hi all,
> > > 
> > > I want to report on my recent experiences getting the C# port of  
> > > BouncyCastle Crypto API (http://www.bouncycastle.org/csharp/) running on 
> > > Mono. It will be a reasonably brief report as it turned out to be mostly 
> > > painless :).
> > > 
> > > (BC is written entirely in C# for .NET 1.1 by the way).
> > 
> > BouncyCastle is a great cryptographic library. However it's C# port
> > doesn't use the cryptographic base classes of the FX so it somewhat
> > limits it's usefulness (e.g. yet another API to learn and difficult
> > interop with existing code).
> > 
> > > Here's what I did:
> > > - Installed Mono 1.1.13.6  and MonoDevelop 0.10 via the Ubuntu package 
> > > manager.
> > > - Imported the existing VS2003 solution file in MonoDevelop, and built 
> > > everything, with no significant issues.
> > > - The existing NAnt build file also seemed to work without modification 
> > > (although I am having a little trouble running the nunit tests via nant).
> > > - Ran our regression tests revealing only one failure, which I tracked 
> > > down to a bug in the x86 runtime (Bug# 79087), fixed in svn.
> > > 
> > > ...and that's all there was to it.
> > > 
> > > I certainly expected it to be more painful; that it wasn't is to the 
> > > credit of the Mono developers.
> > > 
> > > The regression tests take a few minutes to run, allowing a (very) 
> > > ballpark performance observation that Mono is about twice as slow as 
> > > MS.NET for running these tests. I guess anyone concerned with 
> > > performance of Mono might find some or all of these tests a useful 
> > > benchmark.
> > 
> > The results are similar to running our cryptographic code on top of the
> > MS runtime, i.e. they get twice as fast.
> > 
> > > I would be interested in hearing from people who are able to test 
> > > BC/Mono on other architectures than x86. The crypto algorithms do a lot 
> > > of bit/byte twiddling, and could potentially shake out similar problems 
> > > in other runtimes to the bug above.
> > 
> > You can get an approximate idea of the time required by other
> > architectures when looking at monobuild, compare the unit tests
> > execution time with the runtime build time. However the results will be
> > more "general" (and better reflect real-life scenarios) than CPU-bound
> > cryptographic tests.
> > 
> > > Cheers,
> > > Pete.
> > 
> > Thanks for the report!
-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/