How to choose the right encryption

Emphatically no! Encryption is hard. These are solved problems. You should never implement your own encryption primitives in your code. “Never roll your own encryption” is common advice, but it’s also important not to over generalize this advice. Some take this to an illogical extreme and insist upon only using third party library to handle things like user logon. Do you see the difference? Building a secure system on top of well-vetted techniques and protocols is a reasonable thing for a developer to choose to take on. “Building” your own cipher is not, and most likely amount to something more akin to obfuscation than encryption.

Before selecting what kind of encryption you want to use and choosing an algorithm, make sure that you understand the problem you’re trying to solve. Encryption offers no value at all if your encryption scheme relies on storing the private key along with the application and is a pretty good hint that what you really want to be doing is enforcing permissions on something, not “encrypting it”. Sometimes you will even be given in your requirements that the customer wants something “encrypted”. Always ask why and ascertain what problem they are trying to solve or what risk they are trying to mitigate.

The first question you should be asking yourself is if you’re trying to leverage encryption in-flight or encryption at-rest. Notably, SSL/TLS is a protocol agnostic technique for securing a plain-text protocol over what would otherwise be an insecure channel. It is NOT useful to encrypt something at-rest. However, the same building blocks that make up SSL/TLS CAN be used to encrypt something at rest. SSL/TLS combines both symmetric and asymmetric encryption in order to harness the benefits of both. EITHER symmetric or asymmetric encryption is useful for encrypting something at-rest, but probably not at the same time. If you are concerned about an attacker on the wire, the latest revision of SSL/TLS should be the first tool you reach for. If however you are trying to encrypt something at-rest (sending a sensitive file to a client for example), you need to determine what key management strategy to employ, evaluate the residual risks, and determine if they are acceptable for your use case.

Symmetric encryption relies on two parties sharing the same key. A secret value is used as the input to a black-box function that spits out ciphertext only able to be decrypted by someone who has that same key. Symmetric encryption is blazing fast, and key management is wicked simple. However, there is no way to uniquely identify the parties in the conversation, and as such it does not scale well to multiple parties. Examples of symmetrical encryption algorithms include RC4, DES, and AES.

Asymmetric encryption relies on two keys linked by an intrinsic mathematical property. One key cannot be easily derived from the other, but that which is encrypted with the “public key” can only be decrypted by the corresponding “private key” and vice versa (in fact, this corollary is the foundation of digital signature!) The public key is shared with others and the private key is kept secret as a way of uniquely identifying you and only you. Since every party requires two keys per (a public and a private), key management quickly becomes complex. Lots of software that deals with asymmetric encryption, such as OpenGPG, provides a software mechanism for securing lots of public and private keys. Asymmetric encryption is much slower than symmetric encryption. Examples of asymmetric encryption algorithms include DSA, RSA, and ECC.

Given these advantages and disadvantages, it is likely that you will want to rely on asymmetric encryption for encrypting something at-rest that will be shared with a third party. For an in-house application, often, symmetric encryption’s better performance makes it the superior choice.

Let’s say that you want to encrypt a file at-rest using symmetric cryptography. As of this date in 2021, AES is the gold standard. But all AES is not created equal. AES defines 5 possible “modes” : ECB, CBC, CFB, OFB and CTR mode.

AES-ECB (electronic code book) is the simplest mode, but has been proven to be vulnerable to various attacks. It should not be used.

AES-CBC (cipher block chaining) provides encryption but not authentication. There is no guarantee that the ciphertext has not been manipulated by an attacker. In fact, the infamous BEAST attack which affected SSL/TLS in 2011 relied on the weaknesses of AES-CBC. CBC also requires padding the message input to blocks of a fixed size. Other choices do not have this requirement.

AES-CFB (cipher feedback) is useful for making AES (which is a block cipher) behave as a stream cipher. It relies on a cryptographically secure random value to be able to guarantee security, and AES-CFB is only as secure as this value (known as an initialization vector, or IV).

AES-CTR (Counter Mode) allows for extreme parallelization of cryptographic operations. It is by far the fastest mode. However, AES-CTR on its own suffers from certain weaknesses. It is not tamper proof (no message authentication), and requires a separate IV for each block. Lazy implementations frequently reused the same IV for each block leading to practical attack.

AES-GCM (Galois Counter Mode) is an improvement to AES-CTR. It maintains the blazing fast parallelization but also forces unique IVs AND provides message authentication to boot. If you have the choice, always choose AES-GCM, it is widely regarded as a no brainer!

Note that for all practical purposes, AES with a 128-bit key and a 256-bit key are considered equivalently secure. In 2021, both are defensible choices. Pick a 128-bit key for speed and/or battery power efficiency, or a 256-bit key to future-proof past ten years out since we don’t know what the future holds in terms of faster, better computers.

Legacy algorithms such as DES and RCA are no longer considered to be secure. Practically speaking, you will need to choose between using an RSA keypair and using a keypair that takes advantage of ECC (elliptic curve cryptography). RSA with at least a 2048 bit key is battle-vetted and widely compatible. It is never a bad choice. ECC is newer, but a very promising technology. While RSA relies on the factorization of large prime numbers, ECC hangs its hat on certain mathematical properties of elliptic curves. ECC can provide comparable security with smaller key sizes, thus making it more performant and more battery efficient for mobile devices.

Encryption is a very dense and complicated topic but making good decisions for your business doesn’t have to be hard. Start by defining your business requirements, briefing yourself on the pros and the cons of different approaches, and see how others in your business segment are solving these problems. Most importantly, always stay up to date on the latest industry wisdom. Ten years ago, the landscape of what was secure and what wasn’t looked very different.