= Сообщение: 422 из 1927 ========================================== RU.BINKD = От : Pavel Gulchouck 2:463/68 17 May 15 23:29:32 Кому : Yuri Myakotin 17 May 15 23:29:32 Тема : Документы FTSC, поддерживаемые binkd FGHI : area://RU.BINKD?msgid=2:463/68+5559007c На : area://RU.BINKD?msgid=2:5020/4441.4441+5558f5ca = Кодировка сообщения определена как: CP866 ================================== ============================================================================== Hi Yuri!
17 May 15, Yuri Myakotin ==> Pavel Gulchouck:
PG>> Мы говорим о предположении, что использованный алгоритм (широко PG>> применяемый в разных версиях архиватора zip, в т.ч. в pkzip) не PG>> является криптостойким, основываясь только на увиденном слове "crc", PG>> или есть какие-то конкретные данные о его слабости или уязвимости?
YM> из faq инфозипа: YM> [cut] YM> Finally, note that the original encryption scheme used in all versions of Zip (as well as PKWARE's older products) is YM> quite weak; see "A Known-Plaintext Attack on the PKZIP Stream Cipher" (also as gzip'd PostScript) by Eli Biham and Paul C. YM> Kocher. Recent versions of PKZIP and WinZip include stronger AES encryption, and PGP/GnuPG have provided strong encryption YM> for many years. YM> [cut]
Спасибо, понятно. Посмотрел чуть подробнее - да, в 2002 обнаружилось, что известные слова в криптопотоке помогают существенно оптимизировать брутфорс и во многих случаях сузить перебор до реального. Что ж - плохо для алгоритма криптования, но (повторюсь) на мой взгляд не смертельно для тех задач, которые выполняет криптование в binkp. Попутно замечу, что CRC32, на который тут среагировали, к этой слабости криптования Info-Zip практически никакого отношения не имеет, хотя бы потому что о возможности преднамеренного создания коллизий CRC32 было известно намного раньше.
PG>> Ну и, кроме того, сейчас слова о том, что стоило бы делать 15 лет PG>> назад, не выглядят конструктивно. :) В частности:
YM> ihmo изначально стоило бы добавить флаги поддерживаемых алгоритмов, дабы можно было добавлять новые без потери YM> совместимости.
Разные варианты криптования можно заявлять разными флагами, примерно как разным вариантам компрессии соответствуют разные флаги (GZIP, BZIP2).
YM>>> Потоковый шифр типа того же ChaCha20 для этого просто идеален. И YM>>> крайне нересурсоемок.
PG>> https://ru.wikipedia.org/wiki/Salsa20: "ChaCha20 описан в RFC 7539 PG>> (май 2015)". Не очень своевременный совет для выбора алгоритма PG>> криптования для binkp в 2001-м году. :-D
YM> Hу, я просто привел пример хорошего потокового шифра, который сам сейчас активно использую в кое-каких своих проектах.
Да, спасибо. Ничто не мешает сделать флаг ChaCha20.
Тут есть некоторая проблема в том, что алгоритмы и реализации криптования постоянно развиваются. Чтобы не отказываться от мультиплатформенности и слабых зависимостей от сторонних библиотек, нужно встраивать криптование в исходники самого binkd. Но в таком случае при обнаружении уязвимости недостаточно будет проапдейтить библиотеку - нужно вносить изменения в исходный код binkd, пересобирать его и обновлять. Учитывая, насколько "активно" сисопы обновляют binkd, мы рискуем получить ситуацию, когда из-за обнаруженной уязвимости в реализации алгоритма шифрования мы получим множество работающих уязвимых binkd. А такая ситуация вполне вероятна хотя бы потому что на поиск уязвимостей в распространённых библиотеках тратится намного больше усилий, чем на их поиск, например, в коде самого binkd. Практически все распространённые алгоритмы шифрования 15-летней давности или их реализации на сегодняшний день объявлены слабыми или уязвимыми.
Линковка со сторонней библиотекой, которую можно было бы апдейтить отдельно от binkd, проблематична для кроссплатформенности.
Остаётся криптование запуском внешней утилиты. Это и реализовано в (пока не выпущенном) binkd 1.1 - проведение сессии не по сети, а через stdin/stdout запускаемой с указанными параметрами внешней программы (например, ssh или netcat).
PG>> Если же ты говоришь о том, что этот (или ещё какой) алгоритм имеет PG>> смысл добавить в binkp сейчас - соглашусь, но вряд ли буду этим PG>> заниматься, я больше надежд в этом направлении возлагаю на вариант PG>> работы over ssh.
YM> Тоже неплохо, особенно последние версии, использующие Curve25519 обмен ключами и тот же чача20 собственно для шифрования.
Чача - это хорошо. :)
Lucky carrier, Паша aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5 * Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
