Contents





PHOTON-Beetle Authenticated Encryption

PHOTON-Beetle is an authenticated encryption and hash family, that uses a sponge-based mode Beetle[1] with the P256 (used for the PHOTON hash[2]) being the underlying permutation. We denote this permutation by PHOTON256. 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.


Contents
  • 1 Features
  • 2 Mode Specification
  • 3 Primitive
  • 4 Instantiation
  • 5 Rationale
  • 6 Security
  • 7 Hardware Implementations
  • 8 Software Implementations

    • 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 PHOTON256 as the underlying permutation. Below are figures for PHOTON-Beetle-AEAD[r] and PHOTON-Beetle-Hash[r].

    PHOTON-Beetle-AEAD[r] for a associated data blocks and m message blocks


    PHOTON-Beetle-AEAD[r] for a associated data blocks and empty message

    PHOTON-Beetle-AEAD[r] for empty associated data and m message blocks

    PHOTON-Beetle-AEAD[r] for empty associated data and empty message

    PHOTON-Beetle-Hash[r] for m message blocks

    PHOTON Permuation

    In this design, we use the 256-bit state permutation version used in the PHOTON hash function. We denote this permutation by PHOTON256. 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 PHOTON256 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 PHOTON256: 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, PHOTON256 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) (Ni, Ai, Mi),i=1..q to PHOTON-Beetle-AEAD[r] with an aggregate of total σ many blocks and qp many off-line or direct permutation queries (Qi)i=1..qp to PHOTON256 or PHOTON256-1. The adversary can distinguish the construction from a random function with the same domain and range if it finds a state collision

  • among the internal states of two on-line queries
  • among one online query internal state and an offline query output. It has two sub cases.
    • -- 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.
    • Overall IND-CPA advantage is bounded by O(σ2/2256 + qp/2256-r + qqp/2256).

    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.

  • The trivial solution for forging is to guess the key or the tag.
  • Also, if an adversary can obtain a state collision among the input/output of a permutation query with the state of an encryption query or decryption query.
  • Another possible (non-trivial) direction for the adversary is to construct an off-line query chain such that the adversary can simulate a valid forgery.
    • Overall the INT-CTXT security advantage is bounded by O(qp(q+q')/2256 + rqp/2128 + qpr/2128(r-1) + rσ'/2256-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 0256) 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 q2/2256-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 T1||T2, an adversary needs to find a Z such that PHOTON256(T1||Z1) = T2||* or PHOTON256-1(T2||Z) = T1. It is easy to see that the probability of this event can be bounded by q/2128.

    Security Analysis of PHOTON: The basic security analysis for PHOTON256 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 PHOTON256 . In [2] , the authors mentioned a rebound-like attack that allows one to distinguish 8 rounds of PHOTON256 from an ideal permutation of the same size with time complexity 216 and memory complexity of 28. Later, [7], extended the previous result to further decrease the time complexity from 216 to 210.8. In [6], Jean et al. presented a distinguisher for 9 round PHOTON256 with time complexity of 2184 and memory complexity of 232. In 2017, [4], presented a statistical Integral distinguisher that mounts an attack on 10 round PHOTON256 with time complexity of 296.59 and data complexity of 270.46. Recently, Wang et al. [25], presented the first full round distinguishers on PHOTON256 based on zero-sum partitions of size 2184. 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 PHOTON256. The underlying permutation PHOTON256 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 PHOTON256 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 PHOTON256 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 PHOTON288 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 PHOTON196 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 PHOTON256 should lie in-between that of these two primitives, when following the implementation methods in [1], the code size for PHOTON256 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

    1. ^ 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.
    2. ^ 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.
    3. ^ 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.
    4. ^ 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.
    5. ^ 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.
    6. ^ 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.
    7. ^ 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.
    8. ^ 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.
    | Template by HTML5 Templates