Onion v3 Addresses Explained: Architecture and Verification

Arquitectura y criptografía de direcciones Onion v3 en Tor: Ed25519, SHA3-256, claves cegadas y verificación contra ataques de suplantación.

En esta página

Los Servicios Onion de la red Tor representan uno de los paradigmas más robustos para la publicación de contenido anónimo y la comunicación resistente a la censura. Con la obsolescencia y retiro definitivo del protocolo Onion v2 en 2021, la arquitectura v3 se consolidó como el estándar absoluto. Esta transición no solo amplió la longitud de las direcciones de 16 a 56 caracteres, sino que redefinió por completo el modelo de seguridad criptográfico, el sistema de publicación de descriptores y los esquemas de autenticación del lado del cliente, mitigando de forma definitiva vulnerabilidades históricas como la enumeración en directorios y los ataques de colisión.

Anatomía Criptográfica de una Dirección Onion v3

Una dirección Onion v3 consta de una cadena alfanumérica de 56 caracteres codificada en Base32, seguida del sufijo de dominio de nivel superior pseudo-genérico .onion. A diferencia de las direcciones web tradicionales reguladas por el DNS, una dirección v3 es un identificador autocontenido y autorregulador que codifica directamente la clave pública del servicio y metadatos de validación criptográfica.

A nivel binario, la cadena de 56 caracteres decodificada representa exactamente 35 bytes de información estructurados según la siguiente especificación del protocolo de Tor:

dirección = base32( CLAVE_PÚBLICA_ED25519 || CHECKSUM || VERSIÓN )

Donde:
- CLAVE_PÚBLICA_ED25519 : 32 bytes (256 bits)
- CHECKSUM              : 2 bytes
- VERSIÓN               : 1 byte (fijado en 0x03)
Total                   : 35 bytes -> 56 caracteres en Base32 RFC 4648

El Algoritmo de Checksum

El mecanismo de checksum garantiza que errores de escritura o corrupciones en el transporte sean detectados localmente por el cliente Tor antes de iniciar cualquier conexión a la red. El cálculo se define matemáticamente mediante la función de hash criptográfico SHA3-256:

CHECKSUM = primeros_2_bytes( SHA3-256( ".onion checksum" || CLAVE_PÚBLICA_ED25519 || VERSIÓN ) )

La inclusión del prefijo en cadena constante ".onion checksum" previene ataques entre protocolos y colisiones de dominio de hash, asegurando que la salida no pueda ser reutilizada en otros contextos criptográficos del protocolo Tor.

Criptografía Subyacente: Curvas Elípticas y Resistencia a Ataques

La transición de la versión 2 a la 3 supuso el reemplazo integral de primitivas criptográficas obsoletas por estándares modernos de alta seguridad y rendimiento:

  • Ed25519 sobre Curve25519: Reemplaza el esquema RSA-1024 de v2. Ed25519 proporciona aproximadamente 128 bits de nivel de seguridad frente a los vulnerables 80 bits efectivos de RSA-1024. Permite operaciones de firma digital deterministas y resistentes a ataques de canal lateral.
  • SHA3-256 (Keccak): Sustituye a SHA-1, eliminando la exposición teórica y práctica a ataques de colisión de prefijo elegido que amenazaban la unicidad de las direcciones v2.
  • Curvas Biracionales de Montgomery y Edwards: Para el intercambio de claves en la fase de establecimiento del circuito se utiliza X25519, convirtiendo eficientemente las claves públicas de Edwards (Ed25519) a coordenadas de Montgomery para optimizar el protocolo Diffie-Hellman.

El Problema de la Enumeración y la Solución de Claves Cegadas (Blinded Keys)

En el protocolo v2, los nodos de directorio de servicios ocultos (HSDir) podían registrar y almacenar de forma pasiva todas las direcciones que publicaban sus descriptores, permitiendo el escaneo, indexación no autorizada y eventual hostigamiento de servicios. El protocolo v3 resuelve este problema de manera matemática mediante el uso de claves públicas cegadas (blinded public keys).

Un servicio v3 nunca publica su clave pública Ed25519 estática en los nodos HSDir. En su lugar, deriva periódicamente una clave derivada efímera combinando su clave estática con un valor de tiempo y el estado global de consenso de la red:

Clave_Cegada = Clave_Maestra + H(Clave_Maestra || Valor_Aleatorio_Compartido || Periodo_Tiempo) * G

Dado que los nodos HSDir solo reciben Clave_Cegada y el descriptor cifrado, les resulta matemáticamente imposible computar la clave pública original Clave_Maestra debido a la dureza del problema del logaritmo discreto sobre la curva elíptica. Solo un cliente que ya conoce la dirección .onion completa puede derivar la misma clave cegada, calcular el índice de consulta en el anillo de hash (hash ring) y solicitar el descriptor correspondiente.

Estructura del Descriptor y Cifrado en Múltiples Capas

