0

I will need to do some encryption of the user data in my Windows desktop application, written in C/C++ using WinAPIs (no .NET or WinRT stuff.) Namely, I'll be doing the following:

  • Symmetric encryption: AES
  • Public key encryption (asymmetric): preferably using Elliptic curve cryptography.

My only requirements would be:

  • The code must run on Windows XP SP3 and later OS.
  • Be sufficiently robust.

So I was wondering, which would be better suited to use for Windows?

  1. To use Windows built in Cryptography APIs, or

  2. To use some C or C++ based crypto library. If so, which one? Can you explain? (The app will be developed in Visual Studio 2008 as C++/MFC project.)

My thinking on the benefits of the each was this:

  1. With Windows built in crypto APIs, it is a faster coding since most of the encryption code is provided in the APIs. Plus Windows libraries may implement CPU acceleration (for instance, some Intel CPUs have built-in AES operands.)

  2. But, with C/C++ library, there's no dependencies on Windows DLLs that may not be present on the older OS, or contain older bugs that Microsoft did not patch.

  • I think you will get the best answer to this question on the Stackoverflow SE instead of security SE – Limit Jan 21 '17 at 3:53
  • @Limit: Thanks. I'll try it there. ... but what's "Stackoverflow SE"? – c00000fd Jan 21 '17 at 4:01
  • Sorry, I just meant ask it on Stackocerflow – Limit Jan 21 '17 at 4:01
  • Tried it... it got closed on SO. – c00000fd Jan 22 '17 at 6:07
  • What reason did they give? – Limit Jan 22 '17 at 6:08
1

I strongly advise using platform-specific libraries wherever possible. The main reason is that they'll get updates automatically, whereas if you bundle a third-party library then it becomes your responsibility to monitor for updates to that library, produce updated versions of your software with the update to the third-party lib, and get your users to install the update. With frequently-updated libraries (such as OpenSSL), this is a considerable maintenance burden to take upon yourself. In my years as an infosec consultant, I saw many, many outdated OpenSSL libraries bundled with applications, most with a few dozen CVEs.

Of course, if you have to support an OS that no longer gets security updates from its developer (on account of being 16 years old), well, you're screwed either way. I'd still lean towards using the platform-provided libraries (Cryptography API or "CAPI", in this case), both for performance and because worrying about the security of anybody who uses an out-of-support OS is a fool's errand (but your users on current OSes will appreciate being able to stay secure).

One downside of using the platform APIs if you want to support XP is that XP only has the legacy CAPI, not the CNG (Crypto API Next Generation) that Vista+ offer. CNG both supports newer algorithms (I know it offers EC algorithms; less sure about CAPI) and has a nicer / more flexible API.

CNG is also a lot easier to "plug into" by third-party code, which is useful if you have a client that, for example, wants to use a specific implementation of certain algorithms (or key storage, or whatever) instead of the MS-provided implementation. This is another reason to use platform libraries, of course; if somebody has changed their default CNG provider, they probably want you to respect that!

I suggest you consider very carefully whether it's actually necessary to support such an obsolete OS when writing security-conscious code.

  • Appreciate your take on it. Unfortunately besides just dealing with security/crypto issues there's also marketing/sales to contend with, that at times don't go hand-in-hand. – c00000fd May 9 '17 at 20:55
  • Depending on which site you ask, XP is at a 5-7% global market share right now, and declining. I'm not saying that's nothing, but I doubt that it's much of a market unless you're targeting some very niche segment with a particular reason to use obsolete software beyond "I don't like paying for things" (I assume you aren't going to target the "don't like paying for things" crowd, it doesn't seem very profitable). Engineering, maintenance, and product (security) reputation are all factors to consider, balanced against absolutely maximizing potential customers. – CBHacking May 9 '17 at 21:00
0

Choice of encryption algorithm depends on user data flow (data is resident on same system or is being transfered to cloud). Data recovery can also play major role in deciding encryption algorithm. Since security of your algorithm is tied to security of your key, ensure you decide proper encryption based on your requirement.

But choice of library in your case should mainly depend on documentation support and also ongoing development support for the libraries. Since XP is primarily discontinued OS , i would rather not focus on it. If your application is tied to windows only solution, you can use microsoft libraries.

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.