Here we focus, for the first time, on an extreme corner of the design space and initiate a study of symmetric-key primitives that minimize the multiplicative size and depth of their descriptions. This is motivated by recent progress in practical instantiations of secure multi-party computation (MPC), fully homomorphic encryption (FHE), and zero-knowledge proofs (ZK) where linear computations are, compared to non-linear operations, essentially ``free''.
We focus on the case of a block cipher, and propose the family of block ciphers ``LowMC'', beating all existing proposals with respect to these metrics. As examples, we give concrete instatiations for 80-bit, 128-bit, and 256-bit security. We sketch several applications for such ciphers and give implementation comparisons suggesting that when encrypting larger amounts of data the new design strategy translates into improvements in computation and communication complexity by up to a factor of 5 compared to AES-128, which incidentally is one of the most competitive classical designs. Furthermore, we identify cases where ``free XORs'' can no longer be regarded as such but represent a bottleneck, hence refuting this commonly held belief with a practical example.Category / Keywords: secret-key cryptography / block cipher, multiplicative complexity, multiplicative depth, secure multiparty computation, fully homomorphic encryption Original Publication (with major differences): IACR-EUROCRYPT-2015 Date: received 8 Jul 2016 Contact author: christian rechberger at groestl info Available format(s): PDF | BibTeX Citation Note: Compared to the conference version, this paper includes among others (1) updated security analysis and round formula taking recent cryptanalysis into account (LowMC v2). (2) more examples of concrete instantiations, optimizing for metrics such as ANDdepth, #ANDs/bits, and #ANDs separately, incl. concrete instances with 256-bit security. (3) updated benchmarks for LowMCv2 parametersets. Version: 20160712:193744 (All versions of this report) Short URL: ia.cr/2016/687 Discussion forum: Show discussion | Start new discussion