Hoy os traigo algo que aunque hace tiempo que se produjo no había aparecido todavía por aquí. Es la respuesta de Rubén, de Automatic Human Behaviour la entrada Sólo con el ordenador no es suficiente que escribí hace un tiempo. He tomado prestado el título original de su post y el texto íntegro del mismo (él me dio permiso vía mail para hacerlo). La url del artículo en su blog es esta.
¿Podemos fiarnos de los textos escritos por matemáticos?
El artículo de hoy pretende ser una respuesta al texto, ¿Podemos fiarnos de los cálculos efectuados con ordenador? escrito por Óscar Ciaurri y Juán Luis Varona y publicado en La Gaceta de la Real Sociedad Matemática Española. Existe una versión en pdf y Diamond, de Gaussianos, publicó una versión resumida en su blog.
Mi hipótesis de partida es que este texto -si bien siempre es útil detectar fallos y errores comunes para que otros no los cometan- esta basado, parcialmente, en falacias con respecto al funcionamiento de los ordenadores y, lo que es peor, de las matemáticas que se emplean dentro de ellos.
Mi objetivo no es rebatir el texto original desde un blog, si no dar al lector las herramientas para comprobar por si mismo algunas de las falacias que he comentado y, de paso, hacer un poco de divulgación científica, que nunca viene mal.
Para empezar, vamos a presentar un modelo teórico que aproxima bastante bien las capacidades y, sobre todo, las limitaciones de cálculo de un ordenador. Es la conocida como, máquina de Turing.
Esta máquina no es mas que un robot que es capaz de procesar una cinta de datos codificados como unos y ceros. En cada instante, el robot puede leer o modificar el dato que tiene en el cabezal. La decisión se basa en un programa que, junto con los datos que lee, van cambiando el estado interno del robot.
De este modelo teórico, vemos dos cosas que se aplican a todos los ordenadores:
1) Los ordenadores solo son capaces de procesar números. Cualquier cosa que queramos que procesen, la tendremos que transformar a 1s y 0s. Un sonido lo tendremos que transformar en una secuencia de números. Una imagen también pasa a ser una secuencia de números. El texto también son números. Un ordenador no sabe leer, solo sabe contar. Todas estas conversiones se basan en convenios que habremos de decidir de antemano.
2) Los ordenadores -al menos los de un solo núcleo- procesan la información de manera secuencial. Esto tiene una implicación muy importante a la hora de determinar la complejidad de un problema. Por ejemplo, si el ordenador tiene que encontrar el camino óptimo entre una serie de rutas, tendrá que recorrerlas todas antes de estar totalmente seguro de que la que decida sera la óptima.
En determinadas situaciones, y partiendo ciertas intuiciones o información previa podemos obtener soluciones más eficientemente. También se puede buscar una solución que no sea la óptima, pero que en la práctica sea lo suficientemente buena. Sin embargo, en un caso general, no se pueden asumir dichas simplificaciones.
En el peor de los casos, podemos encontrarnos con problemas totalmente irresolubles, como el problema de parada, es decir, saber si un programa (con bucles, saltos e interrupciones) se va a parar o por el contrario, quedaría atrapado en un bucle que se ejecuta continuamente (lo que se llama un bucle infinito). La única forma de saberlo, es ejecutando el programa entero, con lo que si el programa tiene un bucle infinito, el programa quedara atrapado y nunca nos dará la solución.
3) También existe limitaciones a nivel práctico. El robot de Turing puede estar trabajando por tiempo indefinido hasta resolver casi cualquier problema (como hemos dicho cualquiera que tenga solución, lo que se llama un problema decible). Sin embargo, en la práctica, existen muchos otros problemas que no se pueden resolver por un ordenador normal, ya que son problemas intratables. La wikipedia pone el ejemplo de los problemas con complejidad exponencial:
Para ver por qué las soluciones de tiempo exponencial no son útiles en la práctica, se puede considerar un problema que requiera 2n operaciones para su resolución (n es el tamaño de la fuente de información). Para una fuente de información relativamente pequeña, n=100, y asumiendo que una computadora puede llevar a cabo 1010 (10 giga) operaciones por segundo, una solución llevaría cerca de 4*1012 años para completarse, mucho más tiempo que la actual edad del universo.
4) Otra limitación técnica viene del hecho de que la memoria (el tamaño de la cinta), no es infinita. De hecho, para almacenar cualquier posible número, necesitaríamos una cadena arbitrariamente larga de 1s y 0s. Eso no solo aumenta el coste de memoria, si no también el coste computacional de procesar un único número. De este modo, se suele limitar el tamaño de los números a 8, 16, 32 o 64 bits. Puede parecer que 64 bits dan mucho juego (son 264 números), y de hecho, lo dan, pero recordemos que los números naturales son infinitos números. Y tan lejos del infinito esta un googol como el 1. Pero es que además, como vimos en otros articulos, los números reales son un infinito de segundo orden, es decir, en el intervalo que hay entre cada uno de los infinitos números enteros, hay infinitos números reales, cada uno con potencialmente infinitos decimales. ¿No parecen demasiados para representarlos con 264 números? Pues se hace, pero con el consiguiente error asociado que hay que tener en cuenta.
En resumen, hay muchos problemas que para nosotros son triviales, pero que para un ordenador como los que utilizamos habitualmente, son imposibles ya que: requieren un tiempo de cálculo enorme, requiere una cantidad de recursos impracticable o simplemente, no existe ninguna forma de que el ordenador obtenga un resultado.
Para terminar con los preliminares, quisiera añadir un pequeño trasfondo de lo que es la Ingeniería de Software.
El software ha de pensarse que es como un producto más. Por ejemplo, podemos compararlo con un coche.
A principios del siglo XX, los vehículos a motor estaban todavía en fase de desarrollo. Los pocos vehículos que circulaban por las carreteras tenían continuos fallos y taras. Era raro poder circular más de 10 kilómetros sin que se gripase el motor, se fundiese alguna lampara o se pinchase una rueda. El mundo tampoco estaba preparado para ellos, y parte de los problemas provenían de carencia de pavimento en las carretas, falta de señalización, etc.
Sin embargo, a pesar de los avances que se han dado a lo largo del siglo XX (de todos es sabido que la industria de la automoción es una de las que más dinero mueve a nivel mundial), solo recientemente se han creado e implantado extensivos controles de calidad y diseños exhaustivos que otorgan una gran calidad al producto final y una garantía de seguridad.
Se tardó un siglo en desarrollar e implantar toda esa tecnología.
Por otro lado, a pesar de los avances que ha sufrido el campo de la automoción, no le pedimos a un coche que vuele, por mucho que lo utilicemos para viajar, y volar sea una forma eficaz de hacerlo. Incluso si alguien utiliza un motor de coche para volar, no es la mejor forma de hacerlo. Es una falacia razonar que si un elemento se utiliza para un fin, ha sido diseñado para ese propósito.
Por ejemplo, por mucho que utilicemos los ordenadores para cálculo simbólico, el modelo de ordenador de von Neumann, que aun hoy utilizamos, se diseñó para calculo numérico. Y punto. Cualquier algoritmo que resuelva problemas s
imbólicos será porque primero los convierte a problemas numéricos.
La Informática como ciencia y como tecnología, es mucho mas joven que la automoción. Sin embargo, ya se están empezando a implantar controles de calidad dignos de las grandes compañías de vehículos. Casi desde el principio de la programación, han existido los betatester (gente que se dedica a probar y sacar los fallos de un programa al final de su desarrollo), se han desarrollado técnicas de métodos formales y análisis de software para reducir al mínimo los errores.
Sin embargo, siempre aparecen errores. Al igual que en los vehículos siguen apareciendo fallos de diseño (como el famoso Mercedes que hace pocos años tuvo que ser retirado del mercado porque en caso de accidente, el motor se incrustaba en el habitáculo de pasajeros). Por desgracia, el software es algo que se maneja jerárquicamente. Aunque no nos demos cuenta, en todo momento estamos ejecutando varias piezas de software (programas de trabajo, sistemas operativos, drivers, controladores…) que a su vez están basados en otras piezas de software (compiladores, interpretes…). Simplemente con que falle solo uno de esos elementos, el sistema falla. Y lo más probable es que, a fecha de hoy, alguna de esas piezas de software estén todavía hechas con métodos antiguos de programación y sin los controles de calidad que hoy se utilizan. ¿Alguien se atrevería a conducir en una autopista donde, al fallar cualquiera de los vehículos que van en ella, automáticamente fallaran todos? ¡Estaríamos arreglando pinchazos cada 100 metros!
Pero en todo este panorama, los programadores tenemos una ventaja que la automoción no tendrá nunca, los demostradores de teoremas. Un demostrador de teoremas es un programa que nos garantiza, matemáticamente, que nuestro trozo de código hace exactamente lo que queremos que haga. Es decir, nos garantiza que matemáticamente es correcto, perfecto. Por desgracia, los demostradores de teoremas todavía se encuentra en fase de investigación y sus capacidades, a día de hoy, son muy limitadas. Realmente, la dificultad de un demostrador de teoremas, deriva de que es un cálculo simbólico, no numérico.
Ahora, vayamos por partes a resolver algunos de los puntos que comentan los autores. Como he dicho antes, no es mi idea rebatir el texto completo, así que me centrare en algunos de los puntos que se resumen en el blog de Gaussianos.
1) Cálculo de limites:
Los autores denuncian que una función cuyo limite en determinado punto varia si el limite se toma “por arriba” o “por abajo” no es resuelto como tal por Mathematica, ya que si le damos a calcular el limite, sin definir por donde se mira, nos devuelve el valor por arriba y no nos avisa de que esta indefinido.
Solo hace falta ir a la documentación de Mathematica y leer:
The value of Sign[x] at x=0 is 0. [..] Its limit, however, is 1. The limit is by default taken from above.
Es decir, Mathematica sí que nos avisa de que va a coger el límite “por arriba”. En muchos otros ejemplos del articulo, la crítica es la misma: el programa no nos informa de lo que hace. Eso es totalmente falso, porque como lo hemos visto, si que informa, aunque en la documentación. Lógicamente, un software de esa magnitud no puede estar informando de cada acción que haga. ¿Se imaginan los lectores un navegador de internet que cada vez que pulsara en un link le saliese un mensaje:
“Acaba de pulsar un link. Esto le enviara a otra pagina y dejará atras la página que esta leyendo. ¿Desea continuar?”
Acabaríamos todos de los nervios. Lo primero de todo, antes de usar un software, antes de usar cualquier herramienta, es leerse el manual. Eso lo sabe cualquier técnico y debería saberlo cualquier usuario de software. De hecho, existe un programa que se diseñó para intentar informar al usuario bastante a menudo, a sabiendas de que no se leería la documentación por su cuenta. El programa era el asistente de la ayuda de Microsoft Office, más conocido como Clippo. El odio que suscitó es tal, que existen hasta videojuegos cuyo único objetivo es aniquilar el personaje animado de la forma mas cruel posible.
2) Gráficos ficticios:
Decir que en este caso, gran parte del error que se comete no es de los autores originales, si no del resumen de Gaussianos.
En este caso, los autores protestan porque el programa no representa bien según que gráficas, haciendo clara referencia, aunque no explícita, al teorema de Niquist-Shanon.
Para empezar, decir que un ordenador, jamas podrá dibujar una gráfica continua, ya que por definición, tiene infinitos puntos. Y como hemos visto, para un ordenador, infinito es 264. Un ordenador siempre es discreto. De todos modos, aunque la pudiese representar, nunca la podría sacar por pantalla, ya que siempre tendríamos la limitación de los píxeles, o en último término, del ojo humano.
Pero aun así, en este caso, los autores originales claramente comentan que el software Mathematica puede resolver este problema hasta cierto punto. Por la descripción que hacen de la método que usa Mathematica, se están refiriendo al potente algoritmo de bootstrapping. Este algoritmo, aunque fundamentado en una solida base matemática, se puede explicar de manera bastante sencilla: En caso de que las muestras que estemos tomando no sean suficientemente representativas, podemos usar las que tenemos para obtener información sobre la función y así tomar más muestras en determinadas zonas “de manera inteligente”. De este modo se consigue mejorar la calidad del resultado con menos coste añadido.
Por desgracia, el algoritmo de bootstrapping es un algoritmo con coste exponencial. Es decir, cuando aumentamos el número de dimensiones, el coste aumenta enormemente hasta hacerlo intratable, como veíamos antes. Lógicamente, cuando un usuario le da al botón para dibujar una función, no quiere que pasen años o siglos antes de poder verla. Es por ello, que Mathematica ha limitado el uso del bootstrapping a gráficas de una sola dimensión, donde el tiempo de cálculo, entra dentro de lo razonable. Este nimio detalle es contemplado en el articulo original, pero en el resumen de Gaussianos, inexplicablemente, se perdió.
3) Simplificar
Este punto y otros por el estilo donde se habla del cálculo simbólico directamente no tienen sentido. Todos los razonamientos se basan en la premisa de: “Dado que esas operaciones son triviales para cualquiera, también lo deberían ser para la máquina.”
Bien, y yo me pregunto: ¿Por qué? Hemos visto que hay muchos problemas que son triviales para nosotros y no para un ordenador. Otros son triviales para el ordenador y tremendamente complejos para nosotros. Simplemente funcionamos distinto. De hecho, cuando se crearon originalmente, se crearon con la idea de complementarnos, luego se especializaron en lo que se nos da mal a los humanos. Lógico, ¿no creen?
Además,
los autores de Mathematica, dado que el calculo simbólico es muy costoso y ha de probar muchos caminos y opciones, han optado por dar una solución práctica. Han cogido las operaciones más rápidas y que aparecen más frecuentemente a la hora de simplificar y las han incluido en una función. Esta función tiene la ventaja de ser muy rápida, pero no te garantiza un resultado satisfactorio. Luego existe otra función que tiene una biblioteca de operaciones mucho más extensa y por lo tanto da mejores resultados, pero más lento.
Es como cuando nos vamos a comprar un libro, que primero leemos el resumen, y aunque no nos garantiza que el libro sea bueno o malo, si que en algunos casos nos puede servir de ayuda.
Esto no es una solución matemática, ni tiene ninguna base teórica. Simplemente se ha hecho así por comodidad del usuario. Prueba primero la rápida, y si no funciona, siempre podrás probar la lenta, pero si te funciona, eso que te has quitado de encima. Tiene sentido, ¿no?
Pero no sabemos como han escogido los programadores que operaciones poner en la rápida y cuales no. Y no existe ninguna justificación matemática. Hacer suposiciones con la premisa: “esta operación es muy sencilla, debería ser resuelto por la función resumida” simplemente no tiene ni pies ni cabeza.
4) Fallos de código:
Esta parte es la única que no esta basada en falacias. Es normal que haya fallos en un código, al igual que es normal que haya fallos en cualquier producto. No es deseable, pero somos humanos. Me parece una labor encomiable que se busquen esos errores y se hagan públicos a una comunidad que usa ese software masivamente. Incluso la idea de anunciar los fallos de versiones antiguas, ya que mucha gente no actualizara su software a menudo, al ser software de pago.
Desconozco si Mathematica ofrece actualizaciones gratuitas de las correcciones de software, aunque muchos de los programas comerciales sí lo hagan. Normalmente, aunque no nos demos cuenta, cuando se compra un software, muchas veces se compra también el soporte adicional.
Por otro lado, lo que veo un error es escribir el texto a modo de denuncia en vez de simplemente informativo. De hecho, muchos de esos fallos que se comentan se han corregido en las últimas versiones, lo cual es loable y no denunciable. Además en vez de denunciarlo en una revista española que no leerán los programadores, se puede contactar con ellos. Es muy probable que corrijan los fallos en la próxima versión e incluso nos regalen alguna suscripción gratuita por haberlos encontrado.
En este punto, es admirable la labor de las comunidades de software libre, donde puedes informar del error, que normalmente es subsanado a las pocas horas y, al día siguiente, puedes descargarte el nuevo código perfectamente arreglado.
Mi conclusión es que sí podemos fiarnos de los cálculos de un ordenador, pero no podemos fiarnos de los usos y decisiones que tomemos a posteriori.
Nota: Como punto final, me gustaría comentar que no tengo ninguna implicación con Mathematica ni con la compañía que lo ha desarrollado. Simplemente ha sido la herramienta en la que estaba basada el texto original. Personalmente, y dado que mis aplicaciones van más orientadas al cálculo numérico, prefiero Matlab. Como alternativa de software libre y gratuita, existe Octave, que si bien tiene alguna capacidad reducida, es un serio competidor. También existen lenguajes de programación orientados al cálculo científico con excelentes bibliotecas de apoyo, como por ejemplo R (para cálculo estadístico) y Python con SciPy (más general).
Como habéis visto Rubén me dio la réplica con este artículo y, aunque con muchísimo retraso, quería ponerla aquí. Espero vuestros comentarios sobre el asunto, pero, por favor, con la mayor educación posible tanto para hacia Rubén como hacia mí. Aviso ésto porque sé que estos temas a veces se salen de madre y pueden llegar a límites que no estoy dispuesto a aceptar. De todas formas estoy seguro de que todos sabremos mantener la compostura.
Autor: ^DiAmOnD^ | Publicado el 13 de October de 2008
Comments Off
Categorías: Informática, Matemáticas
Este artículo es una colaboración enviada por LordHASH
Algunos de los algoritmos de HASH más utilizados, que son sobre los que trabajaremos, son los siguientes:
- MD5 (Message-Digest Algorithm 5 o Algoritmo de Firma de Mensajes 5): Desarrollado por Ron Rivest, ha sido hasta los últimos años el algoritmo hash más usado. Procesa mensajes de una longitud arbitraria en bloques de 512 bits generando un compendio de 128 bits. Debido a la capacidad de procesamiento actual esos 128 bits son insuficientes, además de que una serie de ataques criptoanalíticos han puesto de manifiesto algunas vulnerabilidades del algoritmo. Puede ser útil para comprobar la integridad de un fichero tras una descarga, por ejemplo, pero ya no es aceptable desde el punto de vista del criptoanálisis.
- SHA-1 (Secure Hash Algorithm 1 o Algorimo de Hash Seguro 1): El SHA-1 toma como entrada un mensaje de longitud máxima 264 bits (más de dos mil millones de Gigabytes) y produce como salida un resumen de 160 bits. Este número es mayor que el que se utilizaba en el algoritmo SHA original, 128 bits. Ya existen nuevas versiones de SHA que trabajan con resúmenes de 224,256,384 e incluso 512 bits.
En realidad, lo seguros o inseguros que estos algoritmos sean no depende de los conocimientos informáticos o telemáticos que uno tenga, sino de sus conocimientos matemáticos. Nuestra intención es demostrar por dónde cojean los algoritmos de HASH, la dificultad computacional que presentan, y qué soluciones se dan a los posibles ataques que puedan sufrir por parte de individuos malintencionados.
Desde el año 2004 aproximadamente, cuando saltaron las primeras noticias escandalosas sobre la ruptura de MD5, la seguridad que ofrecen los algoritmos de HASH a nuestros esquemas de cifrado ha sido una cuestión que se ha puesto en entredicho. ¿Qué seguridad ofrecen estos algoritmos? ¿Resulta computacionalmente complejo romper uno de estos algoritmos? ¿Qué solución se debe adoptar? Intentaremos resolver estas cuestiones.
Intentemos dar una descripción algo más matemática de lo que es una función HASH. Supongamos que tenemos un mensaje a, al que aplicamos una función resumen a la que llamaremos h. Decimos entonces que el resultado de esta operación, al que llamaremos b es el HASH de a. Es decir:
h(a)=b
Esta función debe ser sencilla de realizar para un computador, pero debe ser computacionalmente imposible realizar la operación inversa, al menos para usuarios normales.
Además, esta función tiene otra característica: el tamaño de la entrada no es de longitud fija, puede ser de longitud variable. Esto tiene la siguiente consecuencia, que no demostraremos matemáticamente, pero que asumiremos por estar razonado en otros artículos publicados en Internet (al final se indican): es posible que dos mensajes de entrada a produzcan el mismo mensaje de salida b. Es decir, es posible encontrar un mensaje c, tal que:
h(c)=b
Sin embargo, encontrar ese mensaje debe ser, al igual que la particularidad antes mencionada, muy complejo desde el punto de vista computacional. Para los algoritmos de HASH esto es lo que se conoce como colisión: que dos mensajes de entrada produzcan el mismo mensaje de salida.
Así, a priori, podemos establecer dos posibles vulnerabilidades de las funciones HASH:
- Que sea posible realizar la operación:
h-1(b)=a
Habitualmente, a la operación de invertir la función HASH comprobando todas las posibilidades para los bits de salida se le llama ataque de fuerza bruta. Esto es lo que debe ser computacionalmente impracticable. Supondría aplicar la función HASH 2n veces hasta encontrar la coincidencia (n es el número de bits de salida de la función).
- Que se hallen colisiones:
h(a)=b y h(c)=b, a distinto de c
Lo que antes hemos denominado colisión.
Estas dos posibles debilidades dan lugar a cuatro tipos de ataques:
- Ataque Tipo 1: El atacante es capaz de encontrar dos mensajes al azar que colisionan pero es incapaz de hacerlo de forma sistemática. Si es capaz de dar sólo con dos mensajes que provocan colisión, esta no es razón suficiente para tildar el algoritmo de ineficiente. Índice de peligrosidad: *
- Ataque Tipo 2: El atacante es capaz de generar dos mensajes distintos de forma que sus HASH colisionen, pero sin saber a priori qué hash resultará. Es decir, el atacante no podría generar “queriendo” el HASH que necesite para fines maliciosos. Índice de peligrosidad: **
- Ataque Tipo 3: El atacante es capaz de construir un mensaje sin sentido de forma que su HASH colisione con el de un mensaje con sentido. Si éste es el caso, el agente malicioso puede atacar algoritmos de encriptación asimétricos con firma digital, haciendo que se firmen mensajes sin sentido, y que el destinatario los acepte como fidedignos. Índice de peligrosidad: ***
- Ataque Tipo 4: El atacante es capaz de crear un segundo mensaje falso que tiene sentido y cuyo hash colisiona con el del mensaje verdadero. En este caso, el atacante puede actuar con total impunidad, puede falsificar certificados, firmar mensajes…El resultado sería desastroso. Índice de peligrosidad: ****.
El problema entonces es el siguiente: ¿cómo de difícil es encontrar una solución? ¿Qué ataques reales son practicables? ¿Qué se gana incrementando el número de bits de salida del algoritmo?
En primer lugar, responderemos a la última pregunta. Si aumentamos el número de bits de salida del algoritmo, el ataque de fuerza bruta será más impracticable y también lo será encontrar los mensajes que colisionen, pues teóricamente se cumple que para confiar en que podemos encontrar dos mensajes que colisionen no hay que realizar 2n operaciones, si no sólo 2n/2.
Realicemos algunos cálculos para realizar ataques de fuerza bruta:
Trabajemos ahora con los ataques basados en búsqueda de colisiones:
- Para MD5, la salida es de 128 bits, luego hay que operar sobre la mitad de bits, y sería necesario realizar:
264=18.446.744.073.709.551.616 operaciones.
- Para el algoritmo SHA 1, cuya salida es de 160 bits:
280=1.208.925.819.614.629.174.706.176 operaciones.
Curiosidad: 1.000.000 de ordenadores capaces de procesar en 1 µs cada operación tardarían más de 38.000 años en las 280 operaciones.
Y para los más desconfiados e incluso paranoicos: ¿qué hay de las supercomputadoras y de la gente que sí dispone de los medios necesarios? Cuando saltaron las primeras alarmas sobre estos algoritmos, hace unos dos años, las cifras eran las siguientes:
- Para romper el SHA-0 completo se ha requerido un supercomputador de BULL de 256 procesadores durante unos 9 años de proceso, pero al supercomputador que está instalando IBM en la UPC (Barcelona) sólo le costaría del orden de 1 año.
- Otro grupo de investigadores, Wang, Feng, Lai, y Yu han reportado haberlo conseguido con una complejidad aproximadamente 2000 veces menor (240 en vez de 251). Esta reducción equivaldría a una necesidad de cálculo de algo menos de 1 día, si la relación fuese lineal, pero los mismos investigadores han reportado necesitar sólo 1 día con un IBM P690 en cluster, para romper el MD5, que tiene una complejidad equivalente.
Por tanto, lo habitual no es que nos ataque desde uno de estos grandes usuarios (tienen cosas más interesantes que hacer, diría yo…) si no que nos ataque un cracker o similares (ACLARACIÓN: No incluyamos a los señores programadores en esto, los hackers. Gracias a Richard Stallman).
Lo habitual es que este tipo de usuarios realicen ataques basados en diccionarios, como la aplicación para Ñu/Linux John the Ripper. Este tipo de aplicaciones tiene una base de datos con claves comunes, que prueban sobre los sistemas a los que queremos acceder (por ejemplo Sistemas basados en UNIX donde se almacenan los resúmenes HASH de el nombre de usuario y su clave para autenticar). Ante esto sólo hay una solución: EVITAR LAS PASSWORDS ABSURDAS. No sirve (marta -tkm ni maria-secreto) ok??
Concluyendo, dependiendo de su nivel de paranoia críptica y de la aplicación que estén utilizando…escojan su algoritmo de HASH, pero no acepten menos de SHA-1. Cuando un algoritmo empieza a presentar vulnerabilidades no tarda mucho en ser aniquilado, así que a algunos de estos les queda poco tiempo de vida.
Fuentes:
Ir a Algoritmos HASH (I): Introducción
Autor: ^DiAmOnD^ | Publicado el 18 de April de 2007
Comments Off
Categorías: Colaboraciones, Criptografía, Informática
