Comments 8
То есть, в первом случае читаем весь файл и считаем сумму, а во втором считаем сумму от CRC-сумм JAR-архива?
И какой в этом смысл? Для чего вы считаете контрольную сумму?
Если для проверки подлинности, то что мешает подменить файл внутри jar-архива, чтоб его CRC осталась прежней? Сделать коллизию для CRC гораздо легче, чем для MD5. Вы увеличили скорость, но свели на нет надёжность.
Если для проверки подлинности, то что мешает подменить файл внутри jar-архива, чтоб его CRC осталась прежней? Сделать коллизию для CRC гораздо легче, чем для MD5. Вы увеличили скорость, но свели на нет надёжность.
«У-у-у-у брат, это же жулики!» ©
в моём случае я проверял в первую очередь размер файла и last modification.
В Вашем случае этого может и быть достаточным, но в общем случае — «Малова-то будет» © =)
Честно говоря не понял причём здесь размер файла и последняя модификация, если вы предлагаете использовать их вместо CRC, то их подменить еще легче.
В любом случае, перед тем как использовать какую-то хеш-функцию, нужно понимать для чего мы её используем. CRC годится для проверки ошибок, собственно потому она и используется в jar-архиве, т.к. она значительно быстрее всяких MD5. Для криптографии нужна необратимость и стойкость к коллизиям — этого CRC обеспечить не может, а MD5 от CRC — тем более.
В любом случае, перед тем как использовать какую-то хеш-функцию, нужно понимать для чего мы её используем. CRC годится для проверки ошибок, собственно потому она и используется в jar-архиве, т.к. она значительно быстрее всяких MD5. Для криптографии нужна необратимость и стойкость к коллизиям — этого CRC обеспечить не может, а MD5 от CRC — тем более.
Sign up to leave a comment.
Быстрый алгоритм подсчёта контрольной суммы для больших JAR файлов