Criptografía poscuántica on Arpokrat

Data Act vs CLOUD Act: ¿quién controla realmente sus datos en la nube?

Fri, 19 Jun 2026 00:00:00 +0000

Durante años, el mundo funcionó sobre una hipótesis simple: los datos tienen un lugar de residencia física. Si se encontraban en un servidor en Dublín, estaban sujetos al derecho irlandés y europeo. Esta hipótesis se derrumbó en 2018, cuando Estados Unidos adoptó el CLOUD Act, una ley que otorga a las autoridades estadounidenses acceso a los datos controlados por empresas americanas, independientemente de dónde estén físicamente almacenados en el mundo. Varios años más tarde, Bruselas respondió con su propio mecanismo de protección: el Data Act, ahora plenamente aplicable, que intenta limitar el acceso extraterritorial de las autoridades de terceros países a los datos conservados en la Unión Europea.

A continuación se expone lo que realmente prevén estos dos textos, dónde entran en colisión, y por qué la única protección verdaderamente sólida frente a este conflicto sigue siendo la imposibilidad técnica de acceso.

El CLOUD Act estadounidense: un acceso basado en el control, no en la localización

El CLOUD Act (Clarifying Lawful Overseas Use of Data Act), adoptado en marzo de 2018, modificó el derecho estadounidense añadiendo el artículo 18 U.S. Code § 2713. Este texto obliga a todo proveedor de servicios de comunicación electrónica o de computación en la nube a conservar, salvaguardar o divulgar el contenido de una comunicación o cualquier registro relacionado con ella, cuando dichos datos estén en su posesión, custodia o control, independientemente de si esos datos se encuentran dentro o fuera de Estados Unidos.

Es precisamente esta última cláusula la que lo cambia todo. El criterio ya no es la ubicación física del servidor, sino el control ejercido por la empresa matriz sobre sus filiales. Una empresa estadounidense que opera centros de datos en Europa sigue estando sujeta a las órdenes de divulgación americanas, incluso para datos almacenados íntegramente en suelo europeo.

El Data Act europeo: una barrera jurídica al acceso extraterritorial

El Reglamento (UE) 2023/2854, conocido como Data Act, entró en vigor el 11 de enero de 2024 y es plenamente aplicable desde el 12 de septiembre de 2025, con algunas disposiciones escalonadas hasta 2026 y 2027. Su artículo 32 aborda directamente la cuestión del acceso gubernamental internacional a los datos.

El texto establece una regla clara: toda decisión o resolución de un órgano jurisdiccional o autoridad administrativa de un tercer país que exija a un proveedor de servicios de tratamiento de datos que transfiera o dé acceso a datos no personales conservados en la Unión Europea solo será reconocida y ejecutable si se basa en un acuerdo internacional, como un tratado de asistencia judicial mutua (MLA), vigente entre el país solicitante y la Unión, o entre dicho país y el Estado miembro afectado.

A falta de tal acuerdo, el artículo 32 prevé una segunda vía, aunque estrictamente encuadrada: la decisión extranjera solo podrá ejecutarse si el sistema jurídico del tercer país exige que la solicitud esté motivada, sea proporcionada y suficientemente específica —por ejemplo, estableciendo un vínculo claro con personas o infracciones concretas— y si la oposición motivada del destinatario puede someterse al control de un órgano jurisdiccional competente de dicho tercer país.

Una colisión jurídica directa

El problema es inmediato: el CLOUD Act exige una divulgación basada en el control ejercido por la empresa matriz, sin condición de proporcionalidad comparable a la exigida por el derecho europeo. El Data Act, por el contrario, subordina el reconocimiento de tal solicitud a la existencia de un acuerdo internacional o a garantías procesales precisas. Una empresa estadounidense que opera en Europa, requerida por una autoridad americana para transmitir datos alojados en la Unión, queda atrapada entre dos obligaciones legales contradictorias: cumplir el mandato estadounidense violando el derecho de la Unión, o respetar el Data Act exponiéndose a las consecuencias de una negativa en Estados Unidos.

