AEAD (Authenticated Encryption with Associated Data)

Authenticated Encryption with Associated Data (AEAD) ciphers provide both confidentiality and authenticity in a single cryptographic operation, along with the ability to authenticate additional associated data without encryption.

Why AEAD?

AEAD algorithms solve the “encrypt-then-MAC” vs “MAC-then-encrypt” dilemma by providing:

  • Confidentiality: Data encryption
  • Authenticity: Message authentication
  • Integrity: Tamper detection
  • Associated Data: Authentication of unencrypted metadata
  • Performance: Single operation instead of separate encrypt + MAC steps
  • Safety: Prevents implementation errors from manual composition

Available AEAD Algorithms

ChaCha20-Poly1305

High-performance stream cipher with polynomial authenticator.

  • Key Size: 256 bits (32 bytes)
  • Nonce Size: 96 bits (12 bytes)
  • Tag Size: 128 bits (16 bytes)
  • Security Level: 256-bit classical, 128-bit post-quantum
  • Use Cases: TLS 1.3, VPN protocols, mobile applications

AES-256-GCM

Advanced Encryption Standard in Galois/Counter Mode.

  • Key Size: 256 bits (32 bytes)
  • Nonce Size: 96 bits (12 bytes) recommended
  • Tag Size: 128 bits (16 bytes)
  • Security Level: 256-bit classical, 128-bit post-quantum
  • Use Cases: Hardware acceleration, global standard, enterprise

Deoxys-II

CAESAR competition finalist with nonce-misuse resistance.

  • Key Size: 256 bits (32 bytes)
  • Nonce Size: 128 bits (16 bytes)
  • Tag Size: 128 bits (16 bytes)
  • Security Level: 256-bit classical, 128-bit post-quantum
  • Use Cases: High-security environments, nonce-reuse scenarios

Ascon-128

NIST Lightweight Cryptography standard for constrained environments.

  • Key Size: 128 bits (16 bytes)
  • Nonce Size: 128 bits (16 bytes)
  • Tag Size: 128 bits (16 bytes)
  • Security Level: 128-bit classical, 64-bit post-quantum
  • Use Cases: IoT devices, embedded systems, sensor networks

Algorithm Comparison

Algorithm Key Size Nonce Size Performance Special Features
ChaCha20-Poly1305 256 bits 96 bits Very High Software optimized, TLS 1.3
AES-256-GCM 256 bits 96 bits High* Hardware acceleration, standard
Deoxys-II 256 bits 128 bits High Nonce-misuse resistant
Ascon-128 128 bits 128 bits Moderate Ultra-lightweight, NIST standard

*With AES-NI hardware support

AEAD Performance Characteristics

Throughput (MB/s on modern CPU)

  • ChaCha20-Poly1305: ~1,200 MB/s (software optimized, DJB design)
  • AES-256-GCM: ~2,500 MB/s (with AES-NI hardware acceleration)
  • Deoxys-II: ~800 MB/s (nonce-misuse resistant variant)
  • Ascon-128: ~50 MB/s (lightweight, area/energy optimized)

Memory Requirements

  • ChaCha20-Poly1305: ~200 bytes state (efficient software implementation)
  • AES-256-GCM: ~300 bytes state + lookup tables (hardware optimized)
  • Deoxys-II: ~400 bytes state (additional security features)
  • Ascon-128: ~40 bytes state (ultra-lightweight IoT focus)

Security Properties

Classical Security Levels

  • 256-bit algorithms: Equivalent to ~128-bit symmetric security
  • 128-bit algorithms: Equivalent to ~64-bit symmetric security

Post-Quantum Security

All AEAD algorithms maintain approximately half their classical security against quantum attacks (Grover’s algorithm):

  • 256-bit keys: ~128-bit post-quantum security
  • 128-bit keys: ~64-bit post-quantum security

Nonce Requirements

  • ChaCha20-Poly1305: Never reuse nonces with same key
  • AES-256-GCM: Never reuse nonces with same key
  • Deoxys-II: Nonce-misuse resistant (safer with reuse)
  • Ascon-128: Never reuse nonces with same key

