[Bug erledigt] 0002346 - Internal PGP can not decrypt mail which was encrypted with two keys

Wie ich dir bereits per PN mitgeteilt habe, haben meine Tests ergeben, dass es wohl darauf ankommt, ob mit dem privaten oder dem öffentlichen Schlüssel des Empfängers verschlüsselt wurde.

Du hast die privaten Schlüssel der beiden o.g. Adressen und wenn du von der einen an die andere schickst, wird wohl mit dem privaten Schlüssel des Empfängers verschlüsselt, so dass beim Entschlüsseln auf deiner Seite nach dem Passwort des Empfängers gefragt wird.

Schickst du jetzt aber eine verschlüsselte Nachricht an einen Empfänger, von dem du nur den öffentlichen Schlüssel hast, wird beim Entschlüsseln auf deiner Seite nach dem Passwort des Absenders, also deinem Passwort gefragt.

frage: würde es nicht immer sinn machen mit dem öff. schlüssel des empfängers zu verschlüsseln? oder was spricht dagegen es anders zu machen? ich verstehe das gwen bei ihren tests mit sich selbst natürlich jeweils die priv. und öff. schlüssel besitzt.

Zitat von Liquid Soul

frage: würde es nicht immer sinn machen mit dem öff. schlüssel des empfängers zu verschlüsseln?

Nein.

Wenn Du selbst Deine gesendete E-Mail dann nochmal lesen willst, dann müsste diese entschlüsselt werden - dazu brauchst Du den privaten Schlüssel der Empfängerin. Und den hast Du nicht. [*]

Sinnvoller ist es, die eigenen Mails mit Deinem eigenen öffentlichen Schlüssel zu verschlüsseln, dann kannst Du DEINE Mails in TheBats-Ordner "Versandt" wieder mit deinem privaten Schlüssel entschlüsseln.
Und das Ganze wird dann auch nicht von dir selbst getan, sondern das ist dann die Aufgabe von TheBat! - wenn die RitLaboranten das denn korrekt implementiert haben....!
Gwens und unser (!) Problem als Nutzerin ist, dass diese Implementierung wohl nicht korrekt ist.

Zitat von GwenDragon

Für mich ist das ein Designfehler im internen OpenPGP.

Weitere Infos: Pretty Good Privacy.

[*] Was anderes ist es mit den ausgehenden E-Mail: diese muss mit dem öffentlichen Schlüssel der Empfängerin verschlüsselt werden.

Diese beiden Vorgänge sind zwingend zu unterscheiden.

Zitat von GwenDragon

Versendet von einem Konto info@… an anderes test@… ergibt bei The Bat! in GnuPG-Batch:

Wie ich bereits unter RE: The Bat! 12.2.0.14 (BETA) geschrieben habe, interpretiert GnuPG aber beide Adressen als Empfänger. Das bestätigt auch dein Protokoll. In der Aufforderung steht dann

Bitte geben Sie die OpenPGP-Passphrase eines der folgenden Empfänger der Nachricht ein: 

Das scheint auch nicht ganz richtig zu sein.

Kannst du selbst testen. Verschlüssle mal mit OpenPGP, schalte dann auf GnuPG und versuche, damit zu entschlüsseln.

Zitat von GwenDragon

Dann bekommt info@ das gesendete im Versandt-Ordner nicht mehr entschlüsselt.

Eigentlich schon. Wenn du eine Nachricht an dich selbst schickst, dann hast du ja bereits den privaten Schlüssel sowie das Passwort des Empfängers. Man sieht auch deutlich auf deiner GIF in dem o.g. Thread, dass du nach dem Passwort gefragt wirst. Das geschieht aber nur dann, wenn das Programm den privaten Schlüssel des Empfängers in der Schlüsselverwaltung findet.

Hast du hingegen nur den öffentlichen Schlüssel des Empfängers, erscheint der Hinweis, dass nur der Empfänger die Nachricht öffnen kann. So war das zumindest vor .14. Das haben wir damals beanstandet und deswegen steht jetzt in .14:

[+] Encryption now always includes the sending identity's key, so the Sent copy stays readable

Seit .14 kann also der Sender die versandten Nachrichten mit seinem Passwort öffnen. Das geht aber nur dann, wenn mit dem öffentlichen Schlüssel des Empfängers verschlüsselt wurde, was aber grundsätzlich immer der Fall ist, weil man vom Empfänger normalerweise nur den öffentlichen Schlüssel besitzt. Insofern müsste also das Verhalten wie in GnuPG sein -> es wird mit dem privaten Schlüssel des Senders und dem öffentlichen Schlüssel des Empfängers verschlüsselt.

Wenn aber das Programm in der Schlüsselverwaltung nur den privaten oder neben dem öffentlichen auch den privaten Schlüssel des Empfängers findet, verschlüsselt es damit und nicht mit dem öffentlichen. Die Frage ist lediglich, ob das die Schuld von Ritlabs oder die Eigenheit von OpenPGP ist.

Aber auch in diesem Fall müsste mit zwei Schlüsseln verschlüsselt worden sein -> mit dem privaten des Senders und mit dem privaten des Empfängers. Im Gegensatz zu GnuPG fragt aber OpenPGP nicht nach dem Passwort einer der Adressen, sondern nur nach dem Passwort des Empfängers. Wahrscheinlich weil OpenPGP wiederum im Gegensatz zu GnuPG nicht beide Adressen als Empfänger interpretiert. Die Frage ist daher auch hier, ob das die Schuld von Ritlabs oder die Eigenheit von OpenPGP ist.

Ideal wäre es, wenn in diesem Fall so wie mit GnuPG nach einem der Passwörter gefragt wird. Dann hätte man überhaupt keine Probleme mehr, weil in allen Fällen das eigene Passwort ausreichen würde, um die Nachricht zu öffnen.

Aber auch im aktuellen Zustand gibt es kein großes Problem, denn wer besitzt schon auch den privaten Schlüssel des Empfängers?

Zitat von sanyok

wer besitzt schon auch den privaten Schlüssel des Empfängers?

Und wer es dennoch hat, hat ja normalerweise auch das Passwort dazu. Also kann er die Nachricht so oder so öffnen.

Übrigens,

[+] Encryption now always includes the sending identity's key

bedeutet doch im Klartext, dass ab sofort immer zusätzlich mit dem privaten Schlüssel des Senders verschlüsselt wird. Nur beim Entschlüsseln wird leider nicht immer danach gefragt, so wie GnuPG das z.B. tut.

Schade, dass der BT-Eintrag immer noch privat ist. Wenn du ihn ergänzen kannst, dann schlage dort vor, dass Ritlabs so wie bei GnuPG eine Abfrage nach einem der Passwörter einbauen sollen. Vielleicht kannst du dabei auch den Screenshot von GnuPG anhängen, wie das aussehen sollte.

Zitat von sanyok

Ideal wäre es, wenn in diesem Fall so wie mit GnuPG nach einem der Passwörter gefragt wird. Dann hätte man überhaupt keine Probleme mehr, weil in allen Fällen das eigene Passwort ausreichen würde, um die Nachricht zu öffnen.

Das haben sie jetzt auch für OpenPGP eingebaut und mit der Entschlüsselung sollte es keine Probleme mehr geben.