In one of my projects I was choosing bcrypt or PBKDF2 for the KDF for passwords. I have read that bcrypt is generally more advanced and scrypt is even better. But I am using .NET platform where bcrypt/scrypt are not available from Microsoft though there are various implementations on nuget. In the end I decided to use PBKDF2 since it's a default implementation by MS which is hopefully reviewed by some security experts.

But the question is: what is the best course of action in such situation? Can one just pick top rated library with enough downloads from nuget and trust it's good enough since many people use it? How do I know if it's good enough then. Or it's better to use something from the platform if available? I definitely don't want to implement anything like that myself.

  • IMHO trust on IT-security software is nowadays virtually sort of faith. Human errors and malicious backdoors continue to be discovered. A recent issue is socat. Cf. my recent thread "What could eventually be done to mitigate the risks of errors and backdoors" (currently unfortunately yet on hold due to formulation issues unsatisfying for the moderators). Feb 8, 2016 at 12:45
  • 3
    "hopefully reviewed by some security experts" - LOL
    – symcbean
    Feb 8, 2016 at 14:21
  • Well there is something going on there, like e.g. here: technet.microsoft.com/en-us/library/security/cc750357.aspx. So I really hope that all their crypto libraries go through a 3d party review. Feb 8, 2016 at 14:59
  • 1
    While this may seem "opinion based", it's actually a very fair question. The question is not "which library should I trust?", it's "how do I select a trustworthy library?" Feb 8, 2016 at 16:18

3 Answers 3


You have three tradeoffs: PBKDF vs another algorithm, open source vs closed, and the availability of test vectors.

SCrypt or BCrypt may give you somewhat more security than PBKDF2. On the other hand, if there's an implementation failure in the code (as happened to Ashley Madison) then you get a lot less security.

To the extent that the code gets scrutiny, such failures may get noticed, and here's where the open source tradeoff happens. In theory, anyone can look at the code. In practice, you have to ask how many experts have looked. The supply of volunteer crypto analysts is pretty slim, as demonstrated by OpenSSL flaws. With the MS PBKDF code, you can expect that someone other than the coder did QA, and the crypto code gets relatively more attention under the Security Development Lifecycle. Absent other indicators of security testing, a .NET nugget used by 100 people probably has less analysis done on it than a Microsoft component.

Lastly, if memory serves, PBKDF has test vectors, and the others don't, which makes testing correct implementation of PBKDF easier than testing implementations of scrypt or bcrypt.

I should mention, years ago I tracked free crypto libraries and then, later, worked on Microsoft's Security Development Lifecycle team, but no longer do. I don't think there's a simple answer to your question.


How much can we trust open source implementations of crypto (security) libraries?

Much better than closed source implementation.

When it comes to security that really matters, you have to follow the principle "trust but verify". Trust that popular open source implementations are more likely to get it correct and enough eyeballs to spot mistakes, but verify/audit the code yourself if it really matters to you.

With open source implementation, you can actually verify it yourself if it really matters for you. With closed source implementation, you only have the vendor's word for it.

If anything, distrust over open source security libraries is a good thing; it makes some people to start auditing them before using, rather than just blindly trusting an implementation because they are popular.

  • 3
    Well, verify yourself is a bit complicated if you are not Bruce Schneier. I mean I have no idea how to verify it's implemented properly, so it's as good as just trusting it, even if it's open source. Another thing is, how would you really know there are vulnerabilities even if people find them? Google on security forums, etc.? Feb 8, 2016 at 14:06
  • 2
    +1 for 'Much better than closed source implementation.'
    – marstato
    Feb 8, 2016 at 14:46
  • Researching known issues with the library under test is all you can do. If people spot issues they should tell the library authors. The authors are then to fix the issue; that is the only way to resolve crypto bugs in a sane way. But that is the same for open and closed source libraries; so you are still better off just trusting the open source stuff.
    – marstato
    Feb 8, 2016 at 14:48
  • 1
    One essential difficulty, at least with most large open-source packages, seems to be the result of the fact that they were not designed to highly facilitate review by outsiders. The problem could be poor documentations, poor structuring of the whole, poor programming style and scanty comments of codes. This is very very sad but on the other hand understandable. For otherwise the cost of development would be essentially higher and maybe the time of development would also be much longer. Feb 8, 2016 at 17:13
  • 1
    @marstato: Couldn't "indirectly" have the same "value" as "directly" in this context? Say, a software error or the like causes a critical encrypted message of someone who is accused of something that is threatened with death sentence be cracked in a totalitarian country.. Feb 10, 2016 at 17:53

Never code encryption or hashing libraries yourself, but use already existing ones instead. Those already existing ones are made by people who are often specialized in it.

Besides that. The best one to use should be open-source in first place. By being open-source more security-experts/people have the opportunity to find bugs or errors, and by that more issues get fixed. Logically, the one which is the most used is often also the most reviewed. Higher chance more issues have been fixed on that one.

You can't really check yourself if it's safe. Finding errors in such an algorithm is hard. Quick examples. One security-expert probably won't find them all, so also don't trust the closed-source ones because their code didn't reached that many eyes as the open-source one.

  • a few very competent security experts/programmers thoroughly auditing well written closed source code is better than 100 average security "professionals" who are not really programmers or 100 programmers who are not really security experts looking at open source code. Feb 10, 2016 at 0:36
  • 1
    @RichieFrame: That in the case you mention the qualtity of auditing is better is clear. But how could it be ensured in practice for the users that a closed-source software doesn't contain (intentionally implanted) backdoors? Feb 10, 2016 at 18:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .