Enigma Numero 64

Por falta de tiempo no me he dedicado al blog, pero en recompensa les dejo un boletin publicado por http://www.cripto.es que esta bien interesante, yo me los he pasado a .jad para leérmelos en el movil tranquilo.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Boletín del Taller de Criptografía de Arturo Quirantes
http://www.cripto.es

Número 64 1 de Noviembre de 2008


========================================================================

EDITORIAL

TEMAS DE ACTUALIDAD
- Más sustos inalámbricos

CRIPTO 101
- Encadenando bloques

CRIPTOGRAFÍA HISTÓRICA
- Los primeros criptógrafos - corrección

LIBERTAD VIGILADA
- España reconoce su presencia en ILETS


========================================================================


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
EDITORIAL
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

Si hay algo que mantenía yo con ilusión desde hace tiempo, era
que algún día las máquinas Enigma compradas por Franco aparecerían como
por arte de magia. Descubrí una en el Museo Militar de Madrid. El resto,
al menos una buena parte, aparecieron recientemente en el cuartel
general del Ejército español. No vamos a hablar de ellas hoy, pero
palabrita de honor que pronto les dedicaremos el espacio que se merecen.

En el apartado extremo, desde Viena nos vienen noticias sobre
los últimos avances en criptografía cuántica. Tanto en un caso como en
el otro, la moraleja es la de siempre: !cuánto camino queda aún por
delante! Los descubrimientos tipo "state-of-the-art" (que en usalandés
significa algo así como "lo último de lo último") se suceden mes tras
mes, y las sorpresas que nos guarda aún la musa de la Historia parecen
no tener fin.

Entre medias, seguimos con noticias que, sin ser de actualidad,
enlazan con acontecimientos que ya hemos relatado, sean fallos en
seguridad inalámbrica o anuncios de supuestos avances criptográficos
para vender más. Creo que este boletín satisfará a todos, puesto que de
todo hablamos hoy.

