SSH/SCP - Sicherheit und Geschwindigkeit

• http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_09.htm

Stand: Mai 2011

RSA war mal durch Patente geschützt, die sind jetzt aber abgelaufen. Der ECDSA-Algorithmus stammt noch aus der Zeit und sollte eine freie Alternative zum durch Patent geschützten RSA sein.

Vor kurzem wurde der ECDSA-Algorithmus geknackt. ECDSA-Schlüssel sollte man als „veraltet“ und „unsicher“ betrachten.

Schlüsselstärkenvergleich (Brutforce-Angriff, kein Strukturangriff!):

1. 160 Bit ECDSA-Schlüssel ⇒ 1024 Bit RSA-Schlüssel
2. 224 Bit ECDSA-Schlüssel ⇒ 2048 Bit RSA-Schlüssel
3. 256 Bit ECDSA-Schlüssel ⇒ 3072 Bit RSA-Schlüssel
4. 521 Bit ECDSA-Schlüssel ⇒ 15360 Bit RSA-Schlüssel

1. da die RSA-Patente abgelaufen sind, ist RSA jetzt frei;
2. einen RSA-Schlüssel kann man mit einer beliebigen Schlüssellänge generieren;
3. Signaturen werden schneller verifiziert als erzeugt;
4. um die Sicherheit eines 1024 Bit DSA-Schlüssels zu erzielen, muss der RSA-Schlüssel ca. 1232 Bit lang sein;
5. RSA kann zum Signieren und zum Verschlüsseln verwendet werden (das tut OpenSSH aber nicht, da es aus kryptografischer Sicht ungünstig ist);

1. einen DSA-Schlüssel kann man nur mit einer maximalen Schlüssellänge von 1024 Bit generieren (das alte DSS konnte auch längere);
2. DSA hängt wohl doch sehr von guten Zufallszahlen ab, die man unter Windows wohl nicht bekommt;
3. bei der Implementierung von DSA, kann man wohl viele Fehler machen die die Sicherheit des Verfahrens stark gefährden, dem entsprechend gibt es angeblich auch viele problematische DSA-Implementierungen;
4. Signaturen werden schneller erzeugt als verifiziert;
5. DSA kann nur zum Signieren, nicht zum Verschlüsseln verwendet werden;

Auf dieser Seite wurden Transfervergleiche mit unterschiedlichen Cipher (Kodes) gefahren:

• http://blog.famzah.net/2010/06/11/openssh-ciphers-performance-benchmark/

Da die Pakete bei FTP unbearbeitet über das Netz gehen, ist es die schnellste aber auch unsicherste Methode, Daten zu übertragen. Aus diesem Grunde verwendet man heute SSH/SCP/SFTP zur verschlüsselten Datenübertragung. Hier kann man die Daten auf verschiedene Weise verschlüsseln/kodieren. Jeder von SSH unterstützte Kode hat seine besonderen Eigenschaften, deshalb ergibt sich auch ein Unterschied in der Datenübertragungsrate und der Sicherheit in Abhängigkeit vom verwendeten Kode:

1. Standard ist der Kode „3DES“, es ist der langsamste aber nicht der sicherste;
2. der schnellste ist „ARCFOUR“ (kompatibel zu „RC4“);
3. „AES“ ist langsam aber sicherer als „3DES“;
4. als einen sehr guten Kompromiss zwischen Sicherheit und Geschwindigkeit kann man den „Blowfish“-Kode ansehen;
5. die FreeBSD-Version von SSH2 beherrscht sogar den „Twofish“-Kode, ihn kann man als den sichersten Kode ansehen, von allen die SSH unterstützt;

Welche Kodes (Cipher) von der eingesetzten SSH-Version unterstützt werden, kann man sich wie folgt anzeigen lassen:

# man ssh_config

• ⇒ siehe in der Sektion Ciphers

Beispiel:

# ssh -c blowfish -X fritz@rechner
# scp -c blowfish testdatei.txt fritz@rechner:

Es ist auch möglich mehrere Kodes (Cipher) kommasepariert anzugeben:

# ssh -c blowfish,blowfish-cbc,aes256-ctr,aes192-ctr,aes128-ctr,3des,arcfour,arcfour256,arcfour128 -X fritz@rechner
# scp -c blowfish,blowfish-cbc,aes256-ctr,aes192-ctr,aes128-ctr,3des,arcfour,arcfour256,arcfour128 testdatei.txt fritz@rechner:

Man kann die bevorzugten Kodes (Cipher) auch in der Konfigurationsdatei vom SSH-Client dauerhaft eintragen und spart sich so das aufführen auf der Kommandozeile.

# vi /etc/ssh/ssh_config
....
Ciphers blowfish,blowfish-cbc,aes256-ctr,aes192-ctr,aes128-ctr,3des,arcfour,arcfour256,arcfour128
....