Mich bitte nicht falsch zu verstehen.
Ich bin ein großer Freund von Verschlüsselung.
Ich habe damals PGP 2.6 geliebt. Eine kleine Handvoll Optionen, die taten was man brauchte. Die konnte man sich auch leicht auswendig merken, weil es nur so wenige waren.
Kein unnötiger Schnickschnack oder unzählige exotische Optionen die kaum ein Mensch jemals braucht.
Wenn ich mir allerdings die man-Page von gpg ansehe, überkommt mich eine gewisse Erinnerung an die man-Page von systemd. (Nicht dass es gpg tatsächlich mit systemd aufnehmen könnte - *nichts* hat mehr Funktionen als systemd, vermutlich nicht einmal Emacs.)
Dennoch wimmelt die man-Page vor unzähligen Optionen, von denen viele ähnlich heißen aber doch anderes tun.
Aber es ist nicht nur der Wildwuchs an Funktionen, die mich zunehmend stört.
Bei der Installation von gpg/gpg-agent unter Arch Linux wurde immer ein zusätzlicher Prozess namens "dirmngr" gestartet, den ich überhaupt nicht benötigte da ich aus Privatsphäre-Gründen nicht wollte dass von diesem Prozess ständig automatisch auf den Keyservern nach Revocation-Keys gesucht wird wenn ich eine Public Key benutze. Aber es gelang mir nicht zu konfigurieren dass dirmngr gestartet wird.
Und was mich fast noch mehr ärgerte: dirmngr startete zwar automatisch, wurde aber keinesfalls eben so automatisch beendet! Schließlich erstellte ich einen cron Job der diese Pest bei längerem Nichtgebrauch periodisch killte. Eine allerdings ziemlich primitive und unelegante Lösung.
Nun zurück unter Debian scheint es den dirmngr (noch) nicht zu geben, daher bin ich das Problem vorläufig wieder los. Aber wie lange noch?
Oder der Ärger mit "pinentry" und Passwort-Managern.
Das Passwort-Eingabe-Programm von gnupg bzw. gpg-agent trifft nämlich eigene Sicherheitsmaßnahmen welche verhindern, dass man ein Passwort über die Zwischenablage einfügt.
Das mag in bestimmten Situationen durchaus sinnvoll sein, nicht aber wenn man einen Passwort-Manager wie keepassx verwendet, der Passworte grundsätzlich auf diese Weise übermittelt!
KeepassX beherrscht für solche Fälle allerdings noch eine Alternativ-Methode, indem er simulierte Tastendrücke an ein Passwort-Eingabefeld sendet. Das funktioniert zwar grundsätzlich auch bei "pinentry", aber nicht fehlerfrei da ich immer mehrere Versuche brauche bis es klappt. Und manchmal klappt es gar nicht.
Daher habe ich die GUI-Versionen von pinentry deinstalliert und nur pinentry-ncurses installiert gelassen. Dort gibt man das Passwort in einem Terminal-Fenster ein, und dagegen dass ich dort etwas aus dem Passwort-Manager einfüge kann nicht einmal pinentry-ncurses etwas tun.
Aber wieso dieser Aufwand? Warum gibt es nicht einfach eine Option, dass pinentry-qt und pinentry-gtk das Einfügen eines Passwortes über die Zwischenablage zulassen wie alle anderen Programme, anstatt dies vorsätzlich (mit sicherlich viel Aufwand) zu sabotieren? Diese Einstellung bräuchte ja auch nicht der Default zu sein.
Ein weiteres Ärgernis bei gpg ist die Konfiguration der von Benutzer bevorzugter Crypto-Algorithmen.
Wenn man beispielsweise AES nicht traut sondern lieber einen andern Algorithmus verwenden würde, wird es mühsam.
Als erstes einmal muss man
$ gpg -v --version
aufrufen. Genau in dieser Reihenfolge! Nicht etwa die Optionen anders herum!
Dann bekommt man eine Liste mit Crypto-Algorithmen und eine interne Code-Bezeichnung nach jedem Algorithmus. Diese Codes muss man nun heraus suchen, und zu einer Zeichenkette zusammen setzen, welche die gewünschte Reihenfolge der Bevorzugung der Crypto-Algorithmen angibt.
Dann muss man einen Key in seinem Keyring für den man die Präferenzen ändern will mittels "gpg --edit-key" zum Bearbeiten auswählen.
Im Bearbeitungs-Modus muss man dann den Befehl "setpref" aufrufen, und als Argument die zuvor erstellte Zeichenkette aus den Codes angeben.
Mit "showpref" kann man sich dann zur Kontrolle anzeigen lassen ob alles korrekt angenommen wurde, und ob die Reihenfolge tatsächlich die gewünschte ist.
Dann darf man nicht vergessen, die Änderungen mit "saved" zu sichern, sonst war die ganze Mühe umsonst.
Und damit hat man nun erst die Präferenz-Reihenfolge der Algorithmen für einen *einzigen* Schlüssel im Schlüsselbund gesetzt - man muss diese mühselige Prozedur nun auch für alle anderen Schlüssel wiederholen, oder es gelten dort wieder die Defaults.
Ich konnte keine Möglichkeit finden, die persönlichen Crypto-Präferenzen als neue Defaults für alle Schlüssel festzulegen - nur wie man sie für individuelle Schlüssel übersteuert, wie oben beschrieben.
Ernsthaft - soll das Bedienungs-Komfort sein?
Auch wenn ich nicht ausschließen kann dass es vielleicht doch irgendwie geht, nur dass ich nicht herausfinden konnte, wie. Doch selbst in diesem Fall bleibt der Vorwurf, dass es in der man-Page nicht erklärt ist.
Oder eine andere Sache die ich ärgerlich, unnötig und sogar problematisch finde:
Wenn man eine Datei unter der Angabe eines Dateinamens - also nicht via Umleitung nach standard input - zum Verschlüsseln angibt und nicht zusätzlich eine spezielle Option angibt um genau dies zu verhindern, speichert gpg in der erzeugten .pgp Datei den Dateinamen im Klartext ab - und zwar unverschlüsselt!
Es ist daher gefährlich eine Datei mit verfänglichem Dateinamen - sagen wir "my new nsa-leak.txt" zu in eine .pgp Datei mit nichtssagendem Namen zu verschlüsseln, wenn einem nicht bewusst ist dass der verfängliche ursprüngliche Name immer noch - und unverschlüsselt - in der Datei enthalten ist, außer man gibt noch eine Zusatz-Option an!
Zudem scheint dieser Original-Dateiname ohnehin zu nichts gut zu sein, denn außer dass man sich ihn anzeigen lassen kann scheint er keine Funktion zu erfüllen. Insbesondere scheint es keine Option zu geben, die entschlüsselte automatisch Datei unter dem Originalnamen zu speichern.
Ich frage mich daher: Wozu existiert der eingebettete Dateiname dann überhaupt?
Nur um nichts-ahnende Anwender herein zu legen und den Original-Dateinamen an "interessierte Parteien" auszuplaudern?
Oder wer hat sich die oben erläuterte superkomplizierte Art und Weise einfallen lassen, wie man die Präferenz der Verschlüsselungs-Algorithmen ändern kann?
Zumal, was ich oben noch anzumerken vergaß, die internen Codes der Algorithmen sich zwischen den verschiedenen GPG-Versionen unterscheiden! Man kann also nicht einfach einmal die Zeichenkette mit den Codes ermitteln, sich dies notieren, und zukünftig immer dieselbe Zeichenkette bei "setprefs" angeben. Nein, man muss immer wieder --version aufrufen, da die Codes bei jeder installierten Version vom gpg andere sind oder zumindest sein können.
Mir kommt dieses Feature jedenfalls so vor als hätte es jemand eingebaut der es maximal unattraktiv machen wollten dass der Anwender seine eigenen Crypto-Präferenzen einstellen kann, aber dass ganz hartnäckige User es doch können wenn sie "unbelehrbar" sind.
Und ich bin sicher, bei 99 % der GPG-User hat dies auch Erfolg, und sie werden daher nur die Default-Algorithmen von GPG verwenden, welche rein zufälliger Weise auch vom NIST und der NSA wärmstens für alles besonders Geheime empfohlen werden, da sie absolut sicher seien.
Wenn nun daher ein Spendenaufruf zur "Weiterentwicklung" von GnuPG erfolgt, beschleichen mich Ängste dass dadurch noch weitere wirre Optionen, die alles noch komplizierter machen als es bereits ist, zum Programm hinzu kommen könnten.
Denn die oben erwähnten "Überkompliziert-Features" gab es beim originalen PGP alle nicht. Die kamen erst später im Zuge der Weiterentwicklung hinzu, genau wie andere zweifelhafte Funktionen, wie beispielsweise die versteckten Nachschlüssel die sich konfigurieren lassen und über deren Nutzen versus Gefährlichkeit man trefflich streiten kann.
Jedenfalls würde ich mit Freude etwas Spenden wenn die Mittel dazu verwendet würden GPG zu vereinfachen und unnötige oder sogar gefährliche Funktionalitäten wie die eingebetteten Dateinamen wieder zu entfernen oder zumindest nicht mehr per Default zu benutzen.
Aber meine Befürchtung ist, dass die GnuPG-Entwickler den unseligen eingeschlagenen Weg weiter gehen werden, in systemd-Manier noch mehr unnötige Features hinzu zu fügen und das Programm noch komplizierter (und somit auch fehleranfälliger) zu machen als es bereits ist.