CRIPTOGRAFÍA

Un remailer anónimo es un servidor que recibe mensajes con instrucciones integradas sobre dónde enviarlos a continuación, y que los reenvía sin revelar de dónde provienen originalmente. Hay remailers anónimos de Cypherpunk , remailers anónimos de Mixmaster y servidores nym , entre otros, que difieren en cómo funcionan, en las políticas que adoptan y en el tipo de ataque al anonimato del correo electrónico que pueden (o pretenden) resistirse. El reenvío como se describe en este artículo se aplica a los correos electrónicos destinados a destinatarios particulares, no al público en general. El anonimato en este último caso se aborda más fácilmente utilizando cualquiera de los varios métodos de publicación anónima.

Tipos de remailer [ editar ]

Existen varias estrategias que afectan el anonimato del correo electrónico manejado. En general, las diferentes clases de remailers anónimos difieren con respecto a las elecciones que han hecho sus diseñadores / operadores. Estas elecciones pueden verse influenciadas por las ramificaciones legales de operar tipos específicos de remailers. ^[1]

Se debe entender que cada paquete de datos que viaja en el Internet contiene las direcciones de nodo (como prima IP mordió cuerdas) de los nodos receptores que envían y previstas, y por lo tanto ningún paquete de datos puede nunca ser en realidad el anonimato a este nivel ^{[ cita requerida ]} . Además, todos los mensajes de correo electrónico basados ​​en estándares contienen campos definidos en sus encabezados en los que se debe incluir la fuente y las entidades transmisoras (y también los nodos de Internet).

Algunos remailers cambian ambos tipos de dirección en los mensajes que reenvían, y la lista de nodos de reenvío también en los mensajes de correo electrónico, a medida que el mensaje pasa; en efecto, sustituyen 'direcciones de origen falsas' por los originales. La 'dirección de origen IP' para ese paquete puede convertirse en la del servidor del remailer en sí, y dentro de un mensaje de correo electrónico (que generalmente es de varios paquetes), un 'usuario' nominal en ese servidor. Algunos remailers reenvían su correo electrónico anónimo a otros remailers, y solo después de varios de estos saltos, el correo electrónico se entrega realmente a la dirección prevista.

Hay, más o menos, cuatro tipos de remailers:

Remailers seudónimos [ editar ]

Un reenviador seudónimo simplemente quita la dirección de correo electrónico del remitente, le da un seudónimo al remitente y envía el mensaje al destinatario deseado (que puede ser respondido a través de ese reenviador).

Los remailers de Cypherpunk, también llamados Tipo I [ editar ]

Un remailer de Cypherpunk envía el mensaje al destinatario, quitando la dirección del remitente. Uno no puede responder un mensaje enviado a través de un remailer Cypherpunk. El mensaje enviado al remailer generalmente se puede cifrar, y el remailer lo descifrará y lo enviará a la dirección del destinatario oculto dentro del mensaje cifrado. Además, es posible encadenar dos o tres remailers, de modo que cada remailer no pueda saber quién está enviando un mensaje a quién. Los remailers de Cypherpunk no mantienen registros de transacciones.

Los remailers de Mixmaster, también llamados Tipo II [ editar ]

En Mixmaster , el usuario redacta un correo electrónico a un remailer, que se retransmite a través de cada nodo en la red usando SMTP , hasta que finalmente llega al destinatario final. Mixmaster solo puede enviar correos electrónicos de una manera. Se envía un correo electrónico de forma anónima a una persona, pero para que puedan responder, se debe incluir una dirección de respuesta en el cuerpo del correo electrónico. Además, los remailers de Mixmaster requieren el uso de un programa de computadora para escribir mensajes. Dichos programas no se suministran como parte estándar de la mayoría de los sistemas operativos o sistemas de administración de correo.

Los remailers de Mixminion, también llamados Tipo III [ editar ]

Un remailer de Mixminion intenta abordar los siguientes desafíos en los remailers de Mixmaster: respuestas, anonimato hacia adelante, prevención de reproducción y rotación de teclas, políticas de salida, servidores de directorio integrados y tráfico ficticio. Actualmente están disponibles para las plataformas Linux y Windows. Algunas implementaciones son de código abierto.

Remailers trazables [ editar ]

