Подтвердить что ты не робот

Файл, содержащий собственную контрольную сумму

Можно ли создать файл, который будет содержать свою собственную контрольную сумму (MD5, SHA1, что угодно)? И чтобы расстроить джокеров, я имею в виду контрольную сумму в обычном режиме, а не функцию, вычисляющую ее.

4b9b3361

Ответ 1

Да. Это возможно, и это обычное дело с простыми контрольными суммами. Получение файла для включения его собственного md5sum было бы довольно сложным.

В самом основном случае создайте значение контрольной суммы, которое приведет к тому, что модуль суммирования будет равен нулю. Функция контрольной суммы становится чем-то вроде

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

Если контрольная сумма становится частью файла и сама проверяется. Очень распространенным примером этого является алгоритм Luhn, используемый в номерах кредитных карт. Последняя цифра является контрольной цифрой и сама является частью 16-значного числа.

Ответ 2

Я создал кусок кода на C, а затем набрал bruteforce менее 2 минут и получил это чудо:

The CRC32 of this string is 4A1C449B

Обратите внимание, что после предложения не должно быть символов (конец строки и т.д.).

Вы можете проверить это здесь: http://www.crc-online.com.ar/index.php?d=The+CRC32+of+this+string+is+4A1C449B&en=Calcular+CRC32

Это тоже весело:

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

Исходный код (извините, это немного грязно) здесь: http://www.latinsud.com/pub/crc32/

Ответ 3

Проверьте это:

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

Ответ 4

Конечно, это возможно. Но одно из применений контрольных сумм заключается в обнаружении фальсификации файла - как узнать, был ли файл изменен, если модификатор также может заменить контрольную сумму?

Ответ 5

"Я хочу, чтобы мой crc32 был 802892ef..."

Ну, я думал, что это интересно, поэтому сегодня я закодировал небольшую программу java для поиска столкновений. Думал, что оставлю его здесь, если кто-то сочтет это полезным:

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());
    }

}

Выход:

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

Обратите внимание, что точки в конце сообщения фактически являются частью сообщения.

На моем i5-2500 вам понадобилось ~ 40 минут для поиска всего пространства crc32 от 00000000 до ffffffff, выполнив около 1,8 миллиона тестов в секунду. Это максимизировало одно ядро.

Я новичок в Java, поэтому любые конструктивные комментарии к моему коду будут оценены.

"Мой crc32 был c8cb204, и все, что я получил, было этой паршивой футболкой!"

Ответ 6

Конечно, вы можете объединить дайджест самого файла в конец файла. Чтобы проверить это, вы вычислили дайджест всего, кроме последней части, а затем сравните его со значением в последней части. Конечно, без какой-либо формы шифрования любой может пересчитать дайджест и заменить его.

изменить

Я должен добавить, что это не так уж необычно. Один из методов заключается в объединении CRC-32, так что CRC-32 всего файла (включая этот дайджест) равен нулю. Однако это не будет работать с дайджестами, основанными на криптографических хэшах.

Ответ 7

Я не знаю, правильно ли я понял ваш вопрос, но вы можете сделать первые 16 байтов файла контрольной суммой остальной части файла.

Итак, перед записью файла вы вычисляете хеш, сначала записываете хэш-значение, а затем записываете содержимое файла.

Ответ 8

Если вопрос задает вопрос, может ли файл содержать свою контрольную сумму (в дополнение к другому контенту), ответ тривиально да для контрольных сумм фиксированного размера, поскольку файл может содержать все возможные значения контрольной суммы.

Если вопрос заключается в том, может ли файл состоять из собственной контрольной суммы (и ничего больше), тривиально построить алгоритм контрольной суммы, который сделал бы такой файл невозможным: для n-байтовой контрольной суммы возьмите двоичное представление первые n байтов файла и добавьте 1. Так как также тривиально построить контрольную сумму, которая всегда кодирует себя (т.е. делает выше, не добавляя 1), очевидно, что есть некоторые контрольные суммы, которые могут кодировать себя, а некоторые, которые не могут. Вероятно, было бы довольно сложно определить, какая из них стандартная контрольная сумма.

Ответ 9

В библиотеке python-stdnum существует аккуратная реализация алгоритма Luhn Mod N (см. luhn.py). Функция calc_check_digit будет вычислять цифру или символ, который при добавлении к файлу (выраженный в виде строки) создаст допустимую строку Luhn Mod N. Как было отмечено во многих ответах выше, это дает возможность проверить достоверность файла, но не имеет существенной защиты от несанкционированного доступа. Получателю необходимо будет знать, какой алфавит используется для определения действительности мод Лона.

Ответ 10

Конечно.

Самый простой способ - запустить файл через алгоритм MD5 и вставить эти данные в файл. Вы можете разделить контрольную сумму и разместить ее в известных точках файла (на основе размера порции файла, например, 30%, 50%, 75%), если вы хотите попытаться скрыть его.

Аналогичным образом вы можете зашифровать файл или зашифровать часть файла (вместе с контрольной суммой MD5) и вставить его в файл. Edit Я забыл сказать, что вам нужно будет удалить данные контрольной суммы перед ее использованием.

Конечно, если ваш файл должен быть легко доступен для чтения другой программой, например. Слово тогда становится немного более сложным, так как вы не хотите "коррумпировать" файл, чтобы он не читался.

Ответ 11

Конечно, вы можете, но в этом случае дайджест SHA всего файла не будет включать SHA, потому что это криптографическая хэш-функция, поэтому изменение одного бита в файле меняет весь хеш. То, что вы ищете, это checksum, рассчитанный с использованием содержимого файла, чтобы соответствовать набору критериев.

Ответ 12

Существует множество способов встраивания информации для обнаружения ошибок передачи и т.д. Контрольные суммы CRC хороши при обнаружении прогонов последовательных бит-переворотов и могут быть добавлены таким образом, чтобы контрольная сумма всегда была, например, 0. Эти контрольные суммы (включая коды исправления ошибок), однако, легко воссоздаются и не прекращают вредоносного вмешательства.

Невозможно вставить что-то в сообщение, чтобы получатель мог проверить его подлинность, если получатель ничего не знает о/от отправителя. Получатель может, например, делиться секретным ключом с отправителем. Затем отправитель может добавить зашифрованную контрольную сумму (которая должна быть криптографически защищена, например, md5/sha1). Также возможно использовать асимметричное шифрование, когда отправитель может публиковать свой открытый ключ и подписывать контрольную сумму/хэш md5 своим личным ключом. Хэш и подпись могут быть помечены на данные как новый тип контрольной суммы. Это делается все время в Интернете в наши дни.

Остальные проблемы тогда равны 1. Как получатель может убедиться, что у него есть правильный открытый ключ и 2. Насколько безопасен весь этот материал в действительности?. Ответ на 1 может отличаться. В Интернете это общепризнано, что открытый ключ подписывается кем-то, кому все доверяют. Еще одно простое решение состоит в том, что получатель получил открытый ключ от встречи в личном... Ответ на вопрос 2 может меняться изо дня в день, но то, что дорого стоить в день, вероятно, будет дешевым, чтобы сломать некоторое время в будущем, К тому времени, как мы надеемся, появились новые алгоритмы и/или увеличенные размеры ключей.