blog

Scramble Text With XOR on ESP32: XOR Encryption vs Standard Cryptography

Ethan Martinez

Use XOR on an ESP32 only for light obfuscation, not real encryption. If a message must resist attackers, use proven cryptography such as AES-GCM, ChaCha20-Poly1305, or TLS through well-tested libraries. XOR is simple, fast, and useful for demonstrations or hiding plain text from casual viewing, but it fails quickly when the key is reused or guessed.

TLDR: XOR can scramble text on an ESP32 in a few CPU cycles, so it is fine for harmless masking, test data, or teaching how bytes work. For example, a battery sensor sending a 64-byte status message every 10 seconds may save almost no meaningful power by choosing XOR over AES, while losing nearly all real security. In a small product test, XOR might block a casual serial monitor view, but it would not stop a basic attacker with two or three captured messages. Use standard cryptography for user data, Wi-Fi credentials, tokens, logs, or firmware-related secrets.

XOR on ESP32: What It Actually Does

XOR, short for exclusive OR, is a bitwise operation. It compares two bits. If they are different, the result is 1. If they are the same, the result is 0. That tiny rule makes XOR reversible, which is why developers sometimes call it “XOR encryption.”

If you XOR a text byte with a key byte, the output looks scrambled. If you XOR the scrambled byte with the same key again, the original text returns. This is neat. It is also dangerous when treated as serious security.

A tiny ESP32 example may look like this:

void xorBuffer(uint8_t *data, size_t len, const uint8_t *key, size_t keyLen) {
  for (size_t i = 0; i < len; i++) {
    data[i] = data[i] ^ key[i % keyLen];
  }
}

This function is compact. It works on text, JSON, sensor packets, or any byte array. It also repeats the key, which is exactly where things start to break.

Why Developers Still Use XOR

XOR survives because it is useful in narrow cases. On the ESP32, it is easy to write, easy to test, and easy to reverse during debugging. It does not need a large library. It does not care about block sizes. It adds almost no delay.

Common safe uses include:

  • Masking debug strings so they are not plainly visible in firmware dumps.
  • Teaching encryption basics without adding library setup.
  • Simple checksums or parity-style tricks, though these are not replacements for message authentication.
  • Temporary scrambling of non-sensitive values in RAM or logs.

The catch is, XOR feels better than it is. A scrambled payload can look convincing in a serial terminal. That visual noise often gives a false sense of control. Real attackers do not care that the bytes look messy. They care whether the method leaks patterns, repeats keys, or allows guessing.

Where XOR Fails

XOR fails hard when the same key is reused. If an attacker captures two messages encrypted with the same repeating key, patterns leak. If any part of the original text is predictable, such as {"temp": or "deviceId", the key can start to fall apart.

IoT messages are especially predictable. Many packets share the same structure. A device may send the same field names hundreds of times per day. That gives attackers plenty of material.

For example, assume an ESP32 sends this JSON every minute:

{"id":"node7","temp":22.4,"battery":91}

If the same XOR key protects every message, the repeated parts help expose the key. Once the key is recovered, old and future messages may be readable. Even worse, XOR alone does not prove that a message is authentic. An attacker may flip bits in the scrambled data and cause controlled changes in the plain text.

That last part drives me crazy in real projects. Someone says, “But it’s encrypted,” while the receiving device accepts changed commands without checking who sent them. Encryption without authentication is usually not enough.

XOR Versus Standard Cryptography

Standard cryptography solves problems XOR does not try to solve. AES-GCM and ChaCha20-Poly1305 can provide both confidentiality and integrity. Confidentiality hides the data. Integrity detects tampering. Both matter on connected devices.

The ESP32 is not too small for real cryptography. Many ESP32 variants include hardware help for AES and SHA operations. The ESP-IDF also includes mbedTLS, which supports modern cryptographic protocols and primitives. Arduino-ESP32 projects can also use available crypto libraries, though library quality should be checked with care.

Here is a practical comparison:

  • XOR: Very fast, tiny code, weak security, unsafe with repeated keys, no built-in tamper detection.
  • AES-CBC: Common, but requires correct padding and a random IV. Also needs a MAC for tamper detection.
  • AES-GCM: Strong choice when used correctly. Provides encryption and authentication together.
  • ChaCha20-Poly1305: Strong modern option. Often performs well in software and is easier to use safely than older constructions.
  • TLS: Best for network connections when certificates, identity, and session security are needed.

Performance on ESP32 Is Usually Not the Problem

Many teams pick XOR because they fear standard encryption will be too slow. On an ESP32, that fear is often outdated. Encrypting a small sensor packet with AES usually costs little compared with Wi-Fi connection time, network retries, cloud latency, or waking from deep sleep.

For a 100-byte message sent once per minute, the energy cost of using proper encryption is usually a tiny part of the full budget. Wi-Fi radio activity may consume tens to hundreds of milliamps while active. The CPU time saved by XOR may be invisible in a real power profile.

Expect to waste time on the wrong area if you optimize the XOR loop while ignoring reconnect behavior. A bad Wi-Fi retry pattern can burn far more power than authenticated encryption ever will.

When XOR Is Acceptable

XOR can be acceptable when there is no security promise. Be honest in documentation. Call it scrambling, masking, or obfuscation. Avoid calling it encryption unless the audience understands the limits.

Reasonable XOR cases include:

  • Hiding harmless demo text from casual viewers.
  • Obscuring non-secret configuration labels in flash.
  • Creating reversible transformations for lab exercises.
  • Testing byte pipelines before adding real encryption.

Bad XOR cases include:

  • Protecting Wi-Fi passwords.
  • Storing API tokens.
  • Securing medical, payment, access control, or location data.
  • Protecting firmware update commands.
  • Authenticating device commands.

How to Use Real Cryptography Safely

If the ESP32 handles sensitive data, use a standard construction and follow a few rules. Most failures come from key handling, nonce reuse, and missing authentication.

  • Use a trusted library. Prefer ESP-IDF security APIs, mbedTLS, or a well-reviewed library.
  • Use authenticated encryption. AES-GCM or ChaCha20-Poly1305 are good default choices.
  • Never reuse a nonce with the same key. This can break strong algorithms.
  • Protect keys. Use ESP32 flash encryption, secure boot, and eFuse features where available.
  • Authenticate updates. Firmware must be signed and verified before installation.
  • Use TLS for internet traffic. Do not invent a custom protocol unless you have a strong reason and expert review.

A Practical Decision Rule

Ask one question: Would it matter if a stranger read or changed this data? If the answer is yes, do not use XOR as the security layer. Use standard cryptography. If the answer is no, XOR may be fine as a simple scrambling tool.

For ESP32 projects, this rule saves time and reduces risk. XOR is a useful bit operation. It is not a security plan. Treat it as a tool for masking and learning, not as protection for real users, real devices, or real business data.

Recommended Posts