hash embedded crc

hash - ¿Cuándo es más apropiado usar CRC que MD5/SHA1?



embedded (13)

CRC está diseñado contra cambios involuntarios en los datos. Es decir, es bueno para detectar errores involuntarios, pero será inútil como una forma de garantizar que los datos no se manejen de forma malintencionada.

También mira this .

¿Cuándo es apropiado usar CRC para la detección de errores en comparación con funciones de hash más modernas como MD5 o SHA1? ¿Es el primero más fácil de implementar en el hardware integrado?

CRC funciona bien para detectar errores aleatorios en datos que pueden ocurrir, por ejemplo, de interferencia de red, ruido de línea, distorsión, etc.

CRC es computacionalmente mucho menos complejo que MD5 o SHA1. Usar una función hash como MD5 probablemente sea excesiva para la detección aleatoria de errores. Sin embargo, usar CRC para cualquier tipo de comprobación de seguridad sería mucho menos seguro que una función de hash más compleja como MD5.

Y sí, CRC es mucho más fácil de implementar en hardware integrado, incluso puede obtener diferentes soluciones empaquetadas para esto en IC.

CRC32 es más rápido y el hash tiene solo 32 bits de longitud.

Úselo cuando solo quiera una suma de comprobación rápida y ligera. CRC se usa en ethernet.

Si necesita más confiabilidad, es preferible usar una función de hashing moderna.

CRC32 es mucho más rápido y a veces tiene soporte de hardware (es decir, en procesadores Nehalem). En realidad, la única vez que lo usarías es si estás interactuando con el hardware, o si estás muy ajustado al rendimiento

