Hace 7 años | Por Vio a security.googleblog.com
Publicado hace 7 años por Vio a security.googleblog.com

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.

Comentarios

P

#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.

J

#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í.

V

#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.

P

#46 No hay problema

r

#c-33" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2739157/order/33">#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?

D

#91 era un ejemplo inventado

J

#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'.

J

#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.

z

#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.

z

#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."
http://culturacientifica.com/2013/09/06/el-poder-de-una-idea-sencilla/

Varlak_

#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?

J

#43 Falta la palabra 'práctica': ...colisión práctica de..."

Varlak_

#64 no lo entiendo muy bien, ha habido alguna otra colisión antes?

J

#70 Sí, había posibilidad de colisiones desde que se demostró en 2005: https://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...)

V

#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.

J

#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 cuenta hoy no es suficiente para afirmar que SHA-1 es inseguro, y ni mucho menos para afirmar que es la primera colisión porque la matemática ya dijo en 2005 que hay colisiones. Otra cosa es que ésta sea la primera colisión en la práctica hasta la fecha.
Prueba del caos y del morbo del asunto, distintos medios ya están poniendo titulares del estilo de éste: "Google just cracked one of the building blocks of web encryption (but don’t worry)" por The Verge (http://www.theverge.com/2017/2/23/14712118/google-sha1-collision-broken-web-encryption-shattered).

V

#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 se probó que había colisiones en menor coste que fuerza bruta, es decir, que se puede romper. Google te está diciendo que lo ha roto, y que ha conseguido la primera colisión y que ha encontrado una fórmula para hacerlo (además en menor coste de lo que se dijo en 2005). Te están diciendo que son los primeros en demostrar que es inseguro? No, además te dicen que llevan años quejándose de su uso. Te estoy diciendo yo que se podría enfocar la noticia de otra manera, o que lo de 2005 es más o menos importante? No. Te estoy diciendo que el titular no es erróneo.

He citado exáctamente lo que tenía que citar, que dices que sí cuando es que no, para confundir a una persona que te está preguntando sinceramente, y lo único que quieres es demostrar lo listo que eres. Pues nada, para ti la perra gorda. Quien quiera entender que entienda.

Varlak_

#77 habia posibilidades de colision, pero que se sepa no ha habido ninguna, no?

B

#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?

J

#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

B

#65 Hombre, una colisión generada intencionalmente en un tiempo razonable sí que es suficiente para afirmar que SHA1 no es seguro.

V

#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." https://eprint.iacr.org/2015/967

A ver si esto aclara más las cosas

Waskachu

#2 no me gusta los que van de listillos, negativo.

s

#44 Gracias por la explicación. Todo un mundo esto de la criptografía.

D

#48 De nada. Es que ahora me dedico a la enseñanza... y justo acabamos de terminar ese tema

D

Putos coches autónomos.

JungSpinoza

#1 Los autónomos de este país estamos muy jodidos

armando.s.segura

#9 ¿Y lo poco que os quejáis?

Pelton

#89 Demasiado poco para lo que nos joden

JanSmite

#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.

dagavi

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

D

#59
Jajaja lol lol

m

#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.

Mister_Lala

#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?

m

#95: Claro, pero aquí la cuestión es que tienes que clonar dos hash a la vez.

D

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.

D

#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.

https://en.wikipedia.org/wiki/Quantum_cryptography

P

#3 #7 Bueno, con ordenadores cuánticos podrá crearse cifrados cuánticos también

Mister_Lala

#7 Calla, deja que el genio siga ilustrándonos.

b

#3 Desde la ignorancia. ¿SHA256 es lo mismo que AES-256?

D

#8 Un algoritmo de hash (SHA es uno) crea o asigna un código corto a cada documento o archivo digital que se le entregue. El documento o archivo digital puede ser enorme, pero el código es muy corto.

La idea es que si se puede conseguir un algoritmo de creación de códigos hashes que funcione de forma tal que pueda afirmarse que dado un código hash cualquiera (o simplemente un "hash") exista únicamente un documento o archivo digital que podría conducir a ese código hash, entonces los códigos hashes pueden usarse como "representantes sustitutivos en miniatura" de los documentos o archivos digitales que son más grandes.

Por ejemplo, imagina que creo un algoritmo de hashes, que llamo ALG-H, que produce códigos hashes que cumplen esa condición, es decir, dado un código hash cualquiera producido por el algoritmo ALG-H, puede tenerse la seguridad de que sólamente existe un documento o archivo digital que podría conducir a ese código. Imagina que cojo la Enciclopedia Británica entera y se la doy como input al algoritmo ALG-H, y el algoritmo me calcula el código hash F7GM44Z para la Enciclopedia Británica.

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.

Lógicamente toda la seguridad del procedimiento recae en la condición de que dado un código hash sólamente pueda existir un documento o archivo digital que pueda conducir a él a través del algoritmo de cálculo dado. Si esta seguridad no existe, entonces el código que yo te dije por teléfono, F7GM44Z, lo mismo puede representar la Enciclopedia Británica que algún otro documento digital distinto (esto se llama "colisión", porque si dos documentos digitales tienen el mismo código hash, es como si "colisionaran" entre ellos), así que ese código ya no me sirve a mí para poder asegurar a otras personas que yo te dije a tí la Enciclopedia Británica por teléfono, con lo cual mi algoritmo ALG-H ya no es un buen algoritmo. Esto es lo que le ha pasado al SHA-1.

En teoría es imposible un algoritmo perfecto que garantice que las colisiones jamás ocurrirán. Entonces ¿por qué se siguen utilizando algoritmos de hash? Porque sí es posible crear un algoritmo de hash con el que, aun siendo en teoría posible encontrar colisiones en él, sin embargo en la práctica sea imposible, porque para conseguirlo haría falta superar barreras técnicas tan colosales que no tendría sentido ni utilidad intentar encontrar una colisión (es decir, encontrar un documento digital que consiga hacerse pasar por otro distinto disfrazándose de un mismo código hash válido para ambos).

d

#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.

D

#3 ¿Quieres probarlo de verdad? Empieza con esto: https://hashcat.net/hashcat/

O por ejemplo, para romper contraseñas del RAR prueba con esto: http://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.

s

#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?

D

#35
Según la teoría de la información, no. La cosa es la cantidad de bits de entropía que generas por carácter añadido y eso depende de los caracteres anteriores.

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.

e

#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

D

#90 Eso es para la criptografía asimétrica usando el algoritmo de Shor (https://es.wikipedia.org/wiki/Algoritmo_de_Shor), ahí si que tendríamos problemas serios ya que reventaría totalmente algoritmos como RSA o ECC.

D

#3
Según el artículo, este ataque necesita 1 año con 110 GPUs. Con fuerza bruta requiere 12 millones de GPUs.

santiagogf89

#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 the state of a system requires an amount of energy no less than kTkT, where TT is the absolute temperature of the system and kk is the Boltzman constant. (Stick with me; the physics lesson is almost over.)

Given that k=1.38⋅10−16erg/∘Kelvink=1.38⋅10−16erg/∘Kelvin, and that the ambient temperature of the universe is 3.2∘K3.2∘K, an ideal computer running at 3.2∘K3.2∘K would consume 4.4⋅10−164.4⋅10−16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.

Now, the annual energy output of our sun is about 1.21⋅10411.21⋅1041 ergs. This is enough to power about 2.7⋅10562.7⋅1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all of its energy for 32 years, without any loss, we could power a computer to count up to 21922192. Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.

But that’s just one star, and a measly one at that. A typical supernova releases something like 10511051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.

These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.

Wallack

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?

D

#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.

Wallack

#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 password y eres capaz de generar con otra password el mismo hash si que es un problema gordo pero entre que imagino que las posibilidades sean cercanas a "ni de coña" y que la gran mayoría usan un seed no debe afectar mucho, pero me ha resultado muy curioso.

Yo siempre me pregunté eso, como es que si el hash tiene tamaño fijo no haya dos archivos/pass que den el mismo? pues mira, buen artículo para aprender cosas.

D

#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.

santiagogf89

#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 cualquier friki con su ordenador pueda generar un SHA-1 idéntico para dos archivos. Hace falta mucha potencia de cálculo (110 años de cálculo de GPU son MUCHAS operaciones matemáticas) y muchas condiciones de partida.

En cualquier caso, ya se sabía, no es fácil de hacer en la práctica y ya hay nuevos algoritmos mucho más seguros y complejos y el uso de SHA-1 está desaconsejado desde 2011.

G

#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.

V

#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

J

#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.

Sofrito

Pues yo uso md5

D

#67 Yo prefiero MDMA

Mister_Lala

#67 por el culo te la hinco

D

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.

D

#21 En la literatura técnica a los hashes también se les llama funciones de compresión: https://en.wikipedia.org/wiki/One-way_compression_function

D

#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.

D

#31 Por eso se le llama compresión unidireccional, luego no se pueden descomprimir

fugaz

#34 Como cuando comprimen un coche en el desguace

Mister_Lala

#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.

D

#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

D

#72 #34 #61 La informàtica ha violado violentamente el diccionario de la Real academia lol

V

#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.

D

#21 Creo que entiendo a lo que te refieres... pero en todo caso debería ser al revés

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 salvedad de que es más probable que los elementos de salida sean más cortos que los de entrada... ¡pero no siempre! O sea que unas veces —normalmente— comprime datos, y otras —en casos crónicos— los expande. Esta es la que debería ser llamada "función de transformación", porque no siempre comprime

mefistófeles

Pobre Julio César si levantara la cabeza

f

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.

Zeioth

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.

D

#24
Cierto, pero sigue siendo recomendable migrar a SHA256. En GNU Linux las contraseñas del shadow van en SHA256.

Zeioth

#58 Ves? Por respuestas así es que me tomo la molestia de seguir comentando en Meneame 😂

santiagogf89

#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

j

#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...

D

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.

Frederic_Bourdin

Había una porra y un listo se la ha llevado (o directamente alguien de Google, aunque creo que es menos probable).

Dovlado

Según la wiki ya se había encontrado una vulnerabilidad en 2004, aunque la consideraban "computacionalmente inviable":

https://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, requiriendo incluso más trabajo que MD5 (264)."

"La resistencia del algoritmo SHA-1 se ha visto comprometida a lo largo del año 2005. Después de que MD5, entre otros, quedara seriamente comprometido en el 2004 por parte de un equipo de investigadores chinos, el tiempo de vida de SHA-1 quedó visto para sentencia."

Así que el que lo siga usando es un chapuzas.

Zeioth

#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.

JungSpinoza

#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.

D

#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.


https://marc.info/?l=git&m=115678778717621&w=2

O sea que sí, por poder pueden crear un repo maligno e intentar endiñártelo pero se ve que git por defecto no confía en los repos externos sino que da tu copia local como aquella de la que se puede fiar.

Pero vamos, que sigue siendo muy arriesgado seguir con SHA1, eso desde luego.

fugaz

#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...

Jakeukalane

#60 creo que necesitaría yo para entenderlo una pizarra con líneas y flechas

J

#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.

capitan__nemo

¿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?
Trump ayuda a Wall Street y desmantela las protecciones que se crearon tras la Gran Recesión para evitar otra crisis/c156#c-156

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 guardan), como cuando se descodificó enigma y lo mantuvieron en secreto toda la guerra y años despues.