Por otro lado, en el apartado "mi ombligo y yo", este mes pasado
apareció un artículo dedicado a este que firma ... en una revista tan
poco criptográfica como Más Allá, una publicación mensual de temas de
ciencias ocultas. Está disponible en Internet, y me sacan guapo y todo
(http://www.masalladelaciencia.es/historico-de-revistas/numero_236).
Posteriormente, fui entrevistado por dos cadenas de radio para sendos
programas de ocultismo, lo que me hace sospechar que la creencia de que
la criptografía es cosa de brujas sigue estando muy arraigada. !Y se
reían de Felipe II cuando acusó al criptógrafo francés Viete de
brujería!

Y, hace tan sólo unos minutos, recibio nuevas de que José Ramón
Soler Fuensanta, amigo de la cripto y de este boletín, va a aparecer en
el próximo programa de Cuarto Milenio. Si esto crea moda, me parece que
vamos a tener que reconvertirnos en parapsicólogos, echar las cartas o
algo así. Por de pronto, justo a continuación tenéis un artículo sobre
criptografía wifi que, por pura casualidad, se titula "más sustos
inalámbricos". Criptoterror en estado puro ... o no tanto. Feliz noche
de Halloween.


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
TEMAS DE ACTUALIDAD
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

=----------------------------------------------------------------------=
Más sustos inalámbricos
=----------------------------------------------------------------------=

Las redes inalámbricas son un riesgo para la seguridad. El
motivo es sencillo: para acceder a ellas no hay más que poner una
antena. Las comunicaciones por cable requieren que el atacante tenga
acceso físico (o bien que sea un gobierno, y esgrimiendo razones de
seguridad obligue a las operadoras a concederle ese acceso, pero esa es
otra historia), pero las ondas pertenecen al primero que las capte. Los
soviéticos lo sufrieron en sus propias carnes. Creyendo que las
microondas no podían ser interceptadas desde el espacio, las usaron para
dotar de cobertura de comunicaciones su vasto territorio. Los
norteamericanos, a la chita callando, ingeniaron una forma de captar
dichas ondas, lanzaron al espacio una red de satélites espía Ryolite, y
se pusieron literalmente las botas durante más de una década.

La contramedida es obvia: cifremos la señal. Y la contramedida a
dicha contramedida también lo es: criptoanalicemos la cifra, ataquemos
mediante fuerza bruta, aprovechemos cualquier vulnerabilidad en el
sistema. Los soviéticos cerraron su ventana de vulnerabilidad hace años,
conscientes de lo que se jugaban. ¿Pero qué hay de todos los usuarios de
Internet que usan conexiones wifi?

Ya en boletines pasados hablamos de fallos asociados al
algoritmo WEP, usado hasta ya mismo para cifrar comunicaciones wifi
("WEP, inseguridad inalámbrica", Boletín ENIGMA 52, y algunos
editoriales). Por desgracia, muchas telecos siguen dando a sus clientes
routers inalámbricos que no aceptan más que el protocolo WEP, y al
usuario medio eso le parece más que suficiente. Afortunadamente, tenemos
el protocolo WPA (Wifi Protected Access), mucho más resistente.

Algún día analizaremos WPA como se merece. Hoy, en cambio, vamos
a asustarnos un poco. Aunque WPA incorpora un proceso de cifrado como
WEP, es más fuerte, ya que usa claves de 128 bits junto con un sistema
de verificación de mensajes. Una versión más avanzada, WPA2, incorpora
el algoritmo de cifra simétrica AES, y cumple totalmente con el estándar
802.11i. Parece que no hay vulnerabilidades criptográficas, al menos que
se sepa a día de hoy. Entonces, ¿por qué una empresa nos dice que WPA
está poco menos que muerto?

La empresa de marras es Elcomsoft, una compañía que lleva casi
veinte años diseñando software para recuperación de datos, o para que
nos entendamos, para romper cifras. Es el tipo de programa que necesita
un usuario que ha olvidado su contraseña para abrir su documento zip,
word o de otros tipos. También está especializada en software de
análisis forense, lo que resulta especiamente útil si el señor Grissom
quiere leer los mensajes que oculta el malo en su ordenador. Los
productos de Elcomsoft incorporan métodos de fuerza bruta (probar todas
las contraseñas posibles) y de ataques de diccionario (comprobar si la
contraseña se encuentra en una lista de palabras de uso común). Sus
programas forenses llegan incluso a examinar el disco duro entero,
elaborar diccionarios de posibles contraseñas y probarlas una a una.

Elcomsoft (que, para mayor ironía, es rusa) anunció hace unos
días un par de novedades. La primera es que la nueva versión de su
programa de recuperación de claves (Distributed Password Recovery) puede
ahora funcionar en un ordenador a una velocidad 20 veces superior.
¿Cómo? Pues mediante el ingenioso truco de aprovechar la potencia de
cálculos de los chips (GPU) de las tarjetas gráficas. Todos estábamos
preocupados de cuánto puede hacer la CPU del ordenador, y no caíamos en
la cuenta de que en la actualidad las tarjetas gráficas tienen una
potencia endiablada. De hecho, Elcomsoft afirma que su programa puede
probar más de mil millones de contraseñas por segundo. Esto significa
probar todas las contraseñas posibles de ocho letras en menos de cuatro
minutos. ¿Comenzamos a asustarnos ya?

Bien, en realidad esto no es un problema nuevo. Ya sabemos que
la potencia de cálculo de los ordenadores actuales aumenta que es una
barbaridad, y no sólo ellos sino también cualquier otro cacharro que
pueda ejecutar operaciones matemáticas. En la década de los 90, yo
conseguí simular datos de dispersión de luz mediante la llamada teoría
de Mie en una hoja de cálculo; hacer unos meses, un colega mío lo
consiguió usando ... un teléfono móvil. A partir de ahora, los
documentos que ciframos en zip, o los de Office, tendrán que usar
contraseñas más seguras. Qué le vamos a hacer, hoy las ciencias
adelantan que es una barbaridad. Y si bien el paquete completo de
programas sobrepasa los mil euros de precio, también es cierto que
existen las redes p2p y la gente dispuesta a compartir.

Sin embargo, los rusos de Elcomsoft nos han dado un segundo
susto. O, al menos, lo han intentado. Aprovechando que el Pisuerga pasa
por Valladolid, se descuelgan con esto:

"Con la última versión de Elcomsoft Distributed Password
Recovery (EDPR), es ahora posible reventar la proteción WPA y WPA2 en
redes Wi-Fi hasta cien veces más rápido ... sólo necesita interceptar
unos paquetes (con cualquier sniffer de red que pueda exportar datos en
format tcpdump) para efectuar el ataque" Es decir, se atreven incluso a
pronosticar la muerte de WPA2, que utiliza el algoritmo AES de 256 bits.

Bien, un par de cosas. En primer lugar, usar AES no significa
gran protección si todo lo que usamos para activarlo son claves de 6-8
caracteres, y aquí está la vulnerabilidad de todo lo que protejamos
mediante contraseña. EDPR busca contraseñas en WPA y WPA", igual que lo
hace en los documentos de Office.

En segundo lugar, el ataque no es nuevo, en el sentido de que ya
se sabía que esnifar algunos paquetes permitía, en principio, romper el
sistema. La cuestión, por supuesto, estriba en el "en principio". El
protocolo WPA necesita, para su activación, nada menos que 8192 llamadas
al protocolo SHA1, lo que significa un total de 15 millones de
operaciones. En un procesador Xeon usando el programa Aircrack, se
pueden hacer unas 650 comprobaciones de contraseña por segundo. Con el
aumento de Elcomsoft, quizá llegue a 10.000-20.000 contraseñas por
segundo, lo que significa siglos para descubrir una contraseña de ocho
letras.

Es decir, que su superprograma se meriende mil millones de
contraseñas en ataques a documentos de Office no significa, ni mucho
menos, que WPA esté en riesgo. Más aún, ¿qué "salto cuántico" significa
un aumento de veinte, o de cien? Mucho para mí y mi pequeño portátil,
seguro, pero ya hay grandes recursos a disposición incluso de un usuario
individual. Más parece que Elcomsoft haya querido aprovechar el tirón
mediático usando como cebo WPA. Quizá el año que viene lo intenten con
los algoritmos de telefonía GSM: "ahora se pueden interceptar teléfonos
cien veces más rápido".

El problema es que algunos consultores de seguridad han caído en
el juego. O al menos, uno, un tal David Hobson, de la empresa de
consultoría de seguridad Global Secure Systems, quien en diversos medios
de Internet se ha mostrado muy preocupado, hasta el punto de afirmar que
"el descifrado de los sistemas WPA y WPA2, mediante fuerza bruta, usando
procesamiento en paralelo ha estado en el horizonte de las posibilidades
teóricas desde hace algún tiempo". Si usted, querido lector, sabe leer
entre líneas, habrá visto que eso y nada es lo mismo. Es como decir que,
si juego cinco números a la lotería en lugar de uno, la posibilidad de
que me toque es más probable.

No olvidemos, por otro lado, que la contraseña usada en las
redes wifi puede ser mucho más larga que ocho caracteres. La mía tiene
... hmm, mejor no os lo digo. No es necesario que la introduzcamos cada
vez que nuestro wifi se conecta a la red, y podemos guardarla con
comodidad dentro de un CD o un lápiz USB para cuando la necesitemos. El
avance (por llamarlo así) de Elcomsoft no sirve más que para los que
usen una contraseña débil y corta.

Es posible que algún día aparezca un método de reventar WPA. A
la larga, me huelo que la facilidad con que se captan paquetes del éter
puede acabar con estos protocolos de cifrado. Pero de momento, WPA
parece resistir, y no debemos caer en el pánico creado por una empresa
que vende software.


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
CRIPTO 101
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

=----------------------------------------------------------------------=
Encadenando bloques
=----------------------------------------------------------------------=

Existen dos grandes tipos de algoritmos de cifrado simétrico: de
flujo y de bloque. Los algoritmos de bloque (Block Ciphers) operan con
"bloques" de varios bits, en tanto que los algoritmos de flujo (Stream
Ciphers) operan sobre bits individuales. Un algoritmo de flujo sería
algo así como un taxi, que en cuanto el viajero sube sale disparado. Por
contra, el algoritmo de bloque sería como un autobús que no sale de la
estación hasta que todos los asientos estén ocupados. Ambos tipos de
algoritmos tienen sus peculiaridades, y hoy vamos a ver los
correspondientes a algoritmos de bloque.

La mayoría de los algoritmos simétricos que nos suenan son de
tipo bloque: DES, IDEA, AES. Tienen asignado un tamaño de clave, que
también es el tamaño del texto llano que procesa. Por ejemplo, DES tiene
una clave de 64 bits, o lo que es lo mismo, de 8 bytes. Esto significa
que toma un mensaje M de 64 bits y lo cifra mediante una clave k para
dar un bloque cifrados C de 64 bits de tamaño. Matemáticamente, podemos
representar el algoritmo de cifra como una función E que depende tanto
del mensaje M como de la clave k: C=Ek(M). Como el algoritmo es
simétrico, la función de descifrado es igual que la de cifrado, de forma
que M=Ek(C).

Sencillo hasta aquí, ¿no? Sin embargo, cuando tenemos un mensaje
más largo, las cosas se complican. Por supuesto, podemos dividirlo en
bloques de N bits: M1, M2, M3 ... Mn. Pero ahora, el resultado de cifrar
el bloque Mn puede depender tanto de la función E y de la clave k como
de los bloques que hemos cifrado anteriormente. Es decir, la ruta del
autobús 13 dependerá del recorrido que hayan efectuado los autobuses que
le precedieron. El modo en que tal dependencia sucede puede afectar a
las prestaciones de la cifra, pero también -lo que es más grave- a la
seguridad del sistema.

Vamos a ilustrarlo. Seguro que a más de uno le ha resultado raro
eso de que el cifrado de un bloque dependa de los bloques anteriores.
¿Por qué complicarse la vida? ¿No podemos, sencillamente, cifrar cada
bloque con la clave y dejarnos de monsergas? Sí, podemos. De hecho, ese
es el denominado Modo de Libro de Código Electrónico (Electronic
Codebook Mode, ECB). En el EBC, el cifrado de cada bloque es
independiente, como si los demás no existiesen:

C1 = Ek(M1)
C2 = Ek(M2)
C3 = Ek(M3)
...........
Cn = Ek(Mn)

Es el modo que, a priori, nos parece el más natural. Cada bloque
de texto llano se cifra de modo independiente, lo que resulta muy útil
al cifrar bases de datos de acceso aleatorio, ya que no necesitamos
cifrar de nuevo toda la base cuando añadimos, alteramos o borramos parte
de ella. Es la forma más rápida de cifrar, y la verdad, uno al principio
puede plantearse por qué pensar siquiera que hay otras formas de cifrar.

El problema con el modo de encadenado EBC (es decir, cuando no
hay modo encadenado en absoluto) es que resulta vulnerable a ciertos
tipos de ataques. Por fijar conceptos, imaginemos una base de datos con
la lista de clientes de un banco: nombre, número de cuenta, saldo.
Supongamos que el criptoanalista tiene acceso a toda la base de datos
(cosa que, a tenor de las noticias sobre robos de bases de datos, fallos
de vulnerabilidad y pérdidas accidentales, cada vez es menos raro).
Digamos que de algún modo, el atacante tiene al menos parte de la
información de dicha base de datos en texto llano. Eso le permite
conocer, o al menos deducir, parte de los datos. Por ejemplo, digamos
que examina la base de datos, cifrada, y comprueba que hay diversas
cadenas alfanuméricas que se repiten. ¿Puede tratarse de saldos en
números redondos? Quizá "928hng4l" significa "diez mil", o "kkwg972c" es
un nombre de pila común.

Puede que, rebuscando en mi basura, haya podido relacionar mis
datos bancarios con ciertos textos cifrados en la base de datos. Voy a
simplificar al máximo. Digamos que el lunes, yo soy el único cliente del
banco que hace una operación de retirada de fondos entre las 10:05 y las
10:06 de la mañana. El enemigo accede a la base de datos y averigual
cuál ha sido la única línea de la base de datos que ha sido alterada. De
ese modo, o mejor dicho, de forma similar pero más compleja, un atacante
puede hacer estudios estadísticos sobre el texto cifrado para obtener al
menos parte de la información sin saber la clave.

He aquí el esquema de un ataque alternativo. Imaginemos que el
Banco A envía un mensaje electrónico al Banco B, en el que se detalla
una transferencia a un cliente de este último. Por algún motivo, todo el
paquete de datos está cifrado con la misma clave. Los datos de la
transferencia están divididos en bloques: un bloque para el nombre del
banco emisor, uno para el del banco receptor, tres para el del nombre
del destinatario, uno para el de la cantidad depositada y dos para el
del número de cuenta final. Es decir, algo así como EE-RR-DDD-M-CC

Ahora bien, imaginen que yo quiero enriquecerme rápidamente. Así
haré lo siguente. En primer lugar, ordeno una transferencia legítima
EE-RR-DDD-M-CC desde mi cuenta en A a mi cuenta en B, y la intercepto. A
continuación, intercepto una transferencia de otra persona cualquiera,
digamos ee-rr-ddd-m-cc, le quito los bloques correspondientes al
destinatario y al número de cuenta por los míos, y los envío. Esa
transferencia fraudulenta (digamos ee-rr-ddd-M-CC). De ese modo, un
desconocido (ddd) a quien no tengo el gusto de conocer ha transferido
sobre el papel (bueno, sobre el cable) una cantidad de dinero M que ni
siquiera conozco a mi cuenta. Fíjense que no conozco la clave, no sé
quién es mi anónimo benefactor, y ni siquiera sé la cuantía de la
transferencia. Por supuesto, tarde o temprano el banco receptor se dará
cuenta de que el banco emisor no paga, se dirigirán al cliente y éste
dirá que no es cosa suya, pero para entonces yo ya he vaciado mi cuenta
y me he largado a las Seychelles, desde donde les estoy escribiendo bajo
el nombre supuesto de Arturo Quirantes.

Es decir, el mero hecho de que un mensaje esté cifrado no lo
protege contra diversos tipos de fraude. Podemos alterar la estructuras
de datos, montar ataques de denegación de servicio, el caso es echarle
imaginación. A ver qué les parece este: tomo una de esas transacciones
legítimas y la reproduzco un millón de veces. El banco receptor no sabe
de dónde viene esa montaña de dinero, pero se corre la voz y su
cotización se dispara; por contra, el del banco emisor se hunde ante las
noticias de retiradas masivas de fondos. Al final todo acaba volviendo a
la normalidad, pero mientras tanto yo me he forrado comprando acciones
de un banco y vendiendo las del otro.

De acuerdo, los bancos no son tontos. Hay sistemas que ponen en
marcha para evitar este tipo de fraudes. Pero permanece el hecho de que
permitir el cifrado de bloques de datos de forma independiente es un
riesgo de seguridad. Por ejemplo, los bloques de datos pueden ir
acompañados de un sello temporal o un código de autenticación de
mensajes. Otras aplicaciones tales como bases de datos aleatorios pueden
usar ECB sin problemas. En el caso de una partición cifrada, existe un
procedimiento que veremos algo más adelante.

También podemos ir un paso más allá y usar el encadenado, es
decir, hacer que el bloque idel mensaje dependa de lo que había en el
bloque i-1. De esta forma, si intento copiar y pegar el saldo de Bill
Gates, el resultado será una ristra sin sentido. De hecho, el encadenado
hace que el bloque cifrado Ci dependa del bloque cifrado Ci-1, que a su
vez depende del Ci-2, y así sucesivamente. Un problema que aparece es
que un fallo en uno de los bloques cifrados (por una mala encriptación,
fallos en el hardware, el software o la transmisión) puede propagarse a
los demás bloques. Se conocen diversos modos de encadenamiento, cada uno
de los cuales tiene sus ventajas e inconvenientes.

En primer lugar tenemos el modo de Encadenado de Bloque Cifrado
(CBC, Cipher Block Chaining). En el CBC, lo que se cifra no es el bloque
Mi de texto llano, sino una "suma" entre Mi y el bloque cifrado anterior
Ci-1:

Ci = Ek(Pi + Ci-1)

En la fórmula anterior, "i-1" es un subíndice, mientras que "+"
es una operación denominada XOR (Exclusive-OR). XOR, aplicado a dos
bits, nos da 0 si ambos bits son iguales, y 1 si los bits son distintos.
Esto es: 0+0=1+1=0, 0+1=1+0=1. Si se fijan bien, es una suma sin
acarreo. Esto significa que, en el modo CBC, "xoreamos" el bloque
cifrado anterior con el bloque llano actual, y a lo que sale le
aplicamos el algoritmo de cifrado. La operación inversa, el descifrado,
se hace de la siguiente forma:

Pi = Ci-1 + Ek(Ci)

Ya hemos mencionado algunas de sus ventajas. Como Ci depende de
Ci-1, no podemos sustituir un bloque cifrado por otro sin que el
resultado pase inadvertido. Sigue existiendo el problema de que dos
textos idénticos, sometidos a la misma clave, nos da el mismo texto
cifrado. Peor aún, dos textos con el mismo comienzo darán como resultado
el mismo texto cifrado hasta el punto en que comiencen las diferencias.
Este problema es muy habitual en archivos con idénticos encabezamientos
(documentos de Word, cartas estereotipadas, mensajes de e-mail, etc), y
nos recuerda que incluso en el mundo electrónico de hoy sigue siendo
válida la máxima de evitar las regularidades. Que ya no se use la
máquina Enigma no significa que comenzar los mensajes con "tengo el
gusto de comunicarle..." sea una buena idea. Para evitarlo, una práctica
habitual consiste en insertar al principio del texto una ristra de datos
aleatorios llamada Vector de Inicialización (IV). El IV no significa
nada, no aparece en el texto llano, y su única razón de ser es hacer que
cada texto sea único.

Hay un precio a pagar. En el modo ECB, era posible paralelizar
el proceso. Es decir, si necesitamos un centenar de datos en una base de
acceso aleatorio, podemos irlos descifrarlos en paralelo. Pero el
descifrado en modo CBC ha de hacerse en serie, manipulando los bloques
de datos de uno en uno. En cuanto a la propagación de errores, existe
pero es pequeña. Si en modo ECB un error en un bloque cifrado impide
leer un bloque en texto llano, el mismo error en modo CBC afecta a dicho
bloque y a un bit del bloque siguiente. Nada más. Se dice que el modo
CBC de autorrecuperativo, lo que significa que después de esos dos
bloques erróneos el sistema sigue descifrando textos de forma normal.
También hay que tener en cuenta que un atacante puede añadir bloques de
datos si éstos se colocan al final del texto o mensaje.

Un problema común a los modos ECB y CBC es el de sincronía. Si,
por error, se introduce o se pierde un bit del conjunto de datos
cifrados (por una transmisión errónea, por ejemplo), el texto llano que
se obtiene resulta ilegible. Si no se introducen técnicas capaces de
detectar y corregir variaciones en el texto cifrado, un sólo bit
alterado nos convertirá el resto del texto cifrado en basura. Existe una
variación del modo CBC en la cual el texto llano se puede ir cifrando en
bloques más pequeños. Es decir, si el algoritmo de cifrado funciona en
bloques de 128 bits, el modo CBC nos permite cifrar en bloques de 64
bits, o de 16, o incluso de uno sólo. Este modo, llamado Modo de
Retroalimentación Cifrado (CFB, Cipher-FeedBack mode), es más complejo,
pero elimina los errores de sincronización. Otra variante, llamada Modo
de Retroalimentación de Salida (OFB, Output-FeedBack mode), es algo más
sencilla que la CFM. Tiene la ventaja que el error en un bit cifrado
solamente afecta a un bit de texto llano -lo que cierra las puertas a
algunos tipos de ataques-, pero también tiene errores de sincronización:
un sólo bit añadido o eliminado en el mensaje cifrado, y estamos fritos.

Con todo ello, las recomendaciones de Bruce Schneier en su libro
"Applied Cryptography" sobre los cuatro modos son los siguientes:

- ECB. Es el más simple y rápido, pero también el más
vulnerable. No se recomienda para cifrar mensajes,
- CBC. Es el mejor para cifrar archivos, ideal para
aplicaciones basadas en software (como bases de datos).
- CFB. Es el modo "de rigueur" para cifrar flujos de datos
transmitidos, cuando cada carácter ha de ser tratado individualmente,
como los enlaces entre servidor y terminal. Suele usarse en sistemas de
alta velocidad donde no se puede permitir ninguna propagación de
errores.
- OFB. Muy bueno en situaciones donde pueda haber errores, ya
que no los propaga.

Visto lo visto, nos queda claro que el modo ECB es el menos
seguro, ya que entre otras cosas permite notar patrones en el texto
cifrado. Eso nos permite poder entender mejor un artículo criptográfico
que apareció recientemente, y que ha provocado mucho revuelo. Una de las
aplicaciones de ECB es el cifrado de volúmenes cifrados. Tales bichos
son, sencillamente, grandes archivos cifrados que, al descifrarlos, se
convierten en carpetas enteras (incluso unidades de disco virtuales) en
nuestro disco duro. No es factible usar otros modos de encadenamiento en
este caso, porque de hacerlo el sistema tendría que re-cifrar todo el
volumen cada vez que yo modifique algún archivo de éste, convirtiendo
así un volumen de acceso aleatorio en uno de acceso secuencial, mucho
más lento de manejar.

Puesto que el modo EBC, como hemos visto, es vulnerable, los
fabricantes introducen añadidos tales como usar una clave que cambie
para cada posición del volumen, o de algún modo hacer que el proceso de
cifrado, aun con la misma clave, sea dependiente de la posición en el
volumen cifrado. Sin embargo, seamos sinceros, ¿cuántos de los usuarios
de este tipo de cifrado conoce este tipo de detalles. Yo mismo me he
tenido que empollar el libro del tito Bruce, lo reconozco. Así que, si
alguien dice que puede extraer información de una partición cifrada, nos
entra el pánico.

Algo así pasó hace poco cuando C. B. Roellgen, de la empresa PMC
Ciphers Inc, escribió un artículo con el título de "Visualización de
debilidades potenciales de implementaciones existentes de cifrado en
software comercial para disco". El autor muestra cómo una imagen cifrada
en modo ECB permite adivinar contornos de la imagen original. Para ello,
toma una fotografía reducida a cuatro colores: blanco, negro y dos tonos
de gris. Al cifrar con AES, se observa cómo las principales
características de la foto son aún visibles. El truco consiste en que,
al usar ECB puro y duro, las zonas de color uniforme se convierten en el
mismo tono de "color cifrado".

Es decir, nos están mostrando la obviedad de que iguales bloques
de texto llano se convierten en bloques de texto cifrado iguales a su
vez entre sí. Pero claro, si no sabemos la letra pequeña, lo único que
vemos es una foto cifrada cuyos contornos siguen siendo visibles aunque
de forma más borrosa (lo que se debe a que hay que tomar un puñado de
bits para formar un bloque para cifrar). Cuando utilizan un modo ECB
combinado con un parámetro dependiente de la posición de cada bit en la
foto, la fotografía se convierte en un conjunto de puntos aleatorios sin
patrones que podamos visualizar. Todo ello acompañado de código fuente
para que podamos comprobarlo en caso de duda.

¿Por qué publica este investigador lo evidente? En mi opinión,
para asustar. El autor, dando un paso más, afirma lo siguiente.
Imaginemos dos volúmenes cifrados, el original (1) y una copia exacta
(2). El volumen 1 contiene la fotografía, en tanto que el volumen 2 no
contiene nada, solamente ceros. Lo que dice este señor es que podemos
restar ambos volúmenes (es decir, hacer un XOR entre cada bit del
volumen 1 y el bit de la misma posición en el volumen 2), y al hacerlo
aparece el contorno de la fotografía, más o menos reconocible.

No es difícil ver por qué. Si la fotografía sólo tiene cuatro
colores, uno de ellos será el blanco, que representamos con ceros. En el
volumen 1, por tanto, las partes de la fotografía en blanco se cifrarán
de igual forma que los bits del volumen 2 que se encuentren en la misma
posición. Y, al hacer un XOR, esas partes aparecen. En el artículo, lo
sacan de color negro (restan en lugar de sumar), pero las partes que
aparecen son las blancas: la cara de la chica y su camiseta. El
resultado será igual si usamos ECB con una clave dependiente de la
posición, porque estamos comparando bits en la misma posición en ambos
volúmenes.

El propio artículo reconoce a las claras que "es la consecuencia
lógica de cifrar información idéntica con idéntica clave". De hecho,
esto es solamente posible porque el volumen cifrado 2 no fue creado,
sino copiado, lo que hace que tenga tanto la misma clave como el mismo
vector de inicialización (IV) del volumen 1. De haber creado el volumen
2 independientemente y haberlo dejado vacío, esto no hubiera sido
posible. A fin de cuentas, no se suelen crear volúmenes nuevos mediante
copypaste.

Ahora es donde viene el motivo. Todo el artículo está enfocado a
presentar un problema y, al final de todo, afirmar que hay un programa
llamado TurboCrypt, cuya última versión evita este problema. Este señor
trabaja, como hemos dicho, para PMC Ciphers. ¿Y adivinan qué empresa
fabrica TurboCrypt? !Premio!

La verdad es que todo el tema de PMC y TurboCrypt es hilarante.
Cuando leí el artículo por primera vez, me sonó un poco raro. Reconozco
que me perdí en el artículo, parte por el rollo de código fuente que
incluyen (innecesariamente, creo yo), parte por la sensación de estar
leyendo cómo inventaban la rueda. Cuando le hice notar a Bruce Schneier
sobre el artículo, su respuesta fue tajante: "Sólo están notando
patrones cuando alguien cifra en modo EBC. Nada nuevo ... y usar ECB es
una bobada". Al día siguiente, publicó el asunto en su blog
(http://www.schneier.com/blog/archives/2008/10/new_attack_agai.html, se
incluye enlace al artículo de PMC) donde lo calificaba de "intento
descarado de atraerse publicidad". Ya en 2003, Bruce habló de PMC en
estos términos:

"PMC Ciphers. La descripción de la teoría está tan llena de
pseudo-criptografía que es divertida de leer. Las hipótesis se presentan
como conclusiones. La investigación actual se especifica mal o se
ignora. El primer enlace es un artículo técnico con cuatro referencias,
tres de ellas escritas antes de 1975. ¿Quién necesita treinta años de
investigación criptográfica cuando tienes teoría de cifrado
polimórfico?"

¿Cifrado polimórfico? Pues sí que suena raro. De hecho, tan raro
que en cuanto abrí la página de PMC Ciphers http://www.turbocrypt.com
comencé a oler a "aceite de serpiente". Visto cómo son los americanos,
no resulta raro toparse, lo primero de todo, con una foto de la habitual
pelirroja escotada (la misma del artículo, por cierto). También podemos
considerar como exageración comercial las frases estilo "La herramienta
definitiva ... ninguna agencia gubernamental de este mundo podrá jamás
reventar TurboCrypt". Menos serio parece el concurso "rompa nuestro
sistema y le daremos un pastón", que incluye la típica perorata sobre
cuantísimas claves posibles habría que probar para vencer al sistema
mediante fuerza bruta.

Pero cuando leemos los detalles de su Cifrado Polimórfico
(PolyMorphic Cipher, o PMC) ... algunos detalles son para echarse a
reír, o cuando menos, a uno se le queda cara de bobo. En primer lugar,
se supone que su cifrado polimórfico, de 1024 bits, es tan estupendo que
uno puede usar en su lugar AES "si el usuario tolera una seguridad
menor" (TurboCrypt puede usarse con AES o con PMC, y la empresa afirma
que los usuarios prefieren PMC en un 80%). En otro lugar, dice que su
PMC se basa en cuatro algoritmos seguros (AES Rindjael, AES Twofish, RC6
y Mars), del que el usuario escoge uno; luego toma una especie de
generador de contraseñas y listo. En otro lugar, dicen que el sistema
toma dos contraseñas y las mete en una función hash. Parte del resultado
se usa !para compilar código máquina del algoritmo de cifra!

Lo más llamativo de TurboCrypt, en mi opinión, es la forma en
que se picaron con Bruce Schneier. El enlace que invita a romper su
cifra dice "Intente hacerlo mejor que Bruce Schneier. Rompa el Cifrado
Polimórfico". Justo encima, otro enlace nos lleva a una nota de la
empresa en la que, entre otras cosas, nos recuerda que la empresa en que
traba Bruce, BT Counterpane, "es competidora de PMC Ciphers, Inc. y que
es improbable que alguien con conexiones con los militares de EE.UU.
esté realmente interesado en hacer públicos algoritmos de cifrado
realmente seguros".

Frente a los ataques de Schneier de 2003, PMC Ciphers afirma que
la NSA usa su sistema de cifra, así que ha de ser bueno; y que, lo mismo
hasta lo han hecho bien y todo. Llegan incluso a apoyar los algoritmos
propietarios (esto es, secretos) y a recelar incluso del algoritmo de
cifra AES. ¿El motivo? La NSA tiene algoritmos propietarios, así que han
de ser algo bueno. Y aluden incluso a las fuerzas del mercado:

"¿Cuántos individuos y empresas van a invertir el dinero, tiempo
y esfuerzo necesario para desarrollar nueva tecnología de cifrado, si
luego lo regalan? La verdad pura y dura es que el capitalismo, el
potencial para hacer beneficios, es una de las mayores fuerzas que
impulsan el desarrollo de nuevas tecnologías. Eliminar esta fuerza del
desarrollo del cifrado sólo nos hará más débiles a largo plazo"

