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 : )
Please also mark the comments that contributed to the solution of the article
Content-Key: 345531
Url: https://administrator.de/contentid/345531
Printed on: April 23, 2024 at 11:04 o'clock
3 Comments
Latest comment
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.