[Mono-list] Crytography in Mono using NSS

Sebastien Pouliot Sebastien Pouliot <spouliot@videotron.ca>
Mon, 14 Oct 2002 21:51:54 -0400


> 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

----- Original Message -----
From: "Daniel Morgan" <danmorg@sc.rr.com>
To: "Mono-List" <mono-list@ximian.com>
Sent: Monday, October 14, 2002 8:33 PM
Subject: [Mono-list] Crytography in Mono using NSS


>
>
> Excerpt from www.go-mono.com concering crytography in Mono:
> "Also Sebastien Pouliot has been improving the various cryptographic
classes
> in Mono, something that we had not done in quite some time. We are looking
> for a way to handle big-nums. We need either a managed or unmanaged set of
> classes for handling large numbers, and some volunteers to expose this
> functionality to C# (Either as an internal assembly, or as a set of
> P/Invoke, Internal call wrappers"
>
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>