Opinión: corrección de errores en Tcp/Ip para descarga de aplicaciones

Archivado
Buenas, después de darle vueltas al coco (existen multitud de posts cuya solución ha sido volverse a bajar un archivo), y documentarme un poko también (la verdad por que me ha obligado a ello el examen de redes de la semana que viene ;-) ), os pido vuestra opinión sobre este lindo tema (corrección de errores en Tcp/Ip ).

Bien, primero presento el escenario:
1º Uso por la mayoría de usuarios del protocolo Tcp/Ip para la comunicación por internet.

2º Uso de redes ethernet / wifi / y adsl mayoritario, por no decir único.

3º La estructura de la trama ethernet , de 46/ a 1500 bytes con 4 bytes de Crc ->Detección de errores en la cabecera de la trama ,aunque el uso de redes Lan ethernet se tiene bastante calidad, también se producen errores (el dato de probabilidad estaría entorno a 10^-6 o por ahí, ), y hay que tener en cuenta que la circulación de los paquetes no siempre será a través de lan , por lo que este valor se puede ver incrementado.

4ºEl nivel Ip , no proporciona ninguna correción de errores en los datos (sólo detección de errores en la cabecera)

5º Tcp de la misma forma , considera que la principal componente de errores en la comunicación será debida a congestiones puntuales en la red , por lo que tiene control de flujo y control de errores mediante asentimientos (para perdidas y demás casos particulares ,consecuencia de apoyarse en Ip). Pero carece control de errores de los datos (al igual que Ip, sólo de la cabecera)

6º Como conclusión , no existe control real sobre los errores en una comunicación mediante internet sobre los datos, ya que se suponen bastante infrecuentes (y lo son) y si existe la necesidad de estas características , deberán realizar en las aplicaciones.

7ºDaño de los errores: Escaso , más que nada será dependiente de lo que se envía , me explico , a nadie le importa que en una película o cualquier documento multimedia cada 10 megas bajados haya un pixel que veo su color modificado, por lo que este tipo de transmisiones no se ven afectados por los errores ( las posibilidades de error vendrían en que callera en datos específicos de cabeceras en el comienzo del archivo , francamente improbable).

Entonces , ¿ qué datos son los más sensibles a los errores ? Sí , lo sabes ;-) , quien no se ha bajado un programa y no lo ha conseguido hacer funcionar/instalar y demás y se ha solucionado volviendoselo a bajar? , en la secuencia de un programa , un error sí que tiene más posibilidades de hacer daño, cayendo en espacio del programa por ejemplo ( y quien dice un programa dice una distro entera )

Soluciones Actuales Al problema: Pues en mi finito conocimiento, sólo conozco las firmas md5, que proporcionan una protección muy ligera de los datos (si la firma es tann pequeñita con respecto a los datos y tarda tan poquito tiempo en computar es que necesariamente no cubre mucho x'D)

Opinión: Creeis que existe la necesidad de mejorar la tranferencia de este tipo de archivos ,o , por el contrario pensais que con md5 vamos más que chutamos en ése campo??

De pensar afirmatívamente, qué le pediríais al nuevo programa? , mayor detección de errores? , posibilidad de detección y correción de errores? .Pensais que debería primar un redundancia en el código ínfima (como hace md5) y un proceso de cálculo ligero? (En mi opinión debería ser un programa al estilo md5 en cuanto a funcionamiento, pero si acaso con nuevas características ).

Buff , menudo ladrillo me ha salido [burla2] ,claro está no lo considero offtopic por que , aunque al principio no hable de soft libre directamente , quién sabe si algún día sí. ;-)

Pd: Habiendo abierto el hilo, mi opinión está clara: hay que pensarlo x'D

Salu2
Si no me equivoco, que es fácil que así sea, IP solo detecta errores en la cabecera por el hecho de evitar procesamiento en los nodos intermedios (como los routers) para agilizarlos y hacerlos más sencillos, pero creo que TCP si controla errores en lo que son los datos y la cabecera.

En una red LAN efectivamente el riesgo de pérdida de un paquete o de que aparezca algún error en la trama es bajo, pero en una red como internet, con una conexión de 56k por ejemplo la cosa cambia un poco ;)

