» ICEECC, QuickPAR, MultiPAR, RSC32 и другие

Цитата:

Если данные лежат в облаке и злоумышленик имеет к ним доступ, то ему ничего не стоит подменить их и перепаковать с новыми хешами (тем же blacke2).

1) можно оставить копию таб себе
2) можно поставить на таб пароль - фича есть в проге
3) можно шифрануть таб по RSA - фича есть в проге
4) можно подписать таб эклиптикой или RSA через PGP

persicum
Да, п.1 действительно имеет смысл, достаточно хранить у себя только криптографически-сильные хеши (*.FHash.RSC32) сохраняемых в облаке файлов, чтоб всегда можно было удостовериться в их аутентичности.
А вот пп.2,3,4 особого смысла использованию криптографического хеша в качестве контрольных сумм по-моему не добавляют. Подпись или шифрование защитит одинаково архив что с crc, что с blake. Если же сломают пароль, ключ или подпись - то перепаковать и перезашифровать/переподписать эти поддельные/поврежденные данные с пересчитаными blake-хешами проблемы уже не составит.

Кстати, насколько я понял на VHash этот параметр не влияет, и указанный алгоритм используется только в FHash?

Если crc - достаточно подделать файл, таб не трогать.
Если блейк - файл подделать нельзя, только пересчитать таб.

Пока не вижу смысла защищать vhash - хеши блоки. Если их подделать или испортить - результат один - ничего лечиться не будет.

Кстати, немного смущает название самой опции -sha3. Ведь для SHA-3 выбрали алгоритм keccak, а blake был финалистом, но не победил. Как бы в будущем не возникло путаницы и нестыковки с другими програмами, в которых под опцию sha3 реализуют уже keccak.

Цитата:

Было бы еще круто намутить чтобы он выдавал как-нибудь, типа найдены ли ошибки или нет. А то многие ругаются что ГУЕв не хватает, они может и хороши, но часто батники рулят 8-)

Батник сделал. Там все просто - все параметры в %%а и все. Только он текущие файлы не берет, только дирки и поддирки. Если нужно и текущие - сделать дирку и файлы туда.

Что касается чекинга всех файлов через батник - может посмотреть выдачу и поискать там слово ERRORs? Пока больше ничего придумать не могу.

Добавлено:

Цитата:

Кстати, немного смущает название самой опции -sha3. Ведь для SHA-3 выбрали алгоритм keccak, а blake был финалистом, но не победил. Как бы в будущем не возникло путаницы и нестыковки с другими програмами, в которых под опцию sha3 реализуют уже keccak.

Это чтобы ниочем не думать, так как система параметров ключей слитная. Если бы я назвал -blake2s16, тогда нужно было бы смотреть все другие ключи на -b, что они делают.

А так, слово sha3 встречается только в ключе, но нигде в выдаче - там написано какой блейк и какой длины. Кеччаков тоже много разных с кучей параметров.

Persicum


Цитата:

Батник сделал. Там все просто - все параметры в %%а и все.

О, отлично! С параметрами все понятно, разберемся, тока где он, батник? Забыл наверное перезалить


Цитата:

Что касается чекинга всех файлов через батник - может посмотреть выдачу и поискать там слово ERRORs? Пока больше ничего придумать не могу.

Ладна, пока и так сойдет
Когда будешь перезаливать, подшей туда и этот батник чекинга, чтобы народ не потерял его, удобно же!
Блейк норм штука, может на него перейду, мой камень имеет все эти инструкции, которые должны давать прирост скорости для этого Блейка))

Цитата:

Кстати, немного смущает название самой опции -sha3.

Согласен, в новой версии ключ sha3 убрал, будет 4 других ключа - b2s1 b2s2 b2p1 b2p2

турбопаскальная зомбопрога RSC32 обновилась до версии 3.07

что нового?
1) Реализован хеш нового поколения - блейк2.
Нет ли высокопарности в этой фразе?

Проведем замеры скорости на данных 1G, расположенных в памяти:

