19 research outputs found

    Face-off between the CAESAR Lightweight Finalists: ACORN vs. Ascon

    Get PDF
    Authenticated ciphers potentially provide resource savings and security improvements over the joint use of secret-key ciphers and message authentication codes. The CAESAR competition has aimed to choose the most suitable authenticated ciphers for several categories of applications, including a lightweight use case, for which the primary criteria are performance in resource-constrained devices, and ease of protection against side channel attacks (SCA). In March 2018, two of the candidates from this category, ACORN and Ascon, were selected as CAESAR contest finalists. In this research, we compare two SCA-resistant FPGA implementations of ACORN and Ascon, where one set of implementations has area consumption nearly equivalent to the defacto standard AES-GCM, and the other set has throughput (TP) close to that of AES-GCM. The results show that protected implementations of ACORN and Ascon, with area consumption less than but close to AES-GCM, have 23.3 and 2.5 times, respectively, the TP of AES-GCM. Likewise, implementations of ACORN and Ascon with TP greater than but close to AES-GCM, consume 18 percent and 74 percent of the area, respectively, of AES-GCM

    Fixslicing: A New GIFT Representation

    Get PDF
    The GIFT family of lightweight block ciphers, published at CHES 2017, offers excellent hardware performance figures and has been used, in full or in part, in several candidates of the ongoing NIST lightweight cryptography competition. However, implementation of GIFT in software seems complex and not efficient due to the bit permutation composing its linear layer (a feature shared with PRESENT cipher). In this article, we exhibit a new non-trivial representation of the GIFT family of block ciphers over several rounds. This new representation, that we call fixslicing, allows extremely efficient software bitsliced implementations of GIFT, using only a few rotations, surprisingly placing GIFT as a very efficient candidate on micro-controllers. Our constant time implementations show that, on ARM Cortex-M3, 128-bit data can be ciphered with only about 800 cycles for GIFT-64 and about 1300 cycles for GIFT-128 (assuming pre-computed round keys). In particular, this is much faster than the impressive PRESENT implementation published at CHES 2017 that requires 2116 cycles in the same setting, or the current best AES constant time implementation reported that requires 1617 cycles. This work impacts GIFT, but also improves software implementations of all other cryptographic primitives directly based on it or strongly related to it

    General Classification of the Authenticated Encryption Schemes for the CAESAR Competition

    Get PDF
    An Authenticated encryption scheme is a scheme which provides privacy and integrity by using a secret key. In 2013, CAESAR (the ``Competition for Authenticated Encryption: Security, Applicability, and Robustness\u27\u27) was co-founded by NIST and Dan Bernstein with the aim of finding authenticated encryption schemes that offer advantages over AES-GCM and are suitable for widespread adoption. The first round started with 57 candidates in March 2014; and nine of these first-round candidates where broken and withdrawn from the competition. The remaining 48 candidates went through an intense process of review, analysis and comparison. While the cryptographic community benefits greatly from the manifold different submission designs, their sheer number implies a challenging amount of study. This paper provides an easy-to-grasp overview over functional aspects, security parameters, and robustness offerings by the CAESAR candidates, clustered by their underlying designs (block-cipher-, stream-cipher-, permutation-/sponge-, compression-function-based, dedicated). After intensive review and analysis of all 48 candidates by the community, the CAESAR committee selected only 30 candidates for the second round. The announcement for the third round candidates was made on 15th August 2016 and 15 candidates were chosen for the third round

    Blockcipher-based Authenticated Encryption: How Small Can We Go?

    Get PDF
    This paper presents a lightweight blockcipher based authenticated encryption mode mainly focusing on minimizing the implementation size, i.e., hardware gates or working memory on software. The mode is called COFB, for COmbined FeedBack. COFB uses an nn-bit blockcipher as the underlying primitive and relies on the use of a nonce for security. In addition to the state required for executing the underlying blockcipher, COFB needs only n/2n/2 bits state as a mask. To date, for all existing constructions in which masks have been applied, at least nn bit masks have been used. Thus, we have shown the possibility of reducing the size of a mask without degrading the security level much. Moreover, it requires one blockcipher call to process one input block. We show COFB is provably secure up to O(2n/2/n)O(2^{n/2}/n) queries which are almost up to the standard birthday bound. We first present an idealized mode iCOFB along with the details of its provable security analysis. Next, we extend the construction to the practical mode COFB. We instantiate COFB with two 128-bit blockciphers, AES-128 and GIFT-128, and present their implementation results on FPGAs. We present two implementations, with and without CAESAR hardware API. When instantiated with AES-128 and implemented without CAESAR hardware API, COFB achieves only a few more than 10001000 Look-Up-Tables (LUTs) while maintaining almost the same level of provable security as standard AES-based AE, such as GCM. When instantiated with GIFT-128, COFB performs much better in hardware area. It consumes less than 10001000 LUTs while maintaining the same security level. However, when implemented with CAESAR hardware API, there are significant overheads both in the hardware area and throughput. COFB with AES-128 achieves about 14751475 LUTs. COFB with GIFT-128 achieves a few more than 10001000 LUTs. Though there are overheads, still both these figures show competitive implementation results compared to other authenticated encryption constructions
    corecore