Y bueno, sobre el MD5, pues yo nunca lo he usado, pero que sea pequeño no significa que tenga que ser malo. Todavia recuerdo ese juego en ensamblador que ocupa 96kb que no tiene nada que envidiar al Q3 ;)

Un saludo
[looco] Síp , la verdad es que re-revisando el tema de Tcp/Udp después de escribir el primer post viendo si había puesto muchas cagadas , lo he visto , en realidad El checksum de Tcp y Udp es de 8 bytes (contando 1 de puerto origen , o otro de destino y otro de longitud).

Y bueno, sobre el MD5, pues yo nunca lo he usado, pero que sea pequeño no significa que tenga que ser malo. Todavia recuerdo ese juego en ensamblador que ocupa 96kb que no tiene nada que envidiar al Q3


x'D jejeje , no me he expresado todo lo bien que debería... ésa es una razón muy "light" , tp me he querido meter en profundidad innecesaria y aburrir al personal muxo más :-p .
Y sí , la detección /corrección de errores ,como en muchos casos, depende del tamaño x'D (vale y de la manera de hacerlo ,pero por desgracia en estos temas no hay mucha panacea )

También apunto de que el hecho que exista el md5 por ejemplo, ""demuestra"" que a Tcp se le "escapan" errores.

Salu2 ahhh y gracias por no sobarse mientras se lee este bodrio x'D
dykstra escribió:También apunto de que el hecho que exista el md5 por ejemplo, ""demuestra"" que a Tcp se le "escapan" errores.

Hombre, si paras / reanudas / paras / reanudas / paras / reanudas la descarga "cienes y cienes" de veces es fácil que algún error que otro te de si :P

Y si descargas el archivo y justo se escribe en un sector defectuoso del HD pues tambien es facil que te dé algun error, o si lo grabas en un cd y no se quema bien, o si le pasas un iman al disco duro XD

TCP/IP no es que sean perfectos ni mucho menos, pero creo que hacen su labor bastante bien, sobre todo TCP.

Un saludo


EDITO: tambien es verdad que la ley de Murphy hace que justo cuando necesitas algo te venga con errores y tengas que bajarlo otra vez ;)
dykstra escribió:[

También apunto de que el hecho que exista el md5 por ejemplo, ""demuestra"" que a Tcp se le "escapan" errores.


Ten en cuenta que otra utilidad de la firma MD5 es también verificar que el fichero no haya sido alterado externamente por un atacante.
dykstra escribió:Salu2 ahhh y gracias por no sobarse mientras se lee este bodrio x'D


Todo lo contrario! almenos yo lo encuentro interesantissimo :D
Y si descargas el archivo y justo se escribe en un sector defectuoso del HD pues tambien es facil que te dé algun error, o si lo grabas en un cd y no se quema bien, o si le pasas un iman al disco duro

Jajajaja , la diferencia es que si se escribe con error en el sistema de ficheros puedes intentar recuperarlo (journaling) , sino se quema bien un cd te lo suele decir el programa de grabación con las técnicas de escritura/lectura , y bueno , si le pasas un imán mereces que te pase x'D. Y lo de cienes y cienes de veces parando/reanudando.... por ejemplo pensar un apt-get dist-upgrade según la ley de murphy da miedo de ver lo que tardarías encontrar el error. (si ya no es por que funcione o no funcione el programa, es por las comidas de cabeza que seguro hemos tenido , nos hayamos percatado o no [mad] [mad] [carcajad] )

Por otra parte:
TCP/IP no es que sean perfectos ni mucho menos, pero creo que hacen su labor bastante bien, sobre todo TCP.


Gracias tíu, de momento 1 a 1 [carcajad] a ver que opinan los demás [beer] .

A lo de
Sobre esto:
Ten en cuenta que otra utilidad de la firma MD5 es también verificar que el fichero no haya sido alterado externamente por un atacante.

Yo la verdad es que todavía no soy muy paranocio (cada vez +) y no me he empezado a meter mucho con el tema de los problemas de seguridad,pero creo recordar que como dices , sólo vale contra ataques de modificación (o lo que es lo mismo , errores al fin y al cabo ) , pero no hace nada en contra de los ataques de interceptación (confidencialidad) , por lo que no le veo mucho futuro, al menos para mí así de momento, sin recapacitar muxo,
(Juas aqui vagueando pero por lo menos hago memoria de cosas del proximo examen de redes x'D).

Salu2
MD5 es suficiente para el 99% de los casos, es una firma de 128 bits, lo que da 2^128 posibles combinaciones, vamos, bastante poco probable que un archivo tenga la misma firma que otro ;)
MD5 es suficiente para el 99% de los casos, es una firma de 128 bits, lo que da 2^128 posibles combinaciones, vamos, bastante poco probable que un archivo tenga la misma firma que otro


Hombre , haciendo así las cuentas......
Contraejemplo:
100 mbytes= 8.38 *10^8 bits, si lo ponemos en número de posibles combinaciones: 2^(8.38*10^8) = Infinito (datos con el scilex , ke tendrá 10^100 o más de representación ) , y sólo con tamaño de 100 megas , luego le sumamos los de 1 , 2 ,3 megas..... ..... tropecientos miles de miles :Ð , tantos infinitos de infitios en "sólo" 2^128 x'D, no en serio , me tendré que mirar a ver como va el algoritmo del md5, (Nota mental: Encontrar los sources del md5 que por algún lado los tenía :Ð ).
Es un ejemplo cutre, pero otro ejemplo es que los md5 , se basan en hash , es decir , cogen una pequeña muestra de los datos y es lo que codifican (suficiente para evitar los ataques de modificación como ya se dijo ) , pero que no veo yo tan claro que sea suficiente para la corrección de errores.

Vamos si es sufiente o no, esa es la cuestión x'D

Salu2
No es hacer las cuentas así, es que es así, no hay vuelta de hoja :-)

