24  Encryption Tools & Calculators

Interactive tool efficiency can be tracked as successful outcomes per minute:

\[ \eta = \frac{N_{\text{successful-attempts}}}{T_{\text{minutes}}} \]

Worked example: If users complete 48 successful interactions in 30 minutes, efficiency is \(48/30=1.6\) successful interactions/minute. This metric helps compare alternative game or wizard designs objectively.

24.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Calculate Encryption Strength: Evaluate brute-force resistance using interactive key-space analysis tools
  • Compare Algorithms: Analyze performance and security tradeoffs between symmetric and asymmetric encryption
  • Simulate Key Exchange: Demonstrate Diffie-Hellman and TLS handshakes through interactive visualizations
  • Select Appropriate Encryption: Choose encryption algorithms based on specific IoT constraints and use cases
In 60 Seconds

Hands-on interactive cryptography tools let learners encrypt, decrypt, and hash data directly in the browser, building concrete understanding of how cryptographic algorithms transform inputs and outputs.

Cryptography for IoT is the science of keeping sensor data and device commands secret and tamper-proof. Think of it as the digital equivalent of secret codes, locked boxes, and wax seals. Even if someone intercepts your IoT data traveling through the air, cryptography ensures they cannot read or alter it without the proper keys.

These interactive tools help you build intuition about cryptographic concepts. Experiment with different key sizes, algorithms, and attack scenarios to understand why security recommendations exist.

“This chapter has interactive tools where you can experiment!” Lila the LED said, flashing with excitement. “Type in a key size, pick an algorithm, and see how long it would take to break it. Try 128-bit AES versus 256-bit AES and watch the difference – it is mind-blowing!”

Sammy the Sensor tried the encryption strength calculator. “A 128-bit key has 340,282,366,920,938,463,463,374,607,431,768,211,456 possible combinations. Even a supercomputer trying a trillion keys per second would need longer than the age of the universe to try them all. But a 56-bit DES key? A supercomputer could crack it in under a day. Key size REALLY matters!”

“The key exchange simulator is my favorite,” Max the Microcontroller said. “It shows how two devices that have never met can agree on a shared secret over a public network. It is like two people shouting numbers across a crowded room, but using mathematical magic so that no one listening can figure out the final secret. That is the Diffie-Hellman key exchange!”

“These tools help you build intuition,” Bella the Battery encouraged. “Instead of just memorizing that AES-256 is strong, you can SEE why by playing with the numbers. Experiment with different settings and you will develop a gut feeling for what is secure and what is not. That instinct will serve you well throughout your security career!”

24.2 Encryption Strength Calculator

Understand how key length and algorithm choice affect security against brute-force attacks and emerging quantum threats.

Understanding the Results:

  • Brute Force Time: How long to try every possible key at the selected attacker’s speed
  • Quantum Attack: For symmetric ciphers, Grover’s algorithm halves effective key length. For RSA/ECC, Shor’s algorithm breaks them entirely by solving the underlying mathematical problem (factoring or discrete logarithm).
  • Security Level: Based on NIST SP 800-131A and industry recommendations

Real-World Context:

  • Universe age: ~13.8 billion years
  • Sun’s remaining lifespan: ~5 billion years
  • Age of Earth: ~4.5 billion years

If brute-force time exceeds these timescales, encryption is effectively unbreakable by classical computers.

24.3 Encryption Comparison Demo

Compare symmetric (AES) and asymmetric (RSA) encryption side-by-side.

24.4 Algorithm Selection Guide

Based on your IoT requirements, select the most appropriate encryption approach:

24.5 Hash Function Demonstrator

See how cryptographic hash functions work with the avalanche effect – a tiny input change produces a completely different output:

24.6 IoT Encryption Performance Estimator

Estimate encryption performance on your target hardware:

24.7 Knowledge Check

You’re building a LoRaWAN sensor that sends 32-byte telemetry every 15 minutes. The maximum payload is 51 bytes. Which encryption approach is most appropriate?