Ahora igual algunos matematicos del open source están encontrando la vulnerabilidad y entonces toca desacerse de este sistema.

O alguien está construyendo o tienen construidos ordenadores cuanticos experimentales suficientemente potentes para calcular y craer colisiones mas rapido.

Aunque no se si era sha1 el que ya era vulnerable u otro, las dichosas siglas.

D

#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.

capitan__nemo

#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.

a

#98 eso es posible, pero si un tío lo ha descubierto cualquier otro también puede hacerlo

Black_Diamond

Entre otras cosas, afecta a git de forma severa...

D

#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.

Me pregunto cuantos de los 76 meneantes saben de qué cojones está hablando el artículo.

D

#41 ¿No crees que haya 76 personas en menéame capaces de entender un artículo técnico sobre informática? Eres nuevo, ¿no?

Mister_Lala

#50 😂 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.

T

En el enlace a shattered.it aparece un pantallazo y usan powerlevel9K. Meneo por ello

T

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 X bits es 2^X siendo 2^X

o

Todo el tema del no repudio en entredicho. Esto podría tener consecuencias incluso legales en algunos casos.

J

#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%.

J

#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.

santiagogf89

#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...

JanSmite

#27 Ya, bueno… No se puede decir que el Estado español vaya a la cabeza de la tecnología…

o

#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...

Itsallgoodman

Oooooooooo

1 2