[Mono-dev] BouncyCastle C# port under Mono

[Carlos J. Muentes]

Thanks for the code review, I wouldn't mind some contributions ^_^

    I really didn't mean to plug any software, I was just trying to post
a helpful comment, in this case pointing to a wrapper library (that I
happened to author) for encryption.  I suppose a BSD license would be
more proper, especially since it's mostly a wrapper class, and doesn't
add much value to the .NET FCL encryption implementation (aside from
static salt, which you're right, should be changed).  As soon as I get
more time, I'd like to make this thing a much better product, with
whatever license seems appropriate at the time.  I don't really have a
preference, since I think encryption should be easily accessible and
easily accomplished, but done correctly so as to achieve true security.


On Mon, 2006-08-21 at 13:29 -0400, Sebastien Pouliot wrote:

> 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060821/aef86dc5/attachment.html