Esta tensión no es teórica. Ya ha sido documentada por el Tribunal de Justicia de la Unión Europea (TJUE) en dos decisiones fundamentales, Schrems I (2015) y Schrems II (2020). En la sentencia Schrems II, el TJUE consideró que la vigilancia estadounidense llevada a cabo al amparo de la Sección 702 de la FISA (Foreign Intelligence Surveillance Act) y de la Orden Ejecutiva 12333 no respeta las garantías mínimas exigidas por el derecho de la Unión en virtud del principio de proporcionalidad, y por tanto no puede considerarse limitada a lo estrictamente necesario. El Tribunal también señaló la ausencia de una vía de recurso judicial efectiva para los interesados de la Unión, en vulneración del artículo 47 de la Carta de los Derechos Fundamentales. Esta decisión invalidó el marco del Privacy Shield, que hasta entonces regulaba las transferencias de datos entre la UE y Estados Unidos.

El riesgo estructural: Harvest Now, Decrypt Later

Más allá del conflicto de jurisdicciones, una amenaza más insidiosa pesa sobre los datos alojados en infraestructuras sujetas al derecho estadounidense: la estrategia conocida como Harvest Now, Decrypt Later (HNDL). El principio consiste, para un servicio de inteligencia o un actor estatal hostil, en interceptar y almacenar desde ahora datos cifrados, a la espera de capacidades de cómputo cuántico suficientes para descifrarlos en el futuro.

Esta estrategia convierte cualquier dependencia prolongada de una infraestructura cloud estadounidense en una deuda de seguridad diferida: lo que hoy es confidencial puede volverse legible en diez o quince años, sin que el atacante necesite realizar ninguna acción adicional, solo tiempo y paciencia.

Por qué solo la imposibilidad técnica constituye una garantía real

El análisis jurídico converge hacia una constatación compartida por numerosos expertos en cumplimiento normativo: por sólido que sea el marco legal del Data Act, sigue siendo un texto que las relaciones de fuerza geopolíticas y las presiones diplomáticas pueden eludir, retrasar o reinterpretar. La única protección que no depende de ninguna negociación futura es la imposibilidad técnica de ejecución.

Una arquitectura zero knowledge, en la que el proveedor no posee ni la custodia ni el control de las claves de descifrado, hace que una orden de divulgación sea materialmente inoperante. No se puede ser obligado a entregar lo que nunca se ha poseído.

Esta es la lógica que estructura ecosistemas como Arpokrat:

Neutralización jurisdiccional: la infraestructura está alojada en Suiza, bajo el régimen de la Ley Federal de Protección de Datos (LPD/FADP), fuera del ámbito de aplicación directa de la extraterritorialidad del CLOUD Act
Ausencia de custodia: la arquitectura zero knowledge priva al proveedor de cualquier capacidad para entregar claves o contenidos que nunca ha poseído
Reducción de la huella identitaria: al eliminar la obligación de registro mediante número de teléfono o dirección de correo electrónico —identificadores que la vigilancia basada en la Sección 702 de la FISA puede rastrear fácilmente—, el usuario deja de ser un abonado identificable para convertirse en una clave criptográfica anónima

La cadena de custodia no termina en el cifrado de los mensajes

Un punto frecuentemente subestimado en los análisis de cumplimiento: no basta con cifrar el contenido de una comunicación si el sistema operativo subyacente, ya sea Android o iOS, continúa capturando metadatos o telemetría a nivel de núcleo, con destino a servidores sujetos a la jurisdicción estadounidense. La protección del secreto exige un cierre completo de la cadena de custodia, desde el contenido hasta la propia infraestructura material.

Por esta razón, la soberanía digital implica también una reflexión sobre el sistema operativo utilizado, no solo sobre las aplicaciones de mensajería. Los sistemas desgooglelizados, en los que módulos como el Bluetooth o la geolocalización GNSS pueden desactivarse directamente a nivel de núcleo, eliminan vectores de ataque físicos que ningún cifrado a nivel de aplicación puede compensar.