Options:

    1. RSA-2048 encryption for maximum security
    1. AES-128-GCM for data, Ed25519 for authentication
    1. No encryption – LoRaWAN has built-in security
    1. AES-256-GCM with SHA-512 HMAC

Correct: B

AES-128-GCM provides strong symmetric encryption with a 16-byte authentication tag (12-byte nonce + 16-byte tag = 28 bytes overhead, leaving 23 bytes for data per message – tight but feasible with compression). Ed25519 produces 64-byte signatures, which exceed the single-message payload but can authenticate batches or be sent separately. RSA-2048 signatures (256 bytes) far exceed the 51-byte payload limit. While LoRaWAN includes AES-128 application-layer encryption, additional end-to-end encryption is recommended for sensitive data since the network server can decrypt LoRaWAN’s built-in encryption.

Scenario: Utility company deploys smart meters that report power consumption every 15 minutes over cellular (NB-IoT).

Given:

  • Fleet size: 10,000 meters
  • Reporting interval: 15 minutes (96 messages/day per meter)
  • Network: NB-IoT (LTE Cat-NB1), 250 kbps downlink
  • MCU: ARM Cortex-M4 @ 64 MHz
  • Battery: 2x D-cell (19,000 mAh @ 3.6 V = 246 kJ)
  • Target lifetime: 10 years
  • Data payload: 32 bytes (meter ID, timestamp, kWh reading, voltage, current)

Security Requirement: Utility needs data authenticity (prevent false billing) and integrity (detect tampering).

Option Analysis:

Option 1: RSA-2048 Signatures

Performance on ARM Cortex-M4 @ 64 MHz:

  • Sign operation: 300 ms @ 40 mA
  • Energy per signature: 0.040 A x 3.6 V x 0.3 s = 43.2 mJ

Annual energy:

  • Signatures: 96/day x 365 days x 43.2 mJ = 1,514 J
  • Transmission: 96/day x 365 days x 100 mJ = 3,504 J (NB-IoT TX)
  • Total crypto: 1,514 J (30% of communication energy)

10-year energy: 15,140 J Battery capacity: 246,000 J Crypto overhead: 15,140 / 246,000 = 6.2% – Acceptable

Signature size: 256 bytes Total message: 32 + 256 = 288 bytes Transmission time: 288 x 8 / 250,000 = 9.2 ms

Option 2: Ed25519 Signatures

Performance on ARM Cortex-M4 @ 64 MHz:

  • Sign operation: 12 ms @ 20 mA
  • Energy per signature: 0.020 A x 3.6 V x 0.012 s = 0.864 mJ

Annual energy:

  • Signatures: 96/day x 365 days x 0.864 mJ = 30.3 J
  • Transmission: 96/day x 365 days x 65 mJ = 2,277 J (smaller packet)
  • Total crypto: 30.3 J (1.3% of communication energy)

10-year energy: 303 J Battery capacity: 246,000 J Crypto overhead: 303 / 246,000 = 0.12% – Excellent

Signature size: 64 bytes Total message: 32 + 64 = 96 bytes Transmission time: 96 x 8 / 250,000 = 3.1 ms (3x faster than RSA)

Option 3: HMAC-SHA256 (Symmetric Authentication)

Performance on ARM Cortex-M4 @ 64 MHz:

  • HMAC operation: 0.5 ms @ 15 mA
  • Energy per HMAC: 0.015 A x 3.6 V x 0.0005 s = 0.027 mJ

Annual energy:

  • HMACs: 96/day x 365 days x 0.027 mJ = 0.95 J
  • Transmission: 96/day x 365 days x 60 mJ = 2,102 J (smallest packet)
  • Total crypto: 0.95 J (0.045% of communication energy)

10-year energy: 9.5 J Battery capacity: 246,000 J Crypto overhead: 9.5 / 246,000 = 0.004% – Negligible

