# PHOTON-Beetle Authenticated Encryption

PHOTON-Beetle is an authenticated encryption and hash family, that uses a
sponge-based mode Beetle^{[1]} with the P_{256} (used for the PHOTON hash^{[2]}) being the underlying permutation.
We denote this permutation by PHOTON_{256}. Based on the functionalities, PHOTON-Beetle can be classified into
two categories: a family of authenticated encryptions, dubbed as PHOTON-Beetle-AEAD and a family of hash
functions, dubbed as PHOTON-Beetle-Hash. Both these families are parameterized by r, the rate of message
absorption. Overall, PHOTON-Beetle-AEAD is proposed with two versions (one is the faster version with r = 128 and the other is the lighter version with r =32) and PHOTON-Beetle-Hash with one version with r = 32.

## Features

1. ** High Security Bound: ** PHOTON-Beetle achieves high security bound. This in
turn makes the mode lightweight by minimizing the state size. In fact we use only a 256-bit permutation in our design.
We follow the approach of boosting the security by using a combined feedback technique over the traditional duplex
sponge. The AE security level increases from c/2 to c - log r, where c is the capacity and r is the rate of absorption. The table below provides a comparative Study on the State size and Security Trade-off: for all the constructions, we have assumed that n/2 bits message is processed per primitive call. Here SpongeAE refers to the AE mode using traditional duplex sponge mode. In addition to that, we assume c = r = n (i.e, state size is n bit).

Design |
State Size |
Security |
---|---|---|

Beetle | n | n/2 - log n/2 |

COFB | 1.5n + k | n/4 - log n/2 |

SpongeAE | n | n/4 |

2. ** Highly Flexible Mode: ** PHOTON-Beetle achieves high Flexibility. It is easy to fit any permutation into this structure. This
depicts that, when used with lighter permutations, it consumes lower hardware footprints. We can also play with r and c to make a proper trade off between the data absorption and the security level.

3. ** Single State: ** PHOTON-Beetle has a state size as
small as the block size of the underlying permutation and it
ensures good implementation characteristics both on
lightweight and high-performance platforms.

4. ** Inverse-Free: ** PHOTON-Beetle is an inverse-free
authenticated encryption algorithm. Both encryption and
decryption algorithms do not require any decryption call to
the underlying tweakable block cipher. This significantly
reduces the overall hardware footprint in combined
encryption-decryption implementations.

5. **Almost No-Overhead: **Apart from the permutation call it requires just *2r-bit XOR per block
of data + 1-bit right rotation of an r/2-bit state*, which seems to be a very small
overhead.

6. **Super Optimal **: PHOTON-Beetle-Hash requires only (m-3) many
primitive invocations to process an m block message. We bind 4 r-bit blocks together in the first clock cycle. The AEAD requires only a+m+1 permutation calls for an a block associated data and an m block message.

7. **Short message Efficiency** : The optimality
on the number of calls and almost no overhead help it to get
very high performance for short messages. Moreover, the hash function absorbs the first 128 bits of plaintext as the initial vector which is also aimed to be efficient for short message.

## PHOTON-Beetle Specification

PHOTON-Beetle family
consists of both AEAD and hash members denoted by PHOTON-Beetle-AEAD[r] and PHOTON-Beetle-Hash[r] (parametrized by the rate r) respectively.

PHOTON-Beetle-AEAD[r]
receives an (1)
128-bit encryption key K, (2) an 128-bit nonce N, (3) an
associated data A of arbitrary length, (4) and a message M
of arbitrary length as inputs, and returns a (5) ciphertext
C of same length as that of the message, and (6) an 128-bit
tag T. PHOTON-Beetle-Hash[r]
receives an arbitrary length message M
and returns a 256-bit
tag T. All the members (both AEAD and hash) use PHOTON_{256} as the underlying permutation. Below are figures for PHOTON-Beetle-AEAD[r] and PHOTON-Beetle-Hash[r].

## PHOTON Permuation

In this design, we use the 256-bit state permutation version used in the PHOTON hash function. We denote this permutation by PHOTON_{256}. The details are given in^{[2]}.

## Recommended Instantiations

**PHOTON-Beetle-AEAD[32] + PHOTON-Beetle-Hash[32]**: Both these AEAD and Hash operate on a 256-bit
state, follow the sponge mode and use PHOTON_{256} as the underlying permutation with the same rate of
data absorption (i.e. r = 32). The associated data process phase in PHOTON-Beetle-AEAD[32] is exactly
the same as the message process phase of PHOTON-Beetle-Hash[32]

