> Его стойкость 112 бит. Не особая, но имещющаяся.Во первых, криптографы нынче недолюбливают подобные схемы с s-box'ами.
Во вторых, любое нечто использующее таблицы - объект для тайминг атак. Любым имеющим доступ к локальной машине, даже под другим пользователем.
В третьих, каких-то особых достоинств у него просто нет. Зато есть недостаток - тормознyтый.
Ну и зачем этот окаменелый шит упоминать?
> То что он в разы медленнее всех остальных вместе взятых -- безусловно.
> Но он не insecure для своих 112 бит.
Он просто дyрной по совокупности параметров. Его место - на клaдбище космических кораблей.
> Как говорит стандарт для SSH-а 1536 байт надо откинуть. Речь как-раз про
> то что его нужно прявильно применять, а не в чистом виде.
Нужда сделать полторы тысячи итераций вхолостую кроме убивает достоинство в виде скорости в ряде применений (e.g. шифрование мелких пакетов с разными ключами). А наличие статистических отклонений - просто плохо и возможно что однажды кто-то на основе этого сможет что-то извлечь. На самом деле он симпатичен простотой и отсутствием блоков. Но, к сожалению, выявились дyрные проблемы, а простоту приходится костылировать. Из очевидных плюсов - скорость. Из минусов - кроме упомянутых еще и операции на таблице в памяти, которая источник утечек информации в сторону других процессов. В целом как-то криптографы нынче охладели к таким схемам.
А какой-нибудь salsa/chacha - быстрые, никаких операций на таблицах. Сугубо математика в регистрах. В память особо не лезет, времянки наружу не утекают даже на более-менее обычных процах. А ssh все-таки крутится на многопользовательской машине. Особенно весело на всяких виртуалках и вдсках - мало ли что там на том же физическом проце крутится...
> Имеет в первых выхлoпах шифра.
Насколько я помню, там еще проблема в том что достаточно большой выхлoп имеет отклонения от случайного.
> В целом это всё касается любых потоковых алгоритмов шифрования.
Однозначно. Просто НАДЕЖНАЯ схема получается не такой простой как казалось бы на первый взгляд.
> Лучше не пользоваться если не сможешь правильно реализовать. Полностью согласен.
Для начала я бы предпочел чтобы про arcfour забыли и если уж так сильно хочется попрыгать по этим граблям - в вике можно найти более интересных последователей, лишенных ряда проблем с утечками ключей в начальном выводе. Но в целом там своих грабель есть и я бы сильно советовать не стал.
> Но конкретно OpenSSH реализация вполне себе годная и грамотная
> к использованию.
Оно как бы да, но...
> И если нет аппаратного ускорения AES/GCM, нет ChaCha20, а
> скорости хочется, то почему бы и нет?
Например, потому что мало ли где там этот ssh юзается (VM/контейнер), а state в памяти в виде таблицы - по идее может утекать информация о ключе или состоянии алгоритма.
> Ну SSH всё же не ставит задачи противодействовать traffic analysis.
А смысл в шифровании, которое не противодействует анализу трафика? Так можно и телнетом пользоваться, если уж анализ пофиг :).
> tag-а MAC-а мы же всё-равно не сгладим утечки в канале по
> времени: они точно такие же детерминированные для shell-а останутся.
Это да - там скорее блоки по типу того что в tor надо.
> Ну и это уже не так сильно играет для передачи файлов (scp, sftp).
Файлов - да. Передачи траффика на форварде портов или впн - нет. Работа с шеллом - совсем нет.
> Поддерживаю! Но пока это прососётся в стандарты, RFC,
Всякие там NSA уж постараются чтобы этого не случилось. Чего ожидать от NIST мы уже видели на примере их нового PRNG.
> тем более какие-нибудь TLS-ы
Использовать TLS - хорошая заявка на залeт. Слишком дофига опций и легаси - он просто не может быть секурным. Я даже предсказал атаку на даyнгрейд. SSH это кстати тоже касается.
> кроме SSH…
В нем кстати на мой вкус тоже слишком дофига опций и легаси накопилось. В результате оно умет сильно больше чем ожидает админ и позволяет сильно много манипуляций со стороны атакущего.
p.s. гаццкий вордфильтр.
