====== Let's DOIT: Using Intel's Extended HW/SW Contract for Secure Compilation of Crypto Code  ======
~~NOTOC~~

<grid>
<col xs="12" sm="8" lg="8">
<TEXT size="large">

\_{{fa>user}}\_\_//Authors:// Santiago Arranz-Olmos, Gilles Barthe, Benjamin Grégoire, [[:publications:authors:jan-jancar|Jan Jancar]], Vincent Laporte, Tiago Oliveira, Peter Schwabe

{{fa>user-circle-o}}\_//Primary contact:// Jan Jancar %%<%%<j08ny@mail.muni.cz>%%>%%

{{fa>bullhorn}}\_//Conference:// [[https://ches.iacr.org/2025/|CHES 2025]]

</TEXT>
</col>

<col xs="12" sm="4" lg="4">
<TEXT align="right">

<button type="warning" icon="fa fa-fw fa-file-pdf-o">[[https://crocs.fi.muni.cz/_media/publications/pdf/2025-ches-jancar.pdf|PRE-PRINT PDF]]</button>
\_
<button icon="fa fa-fw fa-file-image-o">[[|Slides (not yet)]]</button>
\_
<button collapse="bibtex" icon="fa fa-fw fa-file-code-o">BiBTeX</button>
</TEXT>
</col>
</grid>

<collapse id="bibtex" collapsed="false">

  @InProceedings{2025-ches-jancar,
    Title         = {Let's DOIT: Using Intel's Extended HW/SW Contract for Secure Compilation of Crypto Code},
    Author        = {Santiago Arranz-Olmos and Gilles Barthe and Benjamin Grégoire and Jan Jancar and Vincent Laporte and Tiago Oliveira and Peter Schwabe},
    BookTitle     = {IACR Transactions on Cryptographic Hardware and Embedded Systems},
    Publisher     = {Ruhr-University of Bochum},
    Year          = {2025},
    Keywords      = {constant-time, cryptoimplementations, Jasmin},
  }

</collapse>

<panel type="default" title="Abstract">
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.
</panel>