Lightweight Encryption Protocols for Resource-Constrained IoT Devices

Lightweight encryption protocols exist because standard cryptography assumes resources that most IoT devices don't have. A temperature sensor running on a coin cell battery cannot afford the RAM, CPU cycles, or power draw that AES-256 or RSA-2048 demand on a server. This gap between what conventional encryption needs and what embedded hardware can supply has produced an entire category of ciphers built specifically for constrained environments.

Why Standard Cryptography Fails on Small Devices

Most encryption algorithms were designed for desktops, servers, and phones — devices with abundant memory, fast processors, and a stable power supply. IoT endpoints rarely have any of that. A typical microcontroller used in a smart lock or industrial sensor might carry 8-32 KB of RAM and run at speeds measured in single-digit megahertz, not gigahertz.

// Typical constrained IoT device profile
#define RAM_AVAILABLE_KB      16
#define FLASH_AVAILABLE_KB    128
#define CPU_CLOCK_MHZ         8
#define BATTERY_CAPACITY_MAH  220
#define EXPECTED_LIFESPAN_YRS 5

Under these constraints, running AES-256 in software can consume RAM the device simply doesn't have left over after handling sensor input, networking stacks, and application logic. RSA key exchange is worse — the modular exponentiation involved can take seconds on an 8-bit microcontroller, draining battery reserves that are meant to last years, not days.

Engineers working on constrained hardware face a three-way trade-off: security strength, computational cost, and energy consumption. Lightweight cryptography doesn't eliminate this trade-off. It shifts the curve, offering security margins appropriate for the threat model while fitting inside a fraction of the memory and power footprint.

What Makes a Cipher "Lightweight"

The term lightweight cryptography refers to a specific design philosophy rather than a single algorithm. NIST formalized this category through its Lightweight Cryptography Standardization project, which ran from 2018 to 2023 and evaluated dozens of candidate algorithms against criteria including silicon area, RAM footprint, energy per bit, and resistance to side-channel attacks.

Three properties distinguish lightweight ciphers from their conventional counterparts:

Smaller block and key sizes reduce the memory needed to hold intermediate cryptographic state. Simplified round functions cut the number of CPU cycles required per encryption operation. Reduced code size means the compiled binary fits within the limited flash storage typical of microcontrollers, sometimes under 2 KB.

// Comparing memory footprint: AES-128 vs ASCON (illustrative)
struct cipher_footprint {
    const char *name;
    int ram_bytes;
    int rom_bytes;
    int cycles_per_byte;
};

struct cipher_footprint aes128  = {"AES-128", 512, 4096, 180};
struct cipher_footprint ascon128 = {"ASCON-128", 128, 2048, 90};

These are representative figures rather than benchmarks from a specific chip, but they illustrate the general pattern: lightweight ciphers aim to do more with meaningfully less.

ASCON: The Current NIST Standard

In February 2023, NIST selected the ASCON family as the winner of its Lightweight Cryptography competition, and in 2025 it was formally published as NIST SP 800-232. ASCON is an authenticated encryption with associated data (AEAD) construction, meaning it provides both confidentiality and integrity checking in a single pass rather than requiring separate encryption and MAC operations.

#include <ascon.h>

int encrypt_sensor_reading(uint8_t *plaintext, size_t pt_len,
                             uint8_t *key, uint8_t *nonce,
                             uint8_t *ciphertext, uint8_t *tag) {
    ascon_aead_ctx_t ctx;
    ascon_aead128_init(&ctx, key, nonce);
    ascon_aead128_encrypt(&ctx, ciphertext, plaintext, pt_len);
    ascon_aead128_finalize(&ctx, tag);
    return 0;
}

ASCON's sponge-based construction is what allows it to run in such a small footprint. Unlike AES, which relies on lookup tables that consume both memory and are a known vector for cache-timing side-channel attacks, ASCON's permutation-based design avoids table lookups entirely, making it inherently more resistant to certain timing attacks on constrained hardware.

PRESENT and SPECK: Earlier Lightweight Approaches

Before ASCON became the standardized answer, several other lightweight ciphers saw adoption in specific contexts. PRESENT, developed in 2007, is an ultra-lightweight block cipher designed for RFID tags and similarly constrained applications, using a 64-bit block size and either 80-bit or 128-bit keys.

SPECK, published by the NSA in 2013, takes a different approach, favoring simple addition, rotation, and XOR (ARX) operations that map efficiently onto both software and hardware implementations.

