EDICIóN GENERAL
334 meneos
5631 clics
Google anuncia la primera colisión de SHA1 [ENG]

Google anuncia la primera colisión de SHA1 [ENG]

Funciones criptografícas como SHA-1 son la navaja suiza de un criptógrafo. Las funciones hash se usan en la seguridad del navegador, manejando repositorios de código, o incluso detectando archivos duplicados. Estas funciones comprimen grandes cantidades de información en pequeños mensajes (hash). Como requisito criptográfico para su uso extendido, encontrar dos mensajes que lleven al mismo hash debería ser computacionalmente inviable.[...]10 años desde que SHA1 fue introducido, anunciamos la primera técnica para generar una colisión.

| etiquetas: sha1 , criptografía , seguridad
Comentarios destacados:                                  
#2 Ese titular ...

No se trata de "la primera colisión", sino de la primera técnica factible para generar colisiones.
Putos coches autónomos.
#1 Los autónomos de este país estamos muy jodidos
#9 ¿Y lo poco que os quejáis?
#89 Demasiado poco para lo que nos joden
Ese titular ...

No se trata de "la primera colisión", sino de la primera técnica factible para generar colisiones.
#2 Primera colisión (que se sepa) y primera técnica para lograrla... el título está bien.
#6 No, el título no es correcto.
Es la primera colisión práctica. Se sabía ya (y se ha demostrado) que las colisiones eran posibles y factibles, y obviamente faltaba hacerlo de forma práctica, y cuando se lograse (ahora) se podría demostrar empíricamente, pero teóricamente ya se ha demsotrado que la colisión era una realidad.
#2 #6 #12 Si no ha habido colisiones hasta ahora, aunque se supiera teóricamente, y ahora hubo la primera colisión práctica... pues hubo la primera colisión y el titular es correcto.
#25 La cuestión es que el titular no es informativo ni ayuda a que personas con menos conocimientos criptográficos sean conscientes de la gravedad del asunto.

No es lo mismo que se haya encontrado UNA colisión (i.e. "Hola Mundo" y "j983rO#@jro23" tienen el mismo hash) , que que se haya descubierto un método para generar documentos arbitrarios con un hash concreto, cosa que tiene muchas implicaciones de seguridad.
#33 De acuerdo que puede ser más o menos informativo, pero incorrecto no :-) Y sinceramente, a las personas con menos conocimientos criptográficos seguramente les dé igual esta noticia.
#33 Efectivamente, no es lo mismo, pero en este caso se dan ambas opciones.

#2 #12 Se sabía que era inseguro, y de hecho en el artículo mencionan que Google lleva años pidiendo dejar de usarlo. Pero no entiendo qué problema tenéis con que hayan encontrado la primera colisión. Lo mismo podríais dirigir vuestras preocupaciones a los de Google, y lo mismo ellos os pueden resolver las dudas :-P El titular no me lo he inventado yo (por si alguien no se había fijado).

#25 Gracias por intentar ayudarme :-)
#46 Dirijo mis preocupaciones a quién ha escrito éste titular, sea copia y pega o no. La propia página a la que refiere Google lo dice en su segunda línea: "We have broken SHA-1 in practice".
Es obvio que la noticia del blog de Google está orientada al marketing y probablemente los periodistas de medio mundo tomarán el asunto de que SHA-1 no es seguro como algo que es nuevo y de autoría de Google... pero no es así.
#68 Es que yo no he "escrito este titular". Pero vamos, que sólo lo mencionaba por si alguien se había pensado que yo había cambiado el titular por algún motivo.

Sigo sin entender el problema. Lo han logrado romper en la práctica. Han encontrado una colisión. Ese es el titular. But wait, there's more! Entonces sigues leyendo el artículo para terminar el "holy shit" que empezó con la noticia de que encontraron la colisión. No veo cómo las dos cosas son incompatibles. Nadie antes había encontrado una colisión (que se sepa!), por lo tanto esta es la primera.
#46 No hay problema :-)
#33 Me has hecho comprobarlo jodío. Te has inventado la colisión:
[xxxx@xxxx-cave ~]$ echo "Hola Mundo" | sha1sum
38beb661c63932eef289638a2443a7fdb8b7ad2d -
[xxxx@xxxx-cave ~]$ echo "j983rO#@jro23" | sha1sum
e1080bb46aa464b3b08d99e4b476e4d8f653afdd -
[xxxx@xxxx-cave ~]$ echo "j983rO#@jro23" | md5sum
7b52a0a5e6640af4cabef151ff19f99a -
[xxxx@xxxx-cave ~]$ echo "Hola Mundo" | md5sum
b4b9e397fb7e08bfeaa54090d2989e53 -


¿O es que era un ejemplo no md5 ni sha1?
#91 era un ejemplo inventado
#25 La primera colisión ya existía de forma teórica. La matemática demostró hace años que la colisión, primera, segunda o la que te pete, es posible y por tanto existe. Ahora te acaban de demostrar empíricamente que hay una, y la matemática sigue siendo igual de válida porque sigue afirmando que hay una, dos o más bien... que es posible encontrar una colisión de una forma más o menos 'fácil'.
#12 #25 a ver, solo de manera aclaratoria. Todas las funciones hash tienen infinitas colisiones de manera matematica dado que la longitud del hash (la salida) es finita (aunque pueda ser inmensamente grande) y se puede aplicar sobre entradas mas grandes que la longitud de salida. En cristiano, si tuviera una funcion hash de longitud dos, el tercer valor que meta va a colisionar con uno de los dos anteriores. Se considera que el sistema no es seguro cuando se pueden generar a voluntad dichas…   » ver todo el comentario
#12 Lo dices como si la demostración teórica fuera necesaria:
- Sea una función que mapea 'muchos bits' a 'pocos bits'.
- Con 'pocos bits' no se puede describir el mismo espacio que con 'muchos bits'.
- Por tanto, al menos hay dos secuencias de 'muchos bits' que generan la misma secuencia de 'pocos bits'.
Queda demostrado.
#39 Ante tu demostración poco puedo decir más que acudas a clases de álgebra... luego si eso...quizás puedas empezar a intentar a entender de qué la criptografía. La misma que te protege al usar éste sitio web o tu banco.
#69 No, lo que él ha dicho es correcto, y se llama el principio del palomar o principio del agujero de pichón: es.wikipedia.org/wiki/Principio_del_palomar

En álgebra no, a mí me lo enseñaron en la asignatura de cálculo :-D
#69 Yo lo que he demostrado es que existen colisiones en cualquier algoritmo de hashing cuya salida sea de longitud menor que la entrada (por el principio del palomar, gracias #118).

¿Quizás tú querías una demostración de cómo generar una de esas colisiones? No es lo que pones en #12.
#140 Dos ejemplos: El 'principio del palomar' me habría ahorrado 3 líneas en #39. Y una de las aplicaciones más curiosas del 'teorema de Bolzano' que he visto es el enunciado:

"Sobre la superficie de la Tierra, en cualquier momento, hay dos puntos diametralmente opuestos que tienen exactamente la misma temperatura."
culturacientifica.com/2013/09/06/el-poder-de-una-idea-sencilla/
#12 pero esta es la primera colisión de SHA1, verdad? y el título es "google anuncia la primera colisión de SHA1", verdad? entonces, qué está mal en el título?
#43 Falta la palabra 'práctica': ...colisión práctica de..."
#64 no lo entiendo muy bien, ha habido alguna otra colisión antes?
#70 Sí, había posibilidad de colisiones desde que se demostró en 2005: www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
La cuestión está en si necesitas ver un caso práctico (ésta noticia) o la demostración matemática que prueba que hay casos (uno o más...)
#77 Lo siento por contestarte otra vez, no es nada personal, pero es que no lo entiendo. Ya nos ha quedado claro que sabías del tema y tal, y que ya sabías que era inseguro. Pero es que tú mismo te estás contradiciendo.

#70 "ha habido alguna otra colisión antes?"
#77 "Sí, había posibilidad de colisiones" -> o sea, no.

Que era posible? sí
Que había ocurrido? no (que se sepa!)