Authentication tag size: 32 bytes Total message: 32 + 32 = 64 bytes Transmission time: 64 x 8 / 250,000 = 2.0 ms (fastest)

Comparison:

Metric RSA-2048 Ed25519 HMAC-SHA256
Energy per operation 43.2 mJ 0.864 mJ 0.027 mJ
10-year crypto energy 15,140 J 303 J 9.5 J
Signature/tag size 256 bytes 64 bytes 32 bytes
Total message size 288 bytes 96 bytes 64 bytes
Transmission time 9.2 ms 3.1 ms 2.0 ms
Non-repudiation Yes Yes No
Key management Complex (PKI) Medium (PKI) Simple (pre-shared)

Decision:

The utility chooses Ed25519 signatures because:

  1. Non-repudiation: Legal requirement – meters must prove readings came from a specific device
  2. Energy: 50x less energy than RSA, negligible battery impact
  3. Bandwidth: 3x smaller than RSA, reduces NB-IoT costs
  4. Security: 128-bit security equivalent, meets NIST standards

HMAC is rejected because it lacks non-repudiation (the utility cannot prove to a court that a specific meter generated a reading, since both the meter and the server share the same key).

Fleet-Wide Impact:

Metric RSA-2048 Ed25519 Savings
Total fleet energy (10 years) 151 MJ 3 MJ 148 MJ saved
Cellular data usage (10 years) 100 GB 33 GB 67 GB saved
Cellular cost ($0.10/MB) $10,000 $3,300 $6,700 saved

ROI: Switching from RSA to Ed25519 saves $6,700 in cellular fees alone over 10 years for this 10,000-meter deployment. Implementation cost for Ed25519 library: ~$5,000 one-time. Pays for itself in the first 2 years.

Use the calculator tools to evaluate these criteria:

Step 1: Assess Power Budget

Device Type Daily Energy Budget Crypto Allocation Suitable Algorithms
Coin cell (CR2032) ~20 mJ <1 mJ/day AES-128-GCM with HW accel, ChaCha20
AA battery ~200 mJ <10 mJ/day AES-GCM, Ed25519
Solar + supercap Variable <50 mJ/operation AES-GCM, ECDH
Wall-powered Unlimited Any AES-256-GCM, RSA-2048 acceptable

Use the Performance Estimator tool to calculate:

If AES-128-GCM takes 0.5 ms @ 30 mA on your MCU:
Energy per operation = 0.030 A x 3.3 V x 0.0005 s = 0.05 mJ

Daily budget: 200 mJ
Max encryptions: 200 / 0.05 = 4,000/day

Step 2: Evaluate Bandwidth Constraints

Network Type Max Payload Encryption Overhead Algorithm Choice
LoRaWAN SF10 51 bytes <20 bytes AES-GCM (28-byte overhead), truncated HMAC
NB-IoT 1,600 bytes <100 bytes Any modern algorithm
Sigfox 12 bytes <8 bytes Truncated HMAC-SHA256 (4-8 bytes); full crypto impractical
Wi-Fi 1,500 bytes Any Any algorithm

Use the Encryption Strength Calculator to verify:

LoRaWAN example:
- Payload: 32 bytes sensor data
- AES-GCM overhead: 12 (nonce) + 16 (tag) = 28 bytes
- Total: 32 + 28 = 60 bytes
- Verdict: Exceeds 51-byte limit at SF10

Alternative:
- Use AES-GCM with truncated 8-byte tag (reduced but acceptable security)
- Total: 32 + 12 + 8 = 52 bytes -- still tight
- Or: Use LoRaWAN's built-in AES-128 + truncated HMAC for extra integrity

Step 3: Security Requirements vs Performance Trade-offs

Use this decision matrix:

Requirement Symmetric Asymmetric Hybrid
Confidentiality only AES-128-GCM Too slow for bulk data Not needed
Authenticity + integrity HMAC (no non-repudiation) Ed25519 Ed25519 for auth + AES for data
Key exchange problem Cannot solve alone ECDH ECDH once, then AES
Legal non-repudiation Cannot provide Digital signature (Ed25519) Sign hash of encrypted data

Example Selection Process:

Medical device (insulin pump):

  1. Power budget: 50 mAh battery, 1-week lifetime -> 300 mJ/day available
  2. Communication: Bluetooth LE, 1 message/minute
  3. Security need: Authenticity (prevent unauthorized dosing commands)

Analysis with calculator tools:

Option 1: AES-128-GCM + HMAC
- Energy: 0.05 mJ/message x 1,440 messages/day = 72 mJ/day
- Budget check: 72 / 300 = 24% -- Acceptable
- Non-repudiation: No (HMAC uses shared key)

Option 2: AES-128-GCM + Ed25519 signatures
- Energy: 0.05 (AES) + 0.4 (Ed25519) = 0.45 mJ/message
- Total: 0.45 x 1,440 = 648 mJ/day
- Budget check: 648 / 300 = 216% -- Exceeds budget!

Option 3: Optimize -- Sign every 10th message
- Ed25519 signatures: 144/day x 0.4 mJ = 57.6 mJ
- AES-GCM: 1,440/day x 0.05 mJ = 72 mJ
- Total: 129.6 mJ/day
- Budget check: 129.6 / 300 = 43% -- Acceptable

Decision: Use AES-GCM for all messages (confidentiality + integrity), plus Ed25519 signature every 10th message for non-repudiation. Intermediate messages authenticated by the GCM authentication tag.

Common Mistake: Ignoring Handshake Energy Cost

The Mistake: Developers optimize per-message encryption energy but forget that TLS/DTLS handshakes consume 10-100x more energy than individual messages.

The Problem:

TLS 1.3 handshake involves multiple round trips:

  • Client Hello (send)
  • Server Hello, Certificate, Key Exchange (receive)
  • Client Key Exchange, Finished (send)
  • Server Finished (receive)

Total handshake energy (ESP32, cellular network):

  • ECDHE key exchange: 8 mJ
  • Certificate verification: 12 mJ
  • Network I/O (4 round trips): 400 mJ (cellular radio on-time)
  • Total: ~420 mJ per handshake

Per-message encryption (AES-GCM):

  • Encryption: 0.05 mJ
  • Network I/O: 100 mJ
  • Total: ~100 mJ per message

Energy Calculation Error:

Developer thinks:
"I send 96 messages/day, each costs 0.05 mJ to encrypt"
Daily crypto energy = 96 x 0.05 = 4.8 mJ -- looks great!

Reality with new TLS handshake per message:
"I send 96 messages/day, each requires a new TLS handshake"
Daily energy = 96 x (420 + 100) = 49,920 mJ
= ~50 J/day
= ~18,250 J/year

Battery (2x AA = 10 Wh = 36 kJ)
Lifetime = 36,000 / 18,250 = 1.97 years
Target was 5 years!

The Fix: TLS Session Resumption

// WRONG: New handshake every message
void send_message_wrong() {
    WiFiClientSecure client;
    client.connect(server, 443);  // Full handshake
    client.write(data, len);
    client.stop();  // Closes connection
}

// CORRECT: Persistent connection with session resumption
WiFiClientSecure client;

void setup() {
    client.connect(server, 443);  // Full handshake ONCE
}

void send_message_correct() {
    if (!client.connected()) {
        client.connect(server, 443);  // Session resumption (fast)
    }
    client.write(data, len);
    // Keep connection open for next message
}

Energy Comparison:

Approach Handshakes/Day Handshake Energy Messages/Day Message Energy Total
New connection/message 96 40,320 mJ 96 9,600 mJ 49,920 mJ
Persistent connection 1 420 mJ 96 9,600 mJ 10,020 mJ
Session resumption (1h timeout) 24 1,200 mJ 96 9,600 mJ 10,800 mJ

