Banner image of Cryptography myths

Some people are convinced that applying cryptography to their product or service solves all problems regarding security and privacy. Of course, this isn't the case as shown in this article.

Always stay in the loop!
Subscribe to our RSS/Atom feeds.

Myth 1: Applying cryptography makes everything secure

For encryption, you need the original unencrypted text, a key, and an encryption algorithm. Let us assume that your original text has no cryptographic relevance.

Depending on your encryption algorithm, you either need the public key of the recipient of your message (asymmetric key ciphers) or a shared key (symmetric key ciphers). Keys can be leaked, keys can be weak, and keys can be guessed by using certain attacks like brute-force attacks. Stream ciphers, a subclass of symmetric key ciphers, can be attacked if you ever use the same key twice.

Moreover, most encryption algorithms are only secure as long as certain requirements are met. For instance, some rely on unique values and some rely on random values. So even if an encryption algorithm is secure in theory, it can be implemented incorrectly and therefore become insecure.

In summary, cryptography adds some security that varies depending on your threat model, your implementation, and your key management. In general, cryptography doesn't make everything secure.

Myth 2: Applying cryptography makes everything private

Applying cryptography doesn't make everything private.

For instance, if you use OpenPGP for all of your e-mails, there is still lots of unencrypted metadata like senders and recipients of e-mails, length of the content, timestamps, mail servers, and subject lines.

Another example is XMPP: If you always use OMEMO for your messages, your contacts, group memberships and device information is still stored in cleartext on the XMPP server (also see “XMPP: Admin-in-the-middle”).

Even HTTPS doesn't keep everything private since third parties can see to which servers you connect, including how often you access certain servers and the time of connection.

In many cases, cryptography only protects the content of messages while metadata remains unencrypted and accessible to third parties.

Myth 3: AES is secure

Don't get us wrong here! The Advanced Encryption Standard (AES), introduced 20 years ago, is still considered sufficiently secure for most purposes. However, as a block cipher, AES supports the operation modes Electronic Codebook (ECB) and Cipher Block Chaining (CBC) that are considered insecure in some cases. Therefore, it is wrong to claim that AES is secure in general. It is only secure if you use secure modes of operation (like GCM), and if everything is implemented correctly.

Block ciphers like AES transform fixed-length groups (blocks) into groups of the same size. ECB takes a block and always applies the same operation to it. This means having two identical blocks as input results in two identical blocks as output.

For instance, you want to encrypt two messages with ECB mode: This is my secret text and This is no secret book. For simplicity, we assume that 1 block equals 4 characters, and zeros are appended to get a full block at the end. The resulting two messages look like: This ismy secr ette xt00 and This isno secr etbo ok00.

ECB encrypts both messages, resulting in something like 01ab def9 321c c992 8877 and 01ab 7722 321c aaa2 551f. As you can see, there are two identical blocks in both encrypted messages: 01ab (This) and 321c (secr). This is one of the weaknesses of ECB. Each block is handled separately.

Another weakness directly resulting from this: You can modify parts of ECB-encrypted text without knowing the secret key used for encryption. In our example, you can change 01ab def9 321c c992 8877 to 01ab 7722 321c c992 8877. If decrypted, the modified message reads This is no secret text instead of This is my secret text.

The CBC mode, on the other hand, is prone to some padding oracle attacks (e.g., POODLE) and timing attacks (e.g., Lucky13).

Follow us on Mastodon:
@infosechandbook

Conclusion

In most cases, applying cryptography adds confidentiality, integrity, and achieves other security goals. However, applying cryptography neither makes everything secure nor private. Cryptography needs to be correctly implemented, it requires secure key management (see our article on “Modern credential management”), and you need to consider that there is still unencrypted data and metadata.

Claiming that a product or service uses some cryptography or even “military-grade encryption”, doesn't mean that it is secure (see also our article “What is ‘secure’?").

See also