[meka]

mis mas que escasos conocimientos informaticos me hacen imposible opinar sobre el tema de los hash......en esa web que pusistes solo veo,leo como explicas segun tu lo sucedido...alguien te encomienda alli a que cuelgues
una copia de la sentencia...a ver si la pones la leo y puedo darte la absolucion que segun leo necesitas por parte de los usuarios del emule....yo de momento ya no te digo mas nada....que el tema quema ya

[indignado7777]

Mi sentencia de absolución ocupa más de 50 folios.
En ella el Juez ofreció todo tipo de detalles.
Puedes escuchar el
Audio de mi Juicio 01
Audio de mi Juicio 02
Audio de mi Juicio 03
Audio de mi Juicio 04


Aunque si no tienes mucho criterio técnico te será imposible despejar las falacias técnicas que soltó ese perito informático del Estado ante un Juez. Te daré pistas: en la grabación se me escucha resoplar en varios momentos. Momentos en los que me agarraba al banco mirando para mi abogado a ver si decía "¡protesto!" -pero eso solo ocurre en las películas.

El agente pronunció tres veces el nombre del archivo en su traducción española, pese a que el nombre de archivo estaba formado por palabras y siglas inglesas. Archivo que les recuerdo que nunca fue hallado en mis ordenadores.

Un archivo cuyo HASH sigue estando disponible en la red eDonkey eternamente.

Indignado

This post has been edited by indignado7777: 30 January 2013 - 10:42 PM

[DJ_MELERIX]

si se puede identificar a la distancia un archivo compartido en redes ED2K y KAD, gracias al hash unico de archivo usado en estas redes.

con el solo hecho de poner un archivo a compartir, este de indexa en los servidores ED2K asi como en KAD mediante su hash.

por ejemplo, para Fedora 18 su enlace ED2K es:

ed2k://|file|Fedora-18-i686-Live-Desktop.iso|932184064|6514C1A2158AA02AC789A7E5959BD970|/

como puedes ver lo que he marcado en azul es el tamaño en bytes del archivo y lo que esta marcado en rojo es el hash unico del archivo para la red ED2K

y aunque le cambies el nombre, el archivo sigue siendo posible identificarlo por su hash.

This post has been edited by DJ_MELERIX: 31 January 2013 - 06:36 AM

[indignado7777]

Te sugiero que te actualices: El algoritmo HASH MD4 que utiliza la red eDonkey puede romperse con un cálculo “a mano”

Quote

“El público respondió a la presentación del chino Dengguo Feng[3], con una ovación de pie, y la dramática afirmación de que las colisiones MD4 se pudieron calcular “a mano“. La aparición de estos ataques no fue una sorpresa repentina, teniendo en cuenta las advertencias de larga data, y las recomendaciones anteriores (Hans Dobbertin desde 1996) para utilizar el SHA1 más segura y estándar”.

Para no quedarnos en la pura teoría aquí os dejo un ejemplo de colisión MD5.

MD5 es uno de los algoritmos de reducción criptográficos diseñados por el profesor Ronald Rivest del MIT (Massachusetts Institute of Technology, Instituto Tecnológico de Massachusetts). Fue desarrollado en 1991 como reemplazo del algoritmo MD4 después de que Hans Dobbertin descubriese su debilidad.

Windows version
hello.exe. MD5 Sum: cdc47d670159eef60916ca03a9d4a007
erase.exe. MD5 Sum: cdc47d670159eef60916ca03a9d4a007

Linux version (i386):
hello. MD5 Sum: da5c61e1edc0f18337e46418e48c1290
erase. MD5 Sum: da5c61e1edc0f18337e46418e48c1290

En Windows al ejecutar el hello.exe nos mostraría esto:

C:\TEMP> md5sum hello.exe
cdc47d670159eef60916ca03a9d4a007
C:\TEMP> .\hello.exe
Hello, world!

(press enter to quit)
C:\TEMP>

y al ejecutar el erase.exe esto (solo muestra un texto amenazante. No hace nada con nuestro disco):

C:\TEMP> md5sum erase.exe
cdc47d670159eef60916ca03a9d4a007
C:\TEMP> .\erase.exe
This program is evil!!!
Erasing hard drive...1Gb...2Gb... just kidding!
Nothing was erased.

(press enter to quit)
C:\TEMP> 