Algunos remailers establecen una lista interna de remitentes reales y nombres inventados de manera que un receptor puede enviar correo a nombre inventado AT algunos-remailer.example . Al recibir el tráfico dirigido a este usuario, el software del servidor consulta esa lista y reenvía el correo al remitente original, permitiendo así una comunicación bidireccional anónima, aunque rastreable con acceso a la lista. El famoso remailer " penet.fi " en Finlandia hizo exactamente eso durante varios años. ^[2]Debido a la existencia de tales listas en este tipo de servidor de reenvío, es posible romper el anonimato al obtener acceso a la (s) lista (s), al ingresar a la computadora, pedirle a un tribunal (o simplemente a la policía en algunos lugares) que ordenar que se rompa el anonimato y / o sobornar a un asistente. Esto le sucedió a penet.fi como resultado del tráfico que pasó a través de él sobre Scientology . ^{[ cita requerida ]} La Iglesia reclamó la infracción de los derechos de autor y demandó al operador de penet.fi. Un tribunal ordenó que la lista esté disponible. El operador de Penet lo cerró después de destruir sus registros (incluida la lista) para conservar la confidencialidad de la identidad. para sus usuarios; aunque no antes de verse obligado a proporcionar a la corte las direcciones de correo electrónico reales de dos de sus usuarios. ^{[ cita requerida ]}

Los diseños de remailer más recientes utilizan criptografía en un intento de proporcionar más o menos el mismo servicio, pero sin tanto riesgo de pérdida de confidencialidad del usuario. Generalmente se denominan servidores nym o remailers seudónimos . El grado en que siguen siendo vulnerables a la divulgación forzada (por los tribunales o la policía) es y seguirá siendo poco claro, ya que los nuevos estatutos / reglamentos y los nuevos desarrollos criptoanalíticos avanzan rápidamente. El reenvío anónimo múltiple entre los revendedores cooperantes en diferentes jurisdicciones puede retener, pero no puede garantizar, el anonimato contra un intento determinado de uno o más gobiernos o litigantes civiles.

Remailers imposibles de rastrear [ editar ]

Si los usuarios aceptan la pérdida de la interacción bidireccional, el anonimato de identidad se puede hacer más seguro.

Al no mantener ninguna lista de usuarios y las etiquetas de anonimato correspondientes para ellos, un remailer puede garantizar que cualquier mensaje que se haya reenviado no deje información interna que luego pueda usarse para romper la confidencialidad de la identidad. Sin embargo, mientras se manejan, los mensajes permanecen vulnerables dentro del servidor (p. Ej., Al software troyano en un servidor comprometido, a un operador de servidor comprometido o a una mala administración del servidor), y la comparación de análisis de tráfico del tráfico entrante y saliente de dicho servidor un servidor puede sugerir muchas cosas, mucho más de lo que casi cualquier crédito acreditaría.

La estrategia Mixmaster está diseñada para derrotar tales ataques, o al menos para aumentar su costo (es decir, para "atacantes") más allá de la viabilidad. Si cada mensaje se pasa a través de varios servidores (idealmente en diferentes jurisdicciones legales y políticas), los ataques basados ​​en sistemas legales se vuelven considerablemente más difíciles, aunque solo sea por la fricción ' clausewitziana ' entre abogados, tribunales, diferentes estatutos, rivalidades organizacionales, sistemas legales , etc. Y, dado que están involucrados muchos servidores y operadores de servidores diferentes, la subversión de cualquiera (es decir, del sistema o del operador) se vuelve menos efectiva también ya que nadie (muy probablemente) podrá subvertir toda la cadena de remailers.

El relleno aleatorio de mensajes, los retrasos aleatorios antes del reenvío y el cifrado de la información de reenvío entre reenviadores de reenvío aumentan aún más el grado de dificultad para los atacantes, ya que el tamaño y el tiempo del mensaje pueden eliminarse en gran medida como pistas de análisis de tráfico y la falta de información de reenvío fácilmente legible. algoritmos de análisis de tráfico automatizados simples e ineficaces.

Mailer basado en web [ editar ]

También hay servicios web que permiten a los usuarios enviar mensajes de correo electrónico anónimos. Estos servicios no proporcionan el anonimato de los remailers reales, pero son más fáciles de usar. Cuando se utiliza un correo electrónico anónimo basado en la web o un servicio de remarcado anónimo, primero se debe analizar su reputación, ya que el servicio se encuentra entre los remitentes y los destinatarios. Algunos de los servicios web mencionados anteriormente registran las direcciones IP de los usuarios para asegurarse de que no infringen la ley; otros ofrecen un anonimato superior con funcionalidad de archivo adjunto al elegir confiar en que los usuarios no violarán los Términos de servicio (TOS) del sitio web.

