Abstract. At ASIACRYPT 1991, Even and Mansour introduced a block cipher construction based on a single permutation. Their construction has since been lauded for its simplicity, yet also criticized for not providing the same security as other block ciphers against generic attacks. In this paper, we prove that if a small number of plaintexts are encrypted under multiple independent keys, the Even-Mansour construction surprisingly offers similar security as an ideal block cipher with the same block and key size. Note that this multi-key setting is of high practical relevance, as real-world implementations often allow frequent rekeying. We hope that the results in this paper will further encourage the use of the Even-Mansour construction, especially when a secure and efficient implementation of a key schedule would result in significant overhead.Keywords: Even-Mansour, multi-key setting, broadcast attack, relatedkey setting.
IntroductionModern block cipher design is based on the concept of iterating a round function [44]. This round function typically consists of a subkey addition followed by an unkeyed invertible function. All commonly-used block ciphers, including the DES [46] and AES [23] standards, follow this design strategy.As such, the design of an iterated block cipher consists of two parts: the design of a round function, and a key schedule to generate the subkeys for every round. Although round function design seems to be a relatively well-understood problem, this is much less the case for the key schedule. For example, Rijmen and Daemen already stated in the AES design book that: "There is no consensus on the criteria that a key schedule must satisfy [23, p. 77]. This fact has been repeated many times since, for example in the SHA-3 finalist Grøstl design document [32, p. 5]. In particular, there seems to be no consensus on whether ⋆ © IACR 2015. This article is the final version submitted by the authors to the IACR and to Springer-Verlag in June 2015. It will appear in the proceedings of CRYPTO 2015.a "strong" or a "simple" key schedule is required, a choice which appears to depend on the application. An argument for a "simple" key schedule is that keys should be chosen uniformly at random from the entire key space anyway, in order to avoid a speed-up of brute-force attacks due to low key entropy. As a result, attacks based on weak keys [25] and known keys [42] are no longer applicable. Similarly, when multiple keys are used, they should be chosen independently to prevent a compromise of one key helping the recovery of other keys. This avoids attacks based on related keys [9][10][11].Proponents of a "strong" key schedule point out that in practice, keys may not always be chosen independently from a uniformly random distribution. The cause of this could be a weak protocol, a programming error or an insecure implementation.Complexity, however, always comes at a cost. It makes cryptosystems more difficult to design, to implement and to analyze. Hence, we argue for a block cipher with a simple key schedule, ...