Самый быстрый способ рассчитать хеш файла?

Это, конечно, вообще невозможно. Многие люди до сих пор используют для этой цели хеширование, и MD5 - популярный алгоритм, который дает вам 128-битную «подпись» для файла с высокой вероятностью изменения при изменении содержимого файла.

В общем случае вам нужно просмотреть каждый бит файла, чтобы включить его в хэш, и производительность, вероятно, будет ограничена вводом-выводом. Это последовательный просмотр всех данных в файле, обновляющий состояние любого хеш-алгоритма, который вы используете для каждого нового байта. На современном процессоре последний будет быстрее, чем первый. Этот довольно старый анализ показывает около 45 МБ / с на процессоре Pentium 90 МГц.

Если я правильно понимаю часть «используется как персональный брандмауэр Windows», MD5 - не лучший выбор в качестве алгоритма.

Существует успешная атака на алгоритм MD5, которая позволяет вам найти другое сообщение, которое производит тот же хэш с относительно небольшой работой (по сравнению с грубой силой). Эта атака привыкший не имеет реального значения, например когда MD5 использовался для хеширования паролей и т.п. Между тем, были обнаружены новые атаки, поэтому как MD5, так и SHA-1 могут хэшироваться / сталкиваться с пугающей скоростью, и взлом целых баз данных «правильно подсоленных» и одноразовых паролей пользователей с помощью этих «старых» хешей не является только полностью выполнимо, но уже было продемонстрировано. Однако в конкретном приложении "убедитесь, что этот файл не был подделан" этот вид атаки всегда был проблемой не только недавно. MD5 вполне безопасно обнаружит битовую ошибку или случайную модификацию, но вредоносная программа, пытающаяся обойти ваш личный файловый экран, может довольно тривиально обойти всю вашу безопасность, обнаружив конфликт для зараженного двоичного файла, чтобы хэш совпадал с оригиналом.

Вы должны использовать SHA-256 для этого случая [Обновлять: в то же время, SHA-3 отсутствует, и хотя я лично не согласен с выбором победителя NIST (или неясными критериями для исключения некоторых очень хороших кандидатов на второй раунд) ), это выбор намного безопаснее для использования SHA-3 (Keccak) или, альтернативно, одного из финалистов SHA-3. Все финалисты были тщательно разработаны опытными командами, были очень тщательно проанализированы, и до сих пор ни у одного из них нет реалистичной атаки или известной проблемы, которая предположительно могла бы привести к реалистичной атаке, и у всех них тоже есть «больше битов» ( что само по себе мало что значит, но больше битов не повредит)].

Кроме того, не забывайте всегда сохранять длину файла в дополнение к хешу, это значительно укрепит даже плохой хеш при незначительной цене. Если можете, рассчитайте два разных хэша. Злоумышленнику легче найти сообщение немного, которое вызывает конфликт в хэше один, чем много, чем найти сообщение, которое вызывает конфликт и имеет точно такую ​​же длину, или даже сообщение, которое сталкивается с двумя разными хэшами и имеет одинаковую длину .
Поскольку пропускная способность (как диск, так и память) является фактором, которым нельзя пренебречь при вычислении хэша, возможно даже, что вычисление одного или двух хэшей одновременно выполняется со сравнимой скоростью. Я наблюдал такой эффект при вычислении CRC и последующем шифровании тех же блоков блочным шифром. Независимо от того, был ли рассчитан CRC, разница в общем времени выполнения составила менее 1%, так что в основном это была бесплатная операция.

Если вы считаете, что у вас есть веская причина не использовать хорошо известный стандартный хеш (ограничения производительности?), Вы можете создать свой собственный безопасный хеш. Используя конструкцию Меркла-Дамгарда (или, в последнее время, HAIFA), вы можете превратить любой безопасный блочный шифр в безопасную хеш-функцию. Например, зашифруйте каждый входной блок с помощью AES, используя фиксированный ключ, и перенесите выход в следующий блок, прежде чем зашифровать и его. Результат после последнего блока - это ваше хеш-значение.

Хотя «создать свой собственный» обычно не является хорошей идеей, в этом случае действительно могут быть веские причины, поскольку AES работает быстро и поддерживается аппаратно в самых последних процессорах. На моей машине скорость AES составляет примерно 130 МБ / с. На i7 (с аппаратной поддержкой) в Интернете сообщается о 570 МБ / с.

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

Если вы проверите файлы, которые претендуют на права на брандмауэре, то это будут исполняемые файлы, которые были загружены в оперативную память (как может быть иначе, ведь они все-таки выполняются!). Таким образом, сопоставление страниц, которые уже находятся в ОЗУ, будет просто добавлением записи в таблицу страниц, более или менее бесполезной. И даже если данных нет в ОЗУ, производительность (и простота) отображения памяти просто потрясающая, я редко использую что-либо еще в наши дни, когда скорость имеет какое-либо значение.