A la vista de la tormenta bursátil que nos azota estos días, no
creo que el argumento les sirva de algo. Y espero que eso que denominan
"activos tóxicos" no se refiera al aceite de serpiente de ciertas
empresas de encriptación.


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
CRIPTOGRAFÍA HISTÓRICA
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

=----------------------------------------------------------------------=
Los primeros criptógrafos - corrección
=----------------------------------------------------------------------=

Como algunos lectores han notado, el artículo "Los primeros
criptógrafos" del mes pasado contiene algunas erratas. Los diablillos
del copypaste hicieron de las suyas, sustituyendo una "e" en lugar de
"L". Entre otras cosas, criptografiaron de mala manera el cifrado
atbash, que debería ser como sigue:

"La transformación de Babilonia en Sesac se hizo mediante una
sustitución monoalfabética llamada "atbash". En una sustitución
monoalfabética, cada letra se convierte en un solo elemento cifrado (que
puede ser otra letra, un número, un signo o cualquier combinación de los
anteriores). En el atbash, se trata de sustituir el alfabeto mediante un
alfabeto escrito en orden contrario. Usando el alfabeto latino actual,
tendríamos:

Texto llano: A B C D E F G H I J K L M N O P Q R S T U V X Y Z
Texto cifrado: Z Y X V U T S R Q P O N M L K J I H G F E D C B A

