[Mono-list] Crytography in Mono using NSS

[Sergey Chaban]

> Speaking of performance I did some tests using native CryptoAPI on Windows
> (from managed code) and found out that, depending how you use it (which is
> something we can't totally control with a frozen API), managed code can be
> faster than unmanaged code

I think it's indeed true (the fact that managed code can be faster in general).
There was a lot of benchmarking in the early days, see for example this MD5 benchmark:
http://mono.eurosoft.od.ua/Crypto/md5-mark.tar.gz
There are versions in C++, C# and Java (both rolled & unrolled for the latter two).
Unrolled C# code is the same as used in mono libs (the unrolled code is machine-generated).

> Many reasons are motivating me to this end including:
> - portability across operating system: I believe that keeping track of
> multiple external library dependencies across multiple operating system is
> going to be a tough job on the long run (and still a bigger job for porting
> to new, and often limited, platform - like new embebbed devices, cell
> phones, PDA, ...);

This is very true, I agree 100%.
It's already non-trivial to port Mono to such platforms, so it's better to avoid
new dependencies (IMO).

Sergey


----- Original Message ----- 
From: "Sebastien Pouliot" <spouliot@videotron.ca>
To: "Daniel Morgan" <danmorg@sc.rr.com>; "Mono-List" <mono-list@ximian.com>
Sent: Tuesday, October 15, 2002 4:51 AM
Subject: Re: [Mono-list] Crytography in Mono using NSS


> > I found this on Mono'w web site about needing cyrtography support in Mono.
> > What about using Netscape Security Services?
> >
> > http://www.mozilla.org/projects/security/pki/nss/overview.html
> 
> I've not looked at NSS for quite some time (before Mozilla 1.0 release). As
> such it predates my interest in Mono...
> 
> > The only problem I see with using NSS is that it uses NSPR (Netscape
> > Portable Runtime).  How well will NSPR cooperate with the mono runtime?
> 
> No comments here (but I'm curious too :-)
> 
> > If
> > NSS and NSPR is good enough for Netscape and Sun, don't you think it could
> > be good enough for us?
> 
> NSS has been certified FIPS140-1 (level 1 or 2) quite a few time in the past
> so I wouldn't have much concern about the cryptographic quality of the
> algorithm implementations. However I don't think that NSS (or any other
> library - there're tons of them) may not implement all the classes required
> for Mono.
> 
> > Then again, I have no idea what the requirements are for cryptography
> > support in Mono.
> 
> Speaking for myself I'm hoping (and working so) we can have fully managed
> cryptographic classes on mono.
> 
> Many reasons are motivating me to this end including:
> - portability across operating system: I believe that keeping track of
> multiple external library dependencies across multiple operating system is
> going to be a tough job on the long run (and still a bigger job for porting
> to new, and often limited, platform - like new embebbed devices, cell
> phones, PDA, ...);
> - security: In the right environment it's easier to be trust managed code
> than unmanaged code. Also many of the current security flaws are based on
> exploits (like stack overrun) that are gonna be harder to reproduce in a
> managed environment (unless it exploit unmanaged code underneath).
> 
> However I do understand that my criteria aren't universal: performance is
> often cited as good reason to include unmanaged code, another one is reusing
> existing code to accelerate the development.
> 
> Speaking of performance I did some tests using native CryptoAPI on Windows
> (from managed code) and found out that, depending how you use it (which is
> something we can't totally control with a frozen API), managed code can be
> faster than unmanaged code (as too much calls between managed/unmanaged code
> can reduce or destroy any performance advantage).
> 
> Hopefully we can get the best of both world (mine and the other one ;-)
> because we can include many implementations of a single algorithm in the
> class library. The application could choose directly which one to use (bad
> choice but 98% of current C# applications are just doing this - so it's kind
> of too late) or ask for a default algorithm implementation (good choice).
> This default implementation could be different between operating systems
> (like CryptoAPI on Windows) or selected at installation time.
> 
> > However, I thought I would pass the link along to those
> > that maybe interested.
> 
> Thanks. I'll get a new (in a mono perspective) look at it.
> 
> 
> Sebastien Pouliot
> Security Architect, Motus Technologies, http://www.motus.com/
> work: spouliot@motus.com
> home: spouliot@videotron.ca
>