Por qué es tan difícil de admitir... todo por un titular. Que en la misma entradilla dice que se ha encontrado una técnica.
#86 No tengo que admitir nada porque no me contradigo de nada (Y si citas... hazlo en contexto, no extraigas las partes de la cita que te interesa). Desde 2005 se sabe que dicho algoritmo es inseguro. Se ha demostrado matemáticamente que no lo es, es decir, dicha demostración era necesaria y suficiente para poder afirmar que no es seguro y que hay colisiones en tiempos inferiores a lo que se podría obtener por fuerza bruta.
La demostración práctica de la inseguridad de SHA-1 que se nos…   » ver todo el comentario
#97 Tú me estás hablando de otra cosa y la mezclas con que el titular es erróneo. Si te vas a poner tiquismiquis entonces también decir que en 2005 no se demostró que haya colisiones, porque colisiones por haberlas hailas, lo que pasa es que no se pueden computar. Nos estás hablando con un tono como si fuéramos tontos, pero es que simplemente no nos estás entendiendo, y tú tampoco eres el más riguroso al expresar tus ideas (totalmente comprensible en un foro distendido y no técnico).

En 2005…   » ver todo el comentario
#97 Te has hecho la picha un lío.

Teóricamente todos los algoritmos de hash tienen colisión, por pura lógica, no hay que ser un genio para saberlo.

Encontrar "en la práctica" la primera colisión es igual a encontrar la primera colisión, así, a secas. Esta es la primera colisión encontrada, punto y pelota, el titular es correcto, Google anuncia la primera colisión.

Después la teoría dice que SHA1 tiene colisiones (anda, como todos, vaya obviedad) y que además en SHA1 se demostró que se pueden hacer en menor coste que fuerza bruta, muy bien, pero la teoría no encontró ninguna colisión, tan solo te dijo que se puede hacer.
#77 habia posibilidades de colision, pero que se sepa no ha habido ninguna, no?
#12 Entonces cuando se demostró en la practica que existe el bosón de Higgs, no fue la primera vez ya que Higgs ya había teorizado que tenía que existir?
#56 No puedo hablar de cómo se puede demostrar la existencia del bosón de Higgs porque desconozco el área, pero sí sé que para ésta función, la demostración teórica era no sólo necesaria si no también suficiente, sin embargo, la demostración práctica (la de la noticia) no es suficiente por ejemplo para afirmar que dicha función no es segura ;)
#65 Hombre, una colisión generada intencionalmente en un tiempo razonable sí que es suficiente para afirmar que SHA1 no es seguro.
#6 #0 Nop, no es la primera pero no sé si considerar la noticia errónea

it.slashdot.org/story/15/10/09/1425207/first-successful-collision-atta
#100 Gracias por el link, la verdad es que sabía que era inseguro pero que no habían encontrado una colisión todavía.
Yo no votaría la noticia errónea porque la colisión que encontraron fue una "freestart collision" y no una colisión de la función hash. O sea, que el título en mi opinión sigue siendo correcto.

Los que publicaron esa primera freestart collision son los que han publicado, junto con google, la nueva colisión (Marc Stevens y Pierre Karpman). En el abstract del report que enviaron se puede leer:
"Freestart collisions do not directly imply a collision for the full hash function." eprint.iacr.org/2015/967

A ver si esto aclara más las cosas :-)
#2 no me gusta los que van de listillos, negativo.
Y con SHA256 pasará lo mismo. Cuando la gente dice "para romper X cifrado, se necesitan más años que la edad del universo". Bien, pon sistemas en paralelo con CUDA, veamos cuánto tarda de verdad. Y con la tecnología cuántica, ya olvídate.
#3 Respecto a la tecnología cuántica, ya se estan estudiando algoritmos para ese futuro. No creas que has sido el primero que ha llegado a la conclusión que con los ordenadores cuánticos los cifrados actuales son una risa.

en.wikipedia.org/wiki/Quantum_cryptography
#3 #7 Bueno, con ordenadores cuánticos podrá crearse cifrados cuánticos también :-D
#7 Calla, deja que el genio siga ilustrándonos. :troll:
#3 Desde la ignorancia. ¿SHA256 es lo mismo que AES-256?
#8 No. SHA es para sacar un hash ("firma digital", si quieres) de un chorro de datos que le pases, AES en cambio es un sistema para cifrar dichos datos.
#11, #8
Hash > resumen o huella digital.
Firma > Hash de lo que se quiere firmar que después se cifra con la clave privada de un par de claves ( clave pública + clave privada, de algoritmo asimétrico ).

