GnuPG, adversary advantage

Hallo, ich suche ein Tool für asymmetrische Verschlüsselung, mit dem ich Chiffretexte erstellen kann, die "negligible adversary advantage" haben. Negligible adversary advantage bedeutet, etwas vereinfacht gesagt, dass der Angreifer den Chiffretext nicht von Rauschen unterscheiden kann. (wen's interessiert, das Konzept ist bei Wikipedia ganz gut erklärt.) Negligible adversary advantage gilt als Königskriterium für die Sicherheit von symmetrischen Chiffren. Natürlich nutze ich GnuPG für e-mail-Verschlüsselung, aber da habe ich das Problem, das GnuPG-Chiffretexte sich immer selbst gleich identifizieren z.B. so: "-----BEGIN PGP MESSAGE----- Version: GnuPG v2 hIwD11qLV+O7oBgBA/9DwRZIg5Qq8NdftADySmN3NnoPdBQsEzS3yK3esfjYImoF IOrwWVauN86LyZsqVQqLE/s7ydmf0LTJ3xELrutnrI53hqlqPSkrEKbNnHfzPIr7 /Ts9ol1AyNzfXL+ma7ItbD3H7R9AWnc12UA9YxLBmeBzrQbtDp5beEFmWjjKltLt..." Kennt jemand eine Einstellung für GnuPG, die "negligible adversary advantage" erlaubt? Ich weiss, dass man statt radix64-codierung binäre codierung wählen kann, aber damit ist die Selbstidentifikation und spezielle Formatierungen nicht weg. Oder ein anderes (idealerweise freies) Tool, das asymmetrische Chiffren mit diesen Eigenschaften erzeugen kann? Es müsste für mich auch unter LINUX laufen.
 
Es gibt zwei Probleme mit diesem Ansatz:

- Sicherstellung der Entschlüsselungsfähigkeit beim Empfänger: Der Empfänger braucht die Parameter, Schlüsselbestandteile, Algorithmen, usw., um den Ciphertext zu entschlüsseln. Diese müssen im Klartext übertragen und automatisiert ausgelesen werden, was eine klare Struktur der Nachricht voraussetzt.
- Welches Problem willst du damit lösen? Auch wenn es in der Theorie eine schöne Eigenschaft ist, wenn man Daten nicht von Rauschen unterscheiden kann, in der Praxis ist logisches Rauschen eher unüblich. D.h. ein Abgleich mit Wort- und Sprachdatenbanken würde die Email sofort als auffällig klassifizieren. Was ein anderes Problem von Emails hervorruft: Cops hate encryption but the NSA loves it when you use PGP ? The Register

Letzten Endes bleibt dir nur die Erweiterung von GnuPG, z.B. in dem du den Ciphertext in für Menschen lesbaren Text umwandelst. Je aufwändiger die Algorithmen dahinter, desto besser, denn desto weniger ist die Technik bei einer grossen Menge an Mails automatisierbar.

Letzten Endes ist es aber auch eine kulturelle Frage: Ist jemand auffällig, nur weil er oder sie Verschlüsselung einsetzt? In diese Sinne ist es sogar sinnvoll zu sagen: Hier, ich nutze GnuPG, denn meine Privatsphäre ist mir wichtig! Siehe dazu auch die Diskussion auf der IETF PerPass Mailingliste:
https://mailarchive.ietf.org/arch/msg/perpass/tEDLzadaabxnovrgvlxbuXU6Vfs hat gesagt.:
"You stand out like a sore thumb and they (archive it forever,
focus on you more, ...)" goes with "only the 4 horsemen of the
infopocalypse use encryption" as one of the standard arguments.
 
Zuletzt bearbeitet:
Gründe für negligible adversary advantage