RHash - sha2-256 - 8 сек;
RSC32 - sha2-256 - 10 сек (отстает Ж( турбопаскаль сливает вижуалстудии);

RHash - sha3-256 - 35 сек (пипец, неужели это после всех оптимизаций?)

RSC32 - blake2s - 4 сек (уровень SSSE3);
b2sum - blake2s - 3 сек (уровень SSE4.1)
RSC32 - blake2sp - 2 сек.

Итого, SHA3 финалист blake2sp за 2 сек сделал то, на что Кеччачу потребовалось 35 сек.

2) В меню Фара и в батниках установлен blake2sp с выходом 128 бит.
При возникновении траблов нужно проанализировать оптимальное число нитей ключом -b2t и задать его ключом -tnb. Есть пока неподтвержденное подозрение, что на дутых гипертредовых псевдоядрах реализация зависнет и финишь. Если такое вдруг произойдет, укажите желаемое число ядер ключом -tnb. У кого есть i7 с 4-мя ядрами и 8-ю тредами, интересно было бы взглянуть на результат выполнения ключа -b2t

3) Изменен алгоритм хеширования пароля, если таковой ставится на таблицы (например, от вирусов и врагов). Вместо единократного CRC теперь стоит 100000 раз SHA256. Брутфорсерам мало не покажется. Плюс еще 24 байта соли.

Разумеется, старые пароли теперь будут отвергаться, но на совместимость нам плявать, верно?

4) По просьбе радиослушателей добавлено еще некоторых батников для штучной обработки файлов или директорий. Эти батники также включены в меню ФАР.

5) множественные мелкие улучшения, как то вывод названия алгоритма при просмотре таблиц и тд

Да, blake2 крут. Быстрей и md5 и sha1. Как я понял, 128 бит от 256 в rsc32 по скорости ничем не отличаются?

Для статистики, на моем i5-2450p:
[more]
Код:
PS Z:\> Measure-Command { z:\RSC32.exe -ya -wt -bntest -b2s1 1gb_file }
TotalMilliseconds : 4014,4973

PS Z:\> Measure-Command { z:\RSC32.exe -ya -wt -bntest -b2s2 1gb_file }
TotalMilliseconds : 4011,4766

PS Z:\> Measure-Command { z:\RSC32.exe -ya -wt -bntest -b2p1 1gb_file }
TotalMilliseconds : 2182,3162

PS Z:\> Measure-Command { z:\RSC32.exe -ya -wt -bntest -b2p2 1gb_file }
TotalMilliseconds : 2188,4901

PS Z:\> Measure-Command { b2sum -a blake2s 1gb_file }
TotalMilliseconds : 2261,6387

PS Z:\> Measure-Command { b2sum -a blake2b 1gb_file }
TotalMilliseconds : 1797,8279

PS Z:\> Measure-Command { b2sum -a blake2sp 1gb_file }
TotalMilliseconds : 976,5413

PS Z:\> Measure-Command { b2sum -a blake2bp 1gb_file }
TotalMilliseconds : 759,4719

Ajaja

А перезалить ваши сборки b2sum x64 и x32 можете? А то с их сайта бинарь вылетает на b2sp.

Жалко, что моя прога конкретно сливает в два раза -((. Но для чтения с HDD это не будет заметно. может, переделаю когданить на SSE4.1

А 32-бит версия b2sum такая же быстрая на x64?


Цитата:

128 бит от 256 в rsc32 по скорости ничем не отличаются

Алгоритм один, просто берется 128 бит результата чтоб глаза не мозолили.

persicum

Цитата:

А перезалить b2sum можете?

http://rghost.ru/51400543
Это x64. Но, повторюсь, собирал для своего компа c -march=native. На процессорах старей Sandy Bridge может не пойти.

Собрал без привязки к архитектуре, 32 и 64 бита, референсный код, без SSE/AVX и пр., должен работать на всех процессорах (но медленно):
http://rghost.ru/51402046

persicum

Цитата:

Алгоритм один, просто берется 128 бит результата чтоб глаза не мозолили.

Берется как-то по хитрому? Читая описание на сайте рзработчика ("produces digests of any size between 1 and 32 bytes") думал, что можно просто половину цифр выкинуть. Но в RSC32 цифры у 128-битного и 256-битного хеша получаются совершенно разные.

Цитата:

думал, что можно просто половину цифр выкинуть

Так и есть, ненужные цифры просто выкидываются и все. Плюс маленький секретик.
Сначала интересно спросить, зачем разрабы сделали так, чтобы маленькие хеша отличались от первых цифр полного? Это хорошо или плохо? Чем грозило бы, если бы не отличались?

Добавлено:
Проверил на 32-бит Win. Отставание RSC32 от b2sum поменьше, раза в 1.5 изза sse4.1 -)):

