From Substitution Box To Threshold

With the escalating demand for lightweight ciphers as well as side channel protected implementation of those ciphers in recent times, this work focuses on two aspects. First, we present a tool for automating the task of finding a Threshold Implementation (TI) of a given Substitution Box (SBox). Our tool returns `with decomposition\u27 and `without decomposition\u27 based TI. The `with decomposition\u27 based implementation returns a combinational SBox; whereas we get a sequential SBox from the `without decomposition\u27 based implementation. Despite being high in demand, it appears that this kind of tool has been missing so far. Second, we show an algorithmic approach where a given cipher implementation can be tweaked (without altering the cipher specification) so that its TI cost can be significantly reduced. We take the PRESENT cipher as our case study (our methodology can be applied to other ciphers as well). Indeed, we show over 31 percent reduction in area and over 52 percent reduction in depth compared to the basic threshold implementation

BAKSHEESH: Similar Yet Different From GIFT

We propose a lightweight block cipher named BAKSHEESH, which follows up on the popular cipher GIFT-128 (CHES\u2717). BAKSHEESH runs for 35 rounds, which is 12.50 percent smaller compared to GIFT-128 (runs for 40 rounds) while maintaining the same security claims against the classical attacks. The crux of BAKSHEESH is to use a 4-bit SBox that has a non-trivial Linear Structure (LS). An SBox with one or more non-trivial LS has not been used in a cipher construction until DEFAULT (Asiacrypt\u2721). DEFAULT is pitched to have inherent protection against the Differential Fault Attack (DFA), thanks to its SBox having 3 non-trivial LS. BAKSHEESH, however, uses an SBox with only 1 non-trivial LS; and is a traditional cipher just like GIFT-128, with no claims against DFA. The SBox requires a low number of AND gates, making BAKSHEESH suitable for side channel countermeasures (when compared to GIFT-128) and other niche applications. Indeed, our study on the cost of the threshold implementation shows that BAKSHEESH offers a few-fold advantage over other lightweight ciphers. The design is not much deviated from its predecessor (GIFT-128), thereby allowing for easy implementation (such as fix-slicing in software). However, BAKSHEESH opts for the full-round key XOR, compared to the half-round key XOR in GIFT. Thus, when taking everything into account, we show how a cipher construction can benefit from the unique vantage point of using 1 LS SBox, by combining the state-of-the-art progress in classical cryptanalysis and protection against device-dependent attacks. We, therefore, create a new paradigm of lightweight ciphers, by adequate deliberation on the design choice, and solidify it with appropriate security analysis and ample implementation/benchmark

Side-Channel Evaluation Methodology on Software

Cryptographic implementations need to be robust amidst the widespread use of crypto-libraries and attacks targeting their implementation, such as side-channel attacks (SCA). Many certification schemes, such as Common Criteria and FIPS 140, continue without addressing side-channel flaws. Research works mostly tackle sophisticated attacks with simple use-cases, which is not the reality where end-to-end evaluation is not trivial. In this study we used all due diligence to assess the invulnerability of a given implementation from the shoes of an evaluator. In this work we underline that there are two kinds of SCA: horizontal and vertical. In terms of quotation, measurement and exploitation, horizontal SCA is easier. If traces are constant-time, then vertical attacks become convenient, since there is no need for specific alignment (“value based analysis”). We introduce our new methodology: Vary the key to select sensitive samples, where the values depend upon the key, and subsequently vary the mask to uncover unmasked key-dependent leakage, i.e., the flaws. This can be done in the source code (pre-silicon) for the designer or on the actual traces (post-silicon) for the test-lab. We also propose a methodology for quotations regarding SCA unlike standards that focus on only one aspect (like number of traces) and forgets about other aspects (such as equipment; cf. ISO/IEC 20085-1