Ejecuté cada línea de este código PHP en 1.000.000 de bucle. Los resultados están en comentarios (#).

hash(''crc32'', ''The quick brown fox jumped over the lazy dog.'');# 750ms 8 chars hash(''crc32b'',''The quick brown fox jumped over the lazy dog.'');# 700ms 8 chars hash(''md5'', ''The quick brown fox jumped over the lazy dog.'');# 770ms 32 chars hash(''sha1'', ''The quick brown fox jumped over the lazy dog.'');# 880ms 40 chars hash(''sha256'',''The quick brown fox jumped over the lazy dog.'');# 1490ms 64 chars hash(''sha384'',''The quick brown fox jumped over the lazy dog.'');# 1830ms 96 chars hash(''sha512'',''The quick brown fox jumped over the lazy dog.'');# 1870ms 128 chars

Mi conclusión:

  • Use "crc32b" cuando necesite http://en.wikipedia.org/wiki/Cyclic_redundancy_check y no le importa la seguridad.

  • Use "sha256" (o superior) cuando necesite una capa de seguridad adicional.

  • No use "md5" o "sha1" porque tienen:

    1. algunos problemas de seguridad cuando te preocupas por la seguridad
    2. cadena hash más larga y son más lentas que "crc32b" cuando todo lo que necesitas es CRC

El código CRC es más simple y más rápido.

¿Para qué necesitas alguno?

Empecemos con lo básico.

En Criptografía, un algoritmo de hash convierte muchos bits en menos bits a través de una operación de resumen. Los valores hash se usan para confirmar la integridad de mensajes y archivos.

Todos los algoritmos hashing generan colisiones. Una colisión ocurre cuando varias combinaciones de varios bits producen la misma salida de bit menos. La fortaleza criptográfica de un algoritmo hash se define por la incapacidad de un individuo para determinar cuál será el resultado para una entrada determinada, porque si pudiera, podría construir un archivo con un hash que coincida con un archivo legítimo y comprometer la integridad asumida. del sistema. La diferencia entre CRC32 y MD5 es que MD5 genera un hash más grande que es más difícil de predecir.

Cuando desea implementar la integridad del mensaje, lo que significa que el mensaje no ha sido manipulado en tránsito, la incapacidad de predecir colisiones es una propiedad importante. Un hash de 32 bits puede describir 4 mil millones de mensajes o archivos diferentes utilizando 4 mil millones de hashes únicos diferentes. Si tiene 4 mil millones y 1 archivo, se garantiza que tendrá 1 colisión. 1 TB Bitspace tiene la posibilidad de miles de millones de colisiones. Si soy un atacante y puedo predecir cuál va a ser el hash de 32 bits, puedo construir un archivo infectado que colisione con el archivo de destino; que tiene el mismo hash.

Además, si estoy haciendo una transmisión de 10mbps, la posibilidad de que un paquete se corrompa solo para eludir crc32 y continuar a lo largo del destino y ejecutar es muy bajo. Digamos que a 10mbps obtengo 10 errores por segundo . Si amplío hasta 1gbps, ahora recibo 1,000 errores por segundo . Si acumulo hasta 1 exab por segundo, entonces tengo una tasa de error de 1,000,000,000 de errores por segundo . Supongamos que tenemos una tasa de colisión de 1 / 1,000,000 de errores de transmisión, es decir, 1 en un millón de errores de transmisión da como resultado que los datos corruptos pasen inadvertidos. A 10mbps me enviaban datos de error cada 100,000 segundos o aproximadamente una vez al día. En 1gbps sucedería una vez cada 5 minutos. A 1 exabit por segundo, estamos hablando varias veces por segundo.

Si abre el wireshark, verá que su encabezado típico de ethernet tiene un CRC32, su encabezado IP tiene un CRC32 y su encabezado TCP tiene un CRC32, y eso además de lo que pueden hacer los protocolos de capa superior; por ejemplo, IPSEC podría usar MD5 o SHA para la verificación de integridad además de lo anterior. Hay varias capas de comprobación de errores en las comunicaciones de red típicas, y TODAVÍA se ejecutan una y otra vez a velocidades inferiores a 10mbps.

Cyclic Redundancy Check (CRC) tiene varias versiones comunes y varias poco comunes, pero en general está diseñada para indicar cuándo un mensaje o archivo ha sido dañado en tránsito (múltiples bits volteando). CRC32 en sí mismo no es un protocolo de comprobación de errores muy bueno según los estándares actuales en entornos empresariales escalares grandes debido a la tasa de colisiones; el disco duro promedio de los usuarios puede tener más de 100k archivos, y los archivos compartidos en una compañía pueden tener decenas de millones. La relación de hash-space a la cantidad de archivos es demasiado baja. CRC32 es computacionalmente barato para implicar, mientras que MD5 no lo es.

MD5 fue diseñado para detener el uso intencional de colisiones para hacer que un archivo malicioso parezca maligno. Se considera inseguro porque hashspace se ha mapeado suficientemente para permitir que se produzcan algunos ataques y algunas colisiones son predecibles. SHA1 y SHA2 son los nuevos niños en el bloque.

Para la verificación de archivos, Md5 está comenzando a ser utilizado por muchos proveedores, ya que puede hacer archivos de multigigabytes o archivos de varios bytes rápidamente y apilarlos sobre el uso general del sistema operativo y el soporte de CRC32. No se sorprenda si dentro de la próxima década los sistemas de archivos comienzan a usar MD5 para la comprobación de errores.

Encontré un estudio que muestra cómo los hashes CRC inapropiados son para tablas hash . También explica las características reales del algoritmo. El estudio también incluye la evaluación de otros algoritmos hash y es una buena referencia para mantener.

La conclusión relevante sobre CRC para hashes:

CRC32 nunca fue pensado para el uso de la tabla hash. Realmente no hay una buena razón para usarlo para este propósito, y le recomiendo que evite hacerlo. Si decide utilizar CRC32, es fundamental que utilice los bits hash desde el extremo opuesto al que alimentan los octetos clave. El fin depende de la implementación específica de CRC32. No trate el CRC32 como una función hash de "caja negra", y no lo use como un hash de propósito general. Asegúrese de probar cada aplicación de idoneidad.

ACTUALIZAR

Parece que el sitio está caído. El archivo de internet tiene una copia .

Me encontré con un uso de CRC recientemente, que fue inteligente. El autor de la jdupe identificación y eliminación de duplicación de archivos jdupe (el mismo autor de la jhead de la herramienta popular exif) lo usa durante la primera pasada a través de los archivos. Un CRC se calcula en los primeros 32K de cada archivo para marcar archivos que parecen ser iguales, también los archivos deben tener el mismo tamaño. Estos archivos se agregan a una lista de archivos para hacer una comparación binaria completa. Se acelera la comprobación de grandes archivos multimedia.

No dices qué es lo que estás tratando de proteger.

Un CRC se usa a menudo en sistemas integrados como una verificación contra la corrupción accidental de datos en lugar de evitar la modificación maliciosa del sistema. Los ejemplos de lugares donde un CRC puede ser útil es validar una imagen EPROM durante la inicialización del sistema para protegerse contra la corrupción del firmware. El gestor de arranque del sistema calculará el CRC para el código de la aplicación y lo comparará con el valor almacenado antes de permitir que se ejecute el código. Esto protege contra la posibilidad de corrupción accidental del programa o una descarga fallida.

Un CRC también se puede usar de manera similar para proteger los datos de configuración almacenados en FLASH o EEPROM. Si el CRC es incorrecto, los datos pueden marcarse como no válidos y se puede usar un conjunto de datos predeterminado o de respaldo. El CRC puede no ser válido debido a una falla del dispositivo o si el usuario eliminó la energía durante una actualización del almacén de datos de configuración.

Ha habido comentarios de que un hash proporciona una mayor probabilidad de detectar corrupción que un CRC con múltiples errores de bit. Esto es cierto, y la decisión de usar o no un CRC de 16 o 32 bits dependerá de las consecuencias de seguridad de un bloque de datos corrupto que se utilice y de si puede justificar la posibilidad de 1 en 2 ^ 16 o 2 ^ 32 de una el bloque de datos se declaró incorrectamente válido.

Muchos dispositivos tienen un generador de CRC incorporado para algoritmos estándar. La serie MSP430F5X de Texas tiene una implementación de hardware del estándar CRC-CCITT.

Solo use CRC si los recursos de computación son muy ajustados (es decir, algunos entornos embebidos) o necesita almacenar / transportar muchos valores de salida y el espacio / ancho de banda es ajustado (como CRC son generalmente de 32 bits donde una salida MD5 es de 128 bits, SHA1 160 bit, y otras variantes de SHA hasta 512 bit).

Nunca use CRC para las comprobaciones de seguridad ya que un CRC es muy fácil de "falsificar".

Incluso para la detección de errores accidentales (en lugar de la detección de cambios maliciosos), los hashes son mejores que un CRC simple. En parte debido a la forma simple en que se calcula un CRC (y en parte porque los valores CRC son usualmente más cortos que los resultados hash comunes, por lo que tienen un rango mucho menor de valores posibles) es mucho más probable que en una situación donde haya dos o más errores , un error ocultará a otro para que termine con el mismo CRC a pesar de dos errores.

En resumen: a menos que tenga razones para no usar un algoritmo hash decente, evite los CRC simples.

Todo depende de tus requisitos y expectativas.

Aquí hay breves breves diferencias entre estos algoritmos de función hash :

CRC (CRC-8/16/32/64)

  • no es un algoritmo hash criptográfico (está utilizando una función lineal basada en comprobaciones de redundancia cíclica)
  • puede producir 9, 17, 33 o 65 bits
  • no destinado a ser utilizado con fines criptográficos, ya que no ofrece garantías criptográficas,
  • no apto para su uso en firmas digitales, porque es fácilmente reversible 2006 ,
  • no debe usarse con fines de encriptación,
  • diferentes cadenas pueden generar la colisión,
  • inventado en 1961 y utilizado en Ethernet y muchos otros estándares,

MD5

  • es un algoritmo hash criptográfico,
  • produciendo un valor hash de 128 bits (16 bytes) (números hexadecimales de 32 dígitos)
  • es un hash criptográfico, pero se considera obsoleto si te preocupa la seguridad,
  • hay cadenas conocidas que tienen el mismo valor de hash MD5
  • se puede utilizar con fines de cifrado,

SHA-1

  • es un algoritmo hash criptográfico,
  • produce un valor hash de 160 bits (20 bytes) conocido como resumen de mensaje
  • es un hash criptográfico y desde 2005 ya no se considera seguro,
  • se puede utilizar con fines de cifrado,
  • se ha encontrado un ejemplo de colisión sha1
  • publicado por primera vez en 1993 (como SHA-0), luego 1995 como SHA-1,

  • serie: SHA-0, SHA-1, SHA-2, SHA-3,

    En resumen, usar SHA-1 ya no se considera seguro contra oponentes bien financiados, porque en 2005, los criptoanalistas encontraron ataques contra SHA-1, lo que sugiere que podría no ser lo suficientemente seguro para el uso continuo de schneier . El NIST de EE. UU. Recomienda que las agencias federales dejen de usar SHA1-1 para aplicaciones que requieran resistencia a colisión y deben usar SHA-2 después de 2010 NIST .

Por lo tanto, si busca una solución simple y rápida para verificar la integridad de los archivos (contra la corrupción), o para algunos simples propósitos de almacenamiento en caché en términos de rendimiento, puede considerar CRC-32, para hash puede considerar usar MD5, sin embargo, si está desarrollando una aplicación profesional (que debe ser segura y consistente), para evitar cualquier probabilidad de colisión, use SHA-2 y superior (como SHA-3).

Actuación

Alguna prueba de referencia simple en PHP:

# Testing static text. $ time php -r ''for ($i=0;$i<1000000;$i++) crc32("foo");'' real 0m0.845s user 0m0.830s sys 0m0.008s $ time php -r ''for ($i=0;$i<1000000;$i++) md5("foo");'' real 0m1.103s user 0m1.089s sys 0m0.009s $ time php -r ''for ($i=0;$i<1000000;$i++) sha1("foo");'' real 0m1.132s user 0m1.116s sys 0m0.010s # Testing random number. $ time php -r ''for ($i=0;$i<1000000;$i++) crc32(rand(0,$i));'' real 0m1.754s user 0m1.735s sys 0m0.012s/ $ time php -r ''for ($i=0;$i<1000000;$i++) md5(rand(0,$i));'' real 0m2.065s user 0m2.042s sys 0m0.015s $ time php -r ''for ($i=0;$i<1000000;$i++) sha1(rand(0,$i));'' real 0m2.050s user 0m2.021s sys 0m0.015s

Relacionado:

  • ¿Cuál es la diferencia entre md5 (), crc32 () y sha1 () crypto en PHP?