Leider hatte ich den thread nicht so eng verfolgt, so dass ich jetzt etwas spät antworte. Danke für die Antwort, SchwarzeBeere. Zu den zwei Problemen bei negligible adversary advantage: -> Sicherstellung der Entschlüsselungsfähigkeit beim Empfänger. Wenn jemand mit mir verschlüsselt kommuniziert, kenne ich doch den öffentlichen Schlüssel, den er benutzt. Das ist meiner, den ich veröffentlicht habe. Und der öffentliche Schlüssel hat doch bei OpenPGP auch die Liste meiner präferierten Algorithmen und kann die einfach benutzen oder nicht? Wieso müssen die dann noch im Klartext übermittelt werden? -> Welches Problem willst du damit lösen? Das sind zwei Hauptgründe. Erstens möchte ich einen konturlosen Input für Steganographie haben. Verschlüsselung soll standardisiert sein - das ist wohl Konsens, selbst ausgedacht zählt als unsicher. Aber für Steganographie gilt das grade nicht, die sollte jede Gruppe für sich neu erfinden, hauptsache verschieden von anderen Mustern. In den versteckten Daten dürfen keine Krypto-identifier sein. Zweitens würde es, denke ich, für sich allein die Sicherheit doch erheblich erhöhen. Wenn ich mich in NSA hineinversetze ist der jetzige Zustand doch paradiesisch: Es gibt eine Hand voll Programme, deren Ciphertexts sich selbst identifizieren und auch noch Schlüssellänge und Kryptosystem zeigen. Dann können die das gleich einsortieren und der richtigen Pipeline für das cracken übergeben - oder speichern, wenn das noch nicht knackbar ist. Alles schön vorsortiert für die industrielle Bearbeitung. Und jetzt eine Rausch-cipher: Wo soll das abgelegt werden, was machen wir damit. Wenn wir(die NSA) verschiedenes ausprobiert haben und es hat nicht geklappt - wie lange machen wir weiter. Wir wissen nicht mal, ob wir erschöpfend gebruteforced haben oder ob es sich einfach doch um Versuche von einem Praktikanten zu einem neuen Videoformat handelt. Das verstopft deren Pipeline. Ich fände das super. Es gibt noch ein paar weitere Vorteile: Ich kann die Rausch-Chiffren von hypothetischen Whistleblower Dateien mit einem Busenbildchen XORen und wenn mir die Tür eingetreten wird behaupten, das ist ein OTP und ich wollte die Bildchen vor meiner Freundin verstecken. etc.. etc.. Wenn Rausch-chiffren besser sind und wenn es geht, sollte man das doch auch tun oder nicht?. Also ich stehe schon dazu und bin weiter auf der Suche - vielleicht meldet sich ja jemand, der sowas kennt. Da ist ja vor kurzem ein Survey von Schneir herausgekommen und es soll ein paar hundert freie Kryptopakete geben. Vielleicht komme ich an die Liste ran und kann das auch mal danach durchsuchen....
 
negligible adversary advantage

Hallo, inzwischen hab ich die "Schneir"-Liste durchgesehen und bin fündig geworden. Damit dieser Thread vollständig ist, will ich hier das Ergebnis posten. Ihr findet die Schneir-Liste z.B. hier: Wanted: Cryptography Products for Worldwide Survey - Schneier on Security oder in anderem Format hier: https://www.schneier.com/cryptography/paperfiles/worldwide-survey-of-encryption-products.pdf Das Tool "Academic Signature"( Academic Signature) kann offenbar Chiffretexte erzeugen, die sich nicht identifizieren und auch im Ganzen nicht von Rauschen zu unterscheiden sind. Die nennen das eine "NADA-CAP". Es ist der erste Eintrag auf der Schneir-Liste aus Deutschland. Hat jemand hier im Forum Erfahrung damit?
 
Aha. In Kurzform:

Code:
Verschlüsselung:
mailBody = NADA_enc(ECC_enc(m,pubKey_recv),PSK)

Entschlüsselung:
mailBody = NADA_dec(ECC_dec(m,privKey_recv),PSK)