De esta forma, BABILONIA se convertiría en YZYQNKLQZ. En el
alfabeto hebreo, BABEL (BBL) se convierten en SH-SH-K (Sheshak o Sesac).
Una transformación similar convierte los habitantes de "leb kamai" en
"kasdim" (caldeos) en Jeremías 51:1. Existe en la Biblia una segunda
transformación, denominada "albam", similar al atbash. Junto con el
atbah, forman un trío de sustituciones conocidas en el lenguaje hebreo
desde la antigüedad. Por ese motivo, no puede considerarse un lenguaje
criptográfico ya que la "clave" para cifrar descifrar es conocida e
inalterada."


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
LIBERTAD VIGILADA
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

=----------------------------------------------------------------------=
España reconoce su presencia en ILETS
=----------------------------------------------------------------------=

[Extraído del libro "Libertad Vigilada", de Nacho García Mostazo, con
permiso del autor]

Segunda parte, capítulo 16:

El 10 de abril de 2002, José Luis Centella, diputado de
Izquierda Unida en el Congreso, presentó una pregunta parlamentaria al
Gobierno sobre ILETS y la participación española en este "seminario".
Centella afirmaba que, "según diversos informes del Parlamento Europeo,
España participa desde 1993 en reuniones internacionales de seguridad de
las telecomunicaciones denominadas ILETS" y aseguraba que "el Congreso
de los Diputados, hasta el momento, no ha tenido conocimiento alguno de
tales encuentros", pese a que habían "asistido representantes del Reino
de España", por lo que pedía al Ejecutivo que explicara su implicación
concreta en ILETS. [1]

