constant-time-analysis

Descripción general de constant-time-analysis

constant-time-analysis es una skill de auditoría de seguridad para detectar riesgos de canales laterales de tiempo en código criptográfico antes de que se conviertan en fallos explotables. Es la opción más adecuada para ingenieros, revisores y agentes de IA que necesitan comprobar si operaciones, ramas, comparaciones o instrucciones de ejecución dependientes de datos secretos podrían filtrar claves, tokens u այլores valores sensibles.

La tarea principal no es “entender la teoría criptográfica”, sino “detectar dónde este código deja de ser de tiempo constante”. Por eso, constant-time-analysis resulta especialmente útil durante revisiones de implementación, controles de seguridad previos al merge y triage de incidentes cuando alguien quiere saber si una función es segura frente a ataques de temporización.

Lo que la diferencia de un prompt genérico es que está pensada alrededor del output compilado y de rutas de análisis específicas por lenguaje, no solo del escaneo del código fuente. Esto importa porque los problemas de tiempo constante suelen aparecer en ensamblador, bytecode o instrucciones de la VM incluso cuando el código fuente parece inocuo.

Mejor encaje de constant-time-analysis para auditoría de seguridad

Usa esta skill cuando revises código que:

• gestiona secretos, autenticación o primitivas criptográficas
• usa división, módulo, comparación o branching sobre valores derivados de secretos
• necesita validación sobre artefactos compilados, no solo sobre la intención del código fuente
• apunta a C, C++, Go, Rust, Swift, Java, Kotlin, PHP, JavaScript, TypeScript, Python o Ruby

Qué detecta y qué no detecta

constant-time-analysis es muy sólida para patrones de fuga por tiempo como divisiones de tiempo variable, ramas dependientes de secretos y comparaciones inseguras. Es menos eficaz para errores más amplios de diseño criptográfico, fallos de protocolo o fugas causadas por red, caché o ruido del entorno, salvo que esos problemas aparezcan en la ruta de código analizada.

Por qué la gente la instala

Instala esta skill cuando quieras un flujo de revisión repetible que pueda señalar riesgos de tiempo antes que una lectura manual rápida. Si solo necesitas una opinión puntual sobre un fragmento, puede bastar un prompt normal; si necesitas un comportamiento de revisión de seguridad consistente, la skill aporta estructura.

Cómo usar la skill constant-time-analysis

Instálala y actívala correctamente

Usa la ruta de instalación de constant-time-analysis desde tu gestor de skills y ejecútala en un contexto que incluya el lenguaje objetivo y la función o archivo sensible. Un buen prompt de activación nombra el objetivo criptográfico, las entradas secretas y el lenguaje/runtime, para que la skill elija la ruta de análisis adecuada.

Ejemplo de activación:

• “Revisa src/sign.rs para detectar riesgo de tiempo constante. La entrada secreta es el escalar de la clave privada; céntrate en división, ramas y comparaciones.”
• “Ejecuta constant-time-analysis sobre esta función PHP de comprobación de contraseñas y dime si es probable que exista alguna fuga de tiempo a nivel de opcode.”

Dale la forma de entrada adecuada

La skill funciona mejor cuando proporcionas:

• el archivo o la función a inspeccionar
• qué valores son secretos
• qué comportamiento observable para un atacante importa
• el lenguaje y la versión del runtime de destino, si se conocen

Mejor entrada:

• “Audita verifyToken() en TypeScript. Los bytes del token son secretos; compáralos con el HMAC almacenado; comprueba Div, Mod y comparaciones con salida anticipada.”
• “Analiza esta rutina reduce() en Rust para detectar división dependiente de secretos en x86_64 y arm64.”

Lee primero estos archivos

Para decidir si encaja y entender el flujo de trabajo, empieza por:

• SKILL.md para ver disparadores, alcance y selección de lenguaje
• README.md para los lenguajes compatibles y los objetivos del output
• references/compiled.md para C/C++, Go y Rust
• references/javascript.md, references/python.md, references/php.md, references/ruby.md, references/swift.md, references/kotlin.md para reglas específicas de la VM

Si solo vas a leer un archivo de referencia, elige el que coincida con tu ruta de ejecución, no con la etiqueta del lenguaje fuente.

Usa un flujo de revisión, no una sola pasada

Un flujo práctico de uso de constant-time-analysis es:

1. identificar la función que contiene secretos
2. ejecutar la guía del lenguaje correspondiente
3. inspeccionar cualquier división, módulo, comparación, rama o llamada auxiliar sospechosa
4. volver a ejecutar tras refactorizaciones o cambios del compilador/runtime
5. pedir una salida apta para CI si quieres validar el resultado de forma automática

Esto importa porque una corrección en el código fuente puede seguir compilándose en instrucciones inseguras, sobre todo en lenguajes compilados.

Preguntas frecuentes sobre la skill constant-time-analysis

¿constant-time-analysis es solo para criptografía?

No. Sirve para cualquier código en el que importen las diferencias de tiempo sobre datos secretos, pero normalmente eso significa criptografía, autenticación, manejo de claves y verificación de tokens. Si el código solo procesa datos públicos, probablemente no haga falta.

¿Necesito saber ensamblador o bytecode?

No para empezar. La skill es útil precisamente porque te orienta hacia el artefacto de runtime correcto y la referencia específica del lenguaje. No necesitas leer cada instrucción, pero sí saber qué función o archivo es sensible desde el punto de vista de seguridad.

¿constant-time-analysis es mejor que un prompt normal?

Sí, cuando necesitas un comportamiento de revisión de seguridad repetible. Un prompt normal puede detectar riesgos evidentes, pero constant-time-analysis resulta más útil para trabajo sobre repositorios porque se organiza en torno a la selección de lenguaje, el output compilado y patrones concretos de fuga.

¿Cuándo no debería usarla?

No la uses para lógica de negocio corriente, código de interfaz o transformaciones sobre datos públicos. Tampoco la uses cuando la librería ya garantiza comportamiento de tiempo constante y solo preguntas por el uso de la API a alto nivel sin lógica personalizada dependiente de secretos.

Cómo mejorar la skill constant-time-analysis

Enfócate en el secreto y en el modelo de atacante

Los mejores resultados de constant-time-analysis llegan cuando indicas con precisión qué debe permanecer secreto y qué puede observar el atacante. Di si el riesgo es temporización remota, temporización en proceso local o inspección del código compilado. Sin eso, la skill puede sobrerreaccionar ante ramas inocuas o pasar por alto la restricción real.

Proporciona la ruta de código más pequeña que sea riesgosa

Entrega la función que realmente toca datos secretos, no todo el repositorio. Si la ruta incluye helpers, inclúyelos solo cuando influyan en branching, aritmética o comparaciones. Así reduces ruido y haces que el resultado sea más accionable.

Pide evidencia específica del lenguaje

Para obtener mejores resultados, pide a la skill que revise el artefacto de runtime relevante:

• ensamblador para C/C++, Go y Rust
• bytecode para JavaScript, TypeScript, Python, Ruby y PHP
• comportamiento de la JVM para Kotlin

Eso mejora el uso de constant-time-analysis porque las fugas de tiempo suelen aparecer por debajo del nivel del código fuente.

Repite la prueba después de cada corrección

Un fallo habitual es arreglar el código fuente y asumir que la fuga desapareció. Vuelve a probar después de cambiar el algoritmo, las flags del compilador, el nivel de optimización o la versión del runtime. Para constant-time-analysis para auditoría de seguridad, esa segunda pasada es a menudo la que confirma la postura de seguridad real.