[Mono-dev] About System.Core.dll System.Security.Cryptography and Cng

[Sebastien Pouliot]

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
https://github.com/mono/mono/tree/master/mcs/class/System.Core/System.Security.Cryptography

> >> 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
out ;-)

> I'll review those 
> rules and my code and try to make sure it complies with all the 
> requirements.

Thanks :)

> >> 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.

Great

> >> 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.
> 
> Ok.
> 
> 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
        execute properly).

> 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"

Thanks!
Sebastien