3969 ms : rsc32 -b2s2 f_1g
2610 ms : b2sum -a blake2s f_1g

Цитата:

RHash - sha3-256 - 35 сек (пипец, неужели это после всех оптимизаций?)

Я так понял, что keccak плохо оптимизирован под 32 бита. У меня получился такой результат:

Код:
PS Z:\> Measure-Command { .\sha3sum64.exe 1gb_file }
TotalMilliseconds : 6652,1269

PS Z:\> Measure-Command { .\sha3sum32.exe 1gb_file }
TotalMilliseconds : 23686,0954

PS Z:\> Measure-Command { .\rhash64.exe --sha3-256 .\1gb_file }
TotalMilliseconds : 9722,8049

PS Z:\> Measure-Command { .\rhash32.exe --sha3-256 .\1gb_file }
TotalMilliseconds : 22082,8374

RSC32 обновилась до версии 3.08

What's new:
1) блейк2 переписан на SSE4.1, что дало 30-40% процентов прироста быстродействия:

Было:
rsc32 -b2t -offsse41
blake2s 1 thread(s) took: 5515 ms
blake2sp 1 thread(s) took: 5844 ms
blake2sp 2 thread(s) took: 4078 ms
blake2sp 3 thread(s) took: 3766 ms
blake2sp 4 thread(s) took: 3265 ms

Стало:
rsc32 -b2t
blake2s 1 thread(s) took: 3938 ms
blake2sp 1 thread(s) took: 4234 ms
blake2sp 2 thread(s) took: 3032 ms
blake2sp 3 thread(s) took: 2843 ms
blake2sp 4 thread(s) took: 2547 ms

Отставание от b2sum, конечно, остается, но теперь не такое позорное на 32-бит архитектуре:

5782 ms : RSC32.exe -b2s2 -offsse2 file_1g
4187 ms : RSC32.exe -b2s2 -offssse3 file_1g
3907 ms : RSC32.exe -b2s2 -offsse41 file_1g
2907 ms : RSC32.exe -b2s2 file_1g
2641 ms : b2sum -a blake2s file_1g

В версии RSC32 3.11 исправлены конфликты между нитями b2sp на двухядерных машинах

Подскажите, когда программа выдаёт

Recovery is NOT possible... ;(

существует ли возможность сделать частичное восстановление файлов?

Возможности частичного восстановления нет - или все, или ничего. Причем это не недостаток, а фича. Блоков то много - обычно 200000 или 500000. Тогда 3% уже дают 15000 блоков коррекции, то есть способность исправить 15000 любых дыр.
Ну а 10% - 50000 тысяч дыр. Это заведомо превосходит все разумные потребности. Если файл потерялся на флешке - снять образ и приобщить к делу - данные найдутся.

1) можно попробовать с ключом -dv - глубокий долгий поиск томов
2) нужно убедиться, что это не ошибка и не недоразумение, томов действительно не хватает.

можно посмотреть на лог, если вопрос не праздный

Беда.. -((

Из четырех блейков в rsc32 один реализован НЕ правильно, а именно b2p1 - он же главнейший по умолчанию. Сказывается новизна блейков и отсутствие тестовых примеров для некоторых случаев. Будет пофикшено в 3.12

Обновление 3.12, изменен алгоритм расчета блейк2sp-128, надеюсь, что в последний раз -))

Обновление RSC32 v3.14.

Что нового?
1) Наконец появился INI-файл, где можно прописать пути для временных файлов и некоторые параметры.

persicum
Что нового в v3.15?

1) отменен бредовый приоритет хэшей, который я зачем-то сделал. Теперь какой ключ стоит последним, то и вычисляется.

2) алгоритм усиления паролей был дополнен алгоритмом удлинения, хотя имхо это один хрен. Изучать и следовать букве kdf2 было лень, наворотил своего - мало не покажется -))