El descriptor de un servicio onion contiene los datos necesarios para establecer la comunicación: lista de puntos de introducción (Introduction Points), claves de autenticación y certificados de autorización. En v3, este documento se cifra en dos capas distintas:

  1. Capa Externa: Cifrada con una clave simétrica derivada directamente de la Clave_Cegada. Impide que cualquier nodo intermediario en la red descubra los contenidos del descriptor sin autorización implícita de consulta.
  2. Capa Interna: Contiene las claves de cifrado y las direcciones IP de los puntos de introducción seleccionados por el servicio. Si el servicio activa la función de autorización de cliente (Client Authorization), esta capa se cifra individualmente utilizando las claves públicas X25519 de cada usuario autorizado.
El descriptor de un servicio v3 con autorización de cliente activa es completamente opaco: los nodos HSDir desconocen qué servicio se aloja, y los observadores no pueden deducir cuántos clientes tienen acceso legítimo al recurso.

El Ciclo de Conexión: De la Resolución al Rendezvous

El flujo operativo para establecer un canal de comunicación anónimo de extremo a extremo prescinde de cualquier resolución DNS externa y se ejecuta de forma descentralizada:

  1. Publicación: El servicio onion selecciona un conjunto de nodos Tor como Introduction Points, establece circuitos hacia ellos y publica su descriptor cifrado en los HSDir asignados en el anillo hash mediante su clave cegada del periodo.
  2. Consulta: El cliente parsea la dirección .onion de 56 caracteres, deriva la clave cegada del periodo actual, contacta al HSDir correspondiente y descarga el descriptor cifrado.
  3. Descifrado: El cliente descifra la capa exterior con la clave cegada (y la interior con su clave privada X25519 si se requiere autorización) para obtener las identidades de los Introduction Points.
  4. Punto de Encuentro (Rendezvous): El cliente crea un circuito de tres saltos hacia un nodo aleatorio de la red y lo designa como Rendezvous Point, entregándole un secreto compartido (cookie de encuentro).
  5. Introducción: El cliente envía un mensaje cifrado de extremo a extremo a través de uno de los Introduction Points del servicio, indicándole la dirección del Rendezvous Point y la cookie.
  6. Conexión: El servicio establece un circuito hacia el Rendezvous Point, le presenta la cookie y ambos circuitos se unen. A partir de este momento, cliente y servicio ejecutan un intercambio Diffie-Hellman autenticado y comienzan a intercambiar tráfico cifrado sin conocer recíprocamente sus direcciones IP.

Verificación Manual y Mitigación de Typosquatting

Aunque la criptografía de Onion v3 es robusta contra ataques de fuerza bruta tradicionales, la longitud de 56 caracteres introduce un vector de riesgo operacional: la incapacidad del ser humano para memorizar e inspeccionar visualmente la dirección en su totalidad. Esto habilita ataques de suplantación mediante direcciones vanidosas (vanity addresses) generadas con herramientas optimizadas por GPU como mkp224o.

Un actor malicioso puede generar una clave cuya representación Base32 coincida en los primeros 8 a 14 caracteres con una dirección legítima de alta reputación, induciendo a error al usuario:

Legítimo : duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
Falsificado: duckduckgo55xk2p...[resto de caracteres aleatorios]...onion

Buenas Prácticas Defensivas para Investigadores y Usuarios

  • Verificación Criptográfica de Suma: Implementar scripts locales o utilidades integradas en clientes como Tor Browser que validen la consistencia de los 2 bytes de checksum antes de registrar marcadores o autorizar accesos críticos.
  • Uso de Onion-Location: Los administradores de sistemas deben implementar la cabecera HTTP Onion-Location en sus servidores Clearnet acompañados de certificados TLS válidos, permitiendo que el navegador verifique la autenticidad de la dirección v3 sin intervención manual propensa a errores.
  • Autenticación de Cliente Obligatoria: Para infraestructuras de backend, acceso a bases de datos o paneles de administración defensivos, se debe configurar directivas onion-client-auth en el archivo torrc, inhabilitando totalmente el acceso a cualquier cliente que no posea la clave privada X25519 correspondiente.

Conclusión

La arquitectura de las direcciones Onion v3 constituye un estándar de ingeniería criptográfica donde convergen el anonimato de enrutamiento y la criptografía asimétrica moderna. Al integrar una clave pública Ed25519 completa, verificación SHA3-256 y un sistema dinámico de claves cegadas dentro de una dirección de 56 caracteres Base32, el protocolo Tor garantiza confidencialidad hacia adelante, resistencia a la enumeración y una barrera matemáticamente infranqueable contra ataques de suplantación directa. Para periodistas, investigadores de seguridad y operadores de sistemas, comprender esta arquitectura es el primer paso indispensable para auditar, desplegar y verificar infraestructuras críticas en entornos hostiles.

Palabras clave
TorOnion v3Ed25519SHA3-256criptografíaservicios ocultosprivacidad digitalseguridad defensiva