**PHOTON-Beetle-AEAD[128] + PHOTON-Beetle-Hash[32]**: In this version, the state size, mode and the underlying permutation remain same. However, the rate of absorption is different for the AEAD and the
hash. From the functional point of view, the main design components remain same.

## Rationale

1. ** Choice of Beetle: ** Sponge is a well-known mode of operations typically used for light-weight applications. The main novelty
behind Beetle sponge mode (the generic mode) is the combined feedback of the permutation output and the
ciphertext block to generate the next permutation input. Recall that, in the simple Duplex Sponge^{[3]} , the
ciphertext block itself is used as the rate part of the next permutation input. This technique actually resists
the attacker to control the input block and the next blockcipher input simultaneously. This in turn uplifts the
security level and helps us to reduce the state size and eventually come up with a low state implementation.
In fact, this security upgrade ensures that we meet the security requirements of NIST even with a state size
of 256 bits only.

2. ** Choice of ρ: ** We need We need a ρ function that has high rank. Our choice fulfills this condition and in addition to that, the choice of ρ ensures uniform state
update for associated data and message and identical to the state update of the duplex sponge.

3. ** Choice of PHOTON _{256}: ** Given that we have a good light-weight AEAD and hash mode based on public permutation, we now need
a light-weight permutation with 256-bit state. Among the existing 256-bit permutations, PHOTON

_{256}is considered as one of the lightest design in the literature. It can be implemented with a very low number of GE because all its components have been chosen with low-area in mind.

## Security of PHOTON-Beetle Members

Security claims for PHOTON-Beetle members are summarized in the table below.Mode | Security | Data Complexity | Time Complexity |
---|---|---|---|

PHOTON-Beetle-AEAD[128] | Privacy | 128 | 128 |

PHOTON-Beetle-AEAD[128] | Integrity | 121 | 121 |

PHOTON-Beetle-AEAD[32] | Privacy | 128 | 128 |

PHOTON-Beetle-AEAD[32] | Integrity | 128 | 121 |

PHOTON-Beetle-Hash[32] | Collision | 112 | - |

PHOTON-Beetle-Hash[32] | Pre-image | 128 | - |

**Privacy of PHOTON-Beetle-AEAD[r]:** To attack against the privacy of PHOTON-Beetle-AEAD, we assume that an adversary makes at most q encryption queries of the form (also known as on-line queries) (N_{i}, A_{i}, M_{i}),i=1..q to PHOTON-Beetle-AEAD[r] with an aggregate of
total σ many blocks and q_{p} many off-line or direct permutation queries (Q_{i})i=1..q_{p}
to PHOTON_{256} or PHOTON_{256}^{-1}.
The adversary can distinguish the construction from a random function with the same domain and range if
it finds a state collision

- -- the initial state of an on-line query collides with the input of an offline query
- -- an intermediate state for an on-lne query collides with the output of an off-line query.

^{2}/2

^{256}+ q

_{p}/2

^{256-r}+ qq

_{p}/2

^{256}).

**Integrity of PHOTON-Beetle-AEAD[r]:** To attack against the integrity of PHOTON-Beetle-AEAD, in addition to the queries above, the adversary can also attempt to forge with (N'_{i}, A'_{i}, C'_{i}, T'_{i}),i..q' with an aggregate of σ' blocks.

_{p}(q+q')/2

^{256}+ rq

_{p}/2

^{128}+ q

_{p}

^{r}/2

^{128(r-1)}+ rσ'/2

^{256-r}).

**Collision Security of PHOTON-Beetle-Hash[r]:** To mount a collision attack on PHOTON-Beetle-Hash [r], suppose an adversary can make q many permutation
calls. Suppose all the states reachable from the initial state (we define the initial state as 0^{256}) using the
permutation calls are called reachable states. The adversary can set up the queries in an adaptive way to
make all the query inputs (and hence query outputs) reachable states. Now, if there is a collision in the
capacity part of the output of two permutation calls, it can adjust the message in the rate part to force a
state collision, which in turn can be used to make a collision in the hash. The probability of this event can
be bounded by q^{2}/2^{256-r}.

**Preimage Security of PHOTON-Beetle-Hash[r]:**In PHOTON-Beetle-Hash[r] we set the tag size as 256 bits and the tag squeeze rate as 128 bits. Now, to find a
pre-image of a hash value say T_{1}||T_{2}, an adversary needs to find a Z such that PHOTON_{256}(T_{1}||Z_{1}) = T_{2}||***** or
PHOTON_{256}^{-1}(T_{2}||Z) = T_{1}. It is easy to see that the probability of this event can be bounded by q/2^{128}.

