functions - security hash

Archivo que contiene su propia suma de comprobación

Question

¿Es posible crear un archivo que contendrá su propia suma de comprobación (MD5, SHA1, lo que sea)? Y para molestar a los jokers, me refiero a la suma de comprobación en claro, no a la función de calcularlo.

Answer 1

Ciertamente, es posible. Pero uno de los usos de las sumas de comprobación es detectar la alteración de un archivo. ¿Cómo sabría si se ha modificado un archivo si el modificador también puede reemplazar la suma de comprobación?

Answer 2

Claro, podría concatenar el resumen del archivo al final del archivo. Para verificarlo, debe calcular el resumen de todas las partes menos la última, luego compararlo con el valor en la última parte. Por supuesto, sin alguna forma de encriptación, cualquiera puede recalcular el resumen y reemplazarlo.

editar

Debo agregar que esto no es tan inusual. Una técnica es concatenar un CRC-32 para que el CRC-32 del archivo completo (incluido el resumen) sea cero. Sin embargo, esto no funcionará con compendios basados ​​en hash criptográficos.

Answer 3

Creé un código en C, luego ejecuté Bruteforce por menos de 2 minutos y obtuve esta maravilla:

The CRC32 of this string is 4A1C449B

Tenga en cuenta que no debe haber caracteres (fin de línea, etc.) después de la oración.

Puede consultarlo aquí: http://www.crc-online.com.ar/index.php?d=The+CRC32+of+this+string+is+4A1C449B&en=Calcular+CRC32

Este también es divertido:

I killed 56e9dee4 cows and all I got was...

Código fuente (lo siento, es un poco desordenado) aquí: http://www.latinsud.com/pub/crc32/

Answer 4

Existe una clara implementación del algoritmo Luhn Mod N en la biblioteca python-stdnum ( ver luhn.py ). La función calc_check_digit calculará un dígito o carácter que, cuando se anexe al archivo (expresado como una cadena) creará una cadena Luhn Mod N válida. Como se señala en muchas respuestas anteriores, esto proporciona una verificación de la cordura sobre la validez del archivo, pero no ofrece una seguridad significativa contra la manipulación. El receptor deberá saber qué alfabeto se está utilizando para definir la validez de Luhn mod N.

Answer 5

Hay muchas maneras de incrustar información para detectar errores de transmisión, etc. Las sumas de comprobación CRC son buenas para detectar ejecuciones consecutivas de bit y pueden agregarse de tal forma que la suma de comprobación siempre sea, por ejemplo, 0. Este tipo de suma de comprobación (incluido el error) corrección de códigos) son, sin embargo, fáciles de recrear y no detiene la manipulación maliciosa.

Es imposible insertar algo en el mensaje para que el receptor pueda verificar su autenticidad si el receptor no sabe nada más sobre / del emisor. El receptor podría, por ejemplo, compartir una clave secreta con el remitente. El remitente puede agregar una suma de comprobación encriptada (que debe ser criptográficamente segura, como md5 / sha1). También es posible utilizar el cifrado asimétrico en el que el remitente puede publicar su clave pública y firmar la suma de comprobación md5 / hash con su clave privada. El hash y la firma se pueden etiquetar en los datos como un nuevo tipo de suma de comprobación. Esto se hace todo el tiempo en internet hoy en día.

Los problemas restantes son 1. ¿Cómo puede el receptor estar seguro de que obtuvo la clave pública correcta y 2. Qué tan seguro es todo esto en realidad ?. La respuesta a 1 puede variar. En Internet es común tener la clave pública firmada por alguien en quien todos confíen. Otra solución simple es que el receptor obtuvo la clave pública de una reunión en personal ... La respuesta a 2 podría cambiar día a día, pero lo que es costoso forzar al día probablemente sea barato para romper un tiempo en el futuro . En ese momento, con suerte surgieron nuevos algoritmos y / o tamaños de clave ampliados.

Answer 6

Mira esto:

echo -e ''#!/bin/bash/necho My cksum is 918329835'' > magic

Answer 7

No sé si entiendo su pregunta correctamente, pero podría hacer que los primeros 16 bytes del archivo sean la suma de comprobación del resto del archivo.

Entonces, antes de escribir un archivo, usted calcula el hash, primero escribe el valor hash y luego escribe el contenido del archivo.

Answer 8

Por supuesto, puede hacerlo, pero en ese caso el compendio SHA de todo el archivo no será el SHA que incluyó, porque es una función hash criptográfica, por lo que al cambiar un solo bit en el archivo se cambia todo el hash. Lo que está buscando es una checksum calculada usando el contenido del archivo de manera que coincida con un conjunto de criterios.

Answer 9

Por supuesto.