Estos dos archivos TIENEN NOMBRES DISTINTOS y además TIENEN CONTENIDOS DISTINTOS pero TIENEN EL MISMO TAMAÑO (6Kb) y el HASH MD5 QUE GENERAN ES EL MISMO.

Esta es una colisión especialmente preparada para MD5, que si no sabéis cómo comprobar el HASH de un archivo os sugiero la aplicación HASHTAB. Si esto se hace con un MD5, obviamente será mucho más sencillo para MD4.

COROLARIO: El HASH de archivo MD4 NO DETERMINA REMOTAMENTE UN CONTENIDO, ya que existe la posibilidad de COLISIONES.

Indignado

This post has been edited by indignado7777: 05 February 2013 - 10:12 PM

[DJ_MELERIX]

si sabemos que hay colisiones en MD4, y es por ello que eMule no usa solamente MD4 si no que una variante de MD4 + SHA1 por ello el hash es seguro, eliminando el riesgo de colisiones y/o semenajantes problemas.

[DJ_MELERIX]

aca tienes un ejemplo con los archivos que has puesto arriba:

ed2k://|file|erase.exe|6144|B048FE0098AD72F71382E596DBC6FA85|/

ed2k://|file|hello.exe|6144|AB345D5325A2B50D742E79F40A8CC869|/

y puedes ver como en eMule el hash no colisiona.

saludos

[indignado7777]

Quote

si sabemos que hay colisiones en MD4, y es por ello que eMule no usa solamente MD4 si no que una variante de MD4 + SHA1 por ello el hash es seguro, eliminando el riesgo de colisiones y/o semenajantes problemas.

Estás mezclando los momentos en el que eMule utiliza las cosas. No es el mismo momento la identificación remota inicial (tema de este hilo) que el posterior control de la descarga.

IDENTIFICACIÓN REMOTA
Utiliza el MD4. A partir de la versión 0.50a eMule incorpora una mejora para identificar los archivos en la red Kad (parece que en la eDonkey no). Además del FILEHASH podrás encontrar en algunos archivo (todavía en poquísimos archivos) un ROOTHASH que se calcula a partir del aplicar nuevamente un algoritmo de resumen al árbol raíz de hashes del archivo. Pero insisto, sólo aparecerá ese HASH RAIZ cuando un usuario con versión 0.50a o posterior ofrezca un archivo ¡y ojo! de tamaño superior a 9,28Mb (un chunk).

CONTROL DE DESCARGA
eMule utiliza MD4 + SHA1 después de haberse producido la identificación remota. Por lo tanto la incorporación del SHA1 se usa posteriormente y tiene por cometido impedir que se te cuelen partes corruptas. Ver ICH y AICH

Quote

aca tienes un ejemplo con los archivos que has puesto arriba:

ed2k://|file|erase.exe|6144|B048FE0098AD72F71382E596DBC6FA85|/

ed2k://|file|hello.exe|6144|AB345D5325A2B50D742E79F40A8CC869|/

y puedes ver como en eMule el hash no colisiona.

Efectivamente. Si a los archivos del ejemplo anterior le calculas otro algoritmo distinto al MD5, lógicamente serán distintos.
Si lees bien he dicho que el ejemplo es una colisión especialmente preparada para MD5.

Aquí tienes una librería en lenguaje C para producir colisiones en MD4 md4coll.c

eMule tiene un problema en su identificación remota de contenidos. La industria del copyright lo sabe y además se aprovecha de ello. Actualmente cualquiera con un pocos conocimientos podría poner un eMule en marcha anunciando a nivel de METADATOS la existencia de determinados contenidos HASH para luego intentar colarte archivos distintos especialmente elaborados para saltarse los controles de la posterior descarga (no hablo de simple fake files, hablo de archivos clones).
Copyright Protection in P2P Networks by False Pieces Pollution


Indignado

This post has been edited by indignado7777: 01 February 2013 - 06:42 AM

[DJ_MELERIX]

lo repito, un archivo se puede identificar en eMule de forma remota en base a su hash (ya que ese hash es el que se indexa), y ese tipo de hash de eMule no experimenta colisiones.

saludos

[indignado7777]

DJ_MELERIX, on 01 February 2013 - 01:50 AM, said:

lo repito, un archivo se puede identificar en eMule de forma remota en base a su hash (ya que ese hash es el que se indexa), y ese tipo de hash de eMule no experimenta colisiones.