Ese hash cifrado se pone a disposición del destinatario de el documento/loquesea junto al mismo documento/loquesea.
Para comprobar la validez del documento/loquesea, el destinatario descifra el hash cifrado usando la clave publica del firmante o emisor del documento/loquesea ( que se…   » ver todo el comentario
#51 Si yo te leo la Enciclopedia Británica entera por teléfono, puedo estar tres años leyéndotela. Pero si simplemente te digo por teléfono: "la información que quiero darte a través de esta llamada telefónica es la que conduce al código hash F7GM44Z a través del algoritmo ALG-H", cosa que solo me lleva tres o cuatro de segundos, entonces también te estoy leyendo la Enciclopedia Británica entera, aunque la llamada solo haya durado tres o cuatro segundos, porque tenemos la seguridad de que el único documento digital que a través del algoritmo ALG-H podría conducir al código hash F7GM44Z es la Enciclopedia Británica.

Eso redactado tal que así es un algoritmo de compresión, no un algoritmo de hash.
#3 ¿Quieres probarlo de verdad? Empieza con esto: hashcat.net/hashcat/

O por ejemplo, para romper contraseñas del RAR prueba con esto: www.crark.net

Yo hice la prueba, y mi ordenador daba 12000 contraseñas por segundo, tardó casi 20 minutos en reventar una contraseña de 4 caracteres. ¿Cuánto tardaría en reventar una contraseña de 10 caracteres? 2 millones de años. ¿Una de 16 caracteres? Casi un trillón de años. Aunque pusieras mil millones de máquinas en paralelo, no podrías hacerlo por fuerza bruta.

Y la computación cuántica aplicada a la criptografía simétrica lo más que hace es reducir la longitud de la clave a la mitad, así que con duplicarla volveríamos a estar como antes.
#29 mmm No entiendo del todo lo de reducir la clave a la mitad. Si añadieramos un solo digito no multiplicariamos por 256 la dificultad?
#35 En primer lugar, en criptografía una contraseña y una clave no son exactamente lo mismo. La contraseña (password) es lo que tú escribes, que puede ser más o menos larga y utilizar un conjunto más o menos amplio de caracteres. En cambio una clave (key) es un valor binario de una longitud fija dada por el algoritmo a usar. Por ejemplo, DES utilizaba claves de 56 bits, y AES puede usar claves de 128 ó de 256 bits. El primer paso por tanto es generar una clave a partir de la…   » ver todo el comentario
#44 Gracias por la explicación. Todo un mundo esto de la criptografía.
#48 De nada. Es que ahora me dedico a la enseñanza... y justo acabamos de terminar ese tema :-D
#29 Tampoco puedes hacerlo por fuerza bruta con SHA-1. Aquí lo importante es que han descubierto un método para hacerlo más rápido.
#29 Por lo poco que yo sé, la computación cuántica no reduciría la dificutad de la clave a la mitad sino que el aumento de longitud de clave sómo implicaría un aumento lineal en el tiempo de descrifrarla al contrario que ahora que es exponencial.
Es decir y para entendernos (totalmente inventado):
Ordenador convencional:
Clave con 1 caracter: 6s
2 caracteres: 6^2=36s
4 caracteres: 6^4=1200s
8 caracteres: 6^8=466 horas
10 caracteres=2 años.
Ordenador cuántico:
1 caracter: 6s.
10 caracteres: 60s
#90 Eso es para la criptografía asimétrica usando el algoritmo de Shor (es.wikipedia.org/wiki/Algoritmo_de_Shor), ahí si que tendríamos problemas serios ya que reventaría totalmente algoritmos como RSA o ECC.
#3 No tienes ni idea de criptografía, ¿verdad? Si tuvieses la mínima idea del número de operaciones que hacen falta para "romper" matemáticamente un cifrado AES-256 no afirmarías que si CUDA o si la tecnología cuántica.

Edito para añadir este ilustrador extracto del libro de Schneier Applied Cryptography:

One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing

…   » ver todo el comentario
Miedito los dos pdf con diferente contenido pero el mismo hash. Los he bajado y sí sí, no hay trampa ni cartón.
#4 Estamos hablando de SHA-1 (160 bits), que está marcado como potencialmente inseguro desde hace algún tiempo. En cuanto aumentas el número de bits (SHA3-224, SHA3-256,…), además de mejorar los algoritmos, la cosa cambia. Que sí, que puede que eventualmente se rompa tambien, con tiempo y potencia de proceso, pero para entonces ya se habrán desarrollado sistemas criptográficos más avanzados y acordes con la potencia de proceso disponible.
Todo el tema del no repudio en entredicho. Esto podría tener consecuencias incluso legales en algunos casos.
#5 Tendrá consecuencias desde ahora si alguien usa SHA-1 para demostrar la validez de algún documento/fichero, aunque en principio eso debería ser desde 2011, momento en el que se dejo de recomendar usar SHA-1...
Usarlo desde esa fecha es un tanto masoca por querer meterse en terrenos pantanosos, no por el hecho de la noticia... era algo en lo que había mucha gente trabajando, simplemente éste grupo lo ha logrado antes que el resto, pero ya se sabía que era posible con una certeza del 100%.
#27 Pues gran cagada por parte de quien especificase el DNIe 3.0... porque si era algo que ya no se recomendaba desde 2011 y veo ahora que el DNIe 3.0 es de 2016... parece que o van con retraso o tenían esperanzas de que la realidad no fuese tal.
En cualquier caso, tampoco es tan traumático porque es cuestión de invalidar como dices el uso de SHA-1 y en los nuevos certificados que usen obviamente... ni mirarlo.
#79 #71 #27 #16 ¿Habéis leído la cantidad de esfuerzo necesario para crackear un PDF? ¿Habéis visto que no es aplicable a cualquier archivo? ¿Sabéis que el DNIe 3.0 utiliza AMBOS métodos de hashing precisamente porque SHA-1 fue marcado como inseguro en 2011?
Que atrevida es la ignorancia...
#27 Ya, bueno… No se puede decir que el Estado español vaya a la cabeza de la tecnología… :-P
#16 Probar ante un juez que determinado documento, o disco duro, o firma electrónica no ha sido manipulado y es admisible como prueba, si se ha trabajado con SHA1... ¬¬
Pero en teoría esto es esperable no? cualquier hash o resumen es, al final eso, un string con menos longitud que el original y obviamente hay más combinaciones posibles en un documento más grande que en el resumen generado por lo tanto al final debería haber una colisión no? o hay algo que yo no entiendo?
#10 Lo que dices es básicamente así y los sistemas antiguos de hash han ido cayendo poco a poco con el paso del tiempo. Pero SHA1 ha sido muy, muy duro de pelar. 160 bits se han quedado cortos al final, al mismo tiempo que, supongo, habrán encontrado debilidades en el propio algoritmo.
#13 estaba leyendo un poco ahora mismo sobre las colisiones con md5 que era el que se usaba cuando yo estudiaba básicamente y ya veo. Lo que puedo imaginarme es que ya existiesen colisiones pero que no se conociesen, yo que sé, un password de un foro chino y un hash de un driver de linux por decir algo. A la larga tendría que pasar, lo que pasa es que ha debido de pasar y nadie miró y esto que han descubierto ahora es la forma de forzarlo por lo que veo.

Claro que si obtienes el hash de un…   » ver todo el comentario
#15 Por casualidad no creo que haya ocurrido nunca porque las probabilidades son realmente ridículas. Pero desde que demostraron que los ataques eran 100% viables que el SHA1 se ha dejado de recomendar por activa y por pasiva. Los navegadores no aceptan los certificados firmados con SHA1 o al menos empiezan a quejarse, etc.

Y sí, las personas de bien usan algún tipo de "sal" para hashear las contraseñas.
#22 #15 #13 #10 Que pueda pasar en teoría y que pase en la realidad son dos cosas diferentes. Al igual que hay un número finito de resultados de SHA-1 (2^160...una auténtica barbaridad) también hay un número finito de archivos en internet.

La noticia no es que haya pasado por casualidad, es que se ha encontrado un método "fácil" de engañar al hashing y generar la misma huella dactilar para dos archivos.
SHA-1 se considera "hackeado" desde hoy, pero no significa que…   » ver todo el comentario
#10 Era esperable si, no inviable como dice la entradilla, lo que era bastante improbable que se diera el caso, pero tarde o temprano se iba a dar.

Más todavía improbable que se detectase, alguna vez posiblemente se dio pero paso despercibida.

La importancia de esta noticia no es lo que indica el titulo de que han detectado una colisión, si no que han descubierto una tecnica para generar las colisiones. O eso parece no me la lei por que no tengo tiempo ahora pero de un vistazo es lo que dice.
#19 Lo que dice la entradilla es que para que un hash sea un buen cifrado, la colisión debería ser computacionalmente inviable (no que no se pudiera dar con recursos infinitos). Que es exactamente lo que prueban en este artículo que SHA1 no es (y que sí que se veía venir).

Y sí, lo que dicen en este artículo es que han encontrado una técnica para generarlas, pero si simplemente hubiesen encontrado una única colisión, también sería una noticia importante.

Sólo matizo tu comentario :-)
#10 Dada la computación cuántica... sí es algo que ocurrirá con gran parte de los métodos criptográficos actuales.
Las funciones hash se diseñan de modo que sean seguras, básicamente que no puedas obtener el fichero original a partir del hash del mismo y sobre todo... que no puedas encontrar dos ficheros con el mismo hash con facilidad (colisión). No es imposible encontrar una colisión pero debe ser prácticamente imposible. El cómo se logra esto... es lo que requiere años de trabajo por parte de la gente que propone nuevas funciones hash y la evaluación de las mismas.
Entre otras cosas, afecta a git de forma severa...
#14 Por lo que se dice se comenta (dicho por el propio Linus) en caso de colisión, git se queda con tu commit local e ignora el que te pudiese venir por un repo remoto. Supongo que si ven que la cosa se pone seria se pasarán a SHA256 y arreando.
#17 How is GIT affected?

