Themis: criptografía seria sin morir en el intento

Esta es la parte #2 de Awesome Curated: The Tools, la serie donde analizo en profundidad las herramientas que pasan el filtro de nuestro sistema de curación automático. Si te perdiste el arranque, el post #1 fue sobre Docker for Novices — una joyita que aparece en 16 listas. Hoy el número es más modesto (7), pero el tema es bastante más oscuro: criptografía aplicada.

Hace unos años, laburando en una app que manejaba datos médicos, tuve que implementar cifrado end-to-end entre el cliente mobile y el servidor. La idea era simple: que los datos del paciente nunca viajen en claro, ni siquiera en la base de datos. La ejecución fue una pesadilla. Abrí la doc de OpenSSL y sentí que me habían tirado un manual de física cuántica en alemán. Curvas elípticas, parámetros de padding, longitudes de clave, modos de operación de AES... ¿Tengo que saber todo esto para simplemente cifrar un string? El problema de la crypto para devs no es que sea imposible. Es que la API de bajo nivel te exige un conocimiento que el 95% de los proyectos no necesita — y que si lo hacés mal, no hay warning en runtime. Tu código compila perfecto y tu crypto está rota. Silenciosamente. Eso es lo más peligroso.

Ahí es exactamente donde entra Themis.

Qué hace

Themis es una librería de criptografía de alto nivel, open source (Apache 2.0), desarrollada por Cossack Labs. El pitch es simple: te da primitivas criptográficas serias — ECC, AES, ECDH, ECDSA — pero envueltas en una API que un dev backend puede usar sin necesitar un posgrado en matemáticas. Cubre tres casos de uso principales:

• Secure Cell: cifrado simétrico para almacenar datos en reposo. Pensalo como "quiero guardar esto en la DB y que nadie que acceda a la base pueda leer el contenido". Usa AES-GCM por abajo.
• Secure Message: mensajería asimétrica para intercambio de datos entre dos partes. ECC + ECDSA para firmar, RSA + PSS + PKCS#7 como alternativa. El clásico "encriptalo con la clave pública del destinatario".
• Secure Session: sesiones con forward secrecy. Esto es lo que diferencia a Themis de una librería de cifrado genérica. Usa ECDH para el key agreement — significa que si alguien captura el tráfico hoy y consigue las claves mañana, no puede descifrar lo que capturó. Cada sesión tiene claves efímeras.

El diferencial real es el soporte multi-lenguaje y multi-plataforma. Themis tiene wrappers para Python, Go, JavaScript (Node y browser), Java, Kotlin, Swift, Objective-C, C++, Ruby y PHP. Si tenés un servidor en Go y una app mobile en Swift, los dos hablan el mismo protocolo. No tenés que reimplementar nada ni rezar para que las dos implementaciones sean compatibles.

# Ejemplo: cifrar datos en reposo con Secure Cell (Python)
from pythemis.scell import SCellSeal

# La clave la generás una vez y la guardás segura (env var, secrets manager, etc.)
clave_maestra = b'mi-clave-secreta-de-32-bytes-ok!'
cell = SCellSeal(key=clave_maestra)

# Cifrar — context es opcional pero recomendado (asocia el dato a su contexto)
dato_original = b'datos del paciente muy sensibles'
contexto = b'registro-medico-id-12345'

dato_cifrado = cell.encrypt(dato_original, context=contexto)
# dato_cifrado es bytes — lo guardás en la DB así
print(dato_cifrado)  # bytes ilegibles

# Descifrar — necesitás la misma clave Y el mismo contexto
dato_recuperado = cell.decrypt(dato_cifrado, context=contexto)
print(dato_recuperado)  # b'datos del paciente muy sensibles'

// Ejemplo: Secure Message entre cliente iOS y servidor (Swift)
import themis

// En el cliente: generás tu par de claves
let keyPair = TSKeyGen(algorithm: .EC)!
let clavePublicaCliente = keyPair.publicKey
let clavePrivadaCliente = keyPair.privateKey

// El servidor tiene su propio par. El cliente conoce la clave pública del servidor.
// Encriptás el mensaje con tu clave privada + la pública del servidor
let encryptor = TSMessage(
    inEncryptModeWithPrivateKey: clavePrivadaCliente,
    peerPublicKey: clavePublicaServidor  // la obtuviste en el handshake inicial
)