Selection Guide

For General Applications

High Performance + Hardware → AES-256-GCM
High Performance + Software → ChaCha20-Poly1305
High Security Requirements → Deoxys-II

For Specific Use Cases

Web Applications & TLS

  • Primary: ChaCha20-Poly1305
  • Alternative: AES-256-GCM
  • Reason: TLS 1.3 standard support

Enterprise & Data Centers

  • Primary: AES-256-GCM
  • Alternative: ChaCha20-Poly1305
  • Reason: Hardware acceleration, established standard

IoT & Embedded Systems

  • Primary: Ascon-128
  • Alternative: ChaCha20-Poly1305 (if sufficient resources)
  • Reason: Lightweight, energy efficient

High-Security Environments

  • Primary: Deoxys-II
  • Alternative: AES-256-GCM with careful nonce management
  • Reason: Nonce-misuse resistance

Mobile Applications

  • Primary: ChaCha20-Poly1305
  • Alternative: AES-256-GCM (if device has AES-NI)
  • Reason: Battery efficiency, software performance

Implementation Best Practices

Nonce Management

# Good: Random nonces (if sufficient entropy)
nonce = os.urandom(12)  # 96 bits for ChaCha20-Poly1305/AES-GCM

# Good: Counter-based nonces  
class NonceManager:
    def __init__(self):
        self.counter = 0
        self.prefix = os.urandom(8)
    
    def get_nonce(self):
        nonce = self.prefix + self.counter.to_bytes(4, 'big')
        self.counter += 1
        return nonce

Key Derivation

# Always derive encryption keys from master keys
from metamui_crypto import HKDF

def derive_aead_key(master_key, context):
    return HKDF(
        master_key,
        salt=b"aead-encryption-v1", 
        info=context.encode(),
        length=32  # 256 bits
    )

Associated Data Usage

# Include context information in AAD
associated_data = json.dumps({
    "user_id": user_id,
    "timestamp": timestamp,
    "message_type": "secure_message"
}, separators=(',', ':')).encode()

ciphertext, tag = cipher.encrypt(
    plaintext, 
    nonce, 
    associated_data=associated_data
)

Common Pitfalls

❌ Nonce Reuse

# Never do this!
nonce = b'0' * 12
ciphertext1, tag1 = cipher.encrypt(message1, nonce)
ciphertext2, tag2 = cipher.encrypt(message2, nonce)  # BROKEN!

❌ Key Reuse Across Algorithms

# Don't use same key for different algorithms
# key = os.urandom(32)
# chacha_cipher = ChaCha20Poly1305(key)
# aes_cipher = AES256GCM(key)  # WRONG!

❌ Missing Associated Data Validation

# Always verify AAD hasn't changed
try:
    plaintext = cipher.decrypt(ciphertext, tag, nonce, associated_data)
except ValueError:
    # Authentication failed - AAD or ciphertext was modified
    raise AuthenticationError("Message authentication failed")

Migration Strategies

From Encrypt-then-MAC

# Old approach
# ciphertext = aes_cbc.encrypt(plaintext)
# mac = hmac.new(mac_key, ciphertext).digest()

# New AEAD approach  
ciphertext, tag = aead_cipher.encrypt(plaintext, nonce, associated_data)

Algorithm Upgrades

  1. AES-CBC-HMAC → AES-GCM: Direct upgrade path
  2. Legacy → ChaCha20-Poly1305: Modern alternative
  3. Resource-constrained → Ascon: Lightweight upgrade

Standards Compliance

NIST Standards

  • AES-GCM: NIST SP 800-38D
  • ChaCha20-Poly1305: RFC 8439, TLS 1.3
  • Ascon: NIST Lightweight Cryptography

Industry Adoption

  • TLS 1.3: ChaCha20-Poly1305, AES-GCM
  • IPsec: AES-GCM, ChaCha20-Poly1305
  • SSH: ChaCha20-Poly1305, AES-GCM
  • Signal Protocol: ChaCha20-Poly1305

MetaMUI AEAD Recommendations

For algorithm selection guidance and performance analysis, see: