Use [libsodium](http://cr.yp.to/antiforgery/cachetiming-20050414.pdf). **Use [libsodium](http://www.cryptofails.com/post/70059600123/saltstack-rsa-e-d-1).** Use [libsodium](http://sourceforge.net/p/mcrypt/patches/10/). **Use [libsodium](https://bugs.php.net/bug.php?id=70014).** Use [libsodium](https://gist.github.com/tqbf/be58d2d39690c3b366ad). **Use [libsodium](https://blog.codecentric.de/en/2014/03/crypto-broken-apply-secure-crypto-developer/).** Use [libsodium](http://hintjens.com/blog:35). ## Why not {Mcrypt, OpenSSL, Bouncy Castle, KeyCzar, etc.}? These cryptography libraries are really building blocks that by and large must be used, with expert care, to build the interfaces you want developers to use. In most cases, libsodium *is* the interface you want developers to use. I couldn't tell you how many projects I've found that are riddled with poor implementation choices (`RSA/ECB/PKCS1`, `Rijndael256-ECB`, plain `AES-CBC` without any message authentication, message corruption issues introduced by mcrypt's zero byte padding, timing attacks on the MAC validation that allow message forgery, etc.) that could have easily been avoided had developers only known they could just use libsodium and move on with their lives. By default, these libraries don't provide [authenticated encryption](https://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-probably-broken). Most of them force developers to use RSA (or ECDSA but certainly not EdDSA), which is [hard to get right](http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html) and for which [index calculus attacks are improving each year](https://events.ccc.de/congress/2014/Fahrplan/system/attachments/2501/original/20141227.pdf). ### Why not NaCl? **[NaCl](http://nacl.cr.yp.to) is fine, really.** It's very secure and I don't want to take away from this fact at all, but I still don't recommend most people use it for one simple reason: Unless you're developing in C/C++ and only need to target a few Unix platforms, or you're developing in Python, NaCl isn't an option for you. It might be tempting to fork NaCl and tweak it to work on your platform or expose bindings for NaCl [in your programming language](https://download.libsodium.org/doc/bindings_for_other_languages/index.html), at which point you're better off using libsodium which already did the work for you. Libsodium is an NaCl fork with a 100% compatible API, extra features, and portability. If you're using libsodium, you're using NaCl too. If you're a PHP, Node.js, Ruby, C#, Java, iOS, Android, or Perl developer, libsodium is readily available while the original NaCl is not. If NaCl *is* an option for you, by all means use NaCl. ### What Makes Libsodium so Great? As I said before, libsodium was forked from NaCl. NaCl is a library written by a team of cryptographers known for innovative research into elliptic curve cryptography and side-channel cryptanalysis ([Dan Bernstein](http://cr.yp.to), [Tanja Lange](https://hyperelliptic.org/), and [Peter Schwabe](https://cryptojedi.org/peter/index.shtml)). Libsodium, like NaCl before it, offers simple interfaces for strong and concise cryptography features. Every operation is carried out in constant-time; no branches or array index lookups are controlled by secret information (i.e. your encryption keys). Unlike WebCrypto, which is a potluck of popular cryptography standards, chosen by committee, libsodium's cryptographic primitives and constructions were carefully selected with a clear statement of their security properties for real-world software applications. Despite its emphasis on security, libsodium out-performs the NIST standards. Want to encrypt a message to your friend using a shared secret key? Just use crypto_secretbox(). Don't have a shared secret but have your friend's public key? You want crypto_box(). ### Reasons Not to Use Libsodium 1. FIPS compliance prevents you from using it. (Our condolences.) Update: [Libsodium now has AES-256-GCM](https://download.libsodium.org/doc/advanced/aes-256-gcm.html) (as of 1.0.4), which is one step closer to FIPS compliance. 2. The bindings for libsodium do not yet exist in your language. 3. Strong cryptography is illegal in your country. 4. Stringent requirements to maintain interoperability with weak cryptography. ### How do I get started with Libsodium? For PHP developers, we maintain the [libsodium PHP extension documentation](https://paragonie.com/book/pecl-libsodium), which should help developers understand how to use these features in detail. For developers in other languages, check out the [libsodium documentation](https://download.libsodium.org/doc/bindings_for_other_languages/index.html) to see if bindings exist for your language, then consult the documentation for your specific language (if it exists). ### TL;DR Just use libsodium. ----------------- **Quick note about elliptic curve public key cryptography:** In general, [ECDSA is harder to get right than EdDSA](https://www.schneier.com/blog/archives/2011/01/sony_ps3_securi.html). EdDSA requires no random elements and is easier to implement without side-channels. Many standardized ECDSA curves are not [twist-secure](http://safecurves.cr.yp.to). If you'd like to know more, the team behind NaCl did a great talk at the 31st annual Chaos Communications Congress titled, [A Gentle Introduction to Elliptic Curve Cryptography](https://www.youtube.com/watch?v=l6jTFxQaUJA).