Возможно меня не так поняли, но я нисколько не собирался давить на то что 3des или arcfour стоит рассматривать к применению если под рукой есть chacha20. Вне всяких сомнений chacha20/poly1305/25519 должны использоваться если имеются. То что от rc4/3des и прочего стоит избавляться (так же как и от aes) и их место на кладбище -- всеми руками за. Мой point лишь в том что допустим у человека нет достаточно современного SSH-сервера где бы эти chacha были. По мне так нельзя сказать что это вообще ни на что уже не годно: годно, но тормознуто и так далее.Обращу внимание, как автор "заметок", что в них я никаких 3des и rc4 и не встроил осознанно. aes остался, но после него сразу blowfish и больше ничего. Лучше обновлять софт, чем пытаться с этим работать. Хотя blowfish возможно тоже не стоит, ведь он работает в SSH только в CBC режиме, а многие серверы подвержены атаке когда под 32 бита plaintext-а может утечь, именно в CBC режимах.
По поводу AES и S-box-ов и вообще всего что касается поиска в таблицах и то что криптографы от этого избавляются -- бесспорно, верно, вне всяких сомнений. Если есть выбор в виде Salsa, Chacha, Threefish/whatever -- лучше сделать этот выбор. Но у меня опять же речь про тех у кого нет обновлённых SSH-серверов и они находятся в относительно доверяемом окружении: на железе которое можно потрогать, поглядеть на него, зная что посторонние к нему не подойдут (конечно же не про дата-центры речь). Банально например Wifi домашний между сервером и ноутбуком, где на сервере известно что ничего постороннего не крутится (как и на ноутбуке), а доверять Wifi шифрованию конечно же просто нельзя и приходится делать какой-нибудь канал шифрованный. Хотя... уж в домашних условиях для себя любимого SSH обновить то не сложно должно быть.
Если, как вы и говорите, мало ли где этот SSH-сервер находится/используется, то рисковать лучше конечно не надо и лучше и про AES забыть однозначно.
>А смысл в шифровании, которое не противодействует анализу трафика?
Не, я имел в виду под анализом трафика -- его статистический анализ, то бишь размеры и частота/время прохождения пакетов.
Про TLS: если это TLS канал между собственно настроенным сервером и клиентом, где вырезаны все legacy алгоритмы (хотя бы на уровне строк приоритетов GnuTLS/OpenSSL), где чётко явно задаётся как и с чем он должен работать -- не вижу ничего опасного в этом, если есть доверие к реализации. В целом, в общем случае, когда это HTTPS например с которым общаются сотни самых разных клиентов (и соответственно разное чего поддерживающих), то тут конечно речи о безопасности не будет идти. Но я согласен без сомнений что если есть чем заменить TLS, то лучше это сделать.
То что в SSH накапливается бесполезный хлам -- печально конечно. lsh вон видел что делают свой SSH2-only сервачок и действительно много выпилено. Не знаю насколько качественные там реализации, но всяких chacha/25519 там не видно. Зато приятно что сделали SRP поддержку.