La criptografía poscuántica, un horizonte ya comprometido

Ante la amenaza que representa la estrategia HNDL, la adopción de estándares de criptografía poscuántica (PQC) se convierte en una necesidad para cualquiera que desee garantizar la confidencialidad de datos sensibles a largo plazo, ya se trate de secretos empresariales, correspondencia profesional o datos de salud. Un cifrado considerado robusto hoy según los estándares clásicos no garantiza que resistirá las capacidades de cómputo cuántico esperadas en los próximos quince años.

El conflicto entre el Data Act y el CLOUD Act ilustra una realidad más amplia: la soberanía digital ya no puede construirse únicamente sobre textos legales, por sólidos que sean. Exige un cierre de la cadena de custodia en cada nivel, desde el protocolo de cifrado hasta la jurisdicción de alojamiento, pasando por el propio sistema operativo. Es este enfoque por capas, más que una confianza depositada en un único marco regulatorio, lo que define hoy una verdadera soberanía digital por diseño.

Contraseña y Entropía: La ciencia detrás de tu seguridad

Wed, 03 Jun 2026 00:00:00 +0000

« Tu contraseña debe tener 8 caracteres, una mayúscula, una minúscula, un número y un carácter especial. »

Todos conocemos esta regla. Y, sin embargo, en ciberseguridad, a esto se le llama “teatro de seguridad”. Una contraseña como P@ssw0rd1! respeta todas estas reglas. Pero es una palabra común con sustituciones previsibles, justo lo que las herramientas de cracking prueban primero.

La verdadera seguridad no se basa en reglas visuales arbitrarias, sino en una realidad matemática implacable: la entropía.

La Entropía según Claude Shannon

Para comprender la fuerza de una contraseña, hay que dirigirse a Claude Shannon, el padre de la teoría de la información. La entropía mide el grado de incertidumbre o imprevisibilidad de una información.

Aplicada a las contraseñas, la entropía se calcula en bits. Cuanto mayor sea el número de bits, más impredecible será la contraseña para un ordenador. La fórmula simplificada de la entropía (E) de una contraseña generada aleatoriamente es:

E = L × log2(R)

L es la longitud de la contraseña.
R es el tamaño del repertorio (26 para las minúsculas, 62 con mayúsculas y números, 94 con todos los símbolos imprimibles). Los cuatro conjuntos de caracteres de nuestro generador suman 91, porque su conjunto de símbolos tiene 29 caracteres.

Aumentar el tamaño del repertorio (añadir símbolos) aumenta la entropía, pero aumentar la longitud (añadir caracteres) la aumenta de forma mucho más drástica. Sin embargo, la longitud solo supera a la complejidad con una única condición: que la contraseña se genere de forma aleatoria.

Fuerza bruta vs Ataque de diccionario

Si utilizas palabras o estructuras predecibles, la regla de la longitud pura se derrumba.

Los softwares de piratería no intentan todas las combinaciones de letras una a una (lo que se llama Fuerza Bruta). Utilizan enormes listas de contraseñas reales filtradas en fugas de datos anteriores, junto con palabras y frases comunes. Esto es el Ataque de Diccionario.

Si tu contraseña es larga, pero está compuesta por palabras del diccionario o sustituciones predecibles, su entropía real es drásticamente inferior a su entropía matemática teórica.

La tabla siguiente usa una sola regla: 100 mil millones de intentos por segundo, el ritmo que la página de nuestro generador asume para un ataque sin conexión contra un hash rápido. Los tiempos son promedios (la mitad de todas las posibilidades), redondeados hacia abajo con la misma fórmula que esa página. La ruta más rápida para cada contraseña está en negrita:

