@article{65537,
  abstract     = {{<jats:p>It is a widely accepted standard practice to implement cryptographic software so that secret inputs do not influence the cycle count. Software following this paradigm is often referred to as “constant-time” software and typically involves following three rules: 1) never branch on a secret-dependent condition, 2) never access memory at a secret-dependent location, and 3) avoid variable-time arithmetic operations on secret data. The third rule requires knowledge about such variable-time arithmetic instructions, or vice versa, which operations are safe to use on secret inputs. For a long time, this knowledge was based on either documentation or microbenchmarks, but critically, there were never any guarantees for future microarchitectures. This changed with the introduction of the data-operand-independent-timing (DOIT) mode on Intel CPUs and, to some extent, the data-independent-timing (DIT) mode on Arm CPUs. Both Intel and Arm document a subset of their respective instruction sets that are intended to leak no information about their inputs through timing, even on future microarchitectures if the CPU is set to run in a dedicated DOIT (or DIT) mode.In this paper, we present a principled solution that leverages DOIT to enable cryptographic software that is future-proof constant-time, in the sense that it ensures that only instructions from the DOIT subset are used to operate on secret data, even during speculative execution after a mispredicted branch or function return location. For this solution, we build on top of existing security type systems in the Jasmin framework for high-assurance cryptography.We then use our solution to evaluate the extent to which existing cryptographic software built to be “constant-time” is already secure in this stricter paradigm implied by DOIT and what the performance impact is to move from constant-time to future-proof constant-time.</jats:p>}},
  author       = {{Arranz-Olmos, Santiago and Barthe, Gilles and Grégoire, Benjamin and Jancar, Jan and Laporte, Vincent and Oliveira, Tiago and Schwabe, Peter}},
  issn         = {{2569-2925}},
  journal      = {{IACR Transactions on Cryptographic Hardware and Embedded Systems}},
  number       = {{3}},
  pages        = {{644--667}},
  publisher    = {{Universitatsbibliothek der Ruhr-Universitat Bochum}},
  title        = {{{Let’s DOIT: Using Intel’s Extended HW/SW Contract for Secure Compilation of Crypto Code}}},
  doi          = {{10.46586/tches.v2025.i3.644-667}},
  volume       = {{2025}},
  year         = {{2025}},
}

@article{65538,
  abstract     = {{<jats:p>Developers implementing elliptic curve cryptography (ECC) face a wide range of implementation choices created by decades of research into elliptic curves. The literature on elliptic curves offers a plethora of curve models, scalar multipliers, and addition formulas, but this comes with the price of enabling attacks to also use the rich structure of these techniques. Navigating through this area is not an easy task and developers often obscure their choices, especially in black-box hardware implementations. Since side-channel attackers rely on the knowledge of the implementation details, reverse engineering becomes a crucial part of attacks.This work presents ECTester – a tool for testing black-box ECC implementations. Through various test suites, ECTester observes the behavior of the target implementation against known attacks but also non-standard inputs and elliptic curve parameters. We analyze popular ECC libraries and smartcards and show that some libraries and most smartcards do not check the order of the input points and improperly handle the infinity point. Based on these observations, we design new techniques for reverse engineering scalar randomization countermeasures that are able to distinguish between group scalar randomization, additive, multiplicative or Euclidean splitting. Our techniques do not require side-channel measurements; they only require the ability to set custom domain parameters, and are able to extract not only the size but also the exact value of the random mask used. Using the techniques, we successfully reverse-engineered the countermeasures on 13 cryptographic smartcards from 5 major manufacturers – all but one we tested on. Finally, we discuss what mitigations can be applied to prevent such reverse engineering, and whether it is possible at all.</jats:p>}},
  author       = {{Suchanek, Vojtech and Jancar, Jan and Kvapil, Jan and Svenda, Petr and Chmielewski, Łukasz}},
  issn         = {{2569-2925}},
  journal      = {{IACR Transactions on Cryptographic Hardware and Embedded Systems}},
  number       = {{4}},
  pages        = {{290--316}},
  publisher    = {{Universitatsbibliothek der Ruhr-Universitat Bochum}},
  title        = {{{ECTester: Reverse-engineering side-channel countermeasures of ECC implementations}}},
  doi          = {{10.46586/tches.v2025.i4.290-316}},
  volume       = {{2025}},
  year         = {{2025}},
}

@article{65535,
  abstract     = {{<jats:p>Side-channel attacks on elliptic curve cryptography (ECC) often assume a white-box attacker who has detailed knowledge of the implementation choices taken by the target implementation. Due to the complex and layered nature of ECC, there are many choices that a developer makes to obtain a functional and interoperable implementation. These include the curve model, coordinate system, addition formulas, and the scalar multiplier, or lower-level details such as the finite-field multiplication algorithm. This creates a gap between the attack requirements and a real-world attacker that often only has black-box access to the target – i.e., has no access to the source code nor knowledge of specific implementation choices made. Yet, when the gap is closed, even real-world implementations of ECC succumb to side-channel attacks, as evidenced by attacks such as TPM-Fail, Minerva, the Side Journey to Titan, or TPMScan [MSE+20; JSS+20; RLM+21; SDB+24].We study this gap by first analyzing open-source ECC libraries for insight into realworld implementation choices. We then examine the space of all ECC implementations combinatorially. Finally, we present a set of novel methods for automated reverse engineering of black-box ECC implementations and release a documented and usable open-source toolkit for side-channel analysis of ECC called pyecsca.Our methods turn attacks around: instead of attempting to recover the private key, they attempt to recover the implementation configuration given control over the private and public inputs. We evaluate them on two simulation levels and study the effect of noise on their performance. Our methods are able to 1) reverse-engineer the scalar multiplication algorithm completely and 2) infer significant information about the coordinate system and addition formulas used in a target implementation. Furthermore, they can bypass coordinate and curve randomization countermeasures.</jats:p>}},
  author       = {{Jancar, Jan and Suchanek, Vojtech and Svenda, Petr and Sedlacek, Vladimir and Chmielewski, Łukasz}},
  issn         = {{2569-2925}},
  journal      = {{IACR Transactions on Cryptographic Hardware and Embedded Systems}},
  number       = {{4}},
  pages        = {{355--381}},
  publisher    = {{Universitatsbibliothek der Ruhr-Universitat Bochum}},
  title        = {{{pyecsca: Reverse engineering black-box elliptic curve cryptography via side-channel analysis}}},
  doi          = {{10.46586/tches.v2024.i4.355-381}},
  volume       = {{2024}},
  year         = {{2024}},
}