// SPECK round function (simplified, 32-bit words)
void speck_round(uint32_t *x, uint32_t *y, uint32_t k) {
    *x = (*x >> 8) | (*x << 24);  // rotate right 8
    *x += *y;
    *x ^= k;
    *y = (*y << 3) | (*y >> 29);  // rotate left 3
    *y ^= *x;
}

SPECK's reliance on simple arithmetic rather than substitution tables made it attractive for software-only implementations on devices without dedicated cryptographic hardware. It drew criticism, however, over its NSA origin and the absence of public design rationale for some parameter choices, which slowed formal standardization despite its practical performance advantages.

Elliptic Curve Cryptography for Key Exchange

Symmetric ciphers like ASCON and SPECK handle bulk data encryption efficiently, but IoT devices still need a way to establish shared keys in the first place. This is where the size advantage of elliptic curve cryptography (ECC) over RSA becomes significant: a 256-bit ECC key offers security roughly comparable to a 3072-bit RSA key, at a fraction of the computational cost.

// ECDH key exchange using Curve25519 (via a lightweight library)
#include <monocypher.h>

void generate_shared_secret(uint8_t *my_private_key,
                              uint8_t *their_public_key,
                              uint8_t *shared_secret) {
    crypto_x25519(shared_secret, my_private_key, their_public_key);
}

Curve25519 has become a common choice for constrained devices because its implementation avoids many of the timing-attack pitfalls that plague naive elliptic curve implementations, and reference code exists that compiles to just a few kilobytes of flash.

Protocol-Level Considerations Beyond the Cipher

Choosing an efficient cipher solves only part of the problem. The communication protocol wrapping that cipher matters just as much for real-world deployments. DTLS (Datagram Transport Layer Security), the UDP-based counterpart to TLS, is commonly paired with CoAP (Constrained Application Protocol) in IoT deployments, but full DTLS handshakes can still be too heavy for the most constrained devices due to certificate exchange overhead.

This has driven interest in pre-shared key (PSK) modes, which skip certificate-based authentication entirely in favor of keys provisioned during manufacturing.

// DTLS PSK configuration example (mbedTLS)
mbedtls_ssl_conf_psk(&conf,
                      psk, psk_len,
                      (const unsigned char *)psk_identity,
                      strlen(psk_identity));

PSK mode trades the flexibility of certificate-based trust for a dramatically lighter handshake, which matters when a device wakes from deep sleep, needs to transmit a reading, and must return to sleep within a strict energy budget.

Matching Protocols to Threat Models

Not every IoT deployment needs the same security posture. A soil moisture sensor reporting non-sensitive agricultural data has a different risk profile than a medical device transmitting patient vitals or an industrial controller managing physical machinery. Lightweight cryptography is not a shortcut around security; it's a recalibration of the trade-off between protection and resource cost for a given threat model.

Devices handling sensitive data still warrant the strongest lightweight cipher available, such as ASCON-128a for higher throughput needs, combined with proper key rotation and secure boot to prevent firmware tampering. Lower-stakes telemetry devices may reasonably use a smaller security margin if it meaningfully extends battery life across a large deployed fleet, provided the failure mode of a compromise remains low-consequence.

The honest limitation worth stating plainly: lightweight ciphers generally offer smaller security margins than their full-strength counterparts, and some, like SPECK, faced pushback during standardization over trust and transparency concerns. Engineers should treat cipher selection as one part of a layered security architecture, not a single point of defense, and should stay current with NIST guidance as SP 800-232 implementations mature across hardware platforms.

Bringing It Together

The shift toward lightweight cryptography reflects a broader recognition that security has to fit the hardware it protects. ASCON's selection as the NIST standard gives engineers a well-vetted default for new designs, while ECC-based key exchange and PSK-mode DTLS address the handshake overhead that often gets overlooked when teams focus only on the encryption algorithm itself. For teams building constrained IoT products today, the practical starting point is ASCON for authenticated encryption, Curve25519 for key agreement, and a protocol stack — CoAP over DTLS with PSK where certificate overhead isn't justified — sized to the device's actual power and memory budget rather than borrowed wholesale from enterprise networking.

Before finalizing a cryptographic approach for a new IoT product, benchmark candidate ciphers directly on your target hardware rather than relying on published figures alone, since real-world performance varies significantly across microcontroller architectures and compiler optimizations.