La respuesta tardó casi dos meses en llegar. Lleva fecha del 7
de junio de 2002, aunque no se publicó en el Boletín Oficial de las
Cortes Generales hasta el 1 de julio. El Ejecutivo afirmaba, intentando
quitarle importancia, que "ILETS es una reunión informal en la cual
participan, desde el año 1993 y por invitación, policías de los países
de la Unión Europea y terceros países, y en la que se trata la
problemática de la interceptación legal de los nuevos sistemas de
telecomunicaciones". En concreto, "acuden funcionarios del Cuerpo
Nacional de Policía especialistas en materia de telecomunicaciones e
interceptación legal de las mismas". En cuanto a la participación
española, el Gobierno matizaba afirmando que "están representadas las
agencias invitadas, no los distintos países". [2]

A continuación, explicaba que, "dentro del seminario, existe un
Comité Técnico Permanente (STC) y un Grupo de Trabajo de Política y
Legislación (LPWG), cuyos trabajos se centran en la puesta en común de
los desarrollos nacionales en el ámbito general de la interceptación de
las comunicaciones, tanto desde el punto de vista de las soluciones
técnicas, como en materia de legislación. Asimismo, estos grupos están
en permanente comunicación con las agencias de normalización europeas
ETSEI (Instituto Europeo de Normalización de las Telecomunicaciones) y
estadounidense CALEA (Acta de Asistencia en Comunicaciones para las
Agencias de Interceptación en Estados Unidos), donde se trata de
defender posiciones en común, como puede ser la Resolución del Consejo
de 17 de enero de 1995 sobre la interceptación legal de las
telecomunicaciones". El Ejecutivo se refería a la Resolución del Consejo
que adoptó el documento "IUR 1.0" elaborado por ILETS. Como se ha
mencionado, este documento se aprobó en secreto el 17 de enero de 1995,
pero no se publicó en el Diario Oficial de las Comunidades Europeas
hasta pasados 22 meses, el 4 de noviembre de 1996. [3]

