= Сообщение: 417 из 1928 ========================================== RU.BINKD = От : Pavel Gulchouck 2:463/68 17 May 15 13:12:18 Кому : Mithgol the Webmaster 17 May 15 13:12:18 Тема : Документы FTSC, поддерживаемые binkd FGHI : area://RU.BINKD?msgid=2:463/68+555878e0 На : area://RU.BINKD?msgid=2:50/88+5557a2cc = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.BINKD?msgid=2:5020/4441.4441+555883a5 ============================================================================== Hi Mithgol!
16 May 15, Mithgol the Webmaster ==> Pavel Gulchouck:
PG>> Криптование.
PG>> При хендшейке любая сторона может заявить опцию CRYPT, что означает PG>> поддержку криптования сессии. Криптование включается, если обе стороны PG>> предъявили опцию CRYPT, и только при парольной сессии, и только в случае PG>> CRAM-аутентификации. Если обе стороны поддерживают криптование и заявили PG>> об этом в хендшейке, но сессия непарольная, либо пароль был передан в PG>> открытом виде, криптование не включается. Если же обе стороны передали PG>> CRYPT, пароль проверен, и не был передан открытым текстом, весь трафик PG>> после сообщений M_PWD и M_OK криптуется алгоритмом InfoZIP. Этот алгоритм PG>> представляет собой xor потока псевдослучайной последовательностью байт (на PG>> основе CRC32, т.е. полиномиальной), начальное состояние которой в binkd PG>> инициализируется паролем на сессию (с небольшой модификацией для звонящей PG>> и отвечающей стороны, чтобы эти последовательности не были одинаковыми). PG>> Конкретную реализацию проще посмотреть в исходниках infozip или binkd, чем PG>> пересказывать:
MtW> Ясно; но ясно не всё: насколько я понимаю, CRC32 ── это же хэш для коррекции MtW> ошибок, он не имеет достаточной криптографической устойчивости, то есть его MtW> довольно просто подделать. И о том есть вот такая обзорная статья, например:
MtW> Зачем тогда он в роли крипто? Кто-то в своё время не подумал ── так, что ли?
CRC32, конечно, совершенно не годится в качестве защиты целостности - действительно, совсем нетрудно создать другой текст с той же контрольной суммой. В конце концов, при любом алгоритме 32 бит недостаточно для исключения коллизий (тем более, преднамеренных). Но в данном случае такая задача и не стоит. А стоит задача получения непрогнозируемой псевдослучайной цепочки байт. Состояние этой цепочки определяется тремя 32-битными ключами (т.е. 96 бит). Возможность получения целенаправленных коллизий CRC32 не даёт возможности вскрыть это криптование, хотя бы потому что собственно CRC32 здесь нигде не передаётся и не проверяется, оно участвует лишь в алгоритме генерации этой последовательности.
Я, когда реализовывал криптование в binkd, исходил из следующих соображений. 1. Криптография не является моей специализацией, но даже для специалистов применение готовых и распространённых (а значит, проверенных) алгоритмов криптования надёжнее, чем кустарная реализация собственного. Даже несмотря на то, что в распространённых алгоритмах и их реализациях время от времени находят уязвимости. 2. Ощутимо проще для реализации в протоколе binkp оказываются алгоритмы, не изменяющие размер шифруемой информации. 3. Реализация должна быть мультиплатформенной (по этой причине, например, использование системного SSL не очень подходит). 4. Военная криптостойкость не обязательна - никто не будет в здравом уме использовать фидошную технологию (с паролями на сессию и т.п.) для передачи действительно секретной информации (к тому же, без обёртки в ipsec/vpn или что-то подобное и без предварительного криптования самих передаваемых данных). 5. Криптование должно вызывать минимальные сложности для сисопов. В идеале - оно должно включаться, если оба мейлера его поддерживают, без каких-либо дополнительных действий сисопов, не приводить к дополнительным затратам ресурсов и не требовать дополнительные зависимости. 6. Не должно быть сложностей с лицензией на включение алгоритма криптования в binkd.
По перечисленным критериям был выбран алгоритм InfoZIP. Я не знаю его криптостойкость по нынешним временам, не очень удивлюсь, если он нетрудно вскрывается, но вряд ли за всю историю была хотя бы одна попытка вскрытия перехваченной по сети криптованой binkp-сессии. То есть, считаю, что свою задачу защиты от утечки информации из любопытства или по случайности простым просмотром tcpdump он выполняет. В частности, защищает от открытой передачи паролей, прописанных в заголовках передаваемых PKT или в запросах к areafix. А большего от него ожидать и не нужно.
В разрабатываемой ныне версии 1.1 реализован вариант работы через пайп - это может быть, например, связь over ssh. В частности, на моём узле 2:463/68 этот вариант поддерживается, желающие установить линк через ssh - пишите, обменяемся ключами и настроим линк (несколько таких линков уже работает). В таком варианте с криптостойкостью точно всё хорошо.
Lucky carrier, Паша aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5 * Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
