Если вы пытаетесь воссоздать хэш большой полезной нагрузки (например, файл 1 ГБ), который был разбит на куски (например, размером 10 МБ), хэш (MD5, SHA-256 и т. Д.) Необходимо вычислить наВся коллекция. Таким образом, используя этот пример, вы не можете добавить 100 фрагментированных хешей для воссоздания хеша исходного файла. Однако ...
Вы можете отправить 2 значения с каждым чанком:
- хеш отдельного чанка (как вы делаете сейчас)
- промежуточный хеш укажите , поскольку ваша служба просматривает файл для создания каждой полезной нагрузки чанка: в начале и в конце чанка
По мере поступления чанков можно проверить швысостояние хеша в конце фрагмента N
соответствует состоянию хеш-функции в начале фрагмента N+1
.
Конечным состоянием хеша последнего фрагмента будет хеш для всей полезной нагрузки.
Почему это так? Поскольку хэш может быть вычислен в режиме реального времени при получении фрагментов файла, а не как отдельный процесс, занимающий много времени, после получения всех фрагментов файла.
Правка: на основе комментариев:
Вот примерное решение для состояния хеш-состояния:
Создание большого случайного файла (100 МБ):
dd if=/dev/urandom of=large.bin bs=1048576 count=100
Использование внешнего инструмента для проверки хеш-функции:
$ shasum -a 256 large.bin
4cc76e41bbd82a05f97fc03c7eb3d1f5d98f4e7e24248d7944f8caaf8dc55c5c large.bin
Запуск этого кода игровой площадки в вышеуказанном файле.
...
...
...
offset: 102760448 hash: 8ae7928735716a60ae0c4e923b8f0db8f33a5b89f6b697093ea97f003c85bb56 state: 736861032a24f8927fc4aa17527e1919aba8ea40c0407d5452c752a82a99c06149fd8d35000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006200000
offset: 103809024 hash: fbbfd2794cd944b276a04a89b49a5e2c8006ced9ff710cc044bed949fee5899f state: 73686103bdde167db6a5b09ebc69a5abce51176e635add81e190aa64edceb280f82d6c08000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006300000
offset: 104857600 hash: 4cc76e41bbd82a05f97fc03c7eb3d1f5d98f4e7e24248d7944f8caaf8dc55c5c state: 73686103c29dbc4aaaa7aa1ce65b9dfccbf0e3a18a89c95fd50c1e02ac1c73271cfdc3e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006400000
окончательного совпадения хэша.
Попытка со смещением и промежуточнымхэш-состояние. Файл будет seeked
с этим смещением, возобновляя вычисление хеша с этой точки:
$ ./hash -o 102760448 -s "736861032a24f8927fc4aa17527e1919aba8ea40c0407d5452c752a82a99c06149fd8d35000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006200000"
offset: 103809024 hash: fbbfd2794cd944b276a04a89b49a5e2c8006ced9ff710cc044bed949fee5899f state: 73686103bdde167db6a5b09ebc69a5abce51176e635add81e190aa64edceb280f82d6c08000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006300000
offset: 104857600 hash: 4cc76e41bbd82a05f97fc03c7eb3d1f5d98f4e7e24248d7944f8caaf8dc55c5c state: 73686103c29dbc4aaaa7aa1ce65b9dfccbf0e3a18a89c95fd50c1e02ac1c73271cfdc3e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006400000
мы получаем тот же окончательный хеш, что и раньше.
Примечание: это действительно показывает хешвнутреннее состояние, так что помните о последствиях безопасности , которые это может повлечь за собой. С большим размером куска это не должно быть проблемой.