Por Fernando Acero
Desde hace tiempo, estoy recibiendo correos de gente que me pregunta sobre la posibilidad de decodificar el archivo INSURANCE de Wikileaks, que presuntamente (el nombre lo pone) está codificado usando el algoritmo AES256. Al margen de las discusiones morales, prácticas y éticas, derivadas de decodificar a las bravas un archivo que presuntamente sirve para salvar la vida de alguien, nos podemos centrar en el estudio de la parte técnica de este asunto de la decodificación del AES, que todo hay que decirlo, es un asunto que me interesa mucho más...
De todos modos, ¿alguien se imagina lo que me pasaría si yo dijera en este momento: “Señores, durante una noche de insomnio y usando mi batería de tarjetas NVIDIA, he logrado decodificar el archivo INSURANCE de Wikileaks”?. Puede que en la puerta de mi casa encontrase tantos agentes secretos vigilando mis movimientos y tanta gente atacando mis sistemas informáticos, como periodistas en la final del mundial de fútbol y eso no me apetece en absoluto ¿y a ustedes?.
El ALGORITMO AES
El algoritmo AES (Advanced Encryption Satandard), también conocido como Rijndael, es un sistema de cifrado por bloques simétrico, pensado para sustituir al obsoleto DES y optimizado para las transmisiones seguras de mensajes a través de las redes de telecomunicaciones. AES es muy rápido, tanto en las implementaciones de software, como en las de hardware y además de ser relativamente fácil de implementar, requiere poca memoria para realizar los cálculos. Como nuevo estándar de cifrado, se está utilizando a gran escala por todo el mundo, lo que le parece muy interesante a los amigos de asuntos conspiratorios. El AES/Rijdael, fue desarrollado por dos criptólogos Belgas, llamados Daemen y Rijmen, cuando eran estudiantes de la Universidad Católica de Leuven.
La principal diferencia entre el AES y el DES al que sustituye, es que el AES usa una red de sustitución-permutación (serie de sustituciones y permutaciones, que se suceden unas a otras sobre una matriz), en lugar de una red de Feistel. El AES utiliza un bloque de tamaño fijo de 128 bits (originalmente podía usar bloques de varios tamaños) y las claves pueden ser de 128, 192 y 256 bits. Al igual que el DES, el procedimiento de codificación se basa en una operación básica llamada "ronda", que se repite un número fijo de de veces dependiendo del tamaño de la clave. Así, con las claves de 128 bits, se usan 10 rondas, 12 rondas con las de 192 bits y 14 rondas, para las claves de 256 bits. AES trabaja sobre una estructura conocida como el "estado AES", que es simplemente una reordenación del bloque básico, usando una matriz de 4×4 y por lo tanto, es un sistema que tiene una descripción matemática bastante simple, aunque para la mayoría de los comunes mortales, es más sencillo verlo como operaciones con bytes en una matriz de datos.
Los bloques básicos del AES son:
- SubBytes - Una sustitución no lineal en el estado AES.
- ShiftRows - Realiza un desplazamiento sobre las filas del estado AES.
- MixColumn - Mezcla columnas del estado de AES, haciendo cada celda una combinación de otras celdas.
- AddRoundKey - Mezcla la clave con el estado AES.
Una codificación AES consiste en la realización de los siguientes pasos sencillos:
1. Ronda Inicial:
- AddRoundKey
2. R-1 Rondas:
- SubBytes
- ShiftRows
- MixColumns
- AddRoundKey
3. Ronda final
- SubBytes
- ShiftRows
- AddRoundKey
El proceso de decodificación sin embargo, es más complicado que con el DES, en el que simplemente había que volver a “codificar” un mensaje ya “codificado”, usando por supuesto, la misma clave. En el caso del AES, es necesario definir las operaciones inversas para ShiftRows, SubBytes y MixColumns. Hay que señalar, que para la operación AddRoundKey no se requiere una inversa, puesto que basta con aplicarla otra vez con la misma clave, para obtener su inversa.
SEGURIDAD REAL DEL AES
Se dice que un sistema criptográfico está roto cuando existe algún ataque más rápido que una búsqueda exhaustiva (ataque por fuerza bruta), aunque este ataque sea solamente teórico, y no sea viable por la cantidad de datos, tiempo, o memoria necesaria.
Algunas personas han dicho que el AES está roto por los resultados obtenidos con una clave de 64 bits, que fue llevado a cabo por distributed.net, pero la realidad es que solamente fue un ataque por fuerza bruta de una clave muy pequeña de 64 bits, por lo que no lo podemos considerar como una ruptura del AES.
De hecho, el AES, a pesar de ser un algoritmo público y de uso público, está considerado como la NSA (Agencia de Seguridad Nacional de los EEUU) desde el año 2003, como algoritmo seguro para proteger información clasificada de nivel SECRETO usando claves de 128 bits y de ALTO SECRETO, si se usan claves de 192 o 256 bits. No deja de sorprender, teniendo en cuenta el amor-odio del Gobierno de los Estados Unidos con los sistemas de cifrado, que el gran público pueda tener acceso a un sistema de cifrado considerado apto por la NSA, para proteger información sensible del más alto nivel, lo que no deja de levantar muchas suspicacias.
LOS ATAQUES POSIBLES
La forma más asequible de ver si es posible realizar un ataque a un codificador de bloques, es intentar atacarlo mediante la reducción del número de rondas utilizadas en la codificación. Si recordamos, el AES usa 10 rondas para las claves de 128 bits, 12 rondas para claves de 192 bits, y 14 rondas para claves de 256 bits. Hasta el año 2005, los mejores ataques conocidos tuvieron éxito sobre versiones reducidas a 7 rondas para claves de 128 bits, de 8 rondas para las claves de 192 bits, y de 9 rondas, para las claves de 256 bits.
Sin embargo, también es cierto que en estos ataques se evidencia una escasa diferencia entre las rondas reales y las de los mejores ataques conocidos, por lo que con una pequeña mejora en los ataques, cabría la posibilidad de romper un cifrado que use todas las rondas. Está claro, la mejor vacuna para el problema, sería aumentar el número de rondas sin cambiar el algoritmo. Sin embargo, esta solución también tendría un impacto en la eficiencia del algoritmo y sobre todo, en la actualización de los sistemas basados en hardware. Hay que señalar, que se conocen algunos ataques exitosos sobre determinadas implementaciones del AES, que se basan en el canal auxiliar, pero estos ataques no atacan al algoritmo en sí mismo, sino a una implementación específica del mismo, por lo que tampoco son aplicables a la decodifcación del archivo de Wikeleaks.
En esta línea de investigación, en el año 2009, Alex Biryukov y Dmitri Khovratovich, de la Universidad de Luxemburgo, publicaron este interesante artículo, con dos ataques contra el algoritmo de cifrado AES, que mejoran de forma impresionante los resultados anteriores. Biryukov y Khovratovich anunciaron un ataque contra AES de 256 completo, es decir, con sus 14 rondas. El ataque tiene una complejidad computacional de solamente 2^96 operaciones, es decir, romper la seguridad de un AES256/14 sería tan difícil como probar 2^96 claves. No cabe la menor duda de que está fuera del alcance de la mayoría de los mortales, pero ver un algoritmo de 256 bits con una fortaleza equivalente a la de uno de solamente 96 bits, no dice mucho a favor del algoritmo. Pero tranquilidad, que esta afirmación tiene trampa, solamente funciona con determinadas claves “podridas”, es decir, con una clave de cada 34.000 millones. ¿Habrá usado Wikileaks una de esas claves podridas de forma voluntaria o involuntaria?. Sin duda es una buena pregunta, ya que no sabemos exactamente lo que pretende Wikileaks con este archivo, si que no lo abra nadie, o que solamente lo abran los que están “retratados” en él, para darles miedo.
Sin embargo, el otro ataque de Biryukov y Khovratovich, aunque es menos “efectivo” que el anterior, funciona con cualquier clave y demuestra otros datos preocupantes sobre el AES. El ataque contra el AES-128/10, tendría una complejidad matemática de 2^123 datos (claves), 2^176 en tiempo y de 2^152 en memoria, así que aunque curioso, esto no es nada preocupante por el momento. Sin embargo, el ataque contra el AES-256/14 es mucho más efectivo, ya que solamente se necesitan 2^119 en datos y tiempo y 2^77 en memoria. Dicho de otro modo, el AES-256 tiene la misma fortaleza que un teórico AES-119/14, por debajo del AES-123/10 que se obtendría con el ataque a un AES-128/10 y esto, con independencia de la clave que usemos. Es evidente que esto sigue estando fuera del alcance de cómputo de la mayoría de los mortales, pero ¿lo está del alcance de una superpotencia?, sobre todo, si tenemos en cuenta además, que los autores dicen que pueden mejorar el ataque al AES-256/14 a una complejidad de solamente 2^110,5?. Dicho esto, aunque la NSA dijo que el AES-128/10 era seguro para los SECRETOS y el AES-192/12 y el AES-256/14 para los ALTOS SECRETOS, lo cierto es que visto lo anterior, el AES-128/10 es más seguro que el AES-256/14 en igualdad de condiciones.
Pero si lo anterior no nos preocupa demasiado, hay otro interesante artículo, fechado el 19 de agosto de 2009, y firmado por unos reputados Alex Biryukov, Orr Dunkelman, Nathan Keller, Dmitry Khovratovich, y Adi Shamir. En este articulo comentan algo mucho más preocupante sobre el AES-256, ya que lograron ataques contra el AES-256/9 con una complejidad matemática de solamente 2^39 operaciones, contra el AES-256/10 con una complejidad de solamente 2^45 y consideran que el AES-246/11, podría tener una complejidad de solamente 2^70, valores todos ellos, muy por debajo de los logrados por Biryukov Khovratovich.
Está claro, no se está hablando del AES-256/14, pero es evidente, que hay un problema y grave con el AES-256, aunque solamente hayan llegado a las 10 rondas y especulado un poco sobre las 11 rondas. De nuevo me pregunto ¿está esto fuera del alcance de la NSA con todos sus medios técnicos y sus miles de matemáticos en plantilla?.
Bueno, para ser justos, hay otra trampa en el plantemiento de Shamir y sus amigos, estos ataques no son prácticos con el archivo de Wikileaks, pero solamente desde nuestro lado, ya que el que el que tiene los mensajes en claro (aunque no sepa exactamente los que son). Es decir, el Gobierno de los EEUU, lo tiene complicado, pero no tanto como nosotros, que no tenemos nada para empezar a trabajar. Los ataques anteriores se denominan de “claves relacionadas”, es decir, que se supone que el criptoanalista dispone de acceso a una serie de textos en claro, que han sido codificados mediante varias claves distintas, las cuales, tienen una relación específica entre ellas.
Parece demostrado en el caso del AES, que a mayor tamaño de la clave, menor es la dificultad para romperla. Algo que puede significar que no se eligió un número de rondas adecuado para el tamaño de cada clave, puede que por un compromiso entre la seguridad y la velocidad, pero que al final, ha comprometido la seguridad las versiones de AES 192/12 y 256/14. Los dos “paper” que hemos revisado anteriormente dicen lo mismo con distintas palabras, en este momento, es más seguro el AES-128/10 que el AES-256/14 y en términos estrictos lo podemos considerar roto, desde los primeros resultados de Biryukov y Khovratovich, ya que su fortaleza en ciertas condiciones es inferior a la de un ataque por fuerza bruta.
Teniendo en cuenta que Bruce Shneier ya recomendaba en su blog el día 30 de julio de 2009, que se usase AES-128/10 en lugar de AES-256/14, es curioso y no menos inquietante, que los responsables de Wikileaks, tan preocupados por la seguridad como están, hayan decidido proteger su archivo “salvavidas” con un roto AES-256.
Si me hubieran preguntado, si buscase la seguridad absoluta de que el archivo no sería abierto en un tiempo razonable y mi vida fuera en ello, yo no hubiera optado por el AES-256/14 ni por asomo, que hablando claro, en este momento, lo podemos considerar seguro, aunque menos seguro que el DES que pretende sustituir.
"Copyleft 2010 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
Saludos! Un artículo muy
alexdeguays3 Septiembre 2011 - 8:00am
Saludos! Un artículo muy interesante, del cual me gustaría opinar.
En primer lugar, y sin ánimos de ofender a nadie, creo que el título del artículo es capcioso, ya que presupone que el archivo INSURANCE ha sido cifrado con AES256, cosa que evidentemente nadie puede asegurar sólo por el simple hecho de que el archivo tenga la extensión correspondiente. Ese archivo ha podido ser cifrado con cualquier protocolo, con cualquier modo de cifrado, un número indeterminado de veces y maneras, e incluso el contenido del archivo ha podido ser codificado previamente de una manera entre las infinitas posibles.
Entrando más en el tema AES256, y suponiendo que efectivamente el archivo ha sido cifrado con él y sólo con él, y el contenido original del archivo no ha sido alterado previamente (o alterado el criptograma final de alguna manera!), mi opinión es que, a pesar de las vulnerabilidades que puedan descubrirse, el archivo puede ser seguro durante muchísimo tiempo. Ello es debido a que desconocemos qué modo de cifrado por bloques se ha empleado (considero prácticamente imposible ECB), y por tanto desconocemos, además de la clave de cifrado, el resto de parámetros del cifrado.
Por ejemplo, para fijar ideas supongamos que se ha empleado AES256 en modo CTR...¿qué vale Nonce? ¿con qué valor se inicia el contador? ¿qué tamaño tienen ambos? Y eso si no se ha empleado algo tipo CCM (ver rfc3610) para asegurar encriptación y autenticación, en cuyo caso, ¿qué tamaño tiene el campo MAC? ¿tiene el archivo alguna cabecera CCMP o no?
Todos esos parámetros multiplican las posibilidades hasta el infinito, y de la misma manera complican el descifrado.
Opción
metinha11 Diciembre 2010 - 4:54pm
Lo primero, felicidades por el artículo, está genial. Me gustaría añadir, que quizás la forma de romperlo con una máquina de propósito general, el invertir las permutaciones de filas y columnas puede resultar muy costoso en tiempo computacional, pero...¿y si la máquina fuese diseñada para ese propósito específico? De todas formas opino (y me desdigo con lo que opiné anteriormente) que Julian Assange no tiene la certeza de que al otro lado del charco tengan los medios para romperlo, si no, ¿Por qué antes de entregarse declaró la temática del fichero? Supongo que habrá declarado para asegurarse, aunque crea que lo puedan hacer.
Acerca del algoritmo AES tengo una duda desde hace mucho tiempo, a ver si me podeis ayudar. ¿Por qué no se eligió Serpent? Desde mi ignorancia, me pareció bastante mejor que el actual AES.
Te respondo....
Fernando Acero11 Diciembre 2010 - 8:40pm
Las máquinas específicas son complicadas, caras y es complicado conseguir la potencia necesaria. Posiblemente es mucho más asequible recurrir a soluciones distribuidas como Boinc, pero así y todo, las necesidades para computar 2^120 claves, no deja de ser una tarea ingente.
Respecto al Serpent estoy de acuerdo, aunque son muy parecidos en su estructura interna con un bloque de 128 bits, Serpent es más seguro que el AES/Rijndael ya que los diseñadores se "pasaron" de conservadores en su diseño, lo que puede que les acabase penalizando. En definitiva, estamos de nuevo ante el eterno dilema seguridad o comodidad, al parecer, se decantaron por la comodidad.
Serpent usa más rondas (32, aunque 16 podrían ser suficientes según los diseñadores) que el AES (14 rondas, que ya se han demostrado insuficientes para la versión de 256 bits) y por ello, es más pesado, aunque menos que el DES que pretendía sustituir. Supongo que en una época en la que el procesador medio era un Pentium a 200 Mhz, o a 300 Mhz, este hecho tuvo que tener bastante influencia en la decisión final.
Al no existir problemas de seguridad con ninguno de los finalistas, se tuvieron en cuenta otros factores para tomar la decisión. Las puntuaciones obtenidas en la última conferencia fueron las siguientes:
Rijndael 86
Serpent 59
Twofish 31
RC6 23
MARS 13
Por cierto, hay una versión GNU para Serpent:
http://www.gnupg.org/oids.html
Un saludo, Fernando Acero
Un pequeño offtopic sobre serpent
naw12 Diciembre 2010 - 5:36pm
Serpent esta soportado en la parte S/MIME de GnuPG:
Mientras que en la parte OpenPGP no hay soporte:
Esto es debido a que en el estándar OpenPGP solo están definidos un limitado número de algoritmos, si bien se ha ampliado a otros algoritmos como CAMELLIA. Pero imagino que les cueste bastante añadir algoritmos al estándar por temas de interoperabilidad.
En cuanto a gpgsm, el algoritmo por defecto es 3DES y no se cuantas implementaciones tendrán soporte de SERPENT u otros algoritmos.
Eso imaginaba
metinha11 Diciembre 2010 - 11:59pm
Eso había imaginado, muchas gracias por la aclaración. Como bonus, añadir que Truecrypt también admite Serpent. Ah y una explicación también bastante buna de AES Rijndael la podemos encontrar aquí http://tec.upc.es/sda/AES.pdf.
Me parece que el problema
naw11 Diciembre 2010 - 8:26pm
Me parece que el problema de Serpent es que era más lento y más complejo.
Un aplauso...
Shevek10 Diciembre 2010 - 6:21pm
... sí señor, toda una revisión del "estado del arte" (como dicen los anglófonos) de ataques a AES hasta el momento.
De todas formas, los ataques son muy académicos. Se necesita mucho texto en claro y, como dice Fernando, sólo unos pocos disponen de ese material (que son los menos interesados en que se revele el contenido...). Además, no es suficiente tener el texto claro, sino relacionarlo con el texto cifrado, que puede estar comprimido y ordenado de cualquier forma.
Otra manera de usar una clave de 256 bits es la siguiente: se codifica todo con AES128 siguiendo el esquema CTR con un contador inicial de 128 bits secreto, que sería un trozo de una clave de 256 bits; el otro trozo de la clave sería el que usaría el algoritomo AES128.
Gracias por las alabanzas...
Fernando Acero10 Diciembre 2010 - 4:06pm
Estimados amigos, gracias por las alabanzas, se hace lo que se puede...
¿Te acuerdas, Fernando?
admin10 Diciembre 2010 - 4:54pm
No sé tú, pero yo aún recuerdo muy bien el día que caíste por aquí y yo vi tu nombre y te di la bienvenida a Kriptópolis en nombre mío y de esta comunidad.
Fue como si nos hubiera tocado el gordo ;)
Y en esas estamos. Disfrutando y aprendiendo de ti.
Claro que me acuerdo...
Fernando Acero10 Diciembre 2010 - 7:12pm
Estimado amigo, de eso van a hacer casi 6 años en breve y parece que fue ayer. Para mí ha sido un placer colaborar y siempre, me he sentido con esa colaboración. Sí, hemos superado con creces el lustro.
Gracias a vosotros, yo también he aprendido muchas cosas y por favor José Manuel, no creo que os haya tocado el gordo, peso solamente 82 Kilos :-DDD.
Sin duda, aquí hay más gente que se merece más elogios que yo, que aunque contribuyan menos, sus contribuciones son de mucha más calidad que las mías.
Un saludo, Fernando Acero
A guardar!
Sasha10 Diciembre 2010 - 3:00pm
Pinchar en "versión para imprimir" (iconito de la impresora) y guardar como PDF. La verdad es que el Sr. Acero es de lo más valioso que hay en esta web...
El único punto negativo que le veo a todo esto es que me ha aclarado una serie de conceptos que me hubiesen venido bien antes del pasado 30 de noviembre, ya que tuve ese día un examen para la oposición de Operador de Servicios Informáticos y hubo bastantes cosas sobre criptografía. Alguna la dejé en blanco y la hubiese sacado bien :/
Conio!!! Justo lo comentaba con un colega!!!
packet10 Diciembre 2010 - 12:28pm
Exactamente lo expuesto aquí lo comentaba con un colega como posibilidad: mantener en secreto para la gente de a pie y desencriptable a lo bruto por gente con suficientes recursos.
Cabe la posibilidad
Neofito10 Diciembre 2010 - 12:57am
Cabe la posibilidad de que dentro de ese fichero exista otro fichero encriptado?
Puede ser lo mismo
anv10 Diciembre 2010 - 4:14pm
No se si será el caso de AES pero en muchos sistemas de cifrado, cifrar dos veces equivale simplemente a cifrar con una clave diferente. O sea que si yo cifro 100 veces un mensaje bien podría ser que la dificultad de descifrarlo sea la misma que si lo cifré una sola vez.
En particular, los cifrados basados en XOR tienen esa característica. Ejemplo:
Valor a cifrar: 32
Clave: 123
Resultado: 32 xor 123 = 91
Cifrando de nuevo:
Valor a cifrar: 91
Clave: 234
Resultado: 91 xor 234 = 177
Esto es equivalente a cifrar el valor inicial (32) con la clave 145 (que, no casualmente, es igual a 123 xor 234). O sea, que por más que repitamos el cifrado mil veces, lo único que estamos haciendo es cambiando la clave de cifrado, y la dificultad para descifrarlo es la misma.
No se si esto es aplicable a AES, pero AES utiliza XOR como parte del procedimiento.
Cifrado y re-cifrado - Si cabe imaginar esa posibilidad
Pedro Fdez.10 Diciembre 2010 - 12:09pm
Ya fue comentado en el artículo en que se planteaba la posibilidad e inconveniencia de intentar su descifrado. Son posibilidades imaginables, pero las que realmente importan son las que no podemos imaginar. Y no sólo porque la realidad suela superar a la ficción, sino porque todo ello estará, seguramente, rodeado de un metalenguaje sólo entendible por iniciados.
Suponiendo
anv10 Diciembre 2010 - 12:27am
Suponiendo que lo que se encuentra en el archivo cifrado es una amenaza real. En realidad les conviene que la NSA pueda descifrarlo. De esa forma pueden saber qué es lo que hay ahí y comprobar que la amenaza es verdadera.
Si no pudieran descifrarlo podrían suponer que lo que hay ahí adentro es sólo basura o cualquier documento de los que ya han sido publicados.
Así que si es cierto que AES256 no es tan seguro, puede ser un punto a favor para creer que tienen algo realmente comprometedor.
Un artículo impresionante,
eb4bgr (no verificado)9 Diciembre 2010 - 10:55pm
Un artículo impresionante, Fernando. Muchas gracias por la información. Bueno, supongo que queda menos tiempo para que alguien se decida a hacer ataques más serios al Cifrado PSA y, dicho de paso, la posibilidad de que lo consigan. Eso sí, yo se lo pondré tan difícil como mis neuronas me lo permitan.
Muchas gracias por lo
Boca9 Diciembre 2010 - 10:35pm
Muchas gracias por lo didáctico del artículo.
Ya lo expuse en otro sitio, pero como fue de los últimos comentarios no debió leerlo casi nadie.
Si el "Seguro" de Wikileaks es un verdadero seguro, la NSA conoce el contenido, a Wikileaks le interesa mucho que el gobierno americano sepa a que se expone, cuanto más comprometida sea la información, más interés en que no se publique. O Wikileaks conoce de la existencia de puertas traseras (especialmente en los dispositivos de cifrado por hardware) o, directamente, les han enviado la clave a la NSA. Si la NSA no conoce el contenido del seguro, puede pensar que es un farol. Lo mejor es darles la clave.
Hola, Fernando
Agustín9 Diciembre 2010 - 10:34pm
Me uno a las felicitaciones y agradecimientos. Caramba, entrar en tus artículos o en los Enigmas es como hacerlo en una catedral, resuenan las pisadas y se te encoge el espíritu.
Bueno, pues para completar tu magnífica exposición, pongo un enlace que nos proporcionó inedit00 en otro foro, por si alguien no lo ha visto, donde se visualiza claramente el algoritmo.
http://www.formaestudio.com/rijndaelinspector/archivos/rijndaelanimation...
Que conste que a mí el Rijndael cada vez me gusta menos.
(REEDICIÓN)
P.S.
No es imposible que INSURANCE esté cifrado de cualquier otra forma, aparte de AES. Al fin y al cabo, uno puede ponerle a un fichero la extensión que más le agrade. El que el fichero empiece por "SALTED_" puede significar algo o no. También puede ser un postizo.
He encontrado esto tan curioso...
Fernando Acero16 Diciembre 2010 - 10:43pm
Hola Agustín:
He encontrado esto tan curioso sobre el cifrado del INSURANCE, al parecer, no está cifrado con AES Crypt, tal como afirmaba Assange y está cifrado con OpenSSL.
http://www.securitybydefault.com/2010/12/como-se-descifraria-el-fichero-...
Un saludo, Fernando Acero
Al habla Perogrullo
admin16 Diciembre 2010 - 11:23pm
El tema Wikileaks resulta cada vez más esperpéntico.
A ver... ¿acaso tiene alguna importancia el interfaz utilizado? ¿no es lo "importante" el algoritmo utilizado? ¿acaso no es ése AES256, como indica el propio nombre del fichero?
A este paso hasta los aficionados a la Numerología tendrán algo que decir: ¿por qué 2-5-6, que no es sino 6-5-2 al revés, es decir, el número de la bestia menos dos veces el número de profetas?
Señores: está cayendo una muy gorda en el mundo como para ser pasto de esta pachotada seudoconspiratoria que no pretende más que distraer.
Perdona el retraso
Agustín16 Diciembre 2010 - 11:06pm
en contestarte, Fernando. Sí que es curioso. Y aún más curioso resulta que Assange no se haya molestado en cambiar la cabecera, porque no le hubiera costado nada modificar/añadir unos cuantos bytes, para que pareciera que realmente estaba cifrado con AES Crypt, o con el método de Perico de los Palotes. Bastaba con que junto con la clave hubiera unas instrucciones para restaurar la cabecera original. Eso es lo que yo hubiera hecho para despistar más a los atacantes, si el objetivo era dificultar el descifrado. Claro que yo no soy Assange, y no conozco sus objetivos. Otro misterio más que añadir a la lista.
Un saludo.
Me uno a las felicitaciones
usrdxt9 Diciembre 2010 - 9:55pm
por la sencillez y lo didáctico del artículo.
Gracias Fernando
Gargamel9 Diciembre 2010 - 8:10pm
Gracias Fernando.
Leerte y conocer cosas ... , explicadas con brevedad y sencillez ....
Siempre - o casi - aprendo algo de tus envíos
Saludos
¿Cifrados simétricos existiendo los de clave privada+pública?
Pedro Fdez.9 Diciembre 2010 - 7:42pm
Saludos y gracias, como siempre Fernando; te explicas como un "libro abierto"... Lo que más te agradezco es lo enormemente didácticos que resultan tus artículos. A mí tampoco me llama demasiado la atención todo lo que está ocurriendo con estos asuntos sobre filtraciones para las masas o, como se ha dado en llamar por quienes se dedican a la profesión informativa o periodística: "Mass Leaks", que nos recuerda ese otro, ya acuñado en el pasado siglo XX, de "Mass Media". Ahora, como fenómeno sociólogico, reconozco que es muy importante e interesante aunque yo no tenga el tiempo necesario para poder dedicárselo con un mínimo de rigor ya que, de otra forma, se quedaría todo en un simple cotilleo del que poco conocimiento se podría extraer.
El presente comentario era, más que nada, para expresar un pensamiento que a mí me surgió de inmediato al tener constancia de la verdadera existencia del fichero cifrado 'Insurance.aes256' ¿Por qué usar criptografía simétrica si se puede usar la asimétrica u otra más avanzada que, seguramente, existirá? De la misma forma que se puede hacer pública una simple contraseña o "password" también se puede hacer pública una clave privada cuando fuera necesario... Por más vueltas que le doy no encuentro justificación si de un "nivel alto" estamos hablando.
Por otra parte, parece estar claro que la elección de ese algoritmo concreto (AES) tendrá su razón de ser en alguna de las especulaciones ya vertidas en Kriptópolis estos últimos días. Yo no estoy demasiado al día, pero recuerdo que Bruce Shneier, sin ir más lejos, puso a disposición de todos el Twofish o, mejor, el Blowfish que seguramente son incluso más robustos para un cifrado simétrico.
A ver en que para todo esto, como decían antiguamente: ¡Seguro que, al cocer, mengua!
Saludos cordiales,
Pedro Fernández
--
Cifrado simétrico
xblasco10 Diciembre 2010 - 12:09pm
Los algoritmos de clave privada+pública (asimétricos) tienen un costo computacional muy elevado.
Los programas de cifrado de mensajes (GPG, etc.) en realidad aunque haya una clave pública+privada cifran los mensajes con una clave simétrica generada aleatoriamente. Y usan el par privado+público para cifrar la clave simétrica.
Por lo tanto utilizar la clave publica+privada no incrementa la seguridad en un ataque por fuerza bruta a un único fichero cifrado.
más seguro
anv10 Diciembre 2010 - 11:20am
Porque la criptografía simétrica es más segura.
La debilidad de la criptografía simétrica es la necesidad de divulgar la clave para que sea descifrada, pero por lo demás es segura.
De hecho, la criptografía asimétrica se basa en un cifrado simétrico hecho con una clave generada al azar. Esa clave se envía por métodos asimétricos pero el verdadero cifrado es simétrico. Para descifrar un sistema asimétrico hay dos opciones: o atacar al cifrado asimétrico para obtener la clave simétrica, o tratar de atacar directamente el cifrado simétrico. Como bien sabemos, es mucho más fácil atacar el asimétrico que meterse con la parte simétrica.
No tiene porqué ser así
Andy9 Diciembre 2010 - 7:38pm
Hola Fernando,
Me alegro de
verteleerte nuevamente por aquí.Dices:
Hablas del standard. En el caso de AES256 (Rijndael) se utilizan 14 rondas en el standard.
Pero en realidad eso no está grabado en piedra. Dichos valores de rondas hacen que el algoritmo vaya lo bastante rápido como para ser práctico.
Sin embargo, nada impide utilizar por ejemplo AES256 con 30, 40, 50 o más rondas, a expensas de tiempo de procesado, por supuesto.
En el caso que nos ocupa, este señor puede tranquilamente haber tardado 1 semana en encriptar el fichero utilizando todas las rondas necesarias, ya que se trata de datos estáticos (opuesto a, por ejemplo, paquetes IP de una sesión SSH que hay que encriptar y transmitir).
Un saludo,
Andy
Tocando de oido
Shevek10 Diciembre 2010 - 6:04pm
Andy, estás tocando de oído.
La especificación AES SÍ está grabada en piedra, si no, no sería posible intercambiar archivos cifrados entre aplicaciones distintas. Todas tienen que saber a qué atenerse.
Que no, que no te enteras. Que no se trata de discutir la fortaleza de Rijndael añadiendo o quitando rondas, sino de si Wikileaks hizo bien o mal en cifrar el archivo con AES256, que tiene una especificación pública muy bien conocida que no se cambia a capricho; y si se cambia, deja de ser AES. Así de fácil.