**Security Analysis of PHOTON:**
The basic security analysis for PHOTON_{256} has been provided explicitly in the original paper ^{[2]}. It has been
there for several years now (ISO standard as well) and still remains with a comfortable security margin.
Here we briefly discuss all the existing analysis on PHOTON_{256} . In ^{[2]} , the authors mentioned a rebound-like
attack that allows one to distinguish 8 rounds of PHOTON_{256} from an ideal permutation of the same size
with time complexity 2^{16} and memory complexity of 2^{8}. Later, ^{[7]}, extended the previous result to further
decrease the time complexity from 2^{16} to 2^{10.8}. In ^{[6]}, Jean et al. presented a distinguisher for 9 round
PHOTON_{256} with time complexity of 2^{184} and memory complexity of 2^{32}. In 2017, ^{[4]}, presented a statistical
Integral distinguisher that mounts an attack on 10 round PHOTON_{256} with time complexity of 2^{96.59} and data
complexity of 2^{70.46}. Recently, Wang et al. ^{[25]}, presented the first full round distinguishers on PHOTON_{256}
based on zero-sum partitions of size 2^{184}. We believe these distinguishers have no impact on the security
of PHOTON-Beetle as these attacks are much more costlier than the security target we are aiming, and these
attacks are basically unusable in the mode.

## Hardware Implementations

An advantage of PHOTON-Beetle is that the area of the hardware implementations of its members can be very small. The mode Beetle costs little on top of the costs of the underlying permutation PHOTON_{256}. The underlying permutation PHOTON

_{256}is one of the most compact among primitives with the same dimension. It can be implemented with a very low number of GE because all its components have been chosen with low-area in mind. In particular, the diffusion matrix is lightweight in the sense that it can be serialized very easily and efficiently. Concretely, the area of the hardware implementations of all members in PHOTON-Beetle can be estimated using that of the hash function PHOTON-224/32/32, which also uses PHOTON

_{256}as its underlying permutation. PHOTON-224/32/32 adopts Sponge construction with in-/output bit-rate 32/32. Considering that the Sponge construction also costs little on top of the costs of the underlying permutation, it is reasonable to use the area of the hardware implementation of PHOTON-224/32/32 to estimate that of PHOTON-Beetle. According to

^{[2]}, as for serial ASIC implementation of PHOTON-224/32/32 using the standard cell library UMCL18G212T3 (with data path s = 4, which is the size of cells in the state), when target at minimizing area, it costs 1736 GEs and the latency of the underlying permutation is 1716 clock cycles; when target at minimizing latency, it costs 2786 GEs and the latency of the underlying permutation is 204 clock cycles. Comparing implementations of the members of PHOTON-Beetle with that of PHOTON-224/32/32, additional costs of area may comes from the storage for key, nonce and larger message block (and the XOR gates for larger bit-rate). However, since key bits and nonce bits are used to initialize the state without schedule and will not be used after the initialization, such local storage can be reused and thus costs no additional area on top of the underlying permutation. In serial implementations with data path s = 4, larger bit-rate do not cause additional XOR gates because the XOR-ings are serialized. Hence, we estimate that for all members of PHOTON-Beetle, the area cost will be close to that cost by PHOTON-224/32/32.

## Software Implementations

PHOTON-Beetle is primarily targeted for the constrained devices, and we mainly focus on the software implementation and performance of PHOTON-Beetle on micro-controllers. On 8-bit AVR devices, all members of PHOTON-Beetle are expected to have small code size (ROM) and RAM requirement. We implemented PHOTON-Beetle in assembly with AVR ATmega128 as the targeted device. Our bit-sliced implementation (bit-slicing within a single state, thus do not restrict to process multiple messages) of the underlying permutation PHOTON_{256}requires 604 bytes ROM (556 for code and 48 for data, including the codes for bit-slicing) and 32 bytes RAM (exclude those used for key/nonce/messages/outputs). The ROM and RAM requirements for all members of PHOTON-Beetle can be seen from the Table below, which includes the costs for the two combined AEAD and Hash fucntion families. From theTable below, for PHOTON-Beetle, supporting Hash functionality on top of AEAD costs very limited additional resources. Besides, there are also third party implementations for PHOTON-256/32/32 and PHOTON-160/36/36 in AVR devices. According to a report on the implementation and performance evaluation of Hash functions in ATtiny devices

^{[8]}, the code size of PHOTON-256/32/32 (which uses PHOTON

_{288}as its underlying permutation with the 8- bit S-box of AES) is 1244 bytes, the SRAM requirement is 78 bytes. The code size of PHOTON-160/36/36 (which uses PHOTON

_{196}as its underlying permutation with the 4-bit S-box of PRESENT, which is the same as the one used in PHOTON-224/32/32) is 764 bytes, the RAM requirement is 50 bytes. Considering the performance of PHOTON