3) в блейк2sp поменялась нагрузка на ядра, чтобы главный поток содержал не меньше задач, чем фоновые ядра. Так разумнее. Например, было 2 3 3, а стало 3 3 2. Когда главный поток заканчивает, остальные нити уже отсрелялись.


Короче - мелкие улучшения, не считая несовместимости паролей -))

Обновление RSC32 v3.16

Что нового?
1) ключи -s и -se для сортировки файлов по именам и расширениям;
2) поиск дубликатов -d теперь сканирует файлы, имеющие равный размер, а остальные игнорирует

2ALL

А вот контрольная сумма ДЛЯ ПАПКИ С ПОДПАПКАМИ (не файла) - чем её можно сделать ? Для бэкапов на винтах надо (от вирей, от порчи винтов, от искажений инфы рэками и прочими usb-интерфейсами..

Нашлась темка для макось - Контрольная сумма md5
но нужна софтинка под винду, которой буду постоянно пользоваться, желательно чтоб выдавала подробный отчётец - например md5 каждого файла с путём к нему и общую контрольную сумму на папку и подпапки + возможность быстро найти испортившийся (изменившийся) файл или изменившееся название папки. И поддержка размеров папки с подпапками - до 0.5Tb желательна, длинных русских имён файлов обязательна.

Смысл приписывать контрольную сумму папкам не очень понятен. Почему нельзя запомнить просто суммы для каждого файла, а в конце выдать список всех изменившихся файлов?

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

Рекурсивно считает хэш RHash, если разберетесь с его ключами. Прога консолевая. С русскими буквами проблем не будет, так как есть Юникод.

Моя rsc32 хорошо работает с русской страницей, но Юникода боится - если встретит ё или й как диакретику из двух наложенных символов, не говоря уже про ãåāàáâä - сразу вылетит.

Проблема, что красивые графические проги предназначены в основном для любование единичными хешами, для массированных поисков не приспособлены. Ну может ТоталКоммандер поможет? Я с ним не работал много.

Rsc32 в версии 3.16 обнаружила много наведенных ошибок, специфических только для этой версии изза неудачной правки кода, поэтому удалена, скоро выложу фикс 3.17.

RSC32 реанимирована до версии 3.17;

Что нового?
1) Пофикшены многочисленные наведенные ошибки, возникшие в версии 3.16 в результате неудачной оптимизации
2) Для потерянных файлов теперь выводится пустота либо ожидаемый размер, это вместо 0.
3) Много кода было переписано

yanko12
Можно поюзировать rsc32
1) сохранить хеши с поддиректориями
rsc32 -wt -r
2) проверить хеши
rsc32 -rt
3) обновить хеши для новых файлов
rsc32 -at -r
4) поискать и убрать дубликаты файлов
rsc32 -d -dd -r

Для адекватной работы нужен консольный менеджер файлов, то есть FAR

Persicum

А можно сделать чекинг еще и по CRC16 или какой-нибудь альтернативный, но чтобы был очень быстрый?? Понятно, что при этом он будет совсем не криптостойкий и будет гарантировать целостность файло не со 100%, но, например, часто бывает "МНОГО ГИГ" надо кинуть с одного винта на другой и БЫСТРО почекить что более-менее правильно все записалось. CRC32 то побыстрей любого блейка, но иногда хочется еще больше пожертвовать "вероятностью точности" ради скорости...

Упс... Или я что-то тупанул жестко? Сейчас померял, блейк вроде быстрее старого CRC32...

на i7-4770 скорость crc32c - 128 ГБ/с, vmac-128 - 40 ГБ/с, blake2sp - 3 ГБ/с

nightkeeper

Применительно к RSC32 алгоритмы делятся на две группы:
1) работают быстрее HDD 100mb/s - crc32, crc64, md5, sha1, b2sp
2) работают медленнее, чем читает HDD - tiger, sha256, b2s

Поэтому можно взять любой алгоритм из первой группы. Скорость будет ограничена скоростью чтения с HDD. Из них устойчив к умышленным коллизиям только b2sp. Устойчивы к прообразу, то есть к полной подделке - все кроме crc.

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

Что касается собственно переноски - ограничивается скоростью HDD, ничего нельзя сделать. Скорость самих алгоритмов 500-1000 метров/c