GIT strongly relies on SHA-1 for the identification and integrity checking of all file objects and commits. It is essentially possible to create two GIT repositories with the same head commit hash and different contents, say a benign source code and a backdoored one. An attacker could potentially selectively serve either repository to targeted users. This will require attackers to compute their own collision.
#36 Me baso en lo que su día comentó Linus, no sé si aún estará en vigor o qué. Dijo el pollo:


> if you already have a file A in git with hash X is there any condition where a
> remote file with hash X (but different contents) would overwrite the local
> version?

Nope. If it has the same SHA1, it means that when we receive the object
from the other end, we will not overwrite the object we already have.


marc.info/?l=git&m=115678778717621&w=2…   » ver todo el comentario
#38 Se me ocurre un ataque en 2 pasos.
En la primera sincronización cambias el fichero por otro cualquiera. En la segunda lo cambias por el que tiene el troyano que tiene el mismo sha1 que el original.

Tu tendrás a partir de entonces un fichero troyano pero aunque te sincronices con otra gente, como el sha1 coincide, ni lo transmites ni te lo sobreescribes. Hasta que se cambie el fichero.

Si a mi se me ocurren formas de explotarlo, no te digo lo que se le ocurrirá a los expertos...
#60 creo que necesitaría yo para entenderlo una pizarra con líneas y flechas
#60 bueno pues se guardan los hash anteriores y si en un nuevo conmigo coincide con un hash anterior, pues se coge el archivo original.
Según la wiki ya se había encontrado una vulnerabilidad en 2004, aunque la consideraban "computacionalmente inviable":

