This C library provides constant-time implementations of primitive operations to help developers write code that is resistant to timing-based side-channel attacks. It is targeted at developers working with sensitive data, particularly in security enclaves like Intel SGX or ARM TrustZone, and aims to mitigate information leakage through execution time variations.

How It Works

CTTK employs techniques to ensure that operations on secret data do not leak information through execution time. This is achieved by avoiding data-dependent branches and memory accesses, and by using specialized arithmetic operations. For instance, boolean operations are implemented using non-branching logic, and integer comparisons are designed to have consistent execution times regardless of the input values.

Quick Start & Requirements

• Compile with make.
• Dependencies: Standard C compiler.
• Build produces static and dynamic libraries (libcttk.a, libcttk.so) and a test executable (testcttk).
• Usage: Include cttk.h in your C/C++ project.
• Documentation: API is documented in cttk.h; Doxygen can generate HTML docs.

Highlighted Details

• Provides constant-time primitives for native integers (32/64-bit) including comparisons, multiplexing, and zero checks.
• Offers tunable hexadecimal and Base64 encoding/decoding functions that protect byte values.
• Includes constant-time multiplication for 32/64-bit integers, with guaranteed truncating behavior for signed overflows.
• Features a configurable big integer implementation with support for arbitrary bit sizes, NaN propagation, and protected NaN status.
• Basic Oblivious RAM (ORAM) implementation for constant-time array access (O(N) cost).

Maintenance & Community

• Maintained by Thomas Pornin.
• Early development stage; API may change.
• TODO.md lists planned features.

Licensing & Compatibility

• MIT License: Permissive, allowing reuse in open-source and proprietary projects with license text retention.

Limitations & Caveats

• The library is in early development and may contain bugs; production use is strongly discouraged.
• API stability is not guaranteed.
• ORAM implementation is basic and inefficient (O(N)).
• Shift operations do not protect the shift count by default; protected versions are slower.
• Big integer operations may use malloc for temporary buffers, which can be disabled but may lead to NaN results on failure.