Contraseña	Entropía si cada carácter fuera aleatorio	Fuerza bruta (promedio)	Ataque de diccionario (nuestra estimación)
`password123`	56 bits (11 caracteres, minúsculas y números)	7 días	Menos de un segundo
`S3cr3t!99`	58 bits (9 caracteres, los cuatro conjuntos)	24 días	Menos de un segundo
`correct horse battery staple`	133 bits (28 caracteres, minúsculas y espacio)	Más de 1 billón de años	1 minuto
`gL7!pQ9z#vX2`	78 bits (12 caracteres, los cuatro conjuntos)	51 mil años	Ningún atajo

La columna de diccionario es una estimación. Supone que los intentos del atacante siguen la estructura de cada contraseña, y que cada palabra base está entre las 1000 más comunes:

password123: una palabra común y tres dígitos. Son 1000 × 1000, alrededor de un millón de intentos.
S3cr3t!99: una palabra común, con o sin mayúscula, cada “e” cambiada o no por “3”, y después cualquier sufijo de tres caracteres. Son unos 7 mil millones de intentos.
correct horse battery staple: cuatro palabras comunes. El cómic de xkcd que la hizo famosa cuenta 44 bits para cuatro palabras de una lista de 2048. Al mismo ritmo, son 88 segundos de promedio, redondeados hacia abajo a 1 minuto.
gL7!pQ9z#vX2: ninguna palabra y ningún patrón, así que la fuerza bruta es la ruta más rápida.

Estas estimaciones tratan cada contraseña como desconocida para el atacante. Todas las contraseñas de este artículo son ahora públicas, así que cada una tiene su sitio en un diccionario. Una contraseña publicada es una contraseña quemada.

La ilusión del Leetspeak y las reglas de mutación

Tomemos el ejemplo de S3cr3t!99. Visualmente, parece compleja y robusta. Sin embargo, es simplemente la palabra del diccionario “secret”, donde las ’e’ han sido reemplazadas por ‘3’, a la que se ha añadido un sufijo muy común (!99). A esto se le llama leetspeak.

Frente a un ataque de diccionario, esta contraseña aguanta menos de un segundo, no los 24 días que su longitud haría pensar. Los softwares de descifrado modernos (como Hashcat) no se conforman con probar listas de palabras estáticas; aplican automáticamente reglas de mutación. Cogerán cada palabra de su diccionario, probarán todas las combinaciones posibles de leetspeak, invertirán las mayúsculas y añadirán años o símbolos. El leetspeak ofrece una falsa sensación de seguridad.

El truco del cambio de teclado (Keyboard Shift)

Para complicar una frase fácil de memorizar, algunos utilizan el truco del cambio de disposición del teclado. Por ejemplo, memorizas una frase como my-cat. Pero en el momento de teclearla, pones los dedos en un teclado físico QWERTY mientras tienes tu sistema operativo configurado en AZERTY (francés).

La palabra pensada: my-cat
El resultado tecleado: ,y)cqt (La tecla ’m’ se convierte en ‘,’; el ‘-’ se convierte en ‘)’; la ‘a’ se convierte en ‘q’).

¿Es esta una buena idea en OPSEC? No, este método no es suficiente si se utiliza solo. Igual que el leetspeak, un cambio de distribución de teclado es una sustitución fija: un atacante que la sospecha aplica la misma correspondencia a cada intento. En OPSEC, esto es seguridad por oscuridad: retrasa a un atacante aficionado, pero no detendrá un ataque dirigido y equipado.

Combinada con una contraseña que ya es fuerte (como una frase de contraseña larga y aleatoria), aporta poco. Incluso si un atacante prueba mil pares de distribuciones, eso añade menos de 10 bits, ya que log2(1000) ≈ 9,97. La fuerza sigue viniendo de la frase de contraseña de base.

Construir una contraseña maestra (~250 bits)

Si las listas de palabras, el leetspeak y los trucos de escritura tienen sus límites, ¿cómo construimos una contraseña maestra que perdure? Nuestro generador ya califica 80 bits como “Fuerte” y 100 bits como “Muy Fuerte”. Para una contraseña maestra pensada para durar décadas, este artículo apunta mucho más alto: unos 250 bits de entropía. La sección cuántica más abajo explica por qué, y lo que ese margen no aporta.

