1

I'm looking to build my own digital signature operations into a program I'm writing, and the nuances of cryptography are a bit beyond me.

According to this website the NIST/NSA algorithms (P-224, P-256, P-384) are not "Safe" for a variety of reasons that are admittedly beyond my experience and knowledge.

Microsoft has implemented ECC using P-256, P-384, and P-521 in "Cryptographic Next Generation (CNG)", but none of the other "Safe" algorithms listed in the chart.

What are my options and best choices? Does P-521 correct the deficiencies of the others? Is implementing a curve as simple as turning the math formula into a function? Am I better off sticking with RSA?

  • SuiteB never included P-224 and was withdrawn years ago; its interim replacement CNSASuite has only P-384 for ECC. – dave_thompson_085 Nov 12 '18 at 4:39
1

I'm looking to build my own digital signature operations into a program I'm writing, and the nuances of cryptography are a bit beyond me.

Red flag! Never implement cryptography on your own. Never. Never never never. Even if you are using standard and proven algorithms, you should never be the one who puts them all together. Unless you have a very deep understanding of cryptography, do not attempt to implement it yourself! Use a library that abstracts it away, like libsodium. Don't implement crypto yourself!

What are my options and best choices?

If none of the algorithms listed as safe on Daniel Bernstein's site are supported by the system you are using, then there is nothing you can do short of pulling in a library with support or implementing the curve yourself. However, a brief search is showing a document which claims that Windows supports Curve25519, a safe curve designed by the creator of the website you linked.

Does P-521 correct the deficiencies of the others?

No. P-521 is similar to the other NIST curves in that they use a constant of unknown origin. Because it is bigger, it does claim to offer more security than the other, small curves. Note that the "deficiencies" you point out are highly theoretical. The worry is that the constant was chosen intentionally in order to weaken the curve. Because the constant was generated by SHA-1, a weakness would have to indicate that a very large subset of possible curves are vulnerable, and that NIST, through the NSA, knew about that. This is possible, but unlikely. Chances are, NIST curves are perfectly fine.

Is implementing a curve as simple as turning the math formula into a function?

I'm not sure how exactly this can be done in .NET Core. However, I do see a question on Stack Overflow which indicates that it is indeed possible. I do not know anything beyond that.

Am I better off sticking with RSA?

This depends on your use case. If you are using it for key exchange, then you should not use RSA. The reason is that RSA does not provide forward secrecy, whereas ECC (even NIST curves) does. If you are using the algorithm in a digital signature (as you indicated), then it would be safe to fall back to RSA instead. But again, you should not implement your own cryptography!

  • so, if I'm writing a program that passes a file back and forth, how would you propose doing that? My original plan was to use CNG until I realized it only offered "unsafe" algorithms – NonSecwitter Nov 12 '18 at 2:46
  • Passes a file back and forth over what, a network? – forest Nov 12 '18 at 2:48
  • yea, in peer to peer fashion. I want the file signed programatically. I had recently found this github.com/adamcaudill/libsodium-net so, I think I was looking in the right direction. – NonSecwitter Nov 12 '18 at 2:51
  • Then you should use a library designed for that purpose, like libsodium. – forest Nov 12 '18 at 2:56
  • 1
    You can take a look at NSec. Based on libsodium for dotnet core. – AlphaD Nov 12 '18 at 3:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.