wobei NADA_{enc,dec} zusätzlich Key Derivation und Padding beinhalten und ECC_{enc,dec} Verschlüsselungsfunktionen auf elliptischen Kurven darstellen.

Aufgrund des manuellen Schlüsselaustauschs ist das System allerdings wenig praktikabel und verspielt die Vorteile des darunter liegenden asymmetischen Kryptosystems wieder völlig. Auch müssen Algorithmen im Vorfeld bekannt sein - einem Endanwender würde ich diese Bürde nicht auferlegen (Thema Usable Security). Werden sie aber gebrochen, so ist der Austausch aufwändig bis - je nach Verbreitung - unmöglich. Das sind klassische Probleme, mit denen wir auch heute noch zu tun haben, siehe den aktuell wieder in der Diskussion stehenden DROWN Angriff auf das uralte SSLv2, das immernoch in 30% der Webserver zum Einsatz kommt.

Ich habe letztens eine schöne Grafik gefunden:
Ca8N0HkW0AADKW2.jpg:large

Quelle: John Lambert auf Twitter: "My Kaspersky SAS keynote: Modern defenders are visualizing, sharing, and defending better: [url]https://t.co/tLfk2LufxZ https://t.co/abvRy82eoP"[/url]

Der letzte Punkt ist hier der wichtige: Es sollte uns hier nicht mehr um das Verhindern eines Angriffs gehen. Das ist nahezu unmöglich, denn Angreifer werden immer einen Weg finden - oder hast du in der Praxis schonmal ein "Mail-Rauschen" erlebt? Ich nicht. Also warum sollte ich dann Maßnahmen suchen, um ein Rauschen zu erzeugen? ;)

Im Fokus sollte vielmehr das Erschweren eines Angriffs stehen. Wenn die Entschlüsselung einer nicht als zeitkritisch einzustufenden Email 2 Minuten dauert, dann ist eine Entschlüsselung "large-scale" nicht mehr möglich.

Btw: Ich werde das Gefühl nicht los, dass es sich hier um Werbung für ein Projekt handelt. Der Begriff "negligible adversary advantage" führt bei Google zu dem gleichen Paper, das auch im o.g. Beitrag genannt wird. "Inzwischen bin [ich] fündig geworden" ist hier eher unglaubwürdig...
 
Zuletzt bearbeitet:
Danke für Deine Einschätzung, schwarze Beere. Aber es ist schon stark, dass Du hier die Werbungskarte ziehst. Ich suche übrigens über Disconnect me im Tor Browser.(Disconnect Search: Search privately using your favorite search engine). Und da werde ich zuerst auf den Wikipedia Eintrag geleitet und sehe viele Papers und Krypto-Manuskripte, aber keine Tools. Den deutschen Google-service mit Klar-IPadresse nutze ich aus Datenschutzgründen selbstverständlich nicht. Wenn ich über Disconnect me das Deutsche google wähle, finde ich auch als erstes den Wikipedia Eintrag. Der zweite ist dann schon unser Thread - Glückwunsch :-) Mit Deinem vorletzten Punkt bin ich überhaupt nicht einverstanden: Mir reicht es nicht, einen Angreifer auf meine Daten nur für 2 Minuten hinzuhalten. Deshalb suche ich doch gerade was stärkeres. Bei uns funktioniert der manuelle Schlüsselaustausch übrigens ganz gut.
 
Mir reicht es nicht, einen Angreifer auf meine Daten nur für 2 Minuten hinzuhalten. Deshalb suche ich doch gerade was stärkeres.

Ob eine Angreiferin in zwei Minuten merkt, dass es sich um eine verschlüsselte Datei handelt oder in zwei Stunden ist völlig unwesentlich. Entweder du bist einer gezielten Attacke ausgesetzt, dann ist bekannt, was du für Verschlüsselungssysteme einsetzt, oder du gerätst in die Massenüberwachungsmaschinerie. Dann reichen zwei Minuten, um die Kosten in die Höhe zu treiben und die Maßnahme somit wirtschaftlich als nicht lohnenswert zu entlarven.