Hay dos formas de lograrlo según tus necesidades:

1. Caracteres aleatorios (para un gestor de contraseñas)

Una cadena de caracteres generada totalmente al azar, sin ningún patrón que una máquina pueda aprovechar: 8}8,_$-p)M&n,XvUCT0o+.5hDE6P^w6b@U-evS0 39 caracteres sacados al azar de los 91 de nuestro generador: ≈ 253 bits. Se generó para este artículo, así que ahora es pública. No la uses nunca.

2. Una frase de contraseña aleatoria (para una contraseña que memorizas)

Las palabras aleatorias son más fáciles de recordar que los caracteres aleatorios. Cada palabra sacada de la lista de la EFF de 7776 palabras añade unos 12,9 bits, así que es el número de palabras lo que da la entropía. Doce palabras dan ≈ 155 bits, muy por encima del umbral “Muy Fuerte” de nuestro generador. Las palabras solas solo superan los 250 bits a partir de 20 palabras.

Nuestro generador llega como máximo a 12 palabras. Para superar los 250 bits con menos, marca “Dígito aleatorio tras cada palabra” y elige “Dígito + Símbolo” como separador. Once palabras dan entonces ≈ 260 bits: depletion78$sporting14~overlap11>macaw86>paced95,paramedic41}blot41$flagstone07;uncanny92/broadways77#say2 Generada al azar para este artículo, exactamente con esos ajustes. Una contraseña publicada es una contraseña quemada: no uses nunca esta, ni ningún ejemplo que leas. Solo cuenta lo que se saca al azar. Poner en mayúscula cada palabra no añade nada, y las palabras que eliges tú son mucho más débiles que las aleatorias.

La amenaza cuántica: El algoritmo de Grover

¿Por qué aspirar a 250 bits cuando 128 bits ya bloquean los superordenadores de hoy en día? La respuesta reside en la perspectiva de grandes ordenadores cuánticos.

En criptografía, el algoritmo de Grover permite a un ordenador cuántico buscar en una base de datos no ordenada mucho más rápido que un ordenador clásico. En concreto, Grover reduce a la mitad el nivel de seguridad efectivo de una clave simétrica o de una contraseña.

Frente a un ordenador cuántico que ejecute el algoritmo de Grover, una contraseña con una entropía de 128 bits ofrecería, en teoría, una resistencia equivalente a solo 64 bits. Es un margen mucho más estrecho.

Duplicar la entropía mantiene el margen: unos 256 bits seguirían dejando unos 128 bits frente a Grover. De ahí viene el objetivo de 250 bits de este artículo. Es una precaución que elige este artículo, no una cifra tomada de un estándar.

El margen tiene límites. La aceleración de Grover es cuadrática, no ilimitada. Cada uno de sus pasos sigue teniendo que calcular el hash de la contraseña del sitio, en un ordenador cuántico lo bastante grande como para ejecutarlo. Como comparación, a los 100 mil millones de intentos por segundo que asume la página de nuestro generador, una búsqueda promedio de 100 bits ya tarda al menos 200 mil millones de años.

La lógica se parece a Harvest Now, Decrypt Later (HNDL): una base de datos robada de hashes de contraseñas puede guardarse hoy y atacarse más tarde, con mejores máquinas. Un margen mayor eleva el nivel de exigencia frente a eso. No es una garantía permanente.

Arpokrat Password Generator: Crea la tuya

No dejes la seguridad de tus accesos al azar. Nuestro generador gratuito crea contraseñas y frases de contraseña aleatorias. Para cada una, muestra la entropía en bits y el tiempo promedio que tardaría una búsqueda.

Solo genera: no califica una contraseña que ya uses. Para el objetivo de 250 bits de arriba, elige una contraseña de 39 caracteres con los cuatro conjuntos de caracteres. El generador la muestra como “≈ 253 bits”.

👉 Arpokrat Password Generator