es.wikipedia.org/wiki/Secure_Hash_Algorithm

"En 2004 se encontró una debilidad matemática en SHA-1, que permitiría encontrar colisiones de hash más rápido. Sin embargo, este hallazgo resulta poco relevante, pues la complejidad de búsqueda de colisiones pasaría de 280 a 269, algo que aún es computacionalmente inviable,

…   » ver todo el comentario
#18 La noticia dice que sigue siendo inviable en la práctica, pero que ahora es 100,000 mas sencillo que en el articulo que comentas.
:wall: Anda que está informado el tio:

"Estas funciones comprimen grandes cantidades de información en pequeños mensajes (hash)."

El hash NO son los datos comprimidos. El hash es una casena de texto creada a partir de una fórmula que se aplica sobre los datos, que en teoría es bastante improbable que colisione con otra cadena aplicando la misma formula a datos diferentes.
#21 En la literatura técnica a los hashes también se les llama funciones de compresión: en.wikipedia.org/wiki/One-way_compression_function
#30 Si, pero siempre he pensado que es erróneo. Porque es cierto que si usas un hash puedes desestimar el origen, únicamente si NUNCA necesitas recuperarlo (es decir, descomprimir).
Un ejemplo claro son los passwords, se guarda el hash y nunca se recupera el original, sólo se compara el que escribe el usuario, pasado por la función hash, comprobando si da lo mismo.
Pero yo a eso no lo llamaría compresión, mas bien "transformación". Aunque bueno, creo que tengo el resto del mundo en contra, sigo pensado lo mismo.
#31 Por eso se le llama compresión unidireccional, luego no se pueden descomprimir :-D
#34 Como cuando comprimen un coche en el desguace
#34 Pero es que la salida no tiene por qué ser menor que la entrada. Yo uso SHA512 para las contraseñas, y tú puedes poner una contraseña de 8 caracteres (8 bytes), por ejemplo, y el sha512 tiene 64 bytes. No has comprimido nada. Al contrario.
#93 Ya bueno, pero es que si consideras todo el conjunto de mensajes posibles, la probabilidad de que el mensaje original sea más largo que el hash es de 1.

