home / skills / multiversx / mx-ai-skills / mvx_constant_time

mvx_constant_time skill

safe

This skill helps verify constant-time cryptographic operations in MultiversX smart contracts, preventing timing attacks by enforcing safe comparison patterns

npx playbooks add skill multiversx/mx-ai-skills --skill mvx_constant_time

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.1 KB

---
name: mvx_constant_time
description: Verifying constant-time operations in crypto implementations.
---

# MultiversX Constant Time Analysis

This skill helps you verify that cryptographic secrets are handled in constant time to prevent timing attacks.

## 1. When to Use
- **Custom Crypto**: If the contract implements Elliptic Curve math, ZK verification, or signatures manually (not using the API).
- **Comparison**: Checking secrets (e.g., comparing user-provided HASH against stored HASH).

## 2. Patterns to Avoid (Variable Time)
- **Early Exit**: `if byte[i] != other[i] { return false }`. This leaks the index of the first difference.
- **Short-circuiting**: `&&` or `||` on secrets.

## 3. MultiversX Solution
- **Managed Types**: Use `ManagedBuffer` comparison provided by the API (often constant time implementation in the VM).
- **Subtle crate**: Use `subtle::ConstantTimeEq` for manual `u8` slice comparisons.

## 4. Verification
- **Measurement**: Difficult on-chain due to Gas Metering. Gas usually leaks the execution trace roughly.
- **Rule**: Rely on the VM's crypto functions (`self.crypto().verify_signature(...)`) instead of implementing it in WASM.

Overview

This skill helps you verify that cryptographic secrets are handled in constant time to prevent timing attacks in MultiversX smart contracts. It focuses on patterns that introduce variable-time behavior and on practical mitigations you can apply during development and review. The goal is to reduce secret-dependent timing leakage by preferring VM-managed crypto and safe comparison primitives.

How this skill works

The skill inspects code patterns that perform secret-dependent branching, early returns, and short-circuit boolean logic when operating on secrets. It recommends using VM-provided crypto primitives and managed types that implement constant-time comparisons, or well-reviewed crates like subtle for manual slice comparisons. Verification guidance explains why measuring constant time on-chain is unreliable and why relying on the platform crypto is safest.

When to use it

When implementing custom elliptic curve math, signature verification, or ZK verification inside WASM.
When comparing secrets such as password hashes, MACs, or authentication tokens.
During code reviews to catch early-exit or short-circuit patterns on secret data.
Before shipping contracts that handle private keys, seeds, or user secrets.

Best practices

Avoid early return on byte-by-byte comparisons; do full-scan comparisons that do not short-circuit.
Do not use && or || short-circuit logic on secret-dependent conditions.
Prefer VM-managed crypto functions (self.crypto().verify_signature(...)) instead of custom WASM implementations.
Use ManagedBuffer comparisons provided by the API when available; they are often constant time in the VM.
If you must compare slices manually, use a reviewed constant-time library such as subtle::ConstantTimeEq.

Example use cases

Reviewing a contract that manually implements signature verification and replacing it with the VM crypto call.
Replacing an early-exit byte comparison used for stored hash checks with a constant-time comparison primitive.
Auditing authentication flows to ensure token equality checks do not reveal mismatch index.
Designing a new contract that handles secrets and choosing ManagedBuffer or subtle-based comparisons up front.
Teaching developers safe comparison patterns during security onboarding for smart contract teams.

FAQ

Can I measure constant time on-chain to prove safety?

No. Gas metering and VM behavior make on-chain timing measurements unreliable; rely on code patterns and VM-provided crypto instead.

Is using subtle::ConstantTimeEq always safe?

subtle is a well-reviewed choice for slice comparisons, but prefer VM-managed primitives for cryptographic operations when available.