Komplexität ist natürlich Gift bei jeder Software, aber gerade bei Kryptosoftware ist es gefährlich, wenn der Nutzer Dinge entscheiden muss, die er mangels Wissen gar nicht entscheiden kann, und Fehlentscheidungen Auswirkungen haben, die er gar nicht überblicken kann, nicht nur für sich, sondern auch für Dritte!
Zum anderen ist die Architektur von GnuPG meiner Meinung nach viel zu komplex, da sie anscheinend die "Eierlegende Wollmichsau für alles, das mit Crypto zu tun hat" sein wollen:
http://data.guug.de/slides/lk2008/taking-gpgme-to-new-horizons.slides.pdf
Es ist eben _nicht_ nur ein Kommandozeilenprogramm, wo man eine unverschlüsselte Mail reingibt und eine verschlüsselte Mail herausbekommt und umgekehrt. Es ist inzwischen ein ganzer Zoo von Modulen und Diensten geworden.
Auch ist die Integration von GnuPG in eigene Programme ein Graus. Bei vielen Kommandozeilenprogrammen (z.B. tar, bzip2, jpeg-tools) ist es üblich, die Kernfunktionalität in einer Library zu bündeln. Diese Library wird dann sowohl von dem Kommandozeilenprogramm benutzt und steht auch Drittsoftware zur Verfügung.
Bei GnuPG ist es anders: Die Kernfunktionalität steckt im Binary. Es gibt eine Zusatzbibliothek "gpgme", die eine C API anbietet und dann für einen das gpg Binary "bedient", sprich: es mit den richtigen Kommandozeilenparametern aufruft und die Ausgabe des Programms auswertet. –.–
Wenn man in einem Programm also z.B. RSA-Verschlüsselung und -Signaturprüfung braucht, ist das mit Open-/LibreSSL deutlich einfacher umzusetzen (und das, obwohl die C API von Open-/LibreSSL echt räudig ist, BTDT!) und bietet weniger Stolpersteine, die bei GnuPG/gpgme auftreten können. (z.B. dass beim Generieren von Keys, für die man keine Passphrase will und braucht, plötzlich ein Passwort-Dialog aufpoppt und so lange die Abarbeitung des Programms steht. Ganz prima bei automatischen Tests, die unbeaufsichtigt durchlaufen sollen!)
Lars R.