Nachweisen dass bei RSA eine zu hohe Bit Verschlüsselung zu lange zum verbinden braucht
Hallo zusammen,
ich habe schon einige Male gelesen, dass eine zu starke RSA Bit Verschlüsselung zu lange braucht, um sich zu verbinden.
Deshalb habe ich eben folgendes probiert:
Mit Puttygen ein RSA SSH2 Key generiert mit 10906 Bit.
Hat deutlich länger gebraucht wie mit 2048 oder 4096 Bit. Soweit so gut.
Nun habe ich den Pubkey auf dem Testserver Debian 9 abgelegt und mich mit Putty und dem Privatekey verbunden.
Ich habe nun erwartet, dass die Verbindung deutlich länger benötigen wird, da es ja nun mit 10906 Bit ist.
Wo liegt mein Verständnis Fehler?
Bitte um aufklärung.
Lg und danke : )
ich habe schon einige Male gelesen, dass eine zu starke RSA Bit Verschlüsselung zu lange braucht, um sich zu verbinden.
Deshalb habe ich eben folgendes probiert:
Mit Puttygen ein RSA SSH2 Key generiert mit 10906 Bit.
Hat deutlich länger gebraucht wie mit 2048 oder 4096 Bit. Soweit so gut.
Nun habe ich den Pubkey auf dem Testserver Debian 9 abgelegt und mich mit Putty und dem Privatekey verbunden.
Ich habe nun erwartet, dass die Verbindung deutlich länger benötigen wird, da es ja nun mit 10906 Bit ist.
Wo liegt mein Verständnis Fehler?
Bitte um aufklärung.
Lg und danke : )
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 345531
Url: https://administrator.de/forum/nachweisen-dass-bei-rsa-eine-zu-hohe-bit-verschluesselung-zu-lange-zum-verbinden-braucht-345531.html
Ausgedruckt am: 18.05.2025 um 17:05 Uhr
3 Kommentare
Neuester Kommentar
Zitat von @WinLiCLI:
ich habe schon einige Male gelesen, dass eine zu starke RSA Bit Verschlüsselung zu lange braucht, um sich zu verbinden.
ich habe schon einige Male gelesen, dass eine zu starke RSA Bit Verschlüsselung zu lange braucht, um sich zu verbinden.
Das Wort was du suchst heißt "Schlüssellänge"
Nun habe ich den Pubkey auf dem Testserver Debian 9 abgelegt und mich mit Putty und dem Privatekey verbunden.
Ich habe nun erwartet, dass die Verbindung deutlich länger benötigen wird, da es ja nun mit 10906 Bit ist.
Ich habe nun erwartet, dass die Verbindung deutlich länger benötigen wird, da es ja nun mit 10906 Bit ist.
Und was ist passiert? Hat es nicht länger gebraucht?
Aber grundsätzlich: Je länger der Schlüssel ist, desto mehr CPU-Cycles werden beim Client benötigt um sich zu verbinden.
Dieser muss eine vom Server gestellte Nachricht ("Challenge") mit seinem Private Key signieren und an den Server zurücksenden.
Dieser prüft nun die Signatur der Nachricht gegen den ihm bekannten Public-Key. Wenn die Signatur passt wird damit bewiesen, dass sich der Client im Besitz des Private Key befindet ohne ihn übertragen zu müssen.
Da normalerweise nicht der Challenge selbst sondern nur ein Hash davon signiert wird, ist eine Prüfung ob die Signatur gültig ist deutlich schneller als das eigentliche Signieren selbst.
Oder anders gesagt: Wenn du mehrere Clients hast welche den selben privaten Schlüssel verwenden, aber unterschiedlich starke CPUs haben, wird die Geschwindigkeit der Authentifizierung in erster Linie von der Geschwindigkeit eben dieser CPU begrenzt.
Je nach CPU kann es sein, dass du überhaupt keinen Unterschied zwischen den Schlüssellängen spürst.
Zitat von @LordGurke:
Das Wort was du suchst heißt "Schlüssellänge"
Und was ist passiert? Hat es nicht länger gebraucht?
Aber grundsätzlich: Je länger der Schlüssel ist, desto mehr CPU-Cycles werden beim Client benötigt um sich zu verbinden.
Dieser muss eine vom Server gestellte Nachricht ("Challenge") mit seinem Private Key signieren und an den Server zurücksenden.
Dieser prüft nun die Signatur der Nachricht gegen den ihm bekannten Public-Key. Wenn die Signatur passt wird damit bewiesen, dass sich der Client im Besitz des Private Key befindet ohne ihn übertragen zu müssen.
Da normalerweise nicht der Challenge selbst sondern nur ein Hash davon signiert wird, ist eine Prüfung ob die Signatur gültig ist deutlich schneller als das eigentliche Signieren selbst.
Oder anders gesagt: Wenn du mehrere Clients hast welche den selben privaten Schlüssel verwenden, aber unterschiedlich starke CPUs haben, wird die Geschwindigkeit der Authentifizierung in erster Linie von der Geschwindigkeit eben dieser CPU begrenzt.
Je nach CPU kann es sein, dass du überhaupt keinen Unterschied zwischen den Schlüssellängen spürst.
Zitat von @WinLiCLI:
ich habe schon einige Male gelesen, dass eine zu starke RSA Bit Verschlüsselung zu lange braucht, um sich zu verbinden.
ich habe schon einige Male gelesen, dass eine zu starke RSA Bit Verschlüsselung zu lange braucht, um sich zu verbinden.
Das Wort was du suchst heißt "Schlüssellänge"
Nun habe ich den Pubkey auf dem Testserver Debian 9 abgelegt und mich mit Putty und dem Privatekey verbunden.
Ich habe nun erwartet, dass die Verbindung deutlich länger benötigen wird, da es ja nun mit 10906 Bit ist.
Ich habe nun erwartet, dass die Verbindung deutlich länger benötigen wird, da es ja nun mit 10906 Bit ist.
Und was ist passiert? Hat es nicht länger gebraucht?
Aber grundsätzlich: Je länger der Schlüssel ist, desto mehr CPU-Cycles werden beim Client benötigt um sich zu verbinden.
Dieser muss eine vom Server gestellte Nachricht ("Challenge") mit seinem Private Key signieren und an den Server zurücksenden.
Dieser prüft nun die Signatur der Nachricht gegen den ihm bekannten Public-Key. Wenn die Signatur passt wird damit bewiesen, dass sich der Client im Besitz des Private Key befindet ohne ihn übertragen zu müssen.
Da normalerweise nicht der Challenge selbst sondern nur ein Hash davon signiert wird, ist eine Prüfung ob die Signatur gültig ist deutlich schneller als das eigentliche Signieren selbst.
Oder anders gesagt: Wenn du mehrere Clients hast welche den selben privaten Schlüssel verwenden, aber unterschiedlich starke CPUs haben, wird die Geschwindigkeit der Authentifizierung in erster Linie von der Geschwindigkeit eben dieser CPU begrenzt.
Je nach CPU kann es sein, dass du überhaupt keinen Unterschied zwischen den Schlüssellängen spürst.
Normalerweise nutzt man die asymmetrische Verschlüsselung nur, um die nachfolgende symmetrische auszuhandeln.
Zumindest kenne ich es so.
Bei meinem VPN findet die Negotiation auf 2048 Bit asymmetrisch statt und danach geht es mit AES 256 bit symmetrisch weiter.