La forma más simple sería ejecutar el archivo a través de un algoritmo MD5 e insertar esos datos dentro del archivo. Puede dividir la suma del cheque y colocarla en puntos conocidos del archivo (en función del tamaño de la porción del archivo, por ejemplo, 30%, 50%, 75%) si desea tratar de ocultarlo.

De forma similar, podría cifrar el archivo o cifrar una parte del archivo (junto con la suma de comprobación MD5) e insertarlo en el archivo. Editar Olvidé decir que necesitaría eliminar los datos de suma de comprobación antes de usarlo.

Por supuesto, si su archivo necesita ser fácilmente legible por otro programa, por ejemplo Word, entonces las cosas se vuelven un poco más complicadas ya que no quiere "corromper" el archivo para que ya no sea legible.

Answer 10

Sí. Es posible, y es común con sumas de comprobación simples. Obtener un archivo para incluir su propio md5sum sería bastante desafiante.

En el caso más básico, cree un valor de suma de comprobación que hará que el módulo sumado sea igual a cero. La función de suma de verificación se convierte en algo así como

(n1 + n2 ... + CRC) % 256 == 0

Si la suma de comprobación se convierte en una parte del archivo, se comprueba por sí misma. Un ejemplo muy común de esto es el algoritmo de Luhn utilizado en los números de tarjetas de crédito. El último dígito es un dígito de control, y es en sí mismo parte del número de 16 dígitos.

Answer 11

Si la pregunta es si un archivo puede contener su propia suma de comprobación (además de otro contenido), la respuesta es trivialmente sí para las sumas de comprobación de tamaño fijo, ya que un archivo podría contener todos los valores de suma de comprobación posibles.

Si la pregunta es si un archivo puede consistir en su propia suma de comprobación (y nada más), es trivial construir un algoritmo de suma de comprobación que haría imposible dicho archivo: para una suma de comprobación de n bytes, tome la representación binaria de los primeros n bytes del archivo y agregue 1. Como también es trivial construir una suma de verificación que siempre se codifica (es decir, hacer lo anterior sin agregar 1), claramente hay algunas sumas de comprobación que pueden codificarse y otras que no . Probablemente sea bastante difícil decir cuál de estas es una suma de verificación estándar.

Answer 12

"Desearía que mi crc32 fuera 802892ef ..."

Bueno, pensé que esto era interesante, así que hoy codifiqué un pequeño programa de Java para encontrar colisiones. Pensé que lo dejaría aquí en caso de que alguien lo encuentre útil:

import java.util.zip.CRC32;
public class Crc32_recurse2 {
public static void main(String[] args) throws InterruptedException {
long endval = Long.parseLong("ffffffff", 16);
long startval = 0L;
// startval = Long.parseLong("802892ef",16); //uncomment to save yourself some time
float percent = 0;
long time = System.currentTimeMillis();
long updates = 10000000L; // how often to print some status info
for (long i=startval;i<endval;i++) {
String testval = Long.toHexString(i);
String cmpval = getCRC("I wish my crc32 was " + testval + "...");
if (testval.equals(cmpval)) {
System.out.println("Match found!!! Message is:");
System.out.println("I wish my crc32 was " + testval + "...");
System.out.println("crc32 of message is " + testval);
System.exit(0);
}
if (i%updates==0) {
if (i==0) {
continue; // kludge to avoid divide by zero at the start
}
long timetaken = System.currentTimeMillis() - time;
long speed = updates/timetaken*1000;
percent = (i*100.0f)/endval;
long timeleft = (endval-i)/speed; // in seconds
System.out.println(percent+"% through - "+ "done "+i/1000000+"M so far"
+ " - " + speed+" tested per second - "+timeleft+
"s till the last value.");
time = System.currentTimeMillis();
}
}
}
public static String getCRC(String input) {
CRC32 crc = new CRC32();
crc.update(input.getBytes());
return Long.toHexString(crc.getValue());
}
}

La salida:

49.825756% through - done 2140M so far - 1731000 tested per second - 1244s till the last value.
50.05859% through - done 2150M so far - 1770000 tested per second - 1211s till the last value.
Match found!!! Message is:
I wish my crc32 was 802892ef...
crc32 of message is 802892ef

Tenga en cuenta que los puntos al final del mensaje son en realidad parte del mensaje.

En mi i5-2500 tomaría ~ 40 minutos buscar todo el espacio crc32 de 00000000 a ffffffff, haciendo aproximadamente 1,8 millones de pruebas / segundo. Estaba maximizando un núcleo.

Soy bastante nuevo con Java, por lo que cualquier comentario constructivo sobre mi código sería apreciado.

"Mi crc32 era c8cb204, ¡y lo único que obtuve fue esta pésima camiseta!"