The Dangers of “Rolling Your Own” Encryption

Susan Morrow
March 28, 2019 by
Susan Morrow

Why It Takes a Community to Create Good Encryption

What would our online world be like without cryptography? For a start, security as we know it would not exist. We use (or should use) encryption across all of the touchpoints of the digital information realm — where we store information, how we transmit data and when we share it with others. It is a foundation stone of information online and within our internal networks, too.

For encryption to maintain this high ground, it has to be robust. Robustness does not happen automatically or overnight; in fact, it takes time and a community to achieve it.

Learn Applied Cryptography

Learn Applied Cryptography

Build your applied cryptography and cryptanalysis skills with 13 courses covering hashing, PKI, SSL/TLS, full disk encryption and more.

In his article, we will look at the idea of “rolling your own crypto” or, in other words, developing your own encryption algorithms and/or schemes.

Some Basics on Encryption

Encryption is used to prevent unauthorized reading of data. The process of encryption takes the original data or plaintext and combines it with a key in such a way as to render the data unreadable. The result of this process is ciphertext; the reverse process, decryption, returns the plaintext from the ciphertext.

Encryption can be divided into two types, symmetric and asymmetric, based on the nature of the key. Symmetric encryption uses the same key for both encryption and decryption. Asymmetric or public key encryption uses a pair of keys: a public key for encryption and the corresponding private key for decryption. In symmetric encryption, the key must be kept secret but shared between the parties who can encrypt and decrypt. Conversely, in public key encryption, only the private key is secret and is not shared. The public key is available for anyone to encrypt data for the private key holder.

When people write their own algorithm, it usually involves symmetric encryption. Within any given use case, you need both an algorithm and a scheme (or mode) by which the encryption is applied.

The thing to remember is that encryption algorithms are not the end of the story. Encryption is a system. It uses methodologies with many moving parts, including algorithms, encryption libraries, modes of operation and configuration variables during implementation. All of these things form the whole and any part of the whole can be a weak point.

More details on how encryption works can be found in this mini-course on cryptography fundamentals.

When Home-Grown Crypto Goes Bad

To set the scene, let’s look at two examples of when rolling your own crypto was used but could or did go wrong.

The CSL Dualcom experience

Users of a CSL Dualcom CS2300-R device, used to alarm shops and offices, were placed at risk by a hybrid roll-your-own cryptographic implementation. Researchers identified fundamental flaws in the encryption scheme, which they showed was insecurely implemented.

The Telegram experience

Telegram, the mobile messaging app, developed its own encryption scheme known as MTProto. Researchers Jakob Jakobsen and Claudio Orlandi of Aarhus University demonstrated that “it is possible to turn any ciphertext into a different ciphertext that decrypts to the same message.” Telegram uses AES 256-bit encryption, but because they implement it in a non-standard manner it has left potential issues in their product. As the researchers stated:

“The take-home message (once again) is that well-studied, provably secure encryption schemes that achieve strong definitions of security (e.g., authenticated-encryption) are to be preferred to home-brewed encryption schemes.”

Telegram continue to use MTProto but say that they are “continuously working with the community to improve the security of our protocol and clients.”

Some Reasons Why Roll-Your-Own Crypto is Bad News

Having an encryption algorithm is only part of a larger whole when it comes to securing data. Here are some reasons why home-grown crypto is not something you embark on lightly:

  1. Knowing your mode: Symmetric algorithms are divided into two types: stream and block ciphers. With the latter, data is encrypted in blocks of a defined size, e.g., 16 bytes. How each block is combined with previous blocks is defined by the “mode.” You need to apply the right mode of implementation to the right use case. This has to then be checked for security flaws.
  2. An example is the Electronic Code Book (ECB) mode, which is a simple mode with some inherent weaknesses. ECB passes plaintext through the algorithm directly to output ciphertext. This means that a given plaintext will always give the same ciphertext, making it insecure for many applications. Cipher Block Chain mode (CBC) is more secure because it does not have this weakness. Home-grown modes need to be crypto-analyzed for flaws.

  3. Tried and tested: Crypto standards like Advanced Encryption Standard (AES) are tried and tested. NIST published AES back in 2001. There were 15 candidate algorithms for the standard back in 1998. The finalists included MARS, RC6, Rijndael, Serpent and Twofish. Rijndael was chosen, and over several years, comments from the community were taken on AES. The standard then had to go through rigorous validation in NIST’s Cryptographic Algorithm Validation Program against various modes.
  4. Differential cryptanalysis can be used to find vulnerabilities in an algorithm: It is used to spot areas in a cipher that are non-random and so can be used to predict the output with a high probability. If you push an algorithm out into the wild without extremely thorough testing, you can bet it will be put through differential cryptanalysis by someone trying to find a vulnerability to exploit.
  5. Test vectors that are code-dependent: Say you write your code in a particular language and you want to use the AES standard in that language. You need to know there are test vectors available to prove you are getting the same results as everyone else. This allows your code to be validated against these test vectors. Roll-your-own will not have these cross-check measures available.
  6. Multiple implementation modes will be needed: Roll-your-own would usually mean that multiple complementary implementation modes would need to be developed. These allow the new algorithm to be used across multiple use cases adding complexity and therefore likely further vulnerabilities that require extensive testing to determine.

Should I or Shouldn’t I Roll My Own Crypto?

The general consensus is no. Even if you are an expert, don’t bother. Workable encryption schemes are much more than an algorithm or a mode alone. They require a community of people working together to cross-reference, test and analyze the design.

Encryption is a bottom-line security measure. Without a deep dive into the system design, often requiring years of testing, can we truly be sure of the robustness of a schema. Fortunately, we already have a number of encryption algorithms and modes that are tested in the wild by a global audience. Because of the existence of tried-and-trusted encryption schemes, we are seeing far fewer roll-your-own attempts, unlike back in the 80s when it was a common practice.

Before you go off and spend a long time creating your own home-grown version of encryption, check out what’s already available first. Become an expert in implementation, not in encryption algorithm or mode development.

Learn Applied Cryptography

Learn Applied Cryptography

Build your applied cryptography and cryptanalysis skills with 13 courses covering hashing, PKI, SSL/TLS, full disk encryption and more.



  1. CSL Dualcom CS2300-R signalling unit vulnerabilities, Cybergibbons
  2. Jakob Jakobsen and Claudio Orlandi, “On the CCA (in)security of MTProto
  3. Telegram FAQ, Telegram
  4. ECB, Cryptowiki
  5. CBC, Cryptowiki
  6. AES Standard, NIST
Susan Morrow
Susan Morrow

Susan Morrow is a cybersecurity and digital identity expert with over 20 years of experience. Before moving into the tech sector, she was an analytical chemist working in environmental and pharmaceutical analysis. Currently, Susan is Head of R&D at UK-based Avoco Secure.

Susan’s expertise includes usability, accessibility and data privacy within a consumer digital transaction context. She was named a 2020 Most Influential Women in UK Tech by Computer Weekly and shortlisted by WeAreTechWomen as a Top 100 Women in Tech. Susan is on the advisory board of Surfshark and Think Digital Partners, and regularly writes on identity and security for CSO Online and Infosec Resources. Her mantra is to ensure human beings control technology, not the other way around.