Un pipeline criptográfico real en Eskiu

La carga de trabajo

La credencial de elector del INE de México lleva dos códigos QR que empacan 18 campos biográficos más la foto de la credencial detrás de un pipeline criptográfico de siete capas: múltiples rondas de AES-256-CBC con llaves derivadas en tiempo de ejecución, descifrado de bloques RSA-8192, una etapa base64 y un desempacador de texto de 6 bits. Decodificar una empieza desde una foto de la tarjeta: detectar y leer los dos payloads QR, luego correr todo el pipeline para recuperar los campos y reconstruir la foto. Es una mezcla compacta pero implacable de manejo de imagen, criptografía de verdad y manipulación de bits byte a byte: justo el tipo de código que normalmente le toca a C y a nadie más.

Por qué encajó Eskiu

• Bibliotecas de C, directo. El pipeline se apoya en OpenSSL para AES/RSA y zxing-cpp para el lector de QR. Eskiu habla el ABI de C nativamente, así que llama a ambas con simples declaraciones extern, sin capa de wrappers.
• Memoria que administras. Cada buffer intermedio es un alloc<T>(n) / free explícito. Todo el patrón de asignación es visible en el código, lo que importa cuando un solo free olvidado filtra un buffer descifrado.
• Un servicio sin framework. El decodificador se envuelve en una API HTTP (POST /decode, multipart o JSON, con auth por API-key y rate limiting) construida enteramente sobre la biblioteca estándar de Eskiu (<http>, <json>, <base64>, hilos), sin dependencia externa.
• Nativo, sin runtime. Compila directo a un binario nativo pequeño vía LLVM, así que aterriza en un host Linux con solo las dos bibliotecas de C que enlaza.

Idéntico bit a bit en todo el stack

El decodificador existe en seis implementaciones, mantenidas en sincronía para que un cambio al algoritmo se detecte en todas: C puro y Python, WebAssembly (en el navegador), un AAR de Android, un XCFramework de iOS y la ruta de Eskiu. Las seis producen salida idéntica byte por byte desde la misma credencial. La implementación en Eskiu es un par completo de ese conjunto, no un port de juguete, y su pipeline cripto corre 2.5× más rápido que el C de referencia contra el que se midió.

El dogfooding mejoró el lenguaje

Mover el decodificador al compilador actual fue en sí mismo una prueba del lenguaje. El código cripto está lleno de patrones de adquirir-luego-liberar, así que defer / errdefer colapsaron unas quince llamadas manuales de limpieza, y ocho cascadas de limpieza en rutas de error, en una sola línea cada una, volviendo imposible toda una clase de fugas de buffer (verificado sin fugas bajo AddressSanitizer). Un build --safe agrega chequeos de límites para parsear imágenes no confiables.

Más revelador: ejercitar código real sacó a la luz dos mejoras concretas que entraron de vuelta al compilador en la v0.6.1. Rebanar un puntero crudo de heap (ptr[lo..hi]) crasheaba la generación de código; ahora construye un slice apropiado, así que los buffers de heap, no solo los arreglos fijos, se pueden rebanar. Y se agregó un escape hex \xNN a los literales de string y de carácter para datos byte-precisos. El decodificador necesitaba ambos; el lenguaje creció para cumplir.

Así que el mismo lenguaje que arranca un kernel ARM64 bare-metal, y mete un módulo ajustado en memoria dentro de un motor de renderizado C++ (ve el caso de estudio de ReactVision), también decodifica un formato criptográfico real a velocidad nativa y lo sirve por HTTP. Un solo lenguaje a lo largo del stack, usado donde conviene.