Por cierto, espero que no utilices sólamente SHA-512, sino una función más robusta como PBKDF2, bcrypt, scrypt, o Argon2 :-P
#72 #34 #61 La informàtica ha violado violentamente el diccionario de la Real academia xD
#21 Espero que no lo digas por mi, que me he dedicado a traducir el artículo en la entradilla (aunque he tenido que reducir algunas cosas). Pero el caso es que en este caso compresión se refiere a reducción de datos y no significa que esos datos sean recuperables. La compresión a la que te refieres tú es un caso particular, pero no significa que sea el único uso de la palabra.
#21 Creo que entiendo a lo que te refieres... pero en todo caso debería ser al revés :-D

Una función que convierte m posibles elementos en otros n posibles elementos, siendo m>n, sería una verdadera "función de compresión", al reducir el número de posibles elementos. O sea, un hash.

En cambio, lo que hacen los "compresores de datos" es convertir m posibles elementos en otros n posibles elementos, siendo m=n, con la única…   » ver todo el comentario
En el enlace a shattered.it aparece un pantallazo y usan powerlevel9K. Meneo por ello
Aún con todo, parece un ataque dificil de aplicar en la práctica. Pongamos que despues de 1 año corriendo 110 gpus, logras una colisión y obtienes un duplicado de la clave segura de alguien. Ahora tienes que ponerte a averiguar a quien pertenece la clave que has conseguido. Y alomejor su información ni te sirve de nada siquiera.

Sigue siendo un ataque a ciegas y extremadamente lento.
#24 Ahora pongamos que después de 1 año / 100 (unos 4 días) corriendo 110*100 GPUs (lo puedes hacer con los servicios cloud), logras una colisión y obtienes dos solicitudes de firma de certificado SSL, una para "midominiosinsentido.com" y otra para "google.com". Ahora le envías la de "midominiosinsentido.com" a Symantec para que te la firme, pagas los $1000 que cuesta un certificado EV... y cuando te lo envíen, copias la firma en el de "google.com"…   » ver todo el comentario
#58 Ves? Por respuestas así es que me tomo la molestia de seguir comentando en Meneame {0x1f602}
#58 Alquilar 11.000 GPUs no te lo ofrece ningún servicio cloud hoy en dia, pero si te lo ofreciesen, el precio sería de 10 millones de dólares...sospecho que te cazarían antes de que pudieses rentabilizar tu inversión, sea cual sea el oscuro uso que tienes en mente para una colisión SHA-1.
cc #78
#58 plan perfecto, si no fuera porque desde hace casi 2 años las CAs ya no emiten certificados firmados con SHA-1, precisamente porque se sabía que era vulnerable...
Me pregunto cuantos de los 76 meneantes saben de qué cojones está hablando el artículo.
#41 ¿No crees que haya 76 personas en menéame capaces de entender un artículo técnico sobre informática? Eres nuevo, ¿no?
#50 {0x1f602} El angelito lleva 10 años registrado y aún no se ha enterado que esto está lleno de informáticos que echan el rato entre compilación y compilación.
Y por eso hace 2 años que existe SHA-3... que casi nadie utiliza, pero que todos deberían ir implementando para cuando SHA-256 (realmente SHA-2 256) también acabe cayendo.
Pobre Julio César si levantara la cabeza :-)
Había una porra y un listo se la ha llevado (o directamente alguien de Google, aunque creo que es menos probable).

