{
    "kind": 30023,
    "id": "58e7cdea5a269a3fb2886f192a1fc03ca565c0f24aadaaa2dcf27748e039b16f",
    "pubkey": "c1baf4f74cd829963828b1da8d73e52cc94caa6d8dc944f7ca450a75c4b3311f",
    "created_at": 1791891910,
    "tags": [
        [
            "title",
            "Login mit PGP statt E-Mail: wie das Verfahren aus dem Darknet funktioniert und was es taugt (2026)"
        ],
        [
            "d",
            "pgp-login-statt-email-2026"
        ],
        [
            "summary",
            "Anmelden mit PGP-Schl\u00fcssel statt E-Mail und Passwort: Ablauf aus dem Darknet, Grenzen bei Phishing und Schl\u00fcsselverlust, Vergleich mit Passkeys und Nostr."
        ],
        [
            "published_at",
            "1791891909"
        ]
    ],
    "content": "\nBeim Login mit PGP meldet sich ein Mensch mit seinem Schl\u00fcsselpaar an statt mit E-Mail-Adresse und Passwort. Der Dienst kennt nur den \u00f6ffentlichen Schl\u00fcssel; angemeldet ist, wer einen damit verschl\u00fcsselten Zufallscode entschl\u00fcsseln kann. Auf Darknet-M\u00e4rkten ist das seit mindestens 2016 belegt, dort meist als zweiter Faktor nach dem Passwort, bei Konten ohne E-Mail-Adresse. F\u00fcr diesen Schritt speichert der Betreiber kein Geheimnis, und ohne E-Mail-Adresse f\u00e4llt das Zur\u00fccksetzen \u00fcber das Postfach weg. Zwei Grenzen sind belegt: Wer den entschl\u00fcsselten Code abtippt, ist nach der Definition des US-Standardinstituts NIST nicht vor Phishing gesch\u00fctzt, und wer den privaten Schl\u00fcssel verliert, verliert das Konto. Au\u00dferhalb des Darknets l\u00e4uft dasselbe Prinzip unter anderem Namen seit Jahren: SSH-Login, signierte Git-Commits, Paket-Signaturen bei Debian.\n\nStand aller Angaben: 13.10.2026. Grundlage sind Studien zu Darknet-M\u00e4rkten aus den Jahren 2019 bis 2025, Standards von NIST, W3C und IETF sowie Dokumentationen der Hersteller. Beschrieben wird das Verfahren, nicht der Zugang zu Marktpl\u00e4tzen.\n\n## Beim PGP-Login beweist der Besitz des privaten Schl\u00fcssels die Identit\u00e4t\n\nDer Ablauf ist in allen ausgewerteten Quellen gleich [1][2][3]:\n\n1. Beim Einrichten l\u00e4dt der Nutzer seinen \u00f6ffentlichen PGP-Schl\u00fcssel ins Profil.\n2. Beim Anmelden erzeugt der Server einen Zufallscode, verschl\u00fcsselt ihn an diesen Schl\u00fcssel und zeigt den verschl\u00fcsselten Block an.\n3. Der Nutzer entschl\u00fcsselt den Block mit seinem privaten Schl\u00fcssel im eigenen Programm und gibt den Code zur\u00fcck.\n4. Stimmt der Code, ist bewiesen, dass der Nutzer den privaten Schl\u00fcssel besitzt.\n\nAuf dem Markt AlphaBay war das laut VICE 2016 f\u00fcr Verk\u00e4ufer Pflicht, f\u00fcr K\u00e4ufer freiwillig; der Code hatte 16 Zeichen [1]. Wang und Kollegen untersuchten 12 M\u00e4rkte mit Daten von Mai bis August 2023. Die Registrierung fragte weder E-Mail-Adresse noch Telefonnummer ab, der zweite Faktor lief meist \u00fcber PGP, und 9 der 12 M\u00e4rkte gaben eine Wortliste zur Wiederherstellung aus [2]. G\u00fcldenring und Roth von der FU Berlin pr\u00fcften von September bis November 2023 100 erreichbare Onion-Dienste und fanden PGP als zweiten Faktor bei 10, Einmalcodes per App (TOTP) bei 6 [3]. J\u00fcngere Zahlen als von 2023 enth\u00e4lt keine der ausgewerteten Studien.\n\n## Auf Darknet-M\u00e4rkten ist der PGP-Schl\u00fcssel die Identit\u00e4t, die von Markt zu Markt mitzieht\n\nM\u00e4rkte schlie\u00dfen und neue entstehen, Verk\u00e4ufer ziehen um, Betr\u00fcger kopieren bekannte Namen. Dwyer und Kollegen werteten Forenbeitr\u00e4ge von f\u00fcnf M\u00e4rkten aus den Jahren 2013 bis 2015 aus. PGP diente zur Anmeldung in den Foren und vor allem dazu, Verk\u00e4ufer \u00fcber M\u00e4rkte hinweg wiederzuerkennen. Wer einem Verk\u00e4ufer misstraute, verlangte, eine Nachricht an dessen \u00e4lteren Schl\u00fcssel zu entschl\u00fcsseln [4]. Tai, Soska und Christin von der Carnegie Mellon University z\u00e4hlten in Daten aus acht Jahren 28.417 PGP-Schl\u00fcssel auf 32.101 Konten; manche Verk\u00e4ufer nutzten denselben Schl\u00fcssel auf mehreren M\u00e4rkten [5].\n\nDieselben Autoren nennen zwei Einschr\u00e4nkungen. Ein ver\u00f6ffentlichter \u00f6ffentlicher Schl\u00fcssel beweist nichts, ein Hochstapler kann ihn einfach auf seine Seite kopieren. Erst die gel\u00f6ste Challenge beweist den Besitz. Au\u00dferdem verlieren Menschen h\u00e4ufig den Zugang zu ihrem privaten Schl\u00fcssel und erzeugen aus legitimen Gr\u00fcnden neue [5].\n\n## Im E-Mail-Web kann jeder, der das Postfach kontrolliert, das Passwort zur\u00fccksetzen\n\nDie E-Mail-Adresse als Generalschl\u00fcssel des Webs ist eine Zuspitzung. Belegbar sind ihre Bausteine. Ein vergessenes Passwort wird laut OWASP \u00fcber einen zweiten Kanal zur\u00fcckgesetzt, typischerweise per Link in einer E-Mail [6]. Bei Magic Links, etwa in der Login-Bibliothek Auth.js, ist die Mail der einzige Weg hinein; der Link gilt 24 Stunden [7]. NIST verbietet E-Mail in der Richtlinie SP 800-63B-4 (August 2025) als Anmeldefaktor, weil ein Postfach oft nur mit einem Passwort gesch\u00fctzt ist und Mails unterwegs abgefangen oder umgeleitet werden k\u00f6nnen. Codes per E-Mail zur Wiederherstellung erlaubt dieselbe Richtlinie ausdr\u00fccklich [8].\n\nDazu kommt der Anbieter. Sperrt Google ein Konto, kann sich der Nutzer laut Google-Hilfe weder bei Google-Diensten anmelden noch \u201eMit Google anmelden\u201c verwenden [9]. Die New York Times berichtete 2022 \u00fcber einen Vater, dessen Google-Konto nach einem Foto f\u00fcr den Kinderarzt automatisch als Missbrauchsmaterial eingestuft und gesperrt wurde; mehr als zehn Jahre Kontakte, Mails und Fotos waren weg [10]. Have I Been Pwned listete am 13.10.2026 1.044 Datenlecks mit zusammen 17.845.803.111 betroffenen Konten. Gez\u00e4hlt sind Konten, nicht Personen [11].\n\n## Passkeys und Nostr binden den Schl\u00fcssel-Login an die Domain des Dienstes, der PGP-Login meist nicht\n\nPasskeys (Standard WebAuthn) arbeiten im Kern wie der PGP-Login. Der Dienst speichert einen \u00f6ffentlichen Schl\u00fcssel, der private bleibt beim Nutzer, angemeldet wird per Challenge, ein gemeinsames Geheimnis gibt es nicht. WebAuthn Level 3 ist seit dem 25.08.2026 Empfehlung des W3C. Jeder Passkey gilt nur f\u00fcr die Domain des Dienstes, und das pr\u00fcft der Browser, nicht der Mensch [12]. Synchronisiert werden Passkeys meist \u00fcber Plattformkonten wie den iCloud-Schl\u00fcsselbund oder den Google-Passwortmanager [13][14].\n\nDie Angabe, Passkeys s\u00e4\u00dfen beim Plattformanbieter fest, ist 2026 \u00fcberholt. Das Credential Exchange Protocol der FIDO Alliance erlaubt den Umzug zwischen Passwortmanagern laut Bitwarden seit iOS 26 (15.09.2025) und seit dem 23.07.2026 auch unter Android [15]. Ob die Spezifikation als Entwurf oder final gilt, weist die FIDO-Seite nicht aus.\n\nNostr macht den Schl\u00fcssel selbst zur Identit\u00e4t: Jeder Nutzer hat ein Schl\u00fcsselpaar, jede Nachricht ist signiert (NIP-01). Zum Anmelden signiert der Nutzer ein Ereignis mit der Challenge und der Adresse des Relays (NIP-42) oder mit der exakten URL und HTTP-Methode (NIP-98). Den privaten Schl\u00fcssel h\u00e4lt eine Browser-Erweiterung (NIP-07) oder ein entfernter Signierdienst (NIP-46), die Webseite bekommt ihn nie. Alle genannten Spezifikationen tragen den Status \u201edraft\u201c [16]. Damit steckt die Adresse des Dienstes im Beweis; beim PGP-Login nach Darknet-Vorbild ist das nicht vorgeschrieben.\n\n| | E-Mail und Passwort | Passkey | PGP-Login (Darknet-Stil) | Nostr-Login |\n|---|---|---|---|---|\n| Wo liegt der Schl\u00fcssel | kein Schl\u00fcssel; Passwort beim Nutzer, Hash beim Dienst | Ger\u00e4t oder Plattform-Schl\u00fcsselbund | beim Nutzer: Datei, Programm oder Hardware-Karte | beim Nutzer, in Erweiterung oder bei einem Fernsignierer |\n| Was hat der Betreiber | E-Mail-Adresse, Passwort-Hash | \u00f6ffentlichen Schl\u00fcssel | \u00f6ffentlichen Schl\u00fcssel und Fingerabdruck | \u00f6ffentlichen Schl\u00fcssel |\n| Phishing | Domain nicht im Beweis | Browser pr\u00fcft die Domain | Domain meist nicht im Beweis; Abtippen laut NIST nicht phishing-resistent | URL oder Relay im signierten Ereignis |\n| Wiederherstellung | Link ans Postfach | \u00fcber das Plattformkonto | Wortliste (9 von 12 M\u00e4rkten) oder keine | im Protokoll keine gefunden |\n| Standard | nicht betrachtet | W3C WebAuthn Level 3, FIDO | OpenPGP RFC 9580; Login-Ablauf nicht standardisiert | NIPs, Status \u201edraft\u201c |\n\nQuellen der Tabelle: [2][3][8][12][13][16][22].\n\n## Abgetippte Codes sind nicht phishing-fest, die Challenge braucht eine signierte Domain\n\nNIST stuft jedes Verfahren, bei dem ein Mensch eine Ausgabe von Hand eingibt, als nicht phishing-resistent ein: Eine gef\u00e4lschte Pr\u00fcfstelle kann die Ausgabe an den echten Dienst weiterreichen [8]. Ein abgetippter PGP-Code f\u00e4llt darunter; das ist eine Ableitung, NIST nennt PGP nicht. G\u00fcldenring und Roth kommen unabh\u00e4ngig zum selben Ergebnis. Eine Phishing-Seite kann die verschl\u00fcsselte Challenge des echten Dienstes durchreichen; sch\u00fctzen kann nur eine Challenge, die den echten Domainnamen enth\u00e4lt und vom Dienst signiert ist [3].\n\nBei 8 Diensten, auf denen die beiden Forscher den PGP-Zweitfaktor selbst einrichteten, enthielt die entschl\u00fcsselte Challenge 4-mal nur den Code, 1-mal Code und Domain ohne Signatur, 1-mal eine signierte Domain plus unsignierte Login-Adresse und 2-mal Code und Domain mit Signatur [3]. VICE schrieb 2016, manche Darknet-M\u00e4rkte h\u00e4tten bessere Sicherheit f\u00fcr Nutzer als Gmail [1]. Die Messung von 2023 zeigt: Ein Pflicht-Zweitfaktor per PGP ist nicht dasselbe wie Schutz vor Phishing.\n\nEin weiteres Risiko ist f\u00fcr den Login in keiner ausgewerteten Quelle beschrieben, folgt aber aus dem OpenPGP-Standard. RFC 9580 nennt historische Angriffe, bei denen ein Nutzer eine Nachricht arglos entschl\u00fcsselt, den Klartext zur\u00fcckgibt und so zum Entschl\u00fcsselungsorakel wird [22]. Ein Login nach dem Muster \u201eentschl\u00fcssele und gib den Klartext zur\u00fcck\u201c hat diese Form: Eine gef\u00e4lschte Seite k\u00f6nnte statt eines Zufallscodes eine abgefangene echte Nachricht vorlegen. Ein konkreter Fall ist nicht belegt. Verfahren, die eine Signatur verlangen, haben das Muster nicht.\n\n## Wer den privaten Schl\u00fcssel verliert, verliert das Konto\n\nOhne Postfach gibt es keinen Link zum Zur\u00fccksetzen. Damit entf\u00e4llt der Kontoklau \u00fcber die Mail, und ebenso der Rettungsweg. Auf AlphaBay war ein Konto ohne die Merkliste aus sieben W\u00f6rtern laut VICE \u201elost forever\u201c [1]. Der Passwortmanager Passbolt, der Teams per PGP anmeldet, nennt als Auswege ein Recovery-Kit, also eine Datei mit dem privaten Schl\u00fcssel, oder ein verschl\u00fcsseltes Server-Backup mit Freigabe durch einen Admin, sofern die Organisation es eingerichtet hat [17]. Bei der Videoplattform AVideo entfernt ein Admin den verlorenen Schl\u00fcssel, danach reicht wieder das Passwort [24].\n\nAuch die Aussage, beim Betreiber liege nichts, stimmt nur halb. Er speichert \u00f6ffentlichen Schl\u00fcssel und Fingerabdruck. Wer diese Liste und sp\u00e4ter den privaten Schl\u00fcssel einer Person erbeutet, kann nachweisen, dass sie den Dienst genutzt hat [3].\n\n## Jeder Dienst baut den PGP-Web-Login anders, und er ist selten: 6 von 778 Anmeldungen bei IndieLogin\n\nOpenPGP selbst ist standardisiert, seit Juli 2024 in RFC 9580, der RFC 4880, 5581 und 6637 ersetzt [22]. Anleitungen mit Verweis auf RFC 4880 beschreiben den alten Stand. Das GnuPG-Lager pflegt daneben mit LibrePGP einen eigenen Entwurf mit \u00e4lterem Schl\u00fcsselformat [33]. Den Anmeldeablauf regelt keiner dieser Texte. G\u00fcldenring und Roth fanden ihn auf jeder Website anders umgesetzt [3]. Ein Standard f\u00fcr den Web-Login per PGP fand sich in der Recherche nicht (gesucht: IETF-Datatracker, Dokumentation von Passbolt und IndieLogin).\n\nIndieLogin.com, ein offener Login-Dienst, ver\u00f6ffentlicht Zahlen: Im September 2026 liefen dort 778 Anmeldungen, davon 6 per PGP, 106 per E-Mail, 199 per GitHub und 257 per IndieAuth [23]. Das ist ein einzelner Dienst mit technisch interessiertem Publikum und nicht \u00fcbertragbar. Yubico schreibt in der eigenen Entwicklerdoku: \u201ePGP is not used for web authentication.\u201c [21]\n\nZur Bedienbarkeit liegt in den ausgewerteten Quellen eine einzige Nutzerstudie vor: Eine Masterarbeit an der Carleton University testete 2015 eine Browser-Erweiterung f\u00fcr PGP-Login mit 12 und 16 Teilnehmenden, \u00fcberwiegend Studierenden. Der zweite Prototyp erreichte auf der System Usability Scale 75,78 Punkte; verwirrend fanden die Teilnehmenden das Verkn\u00fcpfen und Signieren der Schl\u00fcssel [18]. Latacora schrieb 2019, das Identit\u00e4tsger\u00fcst von PGP funktioniere nicht, normale Menschen vertrauten allem, was wie ein PGP-Schl\u00fcssel aussehe [19]. Robert J. Hansen hielt im GnuPG-Blog im M\u00e4rz 2026 dagegen: Ein Teil der Kritik sei Halbwahrheit, und die berechtigten Einw\u00e4nde, die Matthew Green 2014 erhoben hatte, entsch\u00e4rften die neuen Spezifikationen gr\u00f6\u00dftenteils [20].\n\n## SSH, Git, Debian und der Linux-Kernel binden Identit\u00e4t seit Jahren an Schl\u00fcssel\n\nBeim SSH-Login ist \u201epublickey\u201c laut RFC 4252 von 2006 die einzige Pflichtmethode. Der Besitz des privaten Schl\u00fcssels ist die Anmeldung, bewiesen durch eine Signatur, die unter anderem die Kennung der laufenden Verbindung einschlie\u00dft [27]. Das ist eine Bindung an den Kanal, eine der beiden Formen, die NIST als phishing-resistent anerkennt [8]. OpenPGP-Schl\u00fcssel kennen neben Signieren und Verschl\u00fcsseln die F\u00e4higkeit Authentifizieren [29], und GnuPG arbeitet auf Wunsch als SSH-Agent [28].\n\nGitHub markiert Commits und Tags, die mit GPG, SSH oder S/MIME signiert sind, als \u201everified\u201c [32]. Der Linux-Kernel zog aus dem Einbruch bei kernel.org 2011 die Regel, Vertrauen geh\u00f6re zu den Entwicklern und nie zur Infrastruktur, die den Code hostet; PGP-Schl\u00fcssel sichern dort die Integrit\u00e4t des Kernels [29]. Bei Debian ist die Identit\u00e4t eines Entwicklers sein OpenPGP-Schl\u00fcssel im Debian-Schl\u00fcsselbund [30]. Die Paketverwaltung APT pr\u00fcft Signaturen seit Version 2.9.19 (Dezember 2024) auf unterst\u00fctzten Plattformen mit Sequoia statt GnuPG [31]. Wie viele Commits oder Pakete weltweit signiert sind, dazu fand sich keine Zahl.\n\nAls Web-Login gibt es einzelne Dienste. Bei IndieLogin.com signiert der Nutzer eine kurze Challenge; der \u00f6ffentliche Schl\u00fcssel liegt auf der eigenen Website, die Identit\u00e4t ist die eigene Domain [23]. Passbolt nennt sein bisheriges Protokoll GpgAuth \u201elegacy\u201c und will es durch einen Ablauf mit JWT ersetzen. Abgel\u00f6st wird das Protokoll, nicht OpenPGP: Auch im neuen Ablauf signiert der Client eine Challenge mit Domain, Token und Ablaufzeit mit seinem PGP-Schl\u00fcssel [17]. Keyoxide belegt \u00fcber OpenPGP-Schl\u00fcssel ohne zentrale Plattform, dass Konten auf verschiedenen Diensten derselben Person geh\u00f6ren [25]. Keybase, fr\u00fcher der bekannteste Dienst daf\u00fcr, wurde am 07.05.2020 von Zoom \u00fcbernommen [26].\n\n## Die Lernseite pgp.stevennoack.de l\u00e4sst den Entschl\u00fcsselungs-Login ausprobieren\n\nDie Lernseite [pgp.stevennoack.de](https://pgp.stevennoack.de) bildet den Ablauf nach Darknet-Vorbild nach: registrieren ohne E-Mail und ohne Passwort, anmelden durch Entschl\u00fcsseln einer Challenge. Im Einsteigerpfad erzeugt der Browser das Schl\u00fcsselpaar mit der Bibliothek OpenPGP.js, der private Schl\u00fcssel wird als Datei heruntergeladen, der Server speichert nur den \u00f6ffentlichen Schl\u00fcssel. Im Profipfad f\u00fcgt der Nutzer einen vorhandenen \u00f6ffentlichen Schl\u00fcssel ein, etwa aus Gpg4win/Kleopatra, und entschl\u00fcsselt die Challenge im eigenen Programm. Registrierungen verfallen nach 30 Tagen [34].\n\nSeit dem 13.10.2026 gibt es zus\u00e4tzlich einen Weg ganz ohne JavaScript unter [pgp.stevennoack.de/ohne-js/](https://pgp.stevennoack.de/ohne-js/), nur mit Formularen, also auch im Tor Browser auf der Stufe \u201eAm sichersten\u201c. Die Challenge enth\u00e4lt seitdem Domain und Ablaufzeit im verschl\u00fcsselten Klartext (\u201eAnmeldung bei: pgp.stevennoack.de\u201c, \u201eG\u00fcltig bis: \u2026\u201c). Im Weg mit JavaScript vergleicht der Browser diese Zeile mit der aufgerufenen Adresse und bricht bei Abweichung ab; der Server weist eingef\u00fcgten Text mit fremder Domain zur\u00fcck. Damit greift die Schw\u00e4che aus der Studie von G\u00fcldenring und Roth hier nur noch, wenn ein Mensch nur den nackten Code abtippt und die Adresszeile nicht liest. Beide Wege wurden am 13.10.2026 live durchgespielt, der Weg ohne JavaScript mit GnuPG auf der Kommandozeile.\n\nOffenlegung: Die Lernseite geh\u00f6rt zu dieser Webseite.\n\n## Quellen\n\nAlle Abrufe am 13.10.2026.\n\n\u2022 [1] VICE/Motherboard, \u201eSome Dark Web Markets Have Better User Security than Gmail, Instagram\u201c, 2016: https://www.vice.com/en/article/some-dark-web-markets-have-better-user-security-than-gmail-instagram/\n\u2022 [2] Wang et al., \u201eSecure in the dark? An in-depth analysis of dark web markets' security\u201c, International Journal of Information Security, 03.04.2025: https://link.springer.com/article/10.1007/s10207-025-01015-1\n\u2022 [3] G\u00fcldenring, Roth, \u201eProtecting Onion Service Users Against Phishing\u201c, arXiv:2408.07787v1, 14.08.2024: https://arxiv.org/html/2408.07787v1\n\u2022 [4] Dwyer et al., \u201eHow darknet market users learned to worry more and love PGP\u201c, arXiv:2203.08557, 16.03.2022: https://arxiv.org/abs/2203.08557\n\u2022 [5] Tai, Soska, Christin, \u201eAdversarial Matching of Dark Net Market Vendor Accounts\u201c, KDD '19: http://www.contrib.andrew.cmu.edu/~nicolasc/publications/Tai-KDD19.pdf\n\u2022 [6] OWASP Forgot Password Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html\n\u2022 [7] Auth.js, E-Mail-Anmeldung: https://authjs.dev/getting-started/authentication/email\n\u2022 [8] NIST SP 800-63B-4, August 2025: https://pages.nist.gov/800-63-4/sp800-63b.html\n\u2022 [9] Google-Hilfe, \u201eYour account is disabled\u201c: https://support.google.com/accounts/answer/40695?hl=en\n\u2022 [10] New York Times, Kashmir Hill, 21.08.2022: https://www.nytimes.com/2022/08/21/technology/google-surveillance-toddler-photo.html\n\u2022 [11] Have I Been Pwned, \u00f6ffentliche API (Summe des Felds PwnCount): https://haveibeenpwned.com/api/v3/breaches\n\u2022 [12] W3C, Web Authentication Level 3, Empfehlung vom 25.08.2026: https://www.w3.org/TR/webauthn-3/\n\u2022 [13] FIDO Alliance, Passkeys: https://fidoalliance.org/passkeys/\n\u2022 [14] Apple, Sicherheit von Passkeys: https://support.apple.com/en-us/102195\n\u2022 [15] Bitwarden zum Credential Exchange Protocol: https://bitwarden.com/blog/security-vendors-join-forces-to-make-passkeys-more-portable-for-everyone/ und FIDO-Spezifikationen: https://fidoalliance.org/specifications-credential-exchange-specifications/\n\u2022 [16] Nostr NIP-01, NIP-07, NIP-42, NIP-46, NIP-98: https://github.com/nostr-protocol/nips\n\u2022 [17] Passbolt, Authentication und \u201eHow Passbolt Secures Your Data\u201c: https://www.passbolt.com/docs/development/authentication/ und https://www.passbolt.com/docs/user/introduction/how-passbolt-secures-your-data/\n\u2022 [18] Wueppelmann, \u201ePGP Auth: Using Public Key Encryption for Authentication on the Web\u201c, Masterarbeit, Carleton University, 2015: https://chorus.scs.carleton.ca/wp-content/papercite-data/pdf/wueppelmann2015thesis-carleton.pdf\n\u2022 [19] Latacora, \u201eThe PGP Problem\u201c, 16.07.2019: https://www.latacora.com/blog/2019/07/16/the-pgp-problem/\n\u2022 [20] Robert J. Hansen, \u201eWhy Some Criticisms Matters More Than Others\u201c, GnuPG-Blog, im Text datiert 30.03.2026, in der Adresse 20.03.2026: https://www.gnupg.org/blog/20260320-some-criticism-matter.html\n\u2022 [21] Yubico, PGP: https://developers.yubico.com/PGP/\n\u2022 [22] RFC 9580, OpenPGP, Juli 2024: https://www.rfc-editor.org/rfc/rfc9580.html\n\u2022 [23] IndieLogin.com, PGP-Einrichtung und Statistik: https://indielogin.com/setup/pgp und https://indielogin.com/stats\n\u2022 [24] AVideo Wiki, \u201ePGP 2FA Login\u201c: https://github.com/WWBN/AVideo/wiki/PGP-2FA-Login\n\u2022 [25] Keyoxide, Dokumentation: https://docs.keyoxide.org/wiki/keyoxide/\n\u2022 [26] Keybase, \u201eKeybase joins Zoom\u201c, 07.05.2020: https://keybase.io/blog/keybase-joins-zoom\n\u2022 [27] RFC 4252, SSH Authentication Protocol, 2006: https://www.rfc-editor.org/rfc/rfc4252.txt\n\u2022 [28] GnuPG, Agent-Optionen: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html\n\u2022 [29] Linux Kernel, Maintainer PGP Guide: https://docs.kernel.org/process/maintainer-pgp-guide.html\n\u2022 [30] Debian Keyring: https://keyring.debian.org/\n\u2022 [31] APT-Changelog (Eintr\u00e4ge 23.12.2024 und 25.04.2025): https://salsa.debian.org/apt-team/apt/-/raw/main/debian/changelog\n\u2022 [32] GitHub, Commit-Signaturen: https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification\n\u2022 [33] LibrePGP: https://librepgp.org/\n\u2022 [34] Lernseite pgp.stevennoack.de und Quellcode, gepr\u00fcft am 13.10.2026: https://pgp.stevennoack.de",
    "sig": "7eb1c5986c17000bb0b03200a87de81ca117ede66c53f88dee6076d367cc14d371c9544fa67f478321fef96f301802d2d6f3edddd73ce846246cc4582f80af9a"
}