> 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" <[EMAIL PROTECTED]> To: "Daniel Morgan" <[EMAIL PROTECTED]>; "Mono-List" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > home: [EMAIL PROTECTED] > _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