_{256}should lie in-between that of these two primitives, when following the implementation methods in [1], the code size for PHOTON

_{256}should be at the range of 764 to 1244 bytes, and the SRAM requirement should be at the range of 50 to 78bytes. On general purpose processors, the software performance of PHOTON-224/32/32 is about 227 cycles per byte for long messages in an Intel(R) Core(TM) i7 CPU. Considering all members in PHOTON-Beetle family have larger output bit rate (128 bit) than PHOTON-224/32/32, the performance of them is expected to be much better. Besides, for PHOTON-Beetle-AEAD[128], the messages are processed 128-bit per call of the underlying permutation, which is 4 times the rate in PHOTON-224/32/32, we expect the member PHOTON-Beetle-AEAD[128] in PHOTON-Beetle family performs significantly better (227/4 = 56.75 cycles per byte) in general purpose processors. For small messages, PHOTON-Beetle-Hash[32] also performs much better than PHOTON-224/32/32 due to absorption of 128-bits message in the initialization.

PHOTON-Beetle-AEAD[128] | PHOTON-Beetle-AEAD[32] | PHOTON-Beetle-Hash[32] | PHOTON-BeetleAEAD[128]+Hash[32] | PHOTON-BeetleAEAD[32]+Hash[32] | |
---|---|---|---|---|---|

ROM | 1122 | 1120 | 850 | 1218 | 1216 |

RAM | 64 | 40 | 36 | 64 | 40 |

## References

**^**Avik Chkraborti, Nilanjan Datta, Mridul Nandi and Kan Yasuda. Beetle Family of Lightweight and Secure Authenticated Encryption Ciphers. IACR Trans. Cryptogr. Hardw. Embed. Syst., 2018(2):218-241, 2018.**^**Jian Guo, Thomas Peyrin, and Axel Poschmann. The PHOTON family of lightweight hash functions. In Phillip Rogaway, editor, Advances in Cryptology - CRYPTO 2011 - 31st Annual Cryptology Conference, Santa Barbara, CA, USA, August 14-18, 2011. Proceedings, volume 6841 of Lecture Notes in Computer Science, pages 222-239. Springer, 2011.**^**Guido Bertoni, Joan Daemen, Michael Peeters, and Gilles Van Assche. Duplexing the sponge: single-pass authenticated encryption and other applications. IACR Cryptology ePrint Archive, 2011:499, 2011.**^**Tingting Cui, Ling Sun, Huaifeng Chen, and Meiqin Wang. Statistical integral distinguisher with multistructure and its application on AES. In Information Security and Privacy - 22nd Australasian Conference, ACISP 2017, Auckland, New Zealand, July 3-5, 2017, Proceedings, Part I, pages 402-420, 2017.**^**Qingju Wang, Lorenzo Grassi, and Christian Rechberger. Zero-sum partitions of PHOTON permutations. In Topics in Cryptology - CT-RSA 2018 - The Cryptographers Track at the RSA Conference 2018, San Francisco, CA, USA, April 16-20, 2018, Proceedings, pages 279-299, 2018.**^**Jeremy Jean, Mar?a Naya-Plasencia, and Thomas Peyrin. Improved rebound attack on the finalist grostl. In Anne Canteaut, editor, Fast Software Encryption - 19th International Workshop, FSE 2012, Washington, DC, USA, March 19-21, 2012. Revised Selected Papers, volume 7549 of LNCS, pages 110-126. Springer, 2012.**^**Jeremy Jean, Mar?a Naya-Plasencia, and Thomas Peyrin. Multiple limited-birthday distinguishers and applications. In Selected Areas in Cryptography - SAC 2013 - 20th International Conference, Burnaby, BC, Canada, August 14-16, 2013, Revised Selected Papers, pages 533-550, 2013.**^**Josep Balasch, Baris Ege, Thomas Eisenbarth, Beno?t Gerard, Zheng Gong, Tim Guneysu, Stefan Heyse, Stephanie Kerckhof, Francois Koeune, Thomas Plos, Thomas Poppelmann, Francesco Regazzoni, Francois-Xavier Standaert, Gilles Van Assche, Ronny Van Keer, Lo?c van Oldeneel tot Oldenzeel, and Ingo von Maurich. Compact implementation and performance evaluation of hash functions in attiny devices. In Stefan Mangard, editor, Smart Card Research and Advanced Applications - 11th International Conference, CARDIS 2012, Graz, Austria, November 28-30, 2012, Revised Selected Papers, volume 7771 of Lecture Notes in Computer Science, pages 158-172. Springer, 2012.