do {
    let mensajeOriginal = "datos sensibles del usuario".data(using: .utf8)!
    // Solo el servidor (con su clave privada) puede descifrar esto
    let mensajeCifrado = try encryptor.wrap(mensajeOriginal)
    // mandás mensajeCifrado al servidor via HTTP/WebSocket
} catch {
    print("Error de cifrado: \(error)")
}

Por qué está en la lista

Siete listas independientes de awesome no se ponen de acuerdo por accidente. La comunidad de seguridad tiende a ser bastante agnóstica de las modas — si algo llega a ese nivel de consenso en el ecosistema de herramientas de crypto, es porque resuelve un problema real con criterio.

El veredicto del sistema de curación fue WORTH_TRYING, pero yo lo marqué como GEM después de revisarlo en profundidad, y lo sostengo. El motivo principal es el forward secrecy en Secure Session. La mayoría de los devs que implementan crypto en sus apps nunca piensan en esto. Cifran los datos, listo. Pero si un atacante captura tráfico cifrado durante meses y después compromete las claves del servidor, puede descifrar todo ese historial. Con forward secrecy, eso no pasa — las claves efímeras de cada sesión se descartan. Es una propiedad de seguridad que TLS moderno implementa, pero que cuando construís tu propio protocolo de comunicación tenés que pensar explícitamente. Themis lo hace por vos.

Comparado con libsodium — que es la alternativa más directa y tiene una comunidad más grande — Themis gana en el escenario multi-plataforma con mobile. La API de libsodium es excelente pero tenés que hacer más trabajo para que el cliente iOS y el servidor Go se entiendan. Themis resuelve esa capa de interoperabilidad out of the box. Frente al AWS Encryption SDK, la diferencia es obvia: Themis es open source, no te ata a ningún cloud, podés auditarlo vos mismo o pagar a alguien para que lo audite.

Además, Cossack Labs tiene experiencia real en seguridad empresarial. No es un proyecto de una persona que lo mantiene los fines de semana. Han hecho auditorías de la librería (los reportes están disponibles en el repo). Eso pesa cuando estás eligiendo una dependencia de crypto.

Cuándo NO usarlo

La abstracción de Themis es su mayor fortaleza y también su techo. Si tu caso de uso requiere control fino sobre los parámetros criptográficos — elegir el tamaño exacto del nonce, usar un modo de operación específico que Themis no expone, o integrar con un HSM con una API particular — te vas a quedar corto. Para eso, libsodium o directamente OpenSSL/BoringSSL son la respuesta correcta, aunque tengas que bancarte la curva de aprendizaje.

También tenés que evaluar el riesgo de supply chain. Agregar cualquier dependencia de crypto externa es una decisión seria. Themis tiene auditorías, tiene historial, tiene mantenimiento activo — pero si tu organización tiene políticas estrictas sobre qué librerías de seguridad pueden entrar al stack (algo muy común en fintech regulado o salud), necesitás pasar esto por el proceso de aprobación correspondiente. Alternativas a evaluar: libsodium para proyectos donde querés máximo control, AWS Encryption SDK si ya estás all-in en AWS y eso te cierra el tema de auditorías.

Cierre

Si alguna vez abriste la doc de OpenSSL y cerraste la pestaña pensando "hay que ser ingeniero en criptografía para hacer esto", Themis es para vos. No reemplaza entender los conceptos — igual tenés que saber qué es symmetric vs asymmetric encryption, qué significa forward secrecy — pero sí te saca del quilombo de implementar los detalles del protocolo a mano. Y en crypto, los detalles son exactamente donde todo se rompe.

Este fue el post #2 de Awesome Curated: The Tools. Cada herramienta que aparece acá pasó por consenso de múltiples listas, análisis de IA y veredicto humano mío. La serie entera está pensada para que cuando necesités una tool en un dominio específico, tengas un lugar donde alguien ya hizo el trabajo de filtrar el ruido. Si querés seguir la serie, la encontrás completa en /blog/series/awesome-curated-tools.