> Тройной DES - гуано. Во первых, он тормозной как черти-что, во вторых,
> никакой особой стойкостью не обладает. Выбор некрофила который прикипел к DES.

Его стойкость 112 бит. Не особая, но имещющаяся. То что он в разы медленнее всех остальных вместе взятых -- безусловно. Но он не insecure для своих 112 бит.

> Arcfour в чистом виде имеет уйму дурных проблем. Самая жестокая - утечка
> ключевого материала в первых примерно 256 байтах вывода его PRNG. Поэтому
> уважающие себя реализации обычно отбрасывают первые 768...1024 байта.

Как говорит стандарт для SSH-а 1536 байт надо откинуть. Речь как-раз про то что его нужно прявильно применять, а не в чистом виде.

> Если этого не  делать - прецеденты взлома имеются.

Ещё какие!

>  Далее arcfour имеет статистические отклонения от
> настоящей случайности, что намекает что его случайность не совсем случайная.

Имеет в первых выхлопах шифра.

> остро нуждается в дополнительных схемах костылирования, ибо если просто юзать вывод
> PRNG от одного и того же ключа на нескольких разных шифротекстах,
> атакующий знающий некий известный текст - узнает часть последовательности.

В целом это всё касается любых потоковых алгоритмов шифрования. Об этом и речь: их надо правильно применять, ибо любая ошибка и цена за неё куда выше (полная дешифрация текста запросто) чем в блочных шифрах.

> В целом специфичный алгоритм, которым лучше бы не пользоваться.

Лучше не пользоваться если не сможешь правильно реализовать. Полностью согласен. Поэтому от греха подальше всегда и везде говорят что лучше его выпилить и забыть. Но конкретно OpenSSH реализация вполне себе годная и грамотная к использованию. И если нет аппаратного ускорения AES/GCM, нет ChaCha20, а скорости хочется, то почему бы и нет?

> Забота о экономии траффика это круто. Вот только чем экономнее траффик -
> тем лучше реконструкция активности пользователя в шелле по размерам пакетов, даже
> без расшифровки.

Ну SSH всё же не ставит задачи противодействовать traffic analysis. Увеличив размер tag-а MAC-а мы же всё-равно не сгладим утечки в канале по времени: они точно такие же детерминированные для shell-а останутся. Ну и это уже не так сильно играет для передачи файлов (scp, sftp).

> //если не сильно обосновывать, я бы вообще выпилил все кроме 25519+poly1305+salsa/chacha.

Поддерживаю! Но пока это прососётся в стандарты, RFC, тем более какие-нибудь TLS-ы кроме SSH…