Antoni Palluth (11 de mayo de 1900, Pobiedziska , provincia de Posen - 18 de abril de 1944), fue uno de los fundadores de la AVA Radio Company . La compañía construyó equipos de comunicaciones para el ejército polaco; El trabajo incluyó no solo radios sino también equipos criptográficos. Palluth estaba involucrado con la sección alemana ( BS-4 ) de la polaca Mayor 's interbellum Cipher Bureau . Ayudó a impartir cursos sobre criptoanálisis y participó en la construcción de equipos para romper la máquina alemana Enigma .

La vida [ editar ]

Palluth era un ingeniero civil graduado del Politécnico de Varsovia . En enero de 1929, fue uno de los instructores en un curso de criptología organizado por Cipher Bureau, en la Universidad de Poznań , al que asistieron estudiantes de matemáticas seleccionados . Los estudiantes incluyeron a los futuros empleados civiles de la Oficina de cifrado Marian Rejewski , Jerzy Różycki y Henryk Zygalski . ^[1]

En la década de 1930, Palluth fue uno de los cuatro directores de la AVA Radio Company en Varsovia , que produjo equipos criptológicos diseñados por la Oficina de cifrado. ^[2]

En marzo de 1943, mientras intentaba cruzar la frontera de la Francia ocupada por los alemanes hacia España , Palluth fue capturada por los alemanes junto con el jefe de la Oficina de cifrado , el teniente coronel Gwido Langer , el jefe de la sección alemana, el mayor Maksymilian Ciężki , y los civiles Edward Fokczyński y Kazimierz Gaca . ^[3]

Palluth murió durante un ataque aéreo aliado en el campo de concentración alemán Sachsenhausen . 

Anubis es un cifrado en bloque diseñado por Vincent Rijmen y Paulo SLM Barreto como participante en el proyecto NESSIE , un antiguo programa de investigación iniciado por la Comisión Europea en 2000 para la identificación de nuevos algoritmos criptográficos . ^[1] Aunque el cifrado no se ha incluido en la cartera final de NESSIE, su diseño se considera muy sólido, y no se han encontrado ataques en 2004 después de que el proyecto hubiera concluido. ^[2] El cifrado no está patentado y ha sido lanzado por los diseñadores para uso público gratuito. ^[3]

Anubis opera en bloques de datos de 128 bits, aceptando claves de longitud 32 N bits ( N = 4, ..., 10). Está diseñado como una red de sustitución-permutación , que tiene una gran similitud con Rijndael . ^[2] Al igual que KHAZAD , diseñado por los mismos autores y también presentado a NESSIE, utiliza involuciones para las diversas operaciones. ^[2] Una involución es una operación cuya inversa es la misma que la operación hacia adelante. En otras palabras, cuando una involución se ejecuta dos veces, es lo mismo que no realizar ninguna operación. Esto permite que las implementaciones de hardware compacto y software de bajo costo utilicen las mismas operaciones para el cifrado y descifrado. AmbosLas operaciones de S-box y las columnas de mezcla son involuciones. ^[1] Aunque muchos componentes involutivos pueden hacer que un cifrado sea más susceptible a distinguir ataques que explotan la estructura del ciclo de permutaciones dentro del cifrado, no se ha presentado una estrategia de ataque para el cifrado Anubis. ^[4]

Hay dos versiones del cifrado Anubis; La implementación original utiliza un S-box pseudoaleatorio. Posteriormente, el S-box fue modificado para ser más eficiente de implementar en hardware; la versión más nueva de Anubis se llama versión "modificada". ^[2]

Los autores afirman que el algoritmo es seguro contra una serie de ataques, incluidos análisis diferencial y lineal de cuatro rondas , así como ataques de clave relacionada , interpolación , boomerang , diferencial truncado , diferencial imposible y saturación. ^[1] Sin embargo, debido a la similitud del cifrado con Rijndael, no se consideró que ofreciera ventajas convincentes y, por lo tanto, no se incluyó en la segunda fase de evaluación del proyecto NESSIE.

Anubis lleva el nombre del dios egipcio de sepultura y embalsamamiento, que los diseñadores interpretaron que incluía cifrado . Afirman que los infractores de la cifra serán maldecidos .

Argon2 es una función de derivación clave que fue seleccionada como la ganadora del concurso Password Hashing en julio de 2015. ^[1] [2] Fue diseñada por Alex Biryukov , Daniel Dinu y Dmitry Khovratovich de la Universidad de Luxemburgo . ^[3] La implementación de referencia de Argon2 se publica bajo una licencia Creative Commons CC0 (es decir, dominio público ) o la Licencia Apache 2.0 , y proporciona tres versiones relacionadas:

