Vlákno názorů k článku
Jak zrychlit ssh od karlik - Mě by spíš zajímalo, kdy vrátí možnost nastavení...

Mě by spíš zajímalo, kdy vrátí možnost nastavení úrovně ssh komprese tak, jak to bylo u ssh1.
Pro úroveň 1-2 by to přineslo znatelné zrychlení přenosu dat oproti současné pevné volbě 6.
Odebrání šifrování arcfour, které jsem používal pro místní zálohování, rychlosti taky napřidalo.
Taky by mne zajímalo, jestli už je defaultně integrovaný HPN-SSH patch.
V odkazovaném článku byla volba UseDNS no dříve defaultní a po změně na "yes" si řada uživatelů začala stěžovat na pomalé připojení, snad to zase vrátí zpět.

arcfour jsem pouzival taky, po tom, co ji odebrali, jsem ji nahradil blowfish-cbc.

chacha20-poly1305

Meh. Je možný, že tvůj use case to rozbíjí, ale uvědom si, že podporování takovýho bordelu jako je RC4 znamená zhoršení auditovatelnosti kriticky důležitýho SW pro všechny. Nehledě na to, že v SW, který má být bezpečný nemá slabá šifra z principu co dělat.
Slabý šifry mají zmizet do propadliště dějin a ty si trhni nohou.
https://xkcd.com/1172/

Můžu se zeptat v čem konkrétně v rozumně navrženém softu zhorší auditovatelnost podpora další (byť slabé) stream šifry? Napadají mě dvě místa:
- Implementace samotné šifry - těch (doslova) pár desítek řádek nepředstavuje nějak velký problém, zejména když to porovnám s korektní implementací eliptickych křivek.
- Kontrola inicializace, že dokud se nevyskytne v configu parametr typu "IReallyKnowWha­tImDoing", tak se rc4 nedostane do tabulky/sezna­mu/kýhovýra podporovaných šifer taky není zase taková překážka.

O tom že v ideálním světě kde jsou všechna zařízení pod supportem, výrobce jim dodává bezpečnostní aktualizace po celou dobu životnosti HW atd. je třeba slabé šifry vyházet co nejrychleji žádná. Ale třeba zdravotnické nebo průmyslové přístroje, nověji třeba IoT nám dokazují že v ideálním světě rozhodně nejsme a občas je nějaký ústupek potřeba.

V průmyslu, či zdravotnictví to SSH neměl co updatovat. Tam se na nic nemá šahat dokud neověřím, že to funguje. Krom toho existují virtuální počítače... Druhá možnost je, že ten, kdo chce mít možnost komunikovat se zařízením po dávno prolomené šifře, nechť má možnost používat SW zbuildovaný proti nějakému openssl-old. (takový SW nechť je jasně označen a umístěn tak, aby si ho nikdo nestáhl omylem, a rozhodně se nesmí nikde instalovat defaultně) Zbytek světa nechť jede na openssl-safe, což bude milá knihovna, která se bude vyznačovat jediným rozdílem oproti openssl-old. A to tím rozdílem, že bude mít o PÁR SET TISÍC řádků kódu
méně. (!!!)

Auditovatelnost OpenSSL se zvýší tím, že naprostou většinu kódu (90%) sioučasného OpenSSL označíme jako "NEAUDITOVAT", protože už není relevantní, přesuneme ho někam daleko od normálního kódu Openssl-safe, a bude od něj pokoj. Tím pádem každý další audit všechen ten nezajímavý kód bude moct přeskočit, což se teď neděje.

OpenSSL má půl milionu řádků kódu, z toho na zpracování TLS se podílí 70000. Amazonu na základní podporu TLS stačilo 6000 řádků kódu, a je otázka, zda vadí, že něco z TLS případně nepodporují.

https://www.theregister.co.uk/2015/07/01/amazon_s2n_tls_library/

Teď jsem si uvědomil, že jsem vlastně neodpověděl na vaši otázku. Podle mě by IT svět měl být nastavený tak, že v kryptografii se staré věci z principu nepodporují. Tím bychom řekli, že OpenSSL, či její náhrada nemusejí umět všechno, ale stačí, aby uměly jen to, co je state-of-the-art. Což jednak vytvoří příležitost většinu openssl zahodit (protože se tím najednou bude dát něco získat), a druhak případně vytvoří možnost ji nahradit něčím jiným, protože i v openssh to bude znamenat mnojhem menší úpravy