|
|
|
|
|
|
|
| | Zitat von eupesco
zu wenig nullen ... | |
Ja, beim Copy&Paste hab' ich Idiot natürlich die Hälfte verpennt da oben, das müssen natürlich 128 Nullen sein, ich hatte es oben bereits korrigiert.
|
|
|
|
|
|
|
|
|
|
|
Kurzer Crosspost vom Erklärbärthread:
| | Zitat von 1-2-3
Kann mal jemand überprüfen, ob das folgende ein Addierschaltung für 2 4bit-Zahlen wäre?
Danke | |
|
|
|
|
|
|
|
|
|
|
|
|
Kann also auch noch dazu schrieben, dass SSL nicht nur für http da ist, sondern auch für ftp, smtp, pop etc. Die heißen dann also ftps, smtps & pops?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Andrrreas
Kann also auch noch dazu schrieben, dass SSL nicht nur für http da ist, sondern auch für ftp, smtp, pop etc. Die heißen dann also ftps, smtps & pops? | |
SSL ist nur die Verschlüsselung an sich, welche Daten über welche Protokolle da nun verschlüsselt werden ist dem Programmierer überlassen.
|
|
|
|
|
|
|
|
|
|
| | Zitat von [TSB]Schalentier
| | Zitat von eupesco
zu wenig nullen ... | |
Ja, beim Copy&Paste hab' ich Idiot natürlich die Hälfte verpennt da oben, das müssen natürlich 128 Nullen sein, ich hatte es oben bereits korrigiert. | |
Copy&Paste |= im Kopf ausrechnen :P
|
|
|
|
|
|
|
|
|
|
|
Ja genau (ist übrigens gar nicht mal so ungewöhnlich  , z.B. unterstützt GMX sogar beim kostenlosen Mailaccount POP-SSL und beim Senden auch SSL (bzw. TLS).
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
| | Zitat von Andrrreas
Kann also auch noch dazu schrieben, dass SSL nicht nur für http da ist, sondern auch für ftp, smtp, pop etc. Die heißen dann also ftps, smtps & pops? | |
SSL ist nur die Verschlüsselung an sich, welche Daten über welche Protokolle da nun verschlüsselt werden ist dem Programmierer überlassen. | |
Aber ich nehme doch mal an, dass er auch Praxisbeispiele braucht
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Andrrreas
Ähm, wie fase ich das nun in verständliche Worte?  | |
Ja, das ist halt nunmal so.
1. Der Server schickt dem Client sein Zertifikat
Das Zertifikat ist mit dem "private key" einer CA signiert. D.h. er nimmt z.B. den "public key" von Verisign, und kann damit verifizieren, daß Verisign das Zertifikat ausgestellt hat. Dann vergleicht er, ob z.B. der Name, auf den das Zertifikat ausgestellt wurde mit dem von dem erwarteten Server (also z.B. www.amazon.de) übereinstimmt.
2. Wenn der Client das Zertifikat akzeptiert hat, schnappt er sich aus dem Zertifikat den "public key" des Servers und verschlüsselt mit diesem einen willkürlichen Schlüssel, der dann verwendet wird.
Alternativ kann man auch SSL-Verbindungen ohne Zertifikate benutzen, in dem Fall wir das Diffie-Hellman-Verfahren zum anonymen Aushandeln eines Schlüssels verwendet. Optional kann auch der Client ein Zertifikat senden.
Zusammenfassend:
- auf jeden Fall wird auf eine von mehreren Möglichen Weisen ein neues Schlüsselpaar ausgehandelt, mit dem alles verschlüsselt wird
- der verwendete (symmetrische) Algorithmus wird auch ausgehandelt
- optional senden Server (in der Regel) und Client (seltener) ein Zertifikat an die andere Seite, was zur Authentifikation herangezogen werden kann, u.U. wird der "public key" hierin für die Übertragung des Session-Schlüssels verwendet
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von 1-2-3
Kann mal jemand überprüfen, ob das folgende ein Addierschaltung für 2 4bit-Zahlen wäre? | |
Ja, ist korrekt.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
| | Zitat von Andrrreas
Kann also auch noch dazu schrieben, dass SSL nicht nur für http da ist, sondern auch für ftp, smtp, pop etc. Die heißen dann also ftps, smtps & pops? | |
SSL ist nur die Verschlüsselung an sich, welche Daten über welche Protokolle da nun verschlüsselt werden ist dem Programmierer überlassen. | |
SSL ist also nicht protokollabhänig.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [TSB]Schalentier
| | Zitat von Andrrreas
Ähm, wie fase ich das nun in verständliche Worte? | |
Ja, das ist halt nunmal so.
1. Der Server schickt dem Client sein Zertifikat
Das Zertifikat ist mit dem "private key" einer CA signiert. D.h. er nimmt z.B. den "public key" von Verisign, und kann damit verifizieren, daß Verisign das Zertifikat ausgestellt hat. Dann vergleicht er, ob z.B. der Name, auf den das Zertifikat ausgestellt wurde mit dem von dem erwarteten Server (also z.B. www.amazon.de) übereinstimmt.
2. Wenn der Client das Zertifikat akzeptiert hat, schnappt er sich aus dem Zertifikat den "public key" des Servers und verschlüsselt mit diesem einen willkürlichen Schlüssel, der dann verwendet wird.
Alternativ kann man auch SSL-Verbindungen ohne Zertifikate benutzen, in dem Fall wir das Diffie-Hellman-Verfahren zum anonymen Aushandeln eines Schlüssels verwendet. Optional kann auch der Client ein Zertifikat senden.
Zusammenfassend:
- auf jeden Fall wird auf eine von mehreren Möglichen Weisen ein neues Schlüsselpaar ausgehandelt, mit dem alles verschlüsselt wird
- der verwendete (symmetrische) Algorithmus wird auch ausgehandelt
- optional senden Server (in der Regel) und Client (seltener) ein Zertifikat an die andere Seite, was zur Authentifikation herangezogen werden kann, u.U. wird der "public key" hierin für die Übertragung des Session-Schlüssels verwendet | |
Mal ne blöde Frage nebenbei: Eigentlich kann man doch in der Zeit wo der Schlüssel ausgehandelt wird (der ja nicht verschlüsselt sein kann) auch der Schlüssel aus dem Netzverkehr gefischt werden und zur Entschlüsselung von für einen bestimmten Daten genutzt werden. Wo bleibt da die Sicherheit?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Andrrreas
Kann also auch noch dazu schrieben, dass SSL nicht nur für http da ist, sondern auch für ftp, smtp, pop etc. Die heißen dann also ftps, smtps & pops? | |
Ja, genau. Die werden manchmal so genannt.
Manchmal handeln diese Verbindungen TLS per Kommando auch erst nachträglich aus (bei SMTP z.B. gängig).
Der Client sagt normal Hallo zum Server, der Server antwortet mit der Liste der verfügbaren Features und wenn da TLS dabei ist, kann der Client sagen, er möchte jetzt TLS verhandeln und ab da wird's verschlüsselt. Da ist nicht wie bei https ein extra Port nötig.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von eupesco
Copy&Paste |= im Kopf ausrechnen :P | |
Ja, im Kopf kann ich ja noch auf 128 zählen. Ich hatte nur keine Lust.
Du willst mich ja bloß nerven. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [TSB]Schalentier
| | Zitat von eupesco
Copy&Paste |= im Kopf ausrechnen :P | |
Ja, im Kopf kann ich ja noch auf 128 zählen. Ich hatte nur keine Lust.
Du willst mich ja bloß nerven. | |
das ist gut möglich 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SirSiggi
Mal ne blöde Frage nebenbei: Eigentlich kann man doch in der Zeit wo der Schlüssel ausgehandelt wird (der ja nicht verschlüsselt sein kann) auch der Schlüssel aus dem Netzverkehr gefischt werden und zur Entschlüsselung von für einen bestimmten Daten genutzt werden. Wo bleibt da die Sicherheit? | |
Entweder eine Seite denkt sich einen Schlüssel aus und schickt ihn mittels "public key" des Servers verschlüsslt an diesen.
Dann kann ihn nur der Server mit seinem "private key" entschlüsseln.
Oder alternativ Diffie-Hellman. Da schicken die sich ein gegenseitig geschickt ein paar Zahlen zu, aus denen sich beide den Schlüssel erzeugen können, aber ein Mithörer nichts anfangen kann. Der verwendet dazu die gleichen Tricks, mit denen auch RSA arbeitet.
http://en.wikipedia.org/wiki/Diffie-Hellman
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von [TSB]Schalentier am 25.10.2004 22:16]
|
|
|
|
|
|
|
|
|
Eine kurze Frage noch  : Das "s" am Ende der Protokolle zeigt ist nur ein Hinweis für SSL, ssh hat damit nichts zu tun, richtig?
|
|
|
|
|
|
|
|
|
|
|
|
Ja, die Protokoll-Namen sind nicht mal überall genau standardisiert. http, https und ftp schon, aber außerhalb davon geht's teilweise ziemlich durcheinander zu.
|
|
|
|
|
|
|
|
|
|
|
|
Ok dann besten Dank an alle! Besonders an Schalentier Mal sehn was el Chefe morgen sagt...
|
|
|
|
|
|
|
|
|
|
|
hab das mal gefunden
http://pgp.gildemax.de/
zitat on
Ist PGP bzw. GnuPG unknackbar ?
Nein ! Man kann kann den Code schon knacken , nur ist der Aufwand enorm !
Im Jahre 1977 wurde ein Wettbewerb von den Entwicklern des RSA-Algorithmus
veranstaltet ! Die Nachricht wurde mit einer 429 Bit Zahl verschlüsselt. Nach
damaliger Technik sollte es 40 Billiarden Jahre dauern, bis jemand den Code knacken
würde. Im Jahre 1994 wurde der Code in 8 Monaten Arbeit von einem weltweit
kooperierenden Team gekna ckt, das über das Internet verbunden war und über
1600 Rechner benutzte.
/zitat off
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von *Donald Duck* am 25.10.2004 22:32]
|
|
|
|
|
|
| Thema: 128Bit? ( Was genau heißt das? ) |