• Argon2d maximiza la resistencia a los ataques de craqueo de GPU. Accede a la matriz de memoria en un orden dependiente de la contraseña, lo que reduce la posibilidad de ataques de compensación de tiempo-memoria (TMTO), pero introduce posibles ataques de canal lateral .
• Argon2i está optimizado para resistir ataques de canal lateral. Accede a la matriz de memoria en un orden independiente de contraseña.
• Argon2id es una versión híbrida. Sigue el enfoque de Argon2i para el primer paso sobre la memoria y el enfoque de Argon2d para los pases posteriores. El borrador de Internet ^[4] recomienda usar Argon2id, excepto cuando haya razones para preferir uno de los otros dos modos.

Los tres modos permiten la especificación por tres parámetros que controlan:

• Tiempo de ejecución
• memoria requerida
• grado de paralelismo

Criptoanálisis [ editar ]

Si bien no existe un criptoanálisis público aplicable a Argon2d, existen dos ataques publicados contra la función Argon2i. El primer ataque es aplicable solo a la versión anterior de Argon2i, mientras que el segundo se ha extendido a la última versión (1.3) ^[5]

El primer ataque muestra que es posible calcular una función Argon2i de un solo paso usando entre un cuarto y un quinto del espacio deseado sin penalización de tiempo, y calcular un Argon2i de múltiples pasos usando solo N / e < N /2.71 espacio con Sin penalización de tiempo. ^[6] Según los autores de Argon2, este vector de ataque se corrigió en la versión 1.3. ^[7]

El segundo ataque muestra que Argon2i puede calcularse mediante un algoritmo que tiene una complejidad O ( n ^7/4 log ( n )) para todas las opciones de parámetros σ (costo espacial), τ (costo de tiempo) y recuento de hilos de manera que n = σ ∗ τ . ^[8] Los autores de Argon2 afirman que este ataque no es eficiente si Argon2i se usa con tres o más pases. ^[7] Sin embargo, Joël Alwen y Jeremiah Blocki mejoraron el ataque y demostraron que para que el ataque falle, Argon2i 1.3 necesita más de 10 pases sobre la memoria. ^[5]

Algoritmo [ editar ]