saludos

¿Alguien más se une a la afirmación de DJ_MELERIX para que quede constancia futura de su desconocimiento sobre estos asuntos?

[DJ_MELERIX]

mira el codigo fuente de eMule y saldras de tus propias dudas.

han pasado ya casi 11 años desde que existe eMule y hasta la fecha no se han reportado colisiones de hash, asi que si logras encotrar alguna colision en el hash que maneja eMule publicala aqui.

saludos

[indignado7777]

DJ_MELERIX ¿existe un mecanismo para detectar colisiones? ¿lo has visto en el código fuente?
Dime ¿cuál es la diferencia apreciable remotamente entre dos números HASH MD4 idénticos?

SUPUESTO:
1) El USUARIO01 comparte el archivo A de 27MB que genera el MD4 = HASHDELARCHIVO
2 ) El USUARIO02 comparte el archivo B de 27MB con contenido distinto de A pero el archivo genera el mismo MD4 = HASHDELARCHIVO
3) El USUARIO03 se descargó el archivo HASHDELARCHIVO pero al percatarse que no era lo que buscaba lo borró de su INCOMING sin refresar su eMule.
4) El USUARIO04 se ha descargado un troyano que anuncia en las redes P2P sin que el usuario lo sepa, la disponibilidad del HASHDELARCHIVO en su ordenador, pero el archivo no es el original sino uno especialmente preparado para saltarse los controles del HASH.

Todos los usuarios utilizan eMule inferiores a la versión 50a.
El USUARIO05 inicia la descarga del HASHDELARCHIVO y 1) 2) 3) y 4) aparecen como fuentes disponibles de todas las partes (3) del mismo.
1) Inicia el envío de la parte1 del archivo anunciado.
2 ) Inicia el envío de la parte2 del archivo anunciado.
3) Ofrece número para la cola de descarga del archivo.
4) Inicia el envío de la parte3 del archivo anunciado.

PREGUNTAS:
1.- ¿En qué momento se daría cuenta el eMule del USUARIO05 de que los archivos remotos no son los mismos?
a) Desde la identificación remota
b ) Por los comentarios y valoraciones de otros usuarios
c) Al descargar una parte y detectar que esa parte es corrupta.
d) Nunca
e) Otra __________

2.- ¿Cuál sería el archivo "original" para la red eDonkey que certifica la falsedad del resto?
a) 1)
b ) 2)
c) 4)
d) Otra __________

3.- Desde la perspectiva del USUARIO05, éste podría afirmar que:
a) El USUARIO01 tiene el contenido A
b ) El USUARIO02 tiene el contenido B
c) El USUARIO03 tiene el contenido A o B
d) No es posible afirmar nada
e) Otra ____________

Indignado

This post has been edited by indignado7777: 03 February 2013 - 10:36 AM

[DJ_MELERIX]

eMule no usa remotamente/localmente MD4 a secas como tu piensas.

como ya te lo he dicho anteriormente, eMule usa una variante de MD4 + SHA1.

[John1950]

DJ_MELERIX, on 03 February 2013 - 12:35 AM, said:

...eMule usa una variante de MD4 + SHA1.

La verdad es que no se en que casos se usaran los dos, pero si que hay casos en los que se inicia la descarga con solo el MD4.

Por ejemplo estos enlaces:
ed2k://|file|linuxmint-14-kde-dvd-64bit.[contentdb.emule-project.net].iso|1095761920|4EBDDB2ADB687AA47C5E16523536C447|/
ed2k://|file|linuxmint-14-kde-dvd-64bit.[contentdb.emule-project.net].iso|1095761920|4EBDDB2ADB687AA47C5E16523536C447|h=LDQUGR6L2WPT3XREK5U454BTTUZJ5BVN|/

Ambos son validos para Emule. Uno incluye el nombre, tamaño y hash MD4. El otro además añade el hash SHA1.

No es raro encontrar enlaces del primer tipo, con solo el MD4. En ese caso supongo que recibirá el SHA1 de las demás fuentes, pero en el caso de que le enviaran varios distintos no se que haría.

Saludos.

[DJ_MELERIX]

lo que esta en rojo es la variante MD4 + SHA1 (eMule hash).

y lo que has puesto en azul corresponde al hash de verificacion extra (AICH hash), es una de las features de la version 0.50a.

