This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. ====== 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>