<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
<ListRecords>
<oai_dc:dc xmlns="http://www.openarchives.org/OAI/2.0/oai_dc/"
           xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/"
           xmlns:dc="http://purl.org/dc/elements/1.1/"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
   	<dc:title>Let’s DOIT: Using Intel’s Extended HW/SW Contract for Secure Compilation of Crypto Code</dc:title>
   	<dc:creator>Arranz-Olmos, Santiago</dc:creator>
   	<dc:creator>Barthe, Gilles</dc:creator>
   	<dc:creator>Grégoire, Benjamin</dc:creator>
   	<dc:creator>Jancar, Jan</dc:creator>
   	<dc:creator>Laporte, Vincent</dc:creator>
   	<dc:creator>Oliveira, Tiago</dc:creator>
   	<dc:creator>Schwabe, Peter</dc:creator>
   	<dc:description>&lt;jats:p&gt;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.&lt;/jats:p&gt;</dc:description>
   	<dc:publisher>Universitatsbibliothek der Ruhr-Universitat Bochum</dc:publisher>
   	<dc:date>2025</dc:date>
   	<dc:type>info:eu-repo/semantics/article</dc:type>
   	<dc:type>doc-type:article</dc:type>
   	<dc:type>text</dc:type>
   	<dc:type>http://purl.org/coar/resource_type/c_6501</dc:type>
   	<dc:identifier>https://ris.uni-paderborn.de/record/65537</dc:identifier>
   	<dc:source>Arranz-Olmos S, Barthe G, Grégoire B, et al. Let’s DOIT: Using Intel’s Extended HW/SW Contract for Secure Compilation of Crypto Code. &lt;i&gt;IACR Transactions on Cryptographic Hardware and Embedded Systems&lt;/i&gt;. 2025;2025(3):644-667. doi:&lt;a href=&quot;https://doi.org/10.46586/tches.v2025.i3.644-667&quot;&gt;10.46586/tches.v2025.i3.644-667&lt;/a&gt;</dc:source>
   	<dc:relation>info:eu-repo/semantics/altIdentifier/doi/10.46586/tches.v2025.i3.644-667</dc:relation>
   	<dc:relation>info:eu-repo/semantics/altIdentifier/issn/2569-2925</dc:relation>
   	<dc:rights>info:eu-repo/semantics/closedAccess</dc:rights>
</oai_dc:dc>
</ListRecords>
</OAI-PMH>