Funciona en tu navegador. Lo que genera nunca se envía ni se guarda.

El eslabón débil final: Reciclaje y gestión de accesos

La entropía matemática no protege contra el error humano. Una contraseña de 250 bits pierde su valor en cuanto se filtra, si se reutiliza en varios sitios (un ataque llamado Credential Stuffing) o si no está protegida por un segundo factor de autenticación (2FA).

La regla de oro de la higiene digital es no tener que recordar más que una sola contraseña: tu contraseña maestra de 250 bits (una frase de contraseña aleatoria, como la de arriba). Todos tus demás accesos (banco, redes sociales, servidores) deben utilizar contraseñas aleatorias únicas, generadas específicamente para ellos.

Para guardar todas estas contraseñas que no puedes recordar, usa un gestor de contraseñas. Elige uno que cifre tu bóveda en tu dispositivo antes de sincronizarla (lo que suele llamarse zero-knowledge), idealmente uno de código abierto y auditado de forma independiente.

La bomba de relojería: Recopilar ahora, descifrar después y el imperativo Zero-Knowledge

Tue, 26 May 2026 00:00:00 +0000

La dependencia de los gobiernos europeos de la infraestructura en la nube estadounidense plantea algo más que un problema de interceptación inmediata. La amenaza más devastadora para las próximas décadas es la estrategia HNDL: “Harvest Now, Decrypt Later”.

No se trata de una intrusión frontal, sino de un robo silencioso. Las agencias de inteligencia almacenan hoy inmensas cantidades de datos cifrados simplemente porque el coste de almacenamiento es insignificante.

Esperan pacientemente el momento en que los saltos tecnológicos hagan obsoletas las claves actuales. Un secreto de Estado protegido en 2026 podría ser un libro abierto en quince años.

Responsabilidad retroactiva y riesgo temporal

El modelo HNDL introduce un concepto novedoso: el daño legal diferido. Con la recopilación masiva de datos para su descifrado futuro, la confidencialidad se convierte en una variable dependiente del tiempo.

Para cuantificar este riesgo, el modelo científico HNDL define que la confidencialidad falla inevitablemente cuando la vida útil requerida del secreto excede el horizonte de descifrado del adversario.

Si un Estado no garantiza la soberanía absoluta de su infraestructura de hardware, en la práctica está firmando una renuncia a la confidencialidad a largo plazo de sus ciudadanos.

La interceptación de hoy es la vulneración del mañana. Convertir la dependencia de la nube en una deuda de seguridad nacional es una apuesta imposible de pagar.

La antítesis Arpokrat: Imposibilidad legal por código

Ante esta vulnerabilidad, la industria responde creando ecosistemas radicales de soberanía digital. El modelo Arpokrat es la antítesis perfecta: opera en una red descentralizada, protegida por la estricta Ley Federal de Protección de Datos (FADP) de Suiza.

La lógica central es de absoluta Privacy by Design. Al eliminar la necesidad de un número de teléfono, el usuario se convierte en una simple clave criptográfica.

Legalmente, esto cambia drásticamente las reglas. Si la arquitectura es fundamentalmente Zero-Knowledge, la empresa se enfrenta a una imposibilidad técnica de cumplir con órdenes judiciales.

No se trata de desobediencia civil, sino de una salvaguarda matemática imparable: lo que no se tiene no se puede revelar.

Más allá del cifrado: Devaluar el dato objetivo

La verdadera respuesta en la aplicación Arpokrat no consiste en apostar por unas matemáticas eternas, sino en devaluar el propio dato.

Sin metadatos centrales para vincular un mensaje a un individuo físico, el contenido cifrado pierde su valor estratégico porque se vuelve inatribuible.

Sin embargo, el software por sí solo no puede hacer nada si el hardware lo traiciona.

En última instancia, la seguridad exige la independencia de la propia máquina. Desplegar un SO soberano sin Google se ha convertido en un requisito de supervivencia absoluto para cualquiera que maneje secretos de Estado.