Sam Craig
July 7, 2022
Authentication Cryptography Data Security Encryption Privacy

Exploring CWE-323 Reusing a Nonce, Key Pair in Encryption

Introduction

The OWASP Top Ten list provides in-depth information about the most common security issues facing web applications. Number two on the list is A02:2021 – Cryptographic Failures, which covers a wide range of common mistakes.

Among these mistakes is the reuse of nonces when sending encrypted messages with the same secret key. This error, which enables replay attacks and can leak information about encrypted data, is tracked as CWE-323.

Why Nonces are Necessary

Secure communication requires the ability for two parties to send encrypted messages to one another. For symmetric encryption, this requires the establishment of a shared secret key, while asymmetric cryptography can use public/private keypairs to encrypt and decrypt messages for each party.

Once two parties set up a set of encryption keys, they tend to reuse them. These keys can be used to send encrypted messages, authenticate the identity of one user to another, etc. In some scenarios, the context of a message matters, such as when encryption is used to protect the privacy of a conversation where each message should logically follow the previous. In others, context is less important, and out-of-order or repeated messages make sense. For example, an application sending making requests of an API could make any request at any time or repeat the same request multiple times.

If the two parties are using the same key for all their messages, then encrypting the same message with the same key will produce the same ciphertext. This creates the potential for replay attacks if an attacker can eavesdrop on a message and then send it again to the intended recipient. It doesn’t matter that the attacker doesn’t have the ability to decrypt the message and couldn’t have generated it themselves. The message will decrypt to a valid plaintext and be accepted by the recipient.

Replay attacks could cause the recipient of a message to repeat actions, which could have a negative effect on them or a positive one for the attacker. For example, an attacker could perform a Denial of Service (DoS) attack on an API by repeatedly replaying legitimate requests from an authenticated user. To protect against these replay attacks, cryptographic algorithms often make use of nonces, which are combined with the plaintext or the secret key during the encryption process. These nonces are values that are intended to be used only once.

There is nothing secret about a nonce, it’s only designed to ensure that two identical plaintexts produce different ciphertexts and that a replayed ciphertext will be obviously invalid because it reuses the same nonce. Nonces can be randomly generated, implemented as a counter, derived from the current time, etc.

Where Nonces Go Wrong

Nonces are designed to protect against replay attacks, but, if you don’t know that, they just seem like another argument that needs to be included to make the cryptographic algorithm work. As a result, some developers may just include a hard-coded nonce that could be used similarly to a cyclic redundancy check (CRC) value to verify that no errors were made in transmission.

However, these reused and hard-coded nonces provide no protection against replay attacks. If the same nonce is used every time, then repeated nonces in multiple ciphertexts doesn’t make it easy for the recipient to identify a replay attack.

Case Study: Red Hat Ceph and Openshift

In 2020, a vulnerability was discovered in the implementation of the secure mode of the messenger v2 protocol used by Red Hat Ceph Storage 4 and Openshift Container Storage 4.2  The vulnerability, tracked as CVE-2020-1759, involved the reuse of a nonce, which could allow an attacker to create fake auth tags and potentially edit data within a session.

Nonce reuse makes messages vulnerable to replay attacks and can also undermine the confidentiality of identical messages sent encrypted with the same key and nonce. Since identical plaintexts produce identical ciphertexts, an eavesdropper can learn that two messages are identical even if they can’t determine the contents.

Using Cryptography Properly

Reuse of nonces, initialization vectors (IVs), and similar arguments to cryptographic algorithms can break the security of the system. These mistakes make replay attacks possible and can leak information about encrypted data (such as the fact that two plaintexts are identical). Key best practices for using nonces securely include:

  • Look up which arguments to a cryptographic algorithm must be unique (nonces, IVs, etc.)
  • When possible, use a secure implementation of cryptography that handles these low-level details for you
  • Never reuse nonces
  • Implement nonces using a counter, random number generator, etc.

Proper use of nonces may seem like a minor detail, but reused nonces can break cryptographic protections.

Up Next

To help build understanding of how cryptography can go wrong and how to fix it, we’ll continue to dive deep into prevention measures and most of the 29 CWEs related to OWASP’s A02:2021 – Cryptographic Failures vulnerability in a series of blogs. Each blog will describe the weakness, why it happens, a real-world case study, and recommended mitigations.

We’re very committed to improving the state of cryptography and data security by sharing knowledge and helping to correct common misconceptions about how cryptography works and how to use it properly. To keep up with this series and our other research and cryptography content, make sure to subscribe to our blog in the page footer below.

Setup is quick and easy

Ready to get started?

Create a FREE account instantly and start encrypting data or get in touch to discuss a custom package for your organization.