Centella también preguntaba si se había celebrado alguna reunión
de ILETS en España, a lo que el Gobierno contestó que "en España no ha
tenido lugar ninguna reunión de ILETS como tal pero, en octubre de 1998,
se reunieron en Madrid, en instalaciones de la Dirección General de la
Policía, los dos Grupos de Trabajo anteriormente mencionados", lo cual
venía a confirmar lo revelado por Duncan Campbell sobre la reunión en
Madrid para preparar la revisión del documento "IUR 1.0". En su
respuesta, el Ejecutivo también explicaba que estos encuentros
"constituyen una herramienta más del trabajo para la mejora de la
eficacia en la función policial. Por ello, se intenta participar en
todas las reuniones donde se traten temas de interés para la labor
policial al efecto de estar perfectamente informados de los avances
técnicos y legislativos a nivel mundial". En cuanto a la necesidad
manifestada por el diputado de Izquierda Unida para que el Gobierno
mantenga informado al Parlamento sobre estas cuestiones, la respuesta
fue contundente: "Su celebración no está sujeta a especiales requisitos
en cuanto a comunicaciones [...], ni en cuanto al suministro de
información que proceda a los organismos institucionales que la
demanden."

Por último, José Luis Centella preguntó sobre la adaptación de
las resoluciones adoptadas en ILETS a la legislación española. Aunque el
Gobierno ya había mencionado la Resolución del Consejo de la Unión
Europea del 17 de enero de 1995, amplió esta información detallando cuál
es el procedimiento habitual que se sigue: "Los temas tratados se llevan
al Consejo Europeo a través de los Grupos de Trabajo de Cooperación
Policial, a los que pertenecen muchos de los representantes de las
agencias que acuden a ILETS." Así pues, el Ejecutivo estaba revelando
que los funcionarios de los Grupos de Trabajo de Cooperación Policial en
la Unión Europea, que son quienes redactan los informes "ENFOPOL", son
los mismos empleados públicos que también acuden a las reuniones de
ILETS, lo cual es especialmente importante para la investigación que nos
ocupa, ya que confirma la relación directa del FBI y la NSA en la
redacción de los documentos aprobados por las instituciones de la UE.