MD5 saca una firma de 128 bits, y con 128 bits, se pueden conseguir 2^128 combinaciones.

md5sum recorre el archivo completo, no solo una parte, no se basa en un hash, sino que md5 se usa como función hash ;)


http://www.faqs.org/rfcs/rfc1321.html
Pues si MD5 no te convence siempre puedes usar SHA1, 160 bits en canal. Con eso sí que no hay quien se equivoque. [tomaaa]

Saludos.

EDIT: 160, son 160. Ya me estoy durmiendo...
Jejeje , asias Churly por la rfc, me has solucionado la buskeda en un santiamén.
Así es mucho más fácil replicarte [qmparto] , claro está que no me la he leido concienzudamente ,pero finjandonos :
The MD5
algorithm is intended for digital signature applications, where a
large file must be "compressed" in a secure manner before being
encrypted with a private (secret) key under a public-key cryptosystem
such as RSA.

El objetivo del md5 no es ser un algoritmo de detección/correción de errores ,sino de "compresión" "segura" del mensaje original (es lo que llaman "fingerprint" y yo malexplicandome dije "hash" [tomaaa] ), de hecho no hablan en todo el rfc de la detección de errores, sino de prevención frente a un posible criptoanálisis para un ataque por modificación.
El hecho que sea matemáticamente imposible modificar el mensaje mediante criptoanálisis para que tenga la misma huella md5 (y también decir que en el rfc también dicen que la huella md5 debe ser codificada con algún criptosistema , como RSA ) , no quiere decir que la madre naturaleza no sea capaz de hacerlo [sonrisa] (bueno , con mínimas posibilidades, pero haberlas ailas , como las meigas.. [sonrisa] ).


Pues si MD5 no te convence siempre puedes usar SHA1, 160 bits en canal. Con eso sí que no hay quien se equivoque.
EDIT: 160, son 160. Ya me estoy durmiendo...


Ole , ole nuevas alternativas [qmparto] , habrá que mirarlas... pero como bien dices.... mejor ahora irse a la camita.....
dykstra escribió:El objetivo del md5 no es ser un algoritmo de detección/correción de errores ,sino de "compresión" "segura" del mensaje original (es lo que llaman "fingerprint" y yo malexplicandome dije "hash" [tomaaa] ), de hecho no hablan en todo el rfc de la detección de errores, sino de prevención frente a un posible criptoanálisis para un ataque por modificación.