This post has been edited by DJ_MELERIX: 03 February 2013 - 06:45 AM

[indignado7777]

@John1950

Quote

La verdad es que no se en que casos se usaran los dos, pero si que hay casos en los que se inicia la descarga con solo el MD4.

De momento el tipo de enlace edk2 sin el HASH ROOT (h=) es el más frecuente.
Los enlaces edk2 con el HASH ROOT únicamente te lo vas a encontrar cuando estés conectado a la red KAD y existan clientes con eMule 50a o posteriores.
Para que este tipo de enlaces con seguridad HASH ROOT fueran la tónica ¿debería suceder dos cosas?:
1) Que eMule dejara de usar la red eDonkey y se centrara en la red KAD
2) Que todo el parque de usuarios (incluido sus MOD) adaptaran la medida implementada a partir de la versión 50a de eMule.

@DJ_MELERIX

Quote

lo que esta en rojo es la variante MD4 + SHA1 (eMule hash).
y lo que has puesto en azul corresponde al hash de verificacion extra (AICH hash), es una de las features de la version 0.50a.

Lo que está en rojo es el HASH de toda la vida en la red eMule, un MD4 calculado a partir del MD4 de cada una de las partes del archivo
Lo que está en azul es el HASH ROOT y es en este hash y sólo en este hash dónde eMule integra el SHA-1

Aquí se explica la diferencia entre HASH, AICH y HASHROOT Filehash, ICH y AICH

¿Alguien se anima a responder a las preguntas del cuestionario anterior?

Indignado

This post has been edited by indignado7777: 03 February 2013 - 09:42 AM

[DJ_MELERIX]

indignado7777, on 03 February 2013 - 04:56 AM, said:

Lo que está en rojo es el HASH de toda la vida en la red eMule, un MD4 calculado a partir del MD4 de cada una de las partes del archivo

todos los tipos de hash se calculan en base a la integridad del archivo lo cual incluye, fechas y peso de estos, etc.

el problema es que tu crees que eMule usa el MD4 original a secas, lo cual es incorrecto, ya que eMule usa una variante propia de MD4, y cuando digo variante propia, me refiero a una version modificada de MD4 (que obviamente no tiene todos los problemas de MD4 original) y ademas en conjunto con SHA1, es por que ello que el hash que veras en los archivos de eMule no corresponde a un hash MD4 a secas ni tampoco un hash SHA1 a secas, si no que una mezcla de varias verificaciones, incluyendo el MD4 modificado.

indignado7777, on 03 February 2013 - 04:56 AM, said:

Lo que está en azul es el HASH ROOT y es en este hash y sólo en este hash dónde eMule integra el SHA-1

lo que esta en azul es lo que se conoce como el "AICH hash" (nuevo algoritmo que fusiona mas versiones de hashes para identificacion final en un solo hash), lo puedes leer en las notas de lanzamiento de eMule 0.50a.

This post has been edited by DJ_MELERIX: 04 February 2013 - 12:31 AM

[indignado7777]

Quote

el problema es que tu crees que eMule usa el MD4 original a secas, lo cual es incorrecto, ya que eMule usa una variante propia de MD4, y cuando digo variante propia,

Cierto, la variante que comentas es que eMule, para archivos mayores de una parte, no utiliza un simple MD4. Calcula el MD4 final de la suma de MD4 de cada una de las partes. Repito, los archivos menores de una parte utilizan un simple MD4.

Después de perder unos cuantos post discutiendo sobre la teoría del HASH te pregunto: imagina que eMule en lugar de usar el obsoleto MD4 para identificar sus archivos, utilizara el mejor algoritmo de resumen actual ¿se acabaría el problema? ¿identificaría remotamente el contenido de un archivo ese algoritmo de resumen? LA RESPUESTA ES ¡NO!

La utilidad final de cualquier HASH NO ES AUTENTICAR REMOTAMENTE UN CONTENIDO, ES COMPROBAR QUE LO RECIBIDO OFRECE EL MISMO RESUMEN que lo anunciado remotamente.

Obviamente eMule y todas las redes P2P intentan identificar archivos mediante el HASH, pero es un error técnico afirmar dogmáticamente que esa identificación es inequívoca. Fíjate que si esa identificación fuera infalible no sería necesario tanto control una vez y se inicia la descarga. Insisto, un HASH desde la distancia no determina el contenido.