Pero de todas las preguntas formuladas por el diputado de
Izquierda Unida, el Gobierno sólo dejó una sin contestar: ¿Quién
organiza estos encuentros? Gracias al Parlamento Europeo podemos saber
que ILETS fue una idea del FBI en colaboración con la NSA. En su
respuesta, el Ejecutivo sí explicó que los funcionarios policiales
acuden a ILETS "por invitación" y en compañía de sus homólogos de otros
Estados de la Unión Europea y de "terceros países", pero no especificó
de qué países y, sobre todo, no dijo que la idea partió de Estados
Unidos, la nación responsable de la mayor red global de interceptación
de las comunicaciones. Es posible que ese dato no tuviera demasiada
relevancia para el Gobierno español, aunque también podríamos pensar que
prefirió ocultarlo, quizá por su, cada vez más, creciente "amistad" con
Norteamérica.


[1]. Documento 184/027764. Pregunta escrita al Gobierno. Boletín
Oficial de las Cortes Generales. Serie D, número 342, de 24 de abril de
2002. P. 44.

[2] Documento 184/027764. Respuesta escrita del Gobierno.
Boletín Oficial de las Cortes Generales. Serie D, número 381, de 1 de
julio de 2002. Pp. 128 y 129.

[3]. NOTA: Hemos respetado la cita literal del Gobierno, aunque
comete varios errores graves en ese párrafo. Cuando se refiere a CALEA,
el Ejecutivo se equivoca porque ese término se refiere a la Ley de
Asistencia en Comunicaciones para los Cuerpos de Seguridad
norteamericanos, no a una agencia estatal de normalización en Estados
Unidos. Asimismo, cuando cita a la agencia europea ETSEI, probablemente
se trate de una equivocación en la transcripción, pero el acrónimo
correcto es ETSI (European Telecommunications Standards Institute).



========================================================================

El boletín ENIGMA es una publicación gratuita del Taller de
Criptografía, y se rige por las normas de la licencia de Creative
Commons "Reconocimiento-NoComercial-CompartirIgual". Se permite su libre
copia, distribución y comunicación para fines no lucrativos, citando
nombre y referencia.

Para más información, véase la licencia Creative Commons en sus formas
reducida y completa:
http://creativecommons.org/licenses/by-nc-sa/2.5/es/deed.es
http://creativecommons.org/licenses/by-nc-sa/2.5/es/legalcode.es

PARA DARSE DE ALTA: envíe un mensaje a la dirección alta arroba
cripto.es añadiendo las palabras alta_enigma en el asunto (subject).

PARA DARSE DE BAJA, envíe un mensaje a la dirección baja arroba
cripto.es añadiendo las palabras baja_enigma en el asunto (subject)

Para comentarios a este boletín (dudas, preguntas, consultas, críticas,
noticias, colaboraciones, etc.), estoy a su disposición en la dirección
noticias arroba cripto.es

Página del Boletín Enigma (incluyendo números atrasados):
http://www.cripto.es/enigma.htm


(c) Arturo Quirantes 2008.

========================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5i

iQA/AwUBSQnfxw7Y43Xkw2u9EQK5UgCgiJJtNGWy85gcMfc0Fk05WAHrOYQAoJol
3x4kImDYI4qeKVt5keqFPYie
=JMAt
-----END PGP SIGNATURE-----

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=