Savings: Persistent connection reduces daily energy from 50 J to 10 J – a 5x improvement with no security compromise.

Implementation Pattern:

// Keep TLS connection alive up to 1 hour
unsigned long last_message_time = 0;
const unsigned long KEEPALIVE_TIMEOUT = 3600000;  // 1 hour

void send_data(const uint8_t *data, size_t len) {
    unsigned long now = millis();

    // Close connection if inactive for >1 hour
    if (now - last_message_time > KEEPALIVE_TIMEOUT) {
        client.stop();
    }

    // Reconnect if needed (uses session resumption if available)
    if (!client.connected()) {
        client.connect(server, 443);
        // Session resumption: ~50 mJ vs full handshake: ~420 mJ
    }

    client.write(data, len);
    last_message_time = now;
}

Key Insight: When using the interactive tools, always include handshake energy in your total calculation. For cellular IoT devices, handshake energy often dominates the crypto overhead.

Use this formula:

Total daily energy = (messages_per_day x message_energy)
                   + (handshakes_per_day x handshake_energy)

Where:
  handshakes_per_day = min(messages_per_day, 24)  // With 1-hour keep-alive
Concept Relationships

These tools help you explore trade-offs in IoT cryptography:

Tool Tests Understanding Of Informs Decisions About Common Insight
Encryption Strength Calculator Key size vs attack time Minimum acceptable key length 128-bit = billions of years, 56-bit = hours on supercomputer
Encryption Comparison Symmetric vs asymmetric speed When to use each type AES: 100-1000x faster than RSA
Algorithm Selection Guide Device constraints Hardware-appropriate crypto Battery sensors need lightweight crypto, not RSA
Hash Demonstrator Avalanche effect Why small changes matter One bit flip = completely different hash
Performance Estimator Energy per operation Battery lifetime impact Crypto energy is small; radio transmission dominates

Use Pattern: Start with the Strength Calculator (understand keyspace) -> Compare Algorithms (speed/energy) -> Selection Guide (apply to your device) -> Verify with Performance Estimator.

24.8 See Also

Theory:

Hands-On:

Implementation Guides:

Real-World Examples:

24.9 Summary

These interactive tools help you:

  • Evaluate encryption strength against classical and quantum attack scenarios
  • Compare algorithms for performance, security, and energy tradeoffs
  • Estimate battery impact of cryptographic operations on specific microcontrollers
  • Select appropriate encryption based on device, network, and compliance constraints
  • Avoid common pitfalls like ignoring handshake energy costs

Experiment with different configurations to develop intuition about IoT cryptography. The key takeaway: security decisions are always trade-offs between protection level, performance, energy, bandwidth, and cost.

::

Key Concepts

  • Plaintext: The original, human-readable data before encryption is applied.
  • Ciphertext: The encrypted, unreadable output produced by applying a cipher with a key to plaintext.
  • Key Length: The size of a cryptographic key in bits; longer keys provide more security but require more computation (e.g., AES-128 vs AES-256).
  • Block Cipher: An encryption algorithm that operates on fixed-size blocks of data (e.g., AES uses 128-bit blocks), requiring a mode of operation for data longer than one block.
  • Stream Cipher: An encryption algorithm that encrypts data one bit or byte at a time, generating a keystream XORed with plaintext.
  • Hex Encoding: Representing binary data as hexadecimal digits (0–9, a–f) for display; not encryption — purely a format for readable representation of binary values.

::

24.10 What’s Next

If you want to… Read this
Deepen understanding of symmetric algorithms Symmetric Encryption
Explore asymmetric and ECC algorithms ECC & Asymmetric Crypto
Try structured labs with exercises Encryption Labs
Play cryptography challenge games Encryption Games

Continue to Encryption Labs for hands-on Wokwi simulations and practice exercises implementing cryptographic operations on ESP32 microcontrollers.