Función Argon2
    Entradas: 
      contraseña ( P ): Bytes (0..2 32 -1)     Contraseña (o mensaje) que se va a codificar 
      sal ( S ): Bytes (8..2 32 -1)     Sal (se recomiendan 16 bytes para el hash de contraseña ) 
      paralelismo ( p ): Número (1..2 24 -1)    Grado de paralelismo (es decir, número de subprocesos) 
      tagLength ( T ): Número (4..2 32 -1)    Número deseado de bytes devueltos 
      memorySizeKB ( m ): Número (8p..2 32 -1)  Cantidad de memoria (en kibibytes ) para usar 
      iteraciones ( t ): Número (1..2 32 -1)    Número de iteraciones para realizar la 
      versión ( v ): Número (0x13)       La versión actual es la 
      tecla 0x13 (19 decimal) ( K ): Bytes (0..2 32 -1)     Clave opcional (Errata: PDF dice 0..32 bytes, RFC dice 0..2 32 bytes) Datos 
      asociados ( X ): Bytes (0..2 32 -1)     Opcional 
      hashType de datos extra arbitrario ( y ): Número (0 = Argon2d, 1 = Argon2i, 2 = Argon2id)
   Salida: 
      etiqueta: bytes (longitud de etiqueta)    Los bytes generados resultantes, longitud de longitud de etiqueta

   Genere el bloque inicial de 64 bytes H 0 .
    Todos los parámetros de entrada se concatenan y se ingresan como fuente de entropía adicional.
    Errata: RFC dice que H 0 es de 64 bits; El PDF dice que H 0 es de 64 bytes.
    Errata: RFC dice que Hash es H ^, el PDF dice que es ℋ (pero no documenta qué es ℋ). En realidad es Blake2b.
    Los elementos de longitud variable se anteponen con su longitud como enteros little endian de 32 bits.
   buffer ← paralelismo ∥ tagLength ∥ memorySizeKB ∥ iteraciones ∥ versión ∥ hashType
         ∥ Longitud (contraseña) ∥ Contraseña
         ∥ Longitud (sal) ∥ sal
         ∥ Longitud (clave) ∥ tecla
         ∥ Longitud (datos asociados) ∥ Datos asociados
   H 0 ← Blake2b (buffer, 64) // el tamaño de hash predeterminado de Blake2b es de 64 bytes

   Calcule el número de bloques de 1 KB al redondear memorySizeKB al múltiplo más cercano de 4 * paralelismo kibibytes
   blockCount ← Floor (memorySizeKB, 4 * paralelism)

   Asigne una matriz bidimensional de 1 bloques KiB (filas de paralelismo x columnas de columnas) 
   Columna ← bloqueCuenta / paralelismo;   // En el RFC, columnCount se conoce como q

   Calcule el primero y segundo bloque (es decir, la columna cero y uno) de cada carril (es decir, fila) 
   para i ← 0 a paralelismo-1 hacer  para cada fila 
      B i [0] ← Hash (H 0 ∥ 0 ∥ i, 1024) / / Generar un resumen de 1024 bytes 
      B i [1] ← Hash (H 0 ∥ 1 ∥ i, 1024) // Generar un resumen de 1024 bytes

   Calcule las columnas restantes de cada carril 
   para i ← 0 al paralelismo-1 do  // para cada fila 
      para j ← 2 a columnCount-1 do  // para cada columna subsiguiente 
         // los índices de i 'y j' dependen si es Argon2i, Argon2d, o Argon2id (Ver sección 3.4) 
         i ′, j ′ ← GetBlockIndexes (i, j)   // la función GetBlockIndexes no está definida 
         B i [j] = G (B i [j-1], B i ′ [j ′] ) // la función hash G no está definida

   
   Luego pasa cuando las iteraciones> 1 para nIteración ← 2 a iteraciones hacen 
      para i ← 0 al paralelismo-1 hacen  para cada fila 
        para j ← 0 a columnCount-1 do  // para cada columna subsiguiente 
           // los índices i 'y j' dependen si es Argon2i, Argon2d o Argon2id (Ver sección 3.4)
           i ′, j ′ ← GetBlockIndexes (i, j)
           si j == 0 entonces  
             B i [0] = B i [0] xor G (B i [columnCount-1], B i ′ [j ′])
            más 
             B i [j] = B i [j] xor G (B i [j-1], B i ′ [j ′])

   Calcule el bloque final C como XOR de la última columna de cada fila 
   C ← B 0 [columnCount-1]
    para i ← 1 al paralelismo-1 do 
      C ← C xor B i [columnCount-1]

   Calcular salida de 
   retorno de etiqueta Hash (C, tagLength)

Función hash de longitud variable [ editar ]

Argon2 utiliza una función hash capaz de producir resúmenes de hasta 2 ³² bytes de longitud. Esta función hash está construida internamente sobre Blake2 .

Función Hash (mensaje, digestSize)
    Entradas: 
      mensaje: Bytes (0..2 32 -1)      Mensaje a hash 
      digestSize: Entero (1..2 32 )      Número deseado de bytes a devolver 
   Salida: 
      digest: Bytes (digestSize)    Los bytes generados resultantes, digestSize bytes de largo

   Hash es una función hash de longitud variable, creada con Blake2b, capaz de generar
   digiere hasta 2 32 bytes.

   Si el digestSize solicitado es de 64 bytes o inferior, entonces usamos Blake2b directamente 
   si (digestSize <= 64) y luego 
      devolvemos Blake2b (digestSize ∥ message, digestSize) // concatenate little endian digestSize de 32 bits con los bytes del mensaje

   Para los hashes deseados de más de 64 bytes (por ejemplo, 1024 bytes para bloques Argon2),
   Usamos Blake2b para generar el doble del número de bloques necesarios de 64 bytes,
   y luego solo usa 32 bytes de cada bloque

   Calcule el número de bloques completos (sabiendo que solo vamos a usar 32 bytes de cada uno)
   r ← Ceil (digestSize / 32) -1;

   Generar r bloques enteros. 
   El bloque inicial se genera a partir del mensaje 
   V 1 ← Blake2b (mensaje digestSize ∥, 64);
   Los bloques posteriores se generan a partir de bloques anteriores 
   para i ← 2 a r do 
      V i ← Blake2b (V i-1 , 64)
    Genera el bloque final (posiblemente parcial)
   partialBytesNeeded ← digestSize - 32 * r;
   V r + 1 ← Blake2b (V r , parcialBytesNeeded)

   Concatenar los primeros 32 bytes de cada bloque V i 
   (excepto el último bloque, posiblemente parcial, que tomamos toda la cosa) 
   Sean A i representan los menores de 32 bytes de bloque V i
    devuelvo A 1 ∥ Un 2 ∥ ∥ ... A r ∥ V r + 1