Wir sprechen hierbei auch nicht von einer Entschlüsselung des Klartextes, sondern lediglich von der Identifikation des Ciphertextes als solchen. Die wirst du nicht verhindern können - wie gesagt: Es gibt für einen fähigen Angreifer faktisch kein "Email-Rauschen" - , sondern nur erschweren.

In Bezug auf andere Protokolle mag dein Ansatz sicherlich mehr Sinn machen. Auch würde ich dem Konzept zustimmen, wenn du z.B. lesbaren Text generierst und den Ciphertext noch zusätzlich steganographisch versteckst. Bis auf ein paar wissenschaftliche Ansätze gibt es hier in Bezug auf Email meines Wissens noch nichts.

Bei uns funktioniert der manuelle Schlüsselaustausch übrigens ganz gut.
Im kleinen Kreis gibt es immer eine Möglichkeit zum sichere Austausch von Informationen. Hierzu nutzt man im seltesten Fall Email, denn es gibt genügend Alternativen, die Sicherheit bereits im Design bedacht und nicht erst nachträglich dazu "gebastelt" haben, von Messaging Protokollen wie XMPP bis hin zu USB Sticks mit Kryptochips und verschlüsselten Dateisystemen. Das sollte also nicht die Messlatte sein.
 
negligible adversary advantage

Zu den 2 Minuten: Auch in der Massenüberwachung reichen zwei Minuten hinhalten nicht. Schon vor den Snowden Enthüllungen war bekannt, dass in Bluffdale, Utah ein NSA Datencenter gebaut wird, das so gross ist, dass der gesamte privaten Internetverkehr gespeichert und dann analysiert werden kann. Utah Data Center - Wikipedia, the free encyclopedia Es gibt also nicht entweder nur 2 Minuten oder die gezielte Attacke. Zum manuellen Schlüsselaustausch: E-Mail ist ein wunderbares Medium, um als Dateianhang beliebige Dateien, d.h. Chiffretexte von vertraulichen Dokumenten zu transportieren. Die Integration in irgendwelche Mailer bringt zwar möglicherweise Bequemlichkeit aber abgesehen davon nur zusätzliche Angriffsfläche. Wir haben mit GnuPG auch schon immer mit manuellen Schlüsselaustausch gearbeitet. Das ist auch weit verbreitet. Das Einstellen in Schlüsselserver bringt für vertrauliche Kommunikation viel mehr Nachteile als Vorteile. In dem NADA-Cap -Artikel, den du(schwarze Beere) oben erwähnst, steht ja ausserdem, dass durch vertraulichen Umgang mit dem öffentlichen Schlüssel als Gruppengeheimnis die Kommunikation sogar gegen den Quantencomputer sicher wird. Übrigens habe ich jetzt, wie du wohl auch, den NADA-Cap Artikel bei der "neglibible adversary advantage" Suche(google, de) auf der ersten Seite gefunden. Das hängt wohl davon ab, von wo aus und wann bei disconnect me gesucht wird. Zu der Identifikation des Ciphertextes als solcher und der Geheimhaltung des verwendeten Kryptosystems: Wenn die Rauschchiffre verwendet wird ist es eben nicht bekannt, welches Kryptosystem wir verwenden. Woher denn ? Und wer hindert uns daran, das ab und zu zu wechseln, wenn es andere Verschlüsselungsprogamme gibt, die das auch anbieten. Ich wünsche mir, dass GnuPG und Veracrypt mit seinen Containern und alle anderen auch solche Rauschformate anbieten, dann geht der Nutzen erst so richtig los und an manchen Stellen würde wirklich das Licht ausgehen. Bluffdale wäre zu einer gigantischen Halde für Rauschen und damit zu einer Investitionsruine geworden.
 
Zurück
Oben