[Mono-dev] About System.Core.dll System.Security.Cryptography and Cng
sebastien.pouliot at gmail.com
Wed Feb 16 11:12:01 EST 2011
On Wed, 2011-02-16 at 17:52 +0200, Juho Vähä-Herttua wrote:
> 16.2.2011 15:39, Sebastien Pouliot kirjoitti:
> > Hello Juho,
> > On Wed, 2011-02-16 at 12:19 +0200, Juho Vähä-Herttua wrote:
> >> Hi,
> >> I have implemented elliptic curve cryptography (ECC) algorithms on .NET
> >> by using the BigInteger struct from .NET 4.0. On Fp curves they seem to
> >> be considerably faster (about twice the speed) than the BouncyCastle
> >> library http://www.bouncycastle.org/csharp/ I used for comparison. This
> >> is probably mostly because of the speed of the BigInteger
> >> implementation, because I don't see much difference in the actual
> >> arithmetics.
> >> I have also implemented most of the Cng related enumerations in
> >> System.Security.Cryptography
> > iirc we already part them (or part of them in our git repository)
> I saw CngAlgorithm and CngAlgorithmGroup, those are only 2 of the 23
> classes I would need (if I counted them right).
yep, looks right
> >> and reverse engineered some
> >> ECDiffieHellmanCng class functionality where the documentation is not
> >> clear.
> > "reverse engineered" means a lot of things to different people. Can you
> > elaborate on this and ensure it's in compliance with:
> > http://www.mono-project.com/Contributing#Important_Rules
> In this context I meant trial-and-error and Microsoft documentation, the
> ECDiffieHellmanCng class should just be a wrapper to the native Cng API
> anyway, so I doubt decompilation would help anything.
True, and I'm glad you did not have to decompile anything to find that
> I'll review those
> rules and my code and try to make sure it complies with all the
> >> I could send these upstream to Mono, but since there are a lot of
> >> files to be added, I'd like to know how should I proceed.
> > That would be great :) and a patch will be fine (for review). But first
> > please read both:
> > http://www.mono-project.com/Contributing
> > and
> > http://www.mono-project.com/Coding_Guidelines
> Thank you for the links, I've tried to follow the code style I have seen
> in other Mono classes, but I'll go through the guidelines while
> reviewing the code myself.
> >> should I write some tests before they
> >> can be accepted?
> > Yes, definitively! Unit tests (nunit) are required to ensure it works
> > correctly (on both MS and Mono runtimes) and ensure no future
> > regressions.
> Ok, I'll have to look into this after I've finished the required
> functionality in the code.
> >> Does Novell have some copyright policy I should
> >> consider? Releasing them with the MIT license shouldn't be a problem.
> > Our class libraries are MIT.X11 licensed, so as long as you can release
> > this code with that license there should not be any problem.
> I also have some questions I might need advice with. The Cng classes
> have functions and properties like
> http://msdn.microsoft.com/en-us/library/bb298399.aspx that return a
> SafeNCryptSecretHandle. This should be a handle to the native
> cryptography API, but it's completely useless in Mono. Since
> SafeNCryptSecretHandle is not implemented, I just dropped those methods
> completely. How should I proceed in this kind of case?
The best way* would be to stub the missing SafeNCryptSecretHandle and
throw NotSupportedException inside the Cng* properties that access it.
* this would avoid runtime exception for code compiled against
MS.NET (e.g. a call could be present without being required to
> Another thing I had to do is that I am throwing exceptions in case
> someone tries persistent key storage, all the keys in my implementation
> are ephemeral. (but can be serialized into a file and made persistent
> that way) Since Mono is not using the real key storage of .NET I suppose
> this should be ok?
While we're not using the same key storage as .NET we do support keypair
persistence. Right now this is publicly* exposed thru CspParameters
which do not match well with CngKey.
Anyway let's do baby-steps and start with what you already have (and
unit tests) then we can look at what's missing :-)
* while Mono.Security expose this more directly "internally"
More information about the Mono-devel-list