ISO/IEC 29192-5: Lightweight Cryptography — Part 5: Hash Functions

Cryptographic hash functions are fundamental building blocks for data integrity, digital signatures, random-number generation, and many authentication protocols. On constrained devices, conventional hash functions such as SHA-256 require significant computational resources and memory. ISO/IEC 29192-5 standardises lightweight hash functions — based primarily on the sponge construction — that achieve the same security properties with drastically reduced hardware footprints, making them suitable for RFID tags, sensor nodes, and embedded controllers.

The sponge construction used by all algorithms in 29192-5 absorbs input data and squeezes output through a fixed-width internal permutation. This unified structure means the same core hardware can serve both hashing and (with minor modifications) authenticated encryption — a significant design reuse advantage.

PHOTON — A Sponge-Based Lightweight Hash Family

Algorithm Family Overview

PHOTON is a family of five hash functions with output sizes ranging from 80 to 256 bits: PHOTON-80/20/16, PHOTON-128/16/16, PHOTON-160/36/36, PHOTON-224/32/32, and PHOTON-256/32/32. Each uses an internal AES-like permutation (Pₙ) with a 4×4 or 5×5 state of bytes, operating for 12 rounds. The permutation employs SubBytes (using a lightweight 4-bit S-box), ShiftRows, MixColumns, and AddConstants. The smallest member, PHOTON-80/20/16, requires only about 1 700 GE in hardware while providing 80-bit preimage resistance and 40-bit collision resistance for short messages.

PHOTON’s collision resistance is only 40–56 bits for its smallest variants, which is inadequate for applications requiring strong collision guarantees (e.g., certificate transparency logs). For most IoT integrity-checking use cases (firmware hash, message authentication), preimage resistance is the more relevant property, and PHOTON delivers 80–128 bits there.

SPONGENT — Parallelisable Lightweight Hashing

Design and Performance

SPONGENT uses a similar sponge framework but with a smaller internal permutation based on a PRESENT-type S-box, making it even more compact than PHOTON at equivalent security levels. SPONGENT-88/80/8 provides 80-bit preimage resistance in approximately 1 050 GE — one of the smallest hash implementations ever standardised. The trade-off is lower throughput: SPONGENT produces only 1 or 4 bits per clock cycle, versus PHOTON’s 16–32 bits per cycle.

Algorithm	Output (bits)	Preimage Security	Collision Security	Gate Count (GE)	Throughput (bits/cycle)
PHOTON-80/20/16	80	80	40	1 700	16
PHOTON-128/16/16	128	128	64	2 100	16
PHOTON-256/32/32	256	256	128	4 600	32
SPONGENT-88/80/8	88	80	40	1 050	1
SPONGENT-128/128/8	128	128	64	1 760	1
SHA-256 (compact)	256	256	128	~5 000	32+

Engineering Design Insights

Hash Function Selection Criteria

The standard guides implementers through a selection process based on four parameters: required preimage security level, maximum message length, available gate budget, and throughput requirement. For RFID tags authenticating 16-byte challenges, PHOTON-80/20/16 is optimal. For sensor networks hashing multi-kilobyte data logs, the throughput of PHOTON-256/32/32 may justify its larger area. SPONGENT excels when absolute minimum area is the overriding concern.

Integration with Other 29192 Parts

The hash functions of Part 5 are designed to pair naturally with the digital signature schemes of Part 4 (hash-then-sign paradigm) and the key-derivation use cases implied by Parts 2 and 3. A notable application is the Hash-Based Message Authentication Code (HMAC) construction, which can be built on top of any 29192-5 hash function to provide message authentication — though Part 6 also defines dedicated lightweight MAC algorithms for this purpose.

When implementing a firmware-over-the-air (FOTA) update mechanism for IoT devices, using PHOTON-256 for integrity verification of signed update images provides a balanced trade-off between security and computational overhead. The hash computation for a 100 kB firmware image takes under 200 ms on a typical ARM Cortex-M0 at 48 MHz.

Do not truncate the output of a lightweight hash function to increase throughput without understanding the impact on collision resistance. For instance, truncating PHOTON-80 to 40 bits halves the preimage resistance. Always use the variant whose specified output size matches your security requirements.

Frequently Asked Questions

Q1: Can I use PHOTON or SPONGENT in place of SHA-256 for a blockchain or distributed ledger node?
For lightweight IoT blockchain nodes (e.g., IOTA or similar DAG-based ledgers), the smaller hash functions can work. For Bitcoin/Ethereum-style proof-of-work, SHA-256 remains the standard. PHOTON-256 provides similar security to SHA-256 with smaller hardware cost and can be used for transaction hashing on embedded nodes.

Q2: Are these hash functions suitable for password hashing and storage?
No — lightweight hash functions are designed for speed and small area, which makes them unsuitable for password storage where slow, memory-hard functions (e.g., Argon2) are required to resist brute-force attacks.

Q3: How do I handle the rate and capacity parameters when implementing the sponge?
The standard defines these explicitly for each variant. The rate (r) determines throughput, and the capacity (c) determines security. A common rule: security level = c/2 for collision resistance and c for preimage resistance.

Q4: What is the maximum message length supported by PHOTON?
The standard imposes no explicit limit, but the sponge construction can absorb up to 2^(c/2) blocks before the security guarantees degrade. For PHOTON-256/32/32 with c = 256, this limit is 2¹²⁸ blocks — effectively unbounded for any real-world IoT application.