4

What are the limitations of the Microsoft Elliptical Curve support in .NET? I'm referring only to what's possible with the System.Cryptography namespace.

With that namespace, can I implement custom curves, or am I limited to a distinct subset which is hard coded in the framework?

One curve I'm particularly interested in is secp256k1, though I don't want to limit myself to that.

Why am I not using Bouncy Castle, and only focused on Microsoft? The reason is because the Microsoft implementations of the Hash functions are many times faster than Bouncy Castle, and so therefore I think the custom Elliptical Curve based encryption.

I don't mind if I need to update the registry or an ini file to add support for additional curves, or build low-level classes; I just want to see what the possibilities and limitations are.

makerofthings7
  • 60,103
  • 53
  • 215
  • 448
  • Does this help?: http://bitcoin.stackexchange.com/questions/3875/which-programming-languages-support-secp256k1 – weston Oct 26 '13 at 14:16
  • @weston I've seen that link, and the C# code it refers to. No, it only shows the Bouncy Castle implementation... I'm interested in using Microsoft-only libraries to implement EC – makerofthings7 Oct 26 '13 at 14:18
  • 2
    @makerofthings7: If MS-only stuff could really do it worth a damn, why would it be so hard to find examples that *don't* revolve around a third-party library? – cHao Oct 26 '13 at 14:21
  • 2
    @cHao Because existing examples involving third party libraries don't always tell the whole story. Case in point: The default cryptography provider in Java limits AES key size to 128 bits. The straightforward answer for those who need 256-bit keys is to use the Bouncy Castle provider. Installing an extra 2MB library that duplicates standard functionality is suboptimal for many reasons, yet no-one seems to have a better solution. Eventually, after months of (on-and-off) research, I managed to solve the issue without involving third party libraries: http://stackoverflow.com/a/18437016/2424896 – ntoskrnl Oct 26 '13 at 15:02

1 Answers1

3

The only supported curves by .NET are (and have long been) the P-xxx curves defined by NIST in Suite B. Any other curves are not supported out of the box. You have defined a specific non-NIST non-prime curve (a Koblitz curve) that is therefore not supported by CNG.

To be more precise, CNG only supports the following domain parameters for ECDSA and ECDH keys. Those parameters are only supported when they are used for "named curves" too:

P-256, P-384, P-521

Note: as I don't have an NDA or similar with Microsoft, I cannot check if these values are hard coded, but I would consider that very likely.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • 1
    all the recommended curves are 'backdoored' by NSA. Do not use them. – NoWhereToBeSeen Feb 02 '16 at 19:43
  • @RedHotScalability Don't spread FUD. Nobody found a way to see how the current parameters can be exploited. The random number generation is somewhat suspicious, so you are better off using a [safe curve](http://safecurves.cr.yp.to). The only thing that we are pretty sure of to be backdoor'ed is the Dual EC *random number generator*. – Maarten Bodewes Feb 02 '16 at 21:58