No necesariamente, lo que mencionan ahí es una de las aplicaciones de MD5 en criptografía, pero también tiene otros usos. Por ejemplo, en el protocolo BitTorrent cada archivo está dividido en segmentos, y el "hash" SHA1 (MD5 también sería aplicable, de hecho creo que eMule lo usa para lo mismo) de esos segmentos se almacena en un archivo .torrent del que disponemos localmente. Al bajarlo, los clientes van comprobando que los segmentos llegan correctamente mediante esos "hashes", que es justo lo que nos interesa aquí.

Saludos.
Un pokillo de culturilla :

Van Oorschot and Wiener [VW94] have considered a brute-force search for collisions (see Question 2.1.6) in hash functions, and they estimate a collision search machine designed specifically for MD5 (costing $10 million in 1994) could find a collision for MD5 in 24 days on average. The general techniques can be applied to other hash functions.


En 1994, se consideraba al md5 "totalmente" seguro.

Página de computación distribuida para cargarse el md5 :-P :
http://www.md5crk.com/
E informe sobre ataques al md5:
http://www.certainkey.com/dnet/

Wikipedia sobre Sha y sus variantes:
http://en.wikipedia.org/wiki/SHA-1#Applications

Ejemplo de uso del md5 como detección de errores /ataque modificación:
http://www.cert.org/security-improvement/implementations/i002.01.html

La verdad , es la corrección contra errores en md5 se "cuenta" el algunas partes y en la mayoría se obvia .
Que el md5 tenga cierta capacidad para la detección de errores nunca la he menospreciado ,simplemente pienso que si nadie dice es capaz de detectar "x's" errores es por que simplemente no puede ya que no se ha diseñado para ello (vamos , que detectar errores lo hace , pero me da a mí que lo hace de una manera algo "aleatoria")