Mis respuestas al cuestionario son estas:
1.- ¿En qué momento se daría cuenta el eMule del USUARIO05 de que los archivos remotos no son los mismos?
Yo diría que c) Al descargar una parte y detectar que esa parte es corrupta o quizás d) Nunca, esto último si se trata del archivo especialmente preparado para saltarse los controles del HASH.

2.- ¿Cuál sería el archivo "original" para la red eDonkey que certifica la falsedad del resto?
Respuesta: d) Otra NINGUNO

Sin la existencia de criptografía mediante un sistema de certificados digitales y claves públicas para cada archivo es imposible determinar cuál es el archivo original. Por ejemplo, el enlace eDK2 que nos ofrece John1950 sobre el Linux Mint, si nos vamos a la página web original de ese software nos ofrece el MD5 (no MD4 emule) de esa descarga con lo que nos dificulta un poco más saber si ese enlace eDK2 se corresponde con el contenido original.

3.- Desde la perspectiva del USUARIO05, éste podría afirmar que:
Respuesta: d) No es posible afirmar nada

Un HASH de archivo es una ristra obtenida de aplicar un algoritmo de resumen a un contenido. Ese resumen tiene utilidad diferenciadora pero no determinista sobre un contenido remoto. Por tanto, desde el extremo de un peer es imposible afirmar que otro peer tiene. Únicamente se podría afirmar tal cosa si la descarga del archivo al completo se produce desde el mismo peer remoto.

Como sabréis una fuente remota P2P puede tener básicamente tres estados: activa, en cola e inactiva.

Fijaos en el caso del USUARIO03. Estamos ante una descarga no deseada en la que el usuario borra el contenido directamente de la carpeta INCOMING pero su eMule no se percata de ello y sigue anunciando a la red que él es fuente disponible del mismo, llegando a ofrecer número de cola.

Esto es una FALSE QUEUE RANK (aquí lo explico con detalle). Una falsa cola de descarga se puede crear de forma natural en un eMule sin ser alterado. Pero ¿qué pasa si el eMule utilizado ha sido manipulado por terceros con otras intenciones?

Indignado

[DJ_MELERIX]

indignado7777, on 04 February 2013 - 03:37 AM, said:

Repito, los archivos menores de una parte utilizan un simple MD4.

tal vez en el pasado, pero actualmente ya no, ya que como lo dije anteriormente:

"han pasado ya casi 11 años desde que existe eMule y hasta la fecha no se han reportado colisiones de hash"

prueba compartir 2 archivos (en los que MD4 "supuestamente" colisione) en eMule y dime que hash obtienes para cada uno

This post has been edited by DJ_MELERIX: 05 February 2013 - 01:08 AM

[DJ_MELERIX]

imagino que lo que buscas es que en eMule se cambie el sistema de hash completamente por uno mas robusto ?

eso tendrias que solicitarlo directo a los desarrolladores, aqui: http://forum.emule-p...php?showforum=6

cambiar el sistema de hash se puede hacer pero actualmente imagino que solo en KAD, ya que en ED2K dudo que lleguen a hacerlo, debido a que tambien tendrian que hacerlo los servers de lugdunum, y creo que se perderia la retro compatibilidad.

[indignado7777]

Quote

tal vez en el pasado, pero actualmente ya no, ya que como lo dije anteriormente:

"han pasado ya casi 11 años desde que existe eMule y hasta la fecha no se han reportado colisiones de hash"

prueba compartir 2 archivos (en los que MD4 "supuestamente" colisione) en eMule y dime que hash obtienes para cada uno

DJ_MELERIX es que son MOMENTOS DISTINTOS.

DESDE LA DISTANCIA DE UN PEER, ninguna red P2P, independientemente del HASH que se utilice, es imposible controlar un listado de archivo que ofrezcan colisiones. Principalmente porque desde la distancia un HASH no determina nada. Yo pudo anunciar que tengo el archivo cuyo HASH es XXXXXXX pero hasta que tú no te lo descargues y compruebes que el algoritmo de resumen que genera lo que te has descargado es el mismo que el que yo he anunciado, no podrías "técnicamente" decir que es el mismo archivo.

DESDE EL PROPIO EMULE QUE COMPARTE ¿qué sentido tiene compartir dos archivos que generen similar HASH MD4 FINAL?