This project has moved and is read-only. For the latest updates, please go here.

CLR Security on Linux with .NET opensourced?

Apr 23, 2015 at 4:02 PM
Edited Apr 23, 2015 at 4:02 PM
With .NET open sourced what are the plan for this project? Obviously the role of strong crypto has increased in the current cyber climate but CLR Security P/Invokes into bcrypt/ncrypt in Windows for Suite B ciphers.

How will this project work on .NET for Linux when it sees the light of day?
Feb 23, 2016 at 5:09 PM
As you surmised, this project won't work on Linux. However, tech and lessons learned from this project are the basis for feature work in the .NET Framework 4.6; and the main implementations of cryptography in .NET Core for Windows (
Feb 23, 2016 at 6:22 PM
Edited Feb 23, 2016 at 6:24 PM
Thanks Barton. It's still a bit confusing since we have the following
  1. a) .NET Framework vs
    b) .NET Core
  2. a) Windows vs
    b) Linux
  3. a) Security.Cryptography (CLR Security) vs
    b) System.Security.Cryptography (.NET Framework)
So it's not very clear what the platform will look for different permutations of the above. For example:
  • What are the cryptography library options on 2b ?
  • What will be the difference in cryptography support in 1a vs 1b ?
  • If 3a gets folded into 3b with .NET Framework 4.6+ what's the destination namespace for 3a APIs? Will it all be ported over?
IMHO, you should have a blog post addressing this in an informal manner vs a formal announcement of any sorts. If you've already covered the .NET cryptography roadmap somewhere, could you share the link?

Thanks for the phenomenal work!
Feb 23, 2016 at 6:54 PM
Good questions.

On Linux the only offering is .NET Core. As far as cryptography is concerned, Linux and Windows are almost equivalent provided that you are talking about "algorithms", vs "implementations". (For example: Use RSA instead of RSACng; now possible because we put the Sign/Verify/Encrypt/Decrypt methods on the RSA class in .NET Framework 4.6). Places where they don't work the same, at the algorithm abstraction level, are bugs.

There are things that exist in .NET Framework that don't in .NET Core. The easiest way to explain it is to share what is in Core, which is described by (the metadata/API declaration file). It's supposed to be the case that if a method on .NET Framework and .NET Core have the same name, they work the same way. If it doesn't, it's a bug (or .NET Core has a behavior that we intentionally changed and are trying to get back into .NET Framework). (There are libraries other than Algorithms. Primitives - enums and structures like RSAParameters; Csp - the *CryptoServiceProvider types; Cng - the *Cng types; OpenSsl - the Unix/OpenSsl interop types; X509Certificates - X.509 Certificates. But the question felt like Algorithms had the answers you were looking for)

Cryptography in .NET Framework is System.Security.Cryptography. The CLRSecurity project code isn't just copied over as-is; it gets merged in. Security.Cryptography.RSACng and System.Security.Cryptography.RSACng are both RSA using CNG; but they have slightly different API surface because of new information learned between their implementations.

So there's a wee-bit of adjustment pain on the part of users of this library to switch to their .NET Framework / .NET Core equivalents as they come online; but the fact that they're using this library makes them a bit of an advanced user already :)

A writeup does sound like a good idea, though... I guess I get to add that to my todo list :)