twitter.com/rauchg/status/834770508633694208
Es cierto que colisiona el sha1, pero no el md5, así pues acabo de salvar el mundo con mi nuevo algoritmo el sha1+md5:
fileEq(file, sha1Check, md5Check): return sha1(f1) == sha1Check and md5(f1) == md5Check
#59: Eso pienso yo: ¿Qué pasa con nuestros programas P2P? ¿Tendremos que añadir el SHA256 a los enlaces eD2K? Hace tiempo añadieron el SHA1 porque se estimó que MD4 era demasiado blando y inseguro, ahora hay esos dos a la vez. ¿Por qué no se inventa un SHA2048 y nos dejamos de historias? O sea, aunque sea lento, pero que sea indestructible en varias décadas.
#81 ¿Te imaginas que lo usan contra el emule y el lugar de bajarte la peli de moda del momento, te descargas una porno porque han clonado el sha-1?
#95: Claro, pero aquí la cuestión es que tienes que clonar dos hash a la vez.
¿Tienen una técnica para crearlas o ha sido casualidad porque tienen hashes de tantos archivos en sus bbdd y han visto que dos ficheros diferentes tienen el mismo sha1?

¿No será una liberación de bug que mantenia la nsa/google y que han decidido que ya es hora?
www.meneame.net/c/21185135

Matematicos que trabajaban para la nsa encontraron la vulnerabilidad hace tiempo (encontraron sistemas para crear colisiones al gusto, hackearon el algoritmo) y no la publicaron (esos bugs que se…   » ver todo el comentario
#66 Deja las drojas y léete la noticia:

In 2013, Marc Stevens published a paper that outlined a theoretical approach to create a SHA-1 collision.

the SHA-1 shattered attack is still more than 100,000 times faster than a brute force attack which remains impractical.

Lo que hay "años después" son datacenters con millones de GPUs capaces de resolver el problema en un tiempo razonable cuando lo simplificas 100.000 veces. Es algo que lleva pasando durante décadas, y seguirá pasando. No hacen falta ni conspiraciones de la NSA, ni ordenadores cuánticos (que según D-Wave los hay, pero ese es otro tema), ni nada parecido.
#82 Pero piensa
¿Y si hay un monton de tipos como Marc Stevens que investigan, pero no publican sus papers?
Los papers se los quedan y los desarrollan otros que tampoco publican papers.

Entonces igual hay metodos incluso muchisimo mas eficaces de resolver el problema, incluso con poquitas maquinas con gpu.
Entonces algunos ya pueden romper sha1 y otros desde hace tiempo, pero no lo sabemos, porque nunca publicaron papers, se los guardaron para otros propósitos (hegemonia, seguridad nacional, ganar)

Y sabemos que entes como la nsa se suelen dedicar a eso bastante. Si alguien lo ha hecho, ellos son unos de los que lo han hecho.
#98 eso es posible, pero si un tío lo ha descubierto cualquier otro también puede hacerlo
Pues yo uso md5 :shit:
#67 Yo prefiero MDMA
#67 por el culo te la hinco
Oooooooooo  media
Es curioso bajarlos y comprobar uno mismo que el sha1 de ambos pdf es el mismo.

Aunque también es cierto que dan un md5 distinto, con lo que bastaría combinar ambas huellas para joder el invento, y eso que el md5 también está superado.
Pero vamos a ver, a mi me resulta bastante obvio que cualquier algoritmo hash va a terminar dando lugar a una colisión (dos archivos que den el mismo hash).

Si la idea es, cojo un archivo, hago unos cálculos con los bits que lo forman usando el algoritmo que sea, para obtener una cadena de caracteres que siempre tiene una longitud fija sea el archivo que sea, la cosa es bien sencilla: el número de archivos distintos posibles es infinito, mientros que el número de combinaciones de una cadena de…   » ver todo el comentario
«12
comentarios cerrados

menéame