Que esa pequeña capacidad de detección nos valga para la mayoría de los casos en los que se usa será relativo (si no te instala una distro seguro que no hace tanta gracia X'D )

Como bien dice , ro9:
No necesariamente, lo que mencionan ahí es una de las aplicaciones de MD5 en criptografía, pero también tiene otros usos. Por ejemplo, en el protocolo BitTorrent cada archivo está dividido en segmentos, y el "hash" SHA1 (MD5 también sería aplicable, de hecho creo que eMule lo usa para lo mismo) de esos segmentos se almacena en un archivo .torrent del que disponemos localmente. Al bajarlo, los clientes van comprobando que los segmentos llegan correctamente mediante esos "hashes", que es justo lo que nos interesa aquí.


Fijate , según tú los p2p utilizan divisiones de segmentos y luego aplican el algoritmo md5/sha en cada división (es lo que creo k dices , no? no estoy muy muy enterado si lo hacen así, la verdad).
El que los programas p2p usen uniones de md5, no resulta extraño? si debería bastar con un md5 , no?! ejejeje ellos usan más , por que se fían menos .... [looco]

Salu2 , y que nadie piense que quiero llevar a nadie al huerto.. x'D
No se que intentas demostrar [buenazo] :P

MD5 no se suele usar como criptografía fuerte, porque entre otras cosas es un algoritmo de un solo sentido, y la única forma de atacarlo es por fuerza bruta. Claro, según aumente la potencia de los ordenadores, las 2^128 se hacen rápidamente. Pero para casos como guardar las passwords de un foro (como en EOL o la mayoría de los foros) es más que de sobra.

Aunque sigo sin entender que quieres decir desde el principio del hilo (tengo las neuronas desgastadas estos días [sonrisa]

Creo que ed2k usa para los segmentos MD4, pero no estoy muy seguro.
Churly escribió:[...]
Creo que ed2k usa para los segmentos MD4, pero no estoy muy seguro.


eMule, a no ser que haya cambiado algo en estos meses que llevo desvinculado, usa MD4.

Y dykstra, si los p2p usan divisiones de un archivo completo, no es por MD4/5 y sus posible corrección de errores, es mucho más simple. Si no hicieran esas divisiones en segmentos (chunks en emule, crumbs en edonkey/overnet), tendrías que tener el archivo completo para compartirlo, si hablamos de mp3s de 5 mbs, pues no es problema, pero imagínate compartir ISOs de 4GBs sin segmentos y que sólo la comparte aquellos que la completan... prácticamente inviable.

El sistema actual de eMule es el siguiente, cuando completas un segmento entero (9,28mbs, a ver si consiguen disminuir el tamaño sin romper la red :(), miras el hash, si está todo correcto, pasas a compartir esa parte con el resto de la red, si no, recibirás el error y tendrás que descargar la parte (bueno, está el ICH para tratar de recuperar la mayor cantidad posible de datos útiles en las partes corruptas).

El sistema de partes suele ser similar en los p2p, en BitTorrent el tamaño de cada parte andaba en 512KB o un 1MB creo.
dykstra escribió:Fijate , según tú los p2p utilizan divisiones de segmentos y luego aplican el algoritmo md5/sha en cada división (es lo que creo k dices , no? no estoy muy muy enterado si lo hacen así, la verdad).
El que los programas p2p usen uniones de md5, no resulta extraño? si debería bastar con un md5 , no?! ejejeje ellos usan más , por que se fían menos .... [looco]


Evidentemente tienen que hacerlo por segmentos. Imagínate que bajas un archivo entero de 700 MB por p2p que te cuesta una semana, y cuando ya ha llegado entero compruebas el hash, y... sorpresa, está corrupto!! ¿Qué haces? Pues no hay otra que bajarlo entero otra vez. En cambio, al hacerlo por segmentos se puede ir comprobando sobre la marcha, y si hay uno mal se descarta solamente ese trozo.

Saludos.
El md5 es mas seguro que la píldora!. No creo que haya problema de seguridad con el. Pero en todo caso y a lo que creo que iba el autor, es a que si se debería automatizar este proceso. Yo creo que la maquina origen debería generar el md5 automaticamente y la maquina destino comprobarlo tb automaticamente.
Churly escribió:No se que intentas demostrar


Jajaja , demostrar , pokito pokito ... si tubiera algo que demostrar así serio lo usaría para hacer el Pfc que tocará el año que viene [tomaaa] .(se aceptan ideas ehhh x'D)

Aunque sigo sin entender que quieres decir desde el principio del hilo (tengo las neuronas desgastadas estos días


Po dios , espero que no sea por mi culpa :-P ..... aunque yo tb me he devanado un pokito los sesos con las entrañas de tcp/ip (vaya examencillo de redes que nos han cascao [poraki] , y la pregunta más chunga ha resultado ser los modos de transmisión del telnet [poraki] (no por k fuera dificil, sino por k lo dijo el pive de bokilla un día) )

Sobre de ké iba el hilo... lo puse al principio! me quemaba mucho la curiosidad sobre vuestra opinión en si considerabais totalmente fiable Tcp/Ip ó Tcp/ip + algún programa ... está claro que considerais todos que síp :) .
Más que nada, por que tengo por ahí a algún colegilla que lo podía explotar este veranito para currarnos algún algoritmo que proporcionara más fiabilidad.... (faltaría pasarlo a C y bajarle la redundancia para que tubiera peores características de detección/corrección pero más liviano )


El md5 es mas seguro que la píldora!. No creo que haya problema de seguridad con el. Pero en todo caso y a lo que creo que iba el autor, es a que si se debería automatizar este proceso. Yo creo que la maquina origen debería generar el md5 automaticamente y la maquina destino comprobarlo tb automaticamente.


Sí también sería una buena opción, ya que visto lo liviano que es, no entiendo como no lo han metido ya en todos los lados.
Y que tampoco me fiaba mucho yo de md5, por que sigo sin ver en ningún lado características técnicas de md5 sobre detección ( que conste que acabo de preguntar a un profesor que enseña todos estos asuntos, y me ha respondido casi lo mismo que vosotros , que lo usa /ha usado pero que ni idea de las características de que hablo.... :) )

También espero que halla valido para que la gente tome en consideración los errores y no se crea que lo bajado debería ir 100% bien... y si puede usar md5 por poner un ejemplo que los use (no sería el primero que me viene a preguntar por problemas de instalación de distros y ni sikiera le ha pasado el md5... )

Y sobre los p2p y el md5.... se me fué la olla un pokejo :-P , no se si será por los examenes que nos dejan fatal .. :-P

y no sé , si konsiderais ke me aburro demasiado pues nada , buscarme una churri :-P jajaja

Salu2 y buen rollito [bye]
18 respuestas
Archivado
Volver a Software libre