Во-первых, ни одному из алгоритмов CRC не присущи ничего, что могло бы помешать им работать с произвольной длиной данных (однако конкретная реализация вполне может наложить ограничение).
Тем не менее, в приложении для синхронизации файлов это, вероятно, не имеет значения, так как вы можете не захотеть хэшировать весь файл, когда он становится большим, в любом случае, просто порциями. Если вы хэшируете весь файл, и хэши на каждом конце отличаются, вам нужно скопировать весь файл. Если вы хэшируете фрагменты фиксированного размера, вам нужно только скопировать фрагменты, чей хэш изменился. Если большая часть изменений в файлах локализована (например, в базе данных), то это, вероятно, потребует гораздо меньшего копирования (и легче распределить расчеты по блокам на несколько ядер).
Что касается самого алгоритма хеширования, основной компромисс между скоростью и отсутствием коллизий (два разных блока данных дают один и тот же хеш). CRC-32 работает быстро, но только с 2 ^ 32 уникальными значениями можно увидеть столкновения. MD5 намного медленнее, но имеет 2 ^ 128 уникальных значений, поэтому столкновения почти никогда не будут видны (но все еще теоретически возможны). Большие хэши (SHA1, SHA256, ...) имеют еще более уникальные значения, но все еще медленнее: я сомневаюсь, что они вам нужны: вы беспокоитесь о случайных коллизиях, в отличие от приложений цифровой подписи, где вы беспокоитесь о намеренно ( необычно) инженерные столкновения.
Похоже, вы пытаетесь сделать что-то очень похожее на то, что делает утилита rsync. Вы можете просто использовать rsync?