Re: Private und Public - Key. Welcher Unterschied?
Moin, Thomas Templin schrieb am 16.04.2002 (11:42):
Dienstag, 16. April 2002 11:32 Hannes Vogelmann wrote:
Da stimmt nun gerade nicht, ist genau umgekehrt. Der Absender verschlüsslt immer mit dem public key des Empfängers und der Empfänger entschlüsselt mit seinem private key. IMHO Qwatsch, dann bräuchte mann ja keinen private key. Erst lesen dann überlegen und dann antworten :))
Nein, nicht Quatsch, sondern richtig. Erst lesen und überlegen und dann antworten *fg*
Ich habe in dem Zenario folgenden Ablauf geschildert - A erzeugt ein key pair
B auch.
- A schickt den public Key an B
... und umgekehrt.
- A schickt eine mit seinem Private Key verschlüsselte Nachricht an B
Nein. A schickt eine mit dem public key von B verschlüsselte Nachricht an B. Wenn A sie nicht gleichzeitig auch mit seinem eigenen public key verschlüsselt hat, kann er sie nun selbst nicht mehr lesen.
- B entschlüsselt diese Nachricht mit dem public key, den er von A bekommen hat
B entschlüsselt die Nachricht mit seinem eigenen private key. (Anmerkung: Bis hierhin brauchte A gar kein eigenes key pair! Das wird erst in dem Moment notwendig, in dem er selber entschlüsseln oder signieren möchte.)
- B schickt eine mit dem public key von A verschlüsselte Nachricht an A - A entschlüsselt die von B kommende Nachricht, die mit seinem eigenen public key verschlüsselt wurde, mit seinem private key
Die letzten beiden Punkte sind doch wieder richtig. Warum sollte mal der private key zum Verschlüsseln genommen werden und mal der public key? Kurzzusammenfassung: Man verschlüsselt mit dem public key des Empfängers. Man entschlüsselt mit dem eigenen private key. Man signiert mit dem eigenen private key. Gruß, Antje -- It doesn't matter what temperature the room is. It's always room-temperature.
Am Dienstag, 16. April 2002 14:34 schrieb Antje M. Bendrich:
Moin,
Thomas Templin schrieb am 16.04.2002 (11:42):
Dienstag, 16. April 2002 11:32 Hannes Vogelmann wrote:
Da stimmt nun gerade nicht, ist genau umgekehrt. Der Absender verschlüsslt immer mit dem public key des Empfängers und der Empfänger entschlüsselt mit seinem private key.
IMHO Qwatsch, dann bräuchte mann ja keinen private key. Erst lesen dann überlegen und dann antworten :))
Nein, nicht Quatsch, sondern richtig. Erst lesen und überlegen und dann antworten *fg*
Ich habe in dem Zenario folgenden Ablauf geschildert - A erzeugt ein key pair
B auch.
- A schickt den public Key an B
... und umgekehrt.
- A schickt eine mit seinem Private Key verschlüsselte Nachricht an B
Nein. A schickt eine mit dem public key von B verschlüsselte Nachricht an B. Wenn A sie nicht gleichzeitig auch mit seinem eigenen public key verschlüsselt hat, kann er sie nun selbst nicht mehr lesen.
- B entschlüsselt diese Nachricht mit dem public key, den er von A bekommen hat
B entschlüsselt die Nachricht mit seinem eigenen private key. (Anmerkung: Bis hierhin brauchte A gar kein eigenes key pair! Das wird erst in dem Moment notwendig, in dem er selber entschlüsseln oder signieren möchte.)
- B schickt eine mit dem public key von A verschlüsselte Nachricht an A - A entschlüsselt die von B kommende Nachricht, die mit seinem eigenen public key verschlüsselt wurde, mit seinem private key
Die letzten beiden Punkte sind doch wieder richtig. Warum sollte mal der private key zum Verschlüsseln genommen werden und mal der public key?
Kurzzusammenfassung: Man verschlüsselt mit dem public key des Empfängers. Man entschlüsselt mit dem eigenen private key. Man signiert mit dem eigenen private key.
sag ich ja, danke, dass mir jemand zustimmt. Nochmal an Thomas Templin: Sorry für das Geflame, vielleicht haben wir wirklich aneinander vorbei geredet, wahrscheinlich meintest Du mit der ersten Verschlüsselung von A nach B tatsächlich nur die Übermittlung der Identitätsfeststellung. Alles andere würde zudem von Dir beschriebenen Verfahren wirklich keinen Sinn machen. Wenn Du schon richtig erkennst dass B mit dem public key von A verschlüsseln soll um eine Nachricht an A zu senden versteht sich eigentlich von selbst, dass umgekehrt das gleiche für A gelten muss. Wenn A eine Nachricht an B sendet muss A eben mit dem public key von B verschlüsseln. cu Hannes
Nochmal an Thomas Templin:
Sorry für das Geflame, vielleicht haben wir wirklich aneinander vorbei geredet, wahrscheinlich meintest Du mit der ersten Verschlüsselung von A nach B tatsächlich nur die Übermittlung der Identitätsfeststellung. Alles andere würde zudem von Dir beschriebenen Verfahren wirklich keinen Sinn machen. Wenn Du schon richtig erkennst dass B mit dem public key von A verschlüsseln soll um eine Nachricht an A zu senden versteht sich eigentlich von selbst, dass umgekehrt das gleiche für A gelten muss. Wenn A eine Nachricht an B sendet muss A eben mit dem public key von B verschlüsseln. Puhh, da bin ich ja beruhigt :) Ich habe versucht die Frage von Stefan so einfach wie Möglich zu beantworten, schliesslich kann ich nicht davon Ausgehen, dass an einer Schule die gesamte Problematik einer PKI Umgebung behandelt wird. Es stimmt schon, es ist immer mit zwei Key Pairs zu Arbeiten will man eine verschlüsselte zweiwege Kommunikation etablieren. Daher wäre es besser gewesen ich hätte ein etwas Umfangreicheres Zenario beschrieben, Asche auf mein Haupt. Allerdings kommt man schnell von Hundertsten ins tausendste, will man den Bereich einigermassen
Dienstag, 16. April 2002 15:23 Hannes Vogelmann wrote: plausibel abdecken. Ohne das Zenario einer gesamten PKI Struktur zu schildern kann man dem wohl kaum gerecht werden. Wenn ich gedacht hätte was ich damit verursache.... *lach* Ich habe diesen Bereich für eine Schulung dokumentiert und bin nur bei Berücksichtigung der gängigsten Verfahren, Richtlinien und Betriebssysteme auf über 100 Seiten gekommen, und das möchte ich Steffan nun wirklich nicht zumuten. Albin Zuccato hat in seiner Anmerkung ja bereits einige Anmerkungen zum Signaturgesetz und bestehenden EU Verordnungen sowie den Regularien der PKCS-7 erläutert. Das Thema reicht sicherlich aus um sich eine Woche lang damit zu Beschäftigen. Von den Knüppeln zwischen den Beinen die man sich in der Praxis momentan noch in heterogenen Umgebungen einfängt gar nicht zu reden. Mit der Bitte um Frieden *lach* Tschüss, Thomas
participants (3)
-
Antje M. Bendrich -
Hannes Vogelmann -
Thomas Templin