PGP/GPG Sicherheit

[Badesalz]

Hallo

Mal so als Allgemeinthread zum Thema, wenn was anfällt. Aber auch, weil es sich grad eh so schön angeboten hat.

Jürgen Schmidt, der imho erklärte Feind von PGP und ein Fan von Signal...
(Signal, ist das hier
https://www.heise.de/security/meldung/Grosser-Lausch-Anruf-Signal-fuer-Android-nimmt-selbsttaetig-Anrufe-an-4546500.html)
... feiert einen neuen Meilenstein auf dem Weg zur Beerdigung von RSA

https://www.heise.de/security/meldung/Forscher-vermelden-neuen-Rekord-beim-Knacken-von-RSA-4603700.html

Der Schmidt fällt mir persönlich und subjektiv (?) nur mit einer Konstante auf: Er will PGP/GPG in der Kommunikation (Email) tot sehen. Was warum weswegen, das stellte er bisher imho nicht ganz klar.
Das stellt er in etwa genauso klar wie das warum man (wie oben im Link) jetzt nur 4096bit Schlüssel nutzen sollte. Was soll mit 2048 Schlüsseln denn sein? RSA-Keys kann min mind. in 256bit Schlüsseln steigern. Nicht in Kilobytes...
Sinnvollerweise in 512bit Schritten. Nach 2048 hat man also noch 2560 und dann 3072, 3584 und dann 4096. Und das geht bis 16384 so (*)
Und wir sollten jetzt lieber eh wenn denn nach ECC schauen (Elyptic Curves). Ja ok. Für welche so? ;)

(*)
Bekanntes "Problem" ist natürlich, mit jeder Verdopplung der Länge von RSA wird der Benutzer so in etwa 6 bis 7x langsamer beim Crypten.
Auf dem einen Kern des 2500k mit 4.5Ghz z.B., merkt man einen 4096 Schlüssel jedenfalls NICHT mehr (Emails egal wie lang nur mit Text).

Ist aber zweitrangig erstmal. Ich frag mich nur seit ner Weile was der Kryptoexperte bei Heise denn jetzt für einer ist. Der fällt mir irgendwie nicht positiv auf...

EDIT:
Richtigstellung von Golem ;) (mir fiel schon einige Male auf, daß sie den Kryptoevangelist von Heise wohl nicht so ganz mögen)
https://www.golem.de/news/rsa-240-faktorisierungserfolg-gefaehrdet-rsa-nicht-1912-145359.html

[Zafi]

Ich kenne ihn nicht, aber ich bin auch kein PGP/GPG-Fan bei Mails. Ich bin der Ansicht, dass es am Thema vollkommen vorbei geht.

Zuerst einmal ist es für den Normalsterblichen viel zu komplex einzurichten und anzuwenden. Gerade wenn man mit mehreren Anwendern kommuniziert und diese auch mehrere Mailadressen verwenden, muss man sich schon aktiv mit dem Thema auseinander setzen. Ein Fire-and-Forget gibt es hier nicht. Man muss es bewusst nutzen und verstehen, was man da macht.

Ein weiteres Problem ist, dass PGP/GPG bei Mails nicht wirklich verbreitet ist. Der Einstieg wird damit erschwert, denn für einen einzelnen Kontakt, der es nutzen will, möchte man sich nicht die ganze Arbeit machen und es bei sich einrichten. Und so greift man zu alternativen Lösungen, die schneller und einfacher gehen oder man verzichtet darauf.

Das nächste Problem ist das Lesen der Mails. Entweder gibt man jedesmal das Passwort für den Key ein, wenn man eine Mail lesen will (und jedesmal aufs neue, jedesmal wenn man sie wieder lesen will). Oder man hantiert mit Kartenlesern, um die Passwort-Eingabe zu umgehen. Was die ganze Sache noch komplexer macht.

Und schließlich ist da noch die Sicherheit als solches. Das diese praktisch garnicht gegeben ist, wenn man sich bei der Mail vertippt oder sie versehentlich an einen anderen Kontakt schickt. Den PGP/GPG weiß nicht, dass der Anwender einen Fehler gemacht hat und verschlüsselt es für den falschen Kontakt, der dann die Mail erhält und lesen kann.

Also unterm Strich: Riesengroßer Aufwand und marginale (und trügerische) Sicherheit.

Als Verschlüsselung kann man ja PGP/GPG so belassen. Aber die implementierung in Mail-Programme bedarf einer grundlegenden modernisierung, um es tatsächlich als Mailverschlüsselung einsetzen zu können. Ich persönlich kenne nämlich sehr viele Leute, die Bedarf hätten und die es auch mit PGP/GPG versucht haben. Aber keinen einzigen, der dabei geblieben ist.

[Badesalz]

Komplexität.
Das ist für mich keine prinzipielle Sache von PGP.
Ich hab das Jahre über Jahre auf dem Amiga genutzt und nur das grundlegendste der Grundlagen verstanden. Emails und Usenet über Mailboxing. Ich glaub die Soft hies MicroDot mein ich. Das unterstützte das vom Haus aus.

Dann hab ich das auf Wintel genutzt und habs erstmal weiter nicht wirklich verstanden, aber die freie 6er Version von PGP und ein Tool. War immernoch kein Thema.
Da ich das aber mit Outlook nutzen wollte, hat das schon viel weniger gebockt (da lästiger).

Und irgendwann bin ich auf Thunderbird gegangen und nutzte das mit Enigmail (und GnuPG eben). Da hab ich das meiste schon verstanden gehabt, ABER es garnicht gebraucht. Die Nutzung ist in dem Fall als wenn es eine build-in Lösung wäre. Das ist von der Nutzung und Benutzung (benutzerseitig) kaum anders als mit S/MIME.
S/MIME, was mit Efail gleich prinzipiell erstochen wurde. Wogegen bei PGP, nur die Implementierungen paar kleine Schnittwunden erlitten.

Der Realitätscheck außerhalb von Tb/Enigmail und TheBat gibt dir leider Recht. Trotzdem war und ist die "Komplexität" niemals ein prinzipielles Problem. Um die muss sich der Anwender nicht zwingend kümmern.

Das wird halt meist eben nur sabotiert. Selbst zwischen Tb und Enigmail gab es nach Efail... Kommunikationsprobleme, weil Mozilla sich lange nur blöd gestellt hat.

10 Jahre lang haben die Leute hinter GPGTools mit jedem Patch und jedem OSX-Update reverse engineering machen müssen, damit GnuPG mit "Mail" wieder läuft. NULL Feedback von Apple. Nur Steine im Weg. Jedes Mal.
(benutzt sich übrigens dann genauso einfach wie Enigmail/Tb, ist aber seit irgendwann 2018 nach diesen 10 Jahren nicht mehr frei :freak:).

Das obige beschreibt gleichzeitig auch die Probleme mit der Verbreitung. Wenn die Mailer selbst, das entweder komplett ignorieren oder es ohne Rücksicht auch ungewollt (?) immer wieder sabotieren, wirds schwierig. Das hat aber nichts mit PGP zu tun.
Wenn Chrome nun die Nutzung von AddBlockern sabotiert, meckert man über die Addblocker?

Bequemlichkeiten.
Das nächste Problem ist das Lesen der Mails. Entweder gibt man jedesmal das Passwort für den Key ein, wenn man eine Mail lesen will (und jedesmal aufs neue, jedesmal wenn man sie wieder lesen will).Sehe das Problem nicht. Es gibt Implementierungen welche die Passphrase für xx Minuten in ihrem Speicher halten. Das kann man dann auch auf mehrere Arten handeln. ZB. 20 Minuten lang nach deiner Eingabe oder 20min. nach dem letzten Aufruf usw. Sehe das Problem nicht.
Hat nichts mit PGP zu tun.

Sicherheit im Handling.
Und schließlich ist da noch die Sicherheit als solches. Das diese praktisch garnicht gegeben ist, wenn man sich bei der Mail vertippt oder sie versehentlich an einen anderen Kontakt schickt. Den PGP/GPG weiß nicht, dass der Anwender einen Fehler gemacht hat und verschlüsselt es für den falschen Kontakt, der dann die Mail erhält und lesen kann.Ist mir am Desktop noch nie passiert. Seit Amiga nicht ;)
Primär verschlüsselt man einen schützenswerten Kanal. Die minimale Sorgfalt bei der Wahl des Empfängers sollte also schon zu den paar Säulen der Sicherheitskette gehören.
Autos sind nicht unsicher, weil Leute beim Abbiegen nicht blinken. Wer so schusselig ist, der eignet sich ALLGEMEIN denkbar schlecht am Vertrauenswürdigen teilzunhemen. Sowas gehört eher zum personellen Ausschussverfahren :rolleyes:

Auch bei Signal & Co. klicken die Leute erstmal nur rum. Meist so grob, daß sie mal eben schnell auch nur nach Profilbildern(erkennung) wählen. Die ja nicht großartig riesig ausfallen. Wenn jetzt 2 Adressen eine ähnliche aussehende blaue Lagune als Profilbild haben, kann man seine Nachricht auch mal an die falsche Person verschicken.
Was mir übrigens mit WhatsApp genau deswegen auch mal passiert ist. Die fanden das Bild beide so toll... und ich schrieb dann kurz etwas an meine Schwägerin, statt an meine Frau :ulol:

Als Verschlüsselung kann man ja PGP/GPG so belassen. Aber die implementierung in Mail-Programme bedarf einer grundlegenden modernisierung, um es tatsächlich als Mailverschlüsselung einsetzen zu können. Ich persönlich kenne nämlich sehr viele Leute, die Bedarf hätten und die es auch mit PGP/GPG versucht haben. Aber keinen einzigen, der dabei geblieben ist.Kann man so stehen lassen. Das alles ist aber wie gesagt nicht PGP anzulasten. Sich wie Jürgen Schmidt nun daran aufgeilen, daß <1024bit Schlüssel geknackt werden, finde ich eher peinlich.

[qiller]

...
Den PGP/GPG weiß nicht, dass der Anwender einen Fehler gemacht hat und verschlüsselt es für den falschen Kontakt, der dann die Mail erhält und nicht lesen kann.
...

Hab obiges mal korrigiert.

Edit: Achso, jetzt erst verstanden, Obiges wieder ignorieren :F. Aber das hat nix mit PGP zu tun, das ist mir auch komplett ohne PGP schon passiert, wenn man zu schnell Adressen aus der Vorauswahl nimmt und bei ähnlich lautenden Kontakten nicht genau hinschaut.

[Badesalz]

Naja er hat schon Recht. Wenn du mehrere Personen mit PGP hast und den falschen Empfänger wählst, geht die Nachricht, verschlüsselt, an den falschen und nicht an den richtigen ;)

Wie aber gesagt hätte ich erstmal keine Idee wie man falschen Empfänger wählen können zum Pferdefuß eines verschlüsselten Kommunikationskanals stilisieren könnte. Die paar wenige Pflichten um die Vertrauenswüdigkeit zu erhalten sollte man schon SELBST wahrnehmen.
Das kann nicht komplett alles die Maschine erledigen. Oder man lässt sie dich mit den gleichen Request rumnerven wie zb. vor dem Format-Befehl :ulol:

Letztendlich ist das wohl für jeden schon ok so, daß unsere Gehirne nicht nur aus dem Hypothalamus bestehen... Oder nicht?

edit:
Eben. Hat nichts mit PGP zu tun.

[iuno]

Man muss es bewusst nutzen und verstehen, was man da macht.

Ein weiteres Problem ist, dass PGP/GPG bei Mails nicht wirklich verbreitet ist. Der Einstieg wird damit erschwert, denn für einen einzelnen Kontakt, der es nutzen will, möchte man sich nicht die ganze Arbeit machen und es bei sich einrichten. Und so greift man zu alternativen Lösungen, die schneller und einfacher gehen oder man verzichtet darauf.
Ja, so ist das auch gedacht.


Was ist denn deiner Ansicht nach so eine Alternative, wenn Verzicht keine Option ist (was in den meisten Faellen gegeben sein duerfte)?


Das nächste Problem ist das Lesen der Mails. Entweder gibt man jedesmal das Passwort für den Key ein, wenn man eine Mail lesen will (und jedesmal aufs neue, jedesmal wenn man sie wieder lesen will). Oder man hantiert mit Kartenlesern, um die Passwort-Eingabe zu umgehen. Was die ganze Sache noch komplexer macht.

Ich weiss jetzt nicht welche Software du benutzt, aber der gpg-agent cacht standardmaessig Passphrasen. Die Behauptung, man muesse bei jeder Mail das Passwort eingeben, ist Unsinn.

Und schließlich ist da noch die Sicherheit als solches. Das diese praktisch garnicht gegeben ist, wenn man sich bei der Mail vertippt oder sie versehentlich an einen anderen Kontakt schickt. Den PGP/GPG weiß nicht, dass der Anwender einen Fehler gemacht hat und verschlüsselt es für den falschen Kontakt, der dann die Mail erhält und lesen kann.

Also unterm Strich: Riesengroßer Aufwand und marginale (und trügerische) Sicherheit.

Also, ich kann ja einen grossen Teil der Kritik an PGP nachvollziehen, aber hier wird es laecherlich. Es ist unsicher weil der Anwender den falschen Kontakt auswaehlen kann. Ist das dein Ernst?

Als Verschlüsselung kann man ja PGP/GPG so belassen. Aber die implementierung in Mail-Programme bedarf einer grundlegenden modernisierung, um es tatsächlich als Mailverschlüsselung einsetzen zu können. Ich persönlich kenne nämlich sehr viele Leute, die Bedarf hätten und die es auch mit PGP/GPG versucht haben. Aber keinen einzigen, der dabei geblieben ist.
Das wird doch bereits gemacht (z.B. mit PEP). Hat halt auch wieder seine Nachteile.

Und bei mir ist es so, dass ein groesserer Teil meiner Mailkontakte PGP benutzt. Ich verschicke und erhalte mehr PGP Mails als "normale". Dabei rede ich von richtigen Kontakten, also Bestellbestaetigung vom Online-Shop etc. ausgenommen.


OpenPGP wird uebrigens demnaechst in Thunderbird integriert. Weil Enigmail noch ein legacy Addon ist, dementsprechend raus faellt und die TB devs die Funktionalitaet als hinreichend wichtig empfunden haben. Wurde auch Zeit, denn andere Clients (KMail, Evolution) unterstuetzen es schon ewig.

Das groesste Hemmnis fuer OpenPGP sind doch aktuell Webmailer und Smartphones. Und diejenigen, die diese betreiben haben natuerlich auch kein Interesse an PGP.

[Badesalz]

Ich will jetzt nicht darüber philosophieren, ob eine verbale Strenge einem Dískussionsverlauf eher schadet oder gelegentlich doch nützt, aber in dem Fall halte ich sie dem bisherigen Verlauf nach für schlicht unnötig ;)

Das groesste Hemmnis fuer OpenPGP sind doch aktuell Webmailer und Smartphones. Und diejenigen, die diese betreiben haben natuerlich auch kein Interesse an PGP.An sich und vor allem (imho) sind es die Mailer selbst, die sich einen feuchten Dreck drum scheren. Meist nicht mal drum, daß Dritte sich bei der Implementierung nicht direkt abkämpfen müssen. Wobei...

OpenPGP wird uebrigens demnaechst in Thunderbird integriert. Weil Enigmail noch ein legacy Addon ist, dementsprechend raus faellt und die TB devs die Funktionalitaet als hinreichend wichtig empfunden haben. Wurde auch Zeit, denn andere Clients (KMail, Evolution) unterstuetzen es schon ewig.Ich sehe soetwas erstmal immer skeptisch. Man gibt das sozusagen aus der Hand. Sachen die nicht passen, darüber war ich meist in 2 Tagen mit Brunschwig durch... Ich hab hier irgendwo noch sogar seine Privatemail :ulol:

Wenn auch das noch die 10 (?) Entwickler von Tb managen sollen... Die kriegen ganz andere Sachen weiterhin nicht gebacken. Es sei denn er wird für den Part der Entwicklung zeichnen. Dann wäre das top :up:

[Ganon]

Als ersten Schritt müsste man meiner Meinung nach gar nicht bereits verschlüsseln. Es wäre schon ein großer Fortschritt wenn alle Mails von großen Unternehmen wenigstens signiert wären.

[Zafi]

Ich weiss jetzt nicht welche Software du benutzt,

Erst Mitte letzten Jahres habe ich mich wieder damit beschäftigen müssen, weil im Zuge der DSGVO viele Anwender sensibilisiert wurden, die mit Patientendaten zu tun haben. Und da Windows und Outlook die Wahl der meisten dieser Anwender ist, habe ich mir eindringlich GPG4Win angesehen. Es liegt schon über ein Jahr zurück, aber das man beim Lesen jeder Mail aufs neue ein Passwort eingeben musste (Standard-Einstellung), hat sich dann doch in meinen Kopf fest eingebrannt.

Selbst wenn sich das ändern lässt, ist es doch nur eins von mehreren Hindernissen, die solch eine Verschlüsselung im täglichen Umfeld unbrauchbar machen. Die typischen beruflichen Mail-Anwender sind ja bereits mit Outlook total überfordert und haben damit oft genug Probleme. Ihnen dann auch noch eine unbehäbiges Verschlüsselssystem auf Outlook aufzudrücken, ist dann der Overkill.

Was ist denn deiner Ansicht nach so eine Alternative,

Meiner Ansicht nach gibt es keine Lösung und somit auch keine Alternativen. Denn das Ganze ist - trotz all der Jahre - einfach noch unausgereift, um es im beruflichen Umfeld zu verwenden. Allein schon der Umstand das nicht jedes Mailprogramm verwendet wird und auch nicht jedes Outlook, macht die Ganze Sache ziemlich unsicher.

Aber falls du eine Alternative suchst. Meine Kunden haben für sich eine entdeckt. Und zwar verwenden sie verschlüsselte Container und schicken diese per Mail an die Patienten, während sie ihnen das Passwort per Telefon mitteilen. Am beliebtesten ist dabei kein klassisches Verschlüsselungsprogramm, sondern ein stink-normales ZIP-Programm, dass dann auch garantiert jeder Empfänger öffnen kann. Tja, in der Not frist der Teufel Fliegen.

[iuno]

@Badesalz: Soll ich das so verstehen, dass mein Beitrag verbal zu "streng" war? Falls ja, kannst du das vielleicht naeher ausfuehren, damit man daran arbeiten kann. Das war naemlich so nicht gedacht und auch im Nachgang kann ich es nicht erkennen.

Und gut, dass OpenPGP die TB devs ueberfordern soll, glaube ich ehrlich gesagt mal nicht. Das kann wie gesagt eigentlich jeder Popel-Client. Man sollte ja auch nicht PGP implementieren sondern bestehende Software (GnuPG/gpg4win) nutzen, hat Enigmail ja auch gemacht.

Ich muss dir in dem einen Punkt allerdings recht geben. Ich habe gerade mal die folgende Quelle bemueht: https://emailclientmarketshare.com/
Solange die Daten einigermassen brauchbar sind, muss ich die vorige Aussage revidieren (edit: stimmt gar nicht, mobile clients hatte ich ja auch genannt ;) ). Dass mehr Leute iOS Mail als Gmail benutzen haette ich nicht gedacht.
Aber das grundlegende Problem sieht man an der liste auch deutlich: Kein einziger der vorderen Plaetze hat Interesse an OpenPGP. Die vertretenen Unternehmen verfolgen kontraere Ziele, man laesst sich da ja sogar die Befugnis geben, Mails der Kunden zu "analysieren".
Mit TB ist dann zwar ein einziger Client, mit dem OpenPGP noch einigermassen funktioniert, gerade noch unter den Top 10, aber halt auch nur mit <0,5%.

@Zafi: dein Problem ist doch ganz klar Outlook und nicht OpenPGP.
Und schade, dass erst auf Alternativen verwiesen, dann aber keine genannt werden kann. ZipCrypto ist natuerlich viel zu schwach, um als Alternative gewertet werden zu koennen. Patientendaten damit zu verschicken finde ich hoechst fahrlaessig. Dann kann man es sich grad sparen, weil dann verzichtet man lieber ganz auf den Versand und geht nicht faelschlicherweise davon aus es sei sicher.

[noid]

@Badesalz: Soll ich das so verstehen, dass mein Beitrag verbal zu "streng" war? Falls ja, kannst du das vielleicht naeher ausfuehren, damit man daran arbeiten kann. Das war naemlich so nicht gedacht und auch im Nachgang kann ich es nicht erkennen.

Und gut, dass OpenPGP die TB devs ueberfordern soll, glaube ich ehrlich gesagt mal nicht. Das kann wie gesagt eigentlich jeder Popel-Client. Man sollte ja auch nicht PGP implementieren sondern bestehende Software (GnuPG/gpg4win) nutzen, hat Enigmail ja auch gemacht.

Ich muss dir in dem einen Punkt allerdings recht geben. Ich habe gerade mal die folgende Quelle bemueht: https://emailclientmarketshare.com/
Solange die Daten einigermassen brauchbar sind, muss ich die vorige Aussage revidieren. Dass mehr Leute iOS Mail als Gmail benutzen haette ich nicht gedacht.
Aber das grundlegende Problem sieht man an der liste auch deutlich: Kein einziger der vorderen Plaetze hat Interesse an OpenPGP. Die vertretenen Unternehmen verfolgen kontraere Ziele, man laesst sich da ja sogar die Befugnis geben, Mails der Kunden zu "analysieren".
Mit TB ist dann zwar ein einziger Client, mit dem OpenPGP noch einigermassen funktioniert, gerade noch unter den Top 10, aber halt auch nur mit <0,5%.

@Zafi: dein Problem ist doch ganz klar Outlook und nicht OpenPGP.

Das Problem von Zafi ist nicht Outlook, sondern dass die Verschlüsselung nicht by-design im Thema email enthalten ist. Solange man aber dann kein Monopol bei der Infrastruktur hat, also Clients und Server, dann wird sich sowas nie durchsetzen.

[iuno]

Unsinn. Mail ist verteilt by design. D.h.
- es muss es sich ueberhaupt niemals durchsetzen. Wer es benutzt, benutzt es (seit vielen Jahren) und der Rest halt nicht.
- falls es sich "durchsetzen" soll, braucht es dazu kein Monopol, sondern eine kritische Masse. HTML E-Mails, ist wie e2ee auch so ein Beispiel, das clientseitig gemacht werden muss. Serverseitig musst du da gar nichts machen*. Und HTML hat auch (fast) jeder implementiert, weil die Leute es halt wollten und sonst was anderes benutzt haetten.
Die Nachfrage ist viel zu gering. Von selbst kommt da von Apple, Google, MS (man hat sie ja oben gesehen) nichts.

Und, sorry. Wenn ein Arztpraxis (willkuerliches Beispiel) dann halt meint, Outlook benutzen zu muessen weil (warum eigentlich, der Grund ist im Prinzip aber egal), man dafuer aber keine brauchbare E2EE bekommt, dann sind die Prioritaeten einfach voellig falsch gesetzt.

Sofern dein Geschaeftsmodell im Angebot eines Maildienstes liegt und nicht aus dem Auswerten der E-Mails deiner Kunden besteht.


Uebrigens, mal so als Gegenbeispiel: S/MIME wurde vor Ewigkeiten von vielen Clients implementiert, darunter auch Apple und Outlook. Benutzt trotzdem kein Schwein.

[Badesalz]

@iuno
Dachte so an "Unsinn" und "lächerlich", aber letztendlich wars nur halb so schlimm ;)
Und gut, dass OpenPGP die TB devs ueberfordern soll, glaube ich ehrlich gesagt mal nicht. Das kann wie gesagt eigentlich jeder Popel-Client. Man sollte ja auch nicht PGP implementieren sondern bestehende Software (GnuPG/gpg4win) nutzen, hat Enigmail ja auch gemacht.
1. Am Tb selbst kritzeln mein ich ZEHN Leute. Das ist jetzt nicht besonders viel.
2. Mal die Features und Fixes von Enigmail nur in den letzten 5 Jahren durchgezählt und auch drübergeschaut was es so alles gab? Mach das mal. Das ist Jahr für Jahr, nichts triviales. Und der Brunschwig macht das seit 2003.
https://www.golem.de/news/e-mail-verschluesselung-90-prozent-des-enigmail-codes-sind-von-mir-1811-137612.html

Der sagt da übrigens was ich immer schon sagte. Am Add-on System um Fx28 rum ist nichts auszusetzen gewesen. Den haben uns im Auftrag ihres Herren irgendwelche Uboote klugscheissend kaputtgeredet.
Mit dem neuen Bullshit haben wir primär nur die eigene Kontrolle darüber abgegeben, was der Browser (ergo auch Thunderbird als ewig leidtragender dessen) wirklich tut und was er nicht zu tun hat. Heutzutage ist schon fast egal, ob man Chrome oder Firefox nimmt.
Wenn man heute aktuelle Firefoxe nimmt, kann man auch die SPD wählen. Die ist auch in der Groko.

@Zafi
Sagen wir mal:
Man braucht Mailer mit entsprechenden APIs und auch einen, deren Umorganisation (API) einen NICHT SABOTIERT.
Man braucht einen Plugin.
Man braucht GnuPGP/OpenPGP.

Alles was du bemängelst liegt im obigen Beispiel am Plugin. Und gibt es so auch nicht in Tb/Enigmail oder TheBat. Das Problem ist natürlich die Durchdringung.
Warum sollte MS jemanden beim Thema Privatsphäre oder Vertrauenswürdigkeit helfen? Das ist aktuell wie damals gegen die Interessen des Vaterlandes. Sie haben auch brav Dual_EC_DRBG implementiert. Was sollte also Outlook mit OpenPGP anfangen sollen bitte? Sie hatten doch eh schon S/MIME ;)

Und eben, daß die übrigen Mailer OpenPGP nicht den feuchten Dreck interessiert. Weil "Wir haben doch S/MIME. Das ist der bewährte Verschlüsselungsstandard weltweit."
Ja. Das ist ja auch wie gesagt mit Efail weltweit komplett explodiert. ENDLICH. Und iIm Gegensatz zu den paar kleinen Schnittwunden welche Implementierungen von OpenPGP abbekamen (weniger zB. GnuPG selbst)

Wer wirklich eine bescheuerte Kryptolösung fahren mochte/möchte, der kann sich mal erstmal auf den Weg machen sich ein S/MIME Zertifikat zu besorgen.
Un-glaub-lich was für ein Dreck das schon damals gewesen ist.

Ich weiß nicht mit welchen Tools und Programmen, aber ich meine VW hat PGP (GnuPG?) im bestimmten Mailverkehr eingesetzt (!!) Ich weiß nicht wie lange, aber was ich damals gelesen habe, war das keine 1jährige Studie oder so. Die hatten (haben??) das also produktiv am laufen gehabt.

weil im Zuge der DSGVO viele Anwender sensibilisiert wurden, die mit Patientendaten zu tun habenKann gut sein. Meine Mutter hatte vor Jahren Probleme mit einem Knie und hatte vom Arzt eine CD per Post zugeschickt (:freak:) bekommen. Interessierte mich als passionierten Bildanalytiker ;) wie die Bilddaten aussehen. Hab bis dato noch nie gesehen sowas. Wunderte mich am Anfang auch schwer wohl über die Formate, weil die CD fast 400MB hatte.
Ja... da waren die kompletten Krankenakten von um die 160 Leuten. MIT ALLES. Von meiner Mutter natürlich auch. Die Arzthelferin hat den ganzen Ordner rüberkopiert. Da brauchst du dir keinen Kopf um OpenPGP machen.

@noid
Ich weiß es grad selbst nicht. Ist Verschlüsselung "by-design" in ext oder NTFS enthalten gewesen?

[iuno]

Zuvor nicht, jetzt schon. Das meiste sind Bugfixes und die haben mit dem Aufwand einer Integration erstmal gar nichts zu tun. Auch die Angabe "in 5 Jahren ist viel passiert" ist so fuer sich allein voellig nichtssagend.
Den Grossteil haette ich in Autocrypt/PEP gesehen und so ist es dem Changelog nach auch. Das braucht man fuer eine OpenPGP Implementierung im Mailclient aber auch nicht unbedingt, und auch nicht von Anfang an.

Ich kann gerade nicht erkennen, ob der Browser deiner Ansicht nach mehr oder weniger Kompetenzen haben sollte. Falls es noch Themabezug hat, koenntest du das ja mal ausfuehren.

[Badesalz]

Ich bezweifelte da auch nicht die Fähigkeit bezüglich der Integration, sondern eben des Bugfixings.
Wobei ich dem trotzdem nur trauen würde, wenn Patrick bei der Umsetzung noch AKTIV mitwirkt, denn rein integrieren wird man es wahrscheinlich nicht, also muss einiges implementiert werden. Richtig?

Ich kann gerade nicht erkennen, ob der Browser deiner Ansicht nach mehr oder weniger Kompetenzen haben sollte.Das war eine Frage der Möglichkeiten, nicht einer Kompetenz. Vielleicht verstehe ich das aber nur nicht richtig. Mein Gehirn erstellt grad leider keine beinflussenden Korellationen, wenn in einem Satz "Browser" und seine "Kompetenz" fallen. Sorry...

Wenn es um die Engine drunter geht, hat Tb mit dem Fx immer ein Themabezug. Leider. Das Kind ist aber eh schon längst in dem Brunnen ersoffen worden.

Denn immer, wenn du etwas langjährig gereiftes und wunderbar flexibles in der Hand hälst, wo jeder der es kann, alles machen kann, wenn er Bock drauf hat, und das mit dir auch teilen kann, kommt ein Haufen Idioten - oder ein Haufen Uboote, gefolgt von einem Haufen Idioten - und erzählt dir, daß "jeder" aber auch die Bösen sein können, wenn du nicht aufpasst. Und du dann so -> "Nein! Doch! Oh!"

Und es auch noch dieses Meer an Unbedarften gibt, die sich sowas böses fangen können und dann wird alles zusammenbrechen. Das Aufpassen kann also nicht mehr dir selbst überlassen werden. Denk doch mal an die Schwachen und sie nicht so egoistisch bitte. Das muss nun also unbedingt vom gebotenen wieder eingeschränkt werden und am besten direkt in eine Sandbox.

Natürlich. Weil... Sandboxen oder auch UAC & Co., Softwareschädlinge nahezu ausgemerzt haben. Das weiß halt jeder der eine HTML-Seite bedienen kann. Richtig? Und jetzt spätestens seit es WebExtensions gibt, niemand mehr sich einen Virus im Netz fängt. Und deswegen bricht auch nichts zusammen.
Also alles nur Geil für dich. Weil du dir wie sonst jährlich zu Weihnachten den Rechner von Onkel Helmut anschaust und da diesmal keine 24 Viren um die CPU und die Bandbreite wetteifern. Weil du ihm letztes Jahr eben Firefox mit WebExtensions ausfgespielt hast. Alles top jetzt. Richtig?

Und sowieso, mal ehrlich, das Add-on System ist kurz vorm Ermeucheln wie alt gewesen? Das soll noch zeitgemäß und MODERN gewesen sein? Also ehrlich, was gibt das och für ein Bild ab, gegenüber der... Konkurrenz wie auch der Userschaft? Eben.

https://www.reddit.com/r/firefox/comments/6cw7ig/why_is_firefox_moving_to_web_extensions_and_why/

https://palant.de/2017/11/11/on-web-extensions-shortcomings-and-their-impact-on-add-on-security/

ps:
Achtung :usweet: Obiges könnte Spuren von Sarkasmus enthalten.

[iuno]

Das hat er doch bereits zugesagt oder nicht?

"Kompetenz" im Sinne von "Zustaendigkeit". Ja ok, vielleicht nicht die beste Wortwahl.

Der Rant ueber WebExtensions hat mir die Frage jetzt nicht beantwortet. Ausser dass ich jetzt weiss, dass du alles moegliche mit Addons machen koennen willst.
Uebrigens hat du da glaube ich etwas falsch verstanden. Sandboxing sollte nie dazu dienen, "Schaedlinge auszumerzen", sondern man hat verstanden, dass das nicht gelingt und versucht darueber stattdessen deren Einfluss einzugrenzen.

[Badesalz]

Er hat geschrieben, daß er das machen würde (Datum beachten). Ich weiß bis jetzt nicht, ob ihn schon jemand gefragt hat...

Welche Frage? Von "Zuständigkeit"? Davon kann man nur sprechen, wenn man überlegt wo die Funktionalität nun verbaut wird.
Für mich soweit kein Problem. Wenn sie in Firefox die Funktionalität der ~70.000 Add-ons einbauen, kann die größere Zuständigkeit beim Browser bleiben... Dann braucht man sich auch nicht um die Schwachen sorgen, die dann wieder ne Weile rein garnichts mehr davon haben
https://discourse.mozilla.org/t/fixed-certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047

Ausser dass ich jetzt weiss, dass du alles moegliche mit Addons machen koennen willst.Das ist mein ich allgemein die Idee dahinter (gewesen). Wobei "alles" ging sowieso noch nie.

Uebrigens hat du da glaube ich etwas falsch verstanden. Sandboxing sollte nie dazu dienen[…]Ich weiß... wozu Sandboxing da ist...
Die Analogie, samt ähnlichen Nebeneffekten, zu CCTV, gefällt mir übrigens sehr gut.

[iuno]

Ich rede nicht von dem Golem-Interview, sondern von der Ankuendigung, wo diese Aussage gemacht wurde. Die ist von Oktober.
https://mail.mozilla.org/pipermail/tb-planning/2019-October/007071.html

[Badesalz]

DAS ist bestens. Top! :smile:

[Badesalz]

Amateure at work

https://www.golem.de/news/bsi-openpgp-ja-nein-vielleicht-1912-145677.html

[lumines]

Für was benutzt ihr PGP eigentlich genau? Ehrlich gesagt beschränkt sich meine PGP / GPG-Nutzung darauf Signaturen von ISOs und einigen Open-Source-Programmen zu checken. Wobei ich ehrlich gesagt für Signaturen signify aus OpenBSD bevorzuge, weil es deutlich einfacher zu handhaben ist als GPG und auf den uralten Kryptorattenschwanz verzichtet, den GPG als Referenzimplementierung von OpenPGP immer mitschleppen wird. Mich würde ehrlich gesagt auch nicht wundern, wenn die ganzen Linux-Distributionen auf lange Sicht auf ein ähnliches Modell umsteigen.

Ich habe es auch einige Zeit für pass (https://www.passwordstore.org/) benutzt, aber irgendwann bin ich dann doch auf 1Password umgestiegen.

Ansonsten fallen mir eigentlich wenige valide Anwendungsfälle ein. E-Mail benutze ich als nicht-vertrauenswürdiges Medium. Dateien verschicke ich an andere Leute per magic-wormhole (https://github.com/warner/magic-wormhole) (auch für Windows-Nutzer dank WSL kein Problem) oder Signal.

Bei Legacy-Systemen kann ich verstehen, dass man sich vielleicht irgendwann darauf festgelegt hat und jetzt nicht mehr davon wegkommt. Aber generell finde ich für E-Mail-Nutzung PGP eher gruselig.

Man sollte auch nicht vergessen, dass es für Webmailer praktisch unmöglich ist PGP korrekt zu implementieren. Entweder müssen sie dafür Browserextensions voraussetzen (welche mit Smartphones nicht funktionieren) oder liefern ihre OpenPGP-Implementierung in JavaScript aus, was PGP zu einer (schlechten) Transportverschlüsselung degradiert.

Ansonsten interessiert mich PGP aber auch nicht besonders. Seit ich pass nicht mehr benutze, brauche ich es eigentlich nicht mehr mehr wirklich.

[Badesalz]

Was GPG alles dabei hat oder nicht, ist doch völlig egal. Für den Benutzer ist der Frontend wichtig. Uns beide vielleicht schon, aber was interessiert sonst einen nur auch interesiserten Laien was da alles passiert, wenn er Tb/Engimail nutzt?
Kein Plan warum man das eher nicht benutzen sollte, weil es nervt, daß auch noch CAST5 dabei ist. Wen interessiert sowas? Jetzt mal davon ab,daß der weiterhin sicher ist ;)

Ich benuzte es für Email. Mit paar interessierten Freunden. Alle auf Tb/Enigmail. Selbst der Kryptoschwächste hat das nach ner Weile geschnallt und nutzt es wie jede andere Soft auch. Ausser die Passphrase mal ggf. alle xx Minuten neu vom KeePass zu copypasten hat er damit auch nichts anderes am Hut.
Läuft bis auf jenes wie jede andere Mail im Tb.

Für mehr taugt das von den vorhandenen Lösungen (für Endbenutzer) imho auch nicht. Jedenfalls was den Durchschnittsbenutzer angeht.
Muss aber auch nicht. Für alles andere gibt es auf jeder Platform genug Tools, falls die Userschaft oft und lantge genug das Internet danach fragt ;)

Signal ist Stück neuer als GPG :ulol: Und hatte schon ganz andere Probleme als die, die direkt GPG betrafen. Sonst halte ich das gerne am leben, weil das eine Lösung ist die "WIR" in der Hand halten. Und nicht irgendein Konzern.
Und das ist vor allem soweit durchgecheckt und wird das immer wieder mal, daß man sich keine Gedanken machen muss, ob die Implementierung der gewählten Methoden genauso gut ist wie die Methoden selbst.

Wenn man Webmailer nutzt, tut man nichts was den Schutz durch GPG rechtfertigen würde. Das wäre sowas wie sicheres Onlinebanking auf dem Smartphone.
Wenn ich daheim bin, brauch ich kein Webmailing. Wenn ich unterwegs bin, brauch ich kein OpenPGP.

Da s/mime ja ALLEN um die Ohren geflogen ist, interessiert sich irgendwie der Staat für GnuPG. Früher bisschen (und endlich) später gar bisschen mehr. Jedenfalls half man nu sogar soweit...
https://gnupg.com/20200107-freigabe-vs-nfd.html

Erstmal ist also schonmal Ende mit dem peinlichen Chiasmus Blödsinn. Immerhin ;) Warum man da nicht lieber auf Signal umstieg, das hab ich noch nicht rausgefunden :whistle:

[iuno]

Für was benutzt ihr PGP eigentlich genau?
Wie du fuer Signaturchecks, aber auch "intern" bei unterschiedlichen Sachen, mit oder ohne git.
pass (kennst du ja). Fuer mich der komfortabelste Passwortmanager. Wir benutzen das auch im Team, natuerlich mit eigenen stores, was aber auch einfach zu handhaben ist.
Und selbstverstaendlich im Zusammenhang mit E-Mails.

Wenn ich daheim bin, brauch ich kein Webmailing. Wenn ich unterwegs bin, brauch ich kein OpenPGP.
Das sehe ich auch so, wobei ich nicht "daheim" sagen wuerde, sondern halt an einem meiner entsprechenden Geraete. Die haben vernuenftige Mail Clients und ich logge mich natuerlich auch nicht auf einem fremden Rechner per Webmail ein, hat also ueberhaupt keine Relevanz.

Ich weiss auch nicht, warum ich Signal benutzen sollte. Dafuer, dass man sich auf einen vendor lockt und zwingend eine Telefonnummer braucht, sehe ich keinen Vorteil und der Client taugt mir auch nicht. Axolotl double ratchet war vielleicht ne gute Sache, aber das wird inzwischen auch von anderen implementiert.

[lumines]

Sonst halte ich das gerne am leben, weil das eine Lösung ist die "WIR" in der Hand halten. Und nicht irgendeine Firma.

Na ja, du bist komplett von der IETF Working Group zu OpenPGP abhängig, weil GPG sich exakt an das hält, was dort beschlossen wird. Werner Koch scheint auch viele Probleme einfach zu ignorieren.

Und das ist vor allem soweit durchgecheckt und wird das immer wieder mal, daß man sich keine Gedanken machen muss, ob die Implementierung der gewählten Methoden genauso gut ist wie die Methoden selbst.

Was genau meinst du damit? GPG hat haufenweise Probleme, die einfach ignoriert werden.

Wenn man Webmailer nutzt, tut man nichts was den Schutz durch GPG rechtfertigen würde.

Genau, das würde man auf andere Kanäle verlagern und E-Mail als unsicheres Medium betrachten.

Ich weiss auch nicht, warum ich Signal benutzen sollte. Dafuer, dass man sich auf einen vendor lockt und zwingend eine Telefonnummer braucht, sehe ich keinen Vorteil und der Client taugt mir auch nicht. Axolotl double ratchet war vielleicht ne gute Sache, aber das wird inzwischen auch von anderen implementiert.

Signal ist eben Vorreiter, weil die komplette UX auf eine sichere Nutzung ausgelegt ist. In der Hinsicht ist es das komplette Gegenteil von PGP-verschlüsselten E-Mails.

Ich würde auch nicht einmal behaupten, dass Signal die große Alternative zu E-Mails ist. Im Grunde ist aber praktisch alles besser als PGP-verschlüsselte Mails.

[Badesalz]

Welche...Probleme...?

Wenn die NASA weiter eine FAQ hat, wie man seine Workloads an die Admins der Mainframes per Mail verschickt, und man dafür GnuPG nutzt, dann kann das nicht so dramatisch sein.
Falls du irgendein Gammelzeug meinst was noch vom Efail übrig sein soll, nein. Ich hab mit Schinzel darüber etwa 2 Wochen immer wieder mal diskutiert. Nein, überhaupt garnichts.

weil die komplette UX auf eine sichere Nutzung ausgelegt ist. In der Hinsicht ist es das komplette Gegenteil von PGP-verschlüsselten E-MailsIch verstehe solche Sätze nicht. UX ist für mich user experience. Ja, die UX von Signal ist komplett was anderes als eine E-Mail. Auch als eine die mit PGP verschlüsselt wurde.

Aber auch ein Glas Nutella ist das komplette Gegenteil von einem Fernseher. Man kann viele solche Beispiele finden, nur was kann man damit erklären? GnuPG hat weder mit UX noch mit UI was am Hut.
Wieso sollte es das auch? GnuPG ist der Treiber, für die Soundkarte. Die Musik macht (hier) Aimp. ÜBer all die Aimps kann man wunderbar diskutieren. Über GnuPG kaum.

[iuno]

Signal ist eben Vorreiter, weil die komplette UX auf eine sichere Nutzung ausgelegt ist. In der Hinsicht ist es das komplette Gegenteil von PGP-verschlüsselten E-Mails.
Wenn das unterbewusst lustig heissen soll, dass das schlecht benutzbar ist, dann ja.

Ich würde auch nicht einmal behaupten, dass Signal die große Alternative zu E-Mails ist. Im Grunde ist aber praktisch alles besser als PGP-verschlüsselte Mails.
Signal ist absolut unpraktisch am PC.

Aber ja, das ist wohl auch nicht als Alternative fuer E-Mails gedacht, auch wenn es von manchen so empfohlen wird.

[Badesalz]

Was die ganzen Signal-Evangelisten bewegt, manche sogar umhertreibt, das peil ich schon. Keine Bange.

Ob das aber zielführend ist, daß sie dabei immer wieder mal, versuchen GnuPG anzupissen, das glaub ich kaum, daß dies zielführend sein kann.

Schon garnicht, wenn man das mit Leuten vorhat die es interessiert nutzen und es auch verstanden haben. Dieser Umstand hievt sie nämlich zwangsläufig auf einen ausreichend hohen Level, um sich nicht irgendeinen Quark erzählen zu lassen.

Auch ein Jürgen Schmidt übrigens möchte das wohl noch nicht ganz verstehen. Macht aber überhaupt nichts ;)

Bis denne.

[lumines]

Signal ist absolut unpraktisch am PC.

Ich benutze es auch nicht am PC.

Aber ja, das ist wohl auch nicht als Alternative fuer E-Mails gedacht, auch wenn es von manchen so empfohlen wird.

Es ist für Messaging geeignet, wofür einige Leute stattdessen E-Mail + PGP verwenden.

Vor zehn oder fünfzehn Jahren hat man noch XMPP oder IRC mit OTR benutzt. E-Mail und PGP war durch die fehlende Forward Secrecy dafür noch nie eine gute Idee. Zumal ich Badesalz Anwendungsfall noch weniger verstehe, wenn er sowieso PGP nur am Desktop verwendet. Es gibt genug Protokolle, die dafür besser geeignet sind.

Schon garnicht, wenn man das mit Leuten vorhat die es interessiert nutzen und es auch verstanden haben.

Absolut niemand versteht PGP. Es ist nicht einmal so wirklich klar, was PGP überhaupt ist oder welche Probleme es löst.

Es gab in der Vergangenheit haufenweise Ideen und Konventionen oder Workflows zu PGP (z.B. Operational PGP), wie man es für bestimmte Anwendungszwecke halbwegs sicher benutzen könnte, aber nichts davon hat sich irgendwie durchgesetzt oder hat dazu geführt, dass PGP weniger fehleranfällig wird.

Nur um das einmal zu verdeutlichen: PGP schlägt sich momentan mit dem Problem herum, dass SHA-1 mittlerweile für ca. $50.000 gebrochen werden kann und das zu allerhand Problemen im PGP-Ökosystem führt. Weil man immer mehr Altlasten mitschleppt und nicht einfach die Kompatibilität zu alten Versionen kappen kann, ist SHA-1 noch immer eine vorgeschriebene Hash-Funktion. Unter anderem lassen sich damit Kollisionsangriffe fahren und damit die Identität von anderen User-IDs annehmen. Aus diesem Paper: https://eprint.iacr.org/2020/014

Es geht sogar so weit, dass PGP besonders anfällig für solche Angriffe ist. Aus dem gleichen Paper:

However, due to details of the PGP/GnuPG certificate structure, our attack can reuse a single collision to target arbitrary users Alice and Bob: for each victim, the attacker only needs to create a new key embedding the collision, and to collect a SHA-1 signature. This is arguably the first practical attack against a real world security application using weaknesses of SHA-1.

Wohlgemerkt ist die Verwendung von SHA-2 für Fingerprints in GPG zwar geplant, ist aber noch immer nur ein Draft für OpenPGP: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-08#section-12.2

Ich will hier niemandem Panik machen, aber das gesamte Thema PGP ist so vollkommen unüberschaubar und mit so vielen Fallstricken gespickt, dass keine einzelne Person überhaupt erahnen kann, welche Probleme sich darin noch verstecken, die noch vollkommen unbekannt sind.

[iuno]

Ich rede auch nicht von IM. XMPP wird uebrigens auch heute noch benutzt, mit OMEMO (ratchet).
Was heisst hier PGP hat sich nicht durchgesetzt? Oben kam noch die Aussage von dir, dass du es selbst zur Integritaetspruefung benutzt. Ich rede hier nicht davon, jeder Person jemals Kontakt aufnehme, PGP Mails zu schicken. Es hat sich laengst durchgesetzt, in den Bereichen, wo es sinnvoll war. Und da gibt es z.T. bis heute auch keine praktikable Alternative.

Dass SHA1 gebrochen wird war abzusehen. Wo genau beeintraechtigt das einen jetzt im Workflow mit PGP? Man bekommt eine Kollision hin, faelscht einen Schluessel, dann muss der Key aber noch zum User. Ueber Keyserver? Die werden nicht benutzt, weil sowieso jeder fake keys hochladen kann. Das macht hier genau keinen Unterschied. Dass das zu einem praktikablen Angriff wird, muss schon noch mehr dazu kommen.

Natuerlich ist es ein Minenfeld. Aber was soll man machen ;p

[lumines]

Ich rede auch nicht von IM. XMPP wird uebrigens auch heute noch benutzt, mit OMEMO (ratchet).
Was heisst hier PGP hat sich nicht durchgesetzt? Oben kam noch die Aussage von dir, dass du es selbst zur Integritaetspruefung benutzt. Ich rede hier nicht davon, jeder Person jemals Kontakt aufnehme, PGP Mails zu schicken. Es hat sich laengst durchgesetzt, in den Bereichen, wo es sinnvoll war. Und da gibt es z.T. bis heute auch keine praktikable Alternative.

Ich benutze es nur zur Signaturprüfung, weil die Linux-Distributionen nicht davon wegkommen.

Alle Pakete und ISOs für OpenBSD werden z.B. schon relativ lange mit signify signiert. Der Code für die Kryptofunktionen in signify kommt direkt aus OpenSSH. Selbst wenn ich die Parameter und Funktionsweise von signify komplett vergesse, kann ich mir das in 10min alleine über die Manpage anlesen. Das sind alles enorme Vorteile gegenüber PGP für Signaturprüfungen.

So etwas wäre auch problemlos für die Linux-Distributionen möglich, aber wahrscheinlich wird das noch ewig dauern.

Dass SHA1 gebrochen wird war abzusehen. Wo genau beeintraechtigt das einen jetzt im Workflow mit PGP? Man bekommt eine Kollision hin, faelscht einen Schluessel, dann muss der Key aber noch zum User. Ueber Keyserver? Die werden nicht benutzt, weil sowieso jeder fake keys hochladen kann. Das macht hier genau keinen Unterschied. Dass das zu einem praktikablen Angriff wird, muss schon noch mehr dazu kommen.

Von welchem Workflow redest du denn genau? Das ist ja der Punkt. Es gibt keine wirklich etablierte Arbeitsweise für bestimmte Anwendungszwecke mit PGP, sondern nur lose Konventionen, die hoffentlich zu einer sicheren Nutzung führen. Bis jetzt zeigen alle praktischen Erfahrungen aber dahin, dass es zu komplex ist. Die Fehlerrate (ob menschlich oder technisch) bei der Nutzung von PGP liegt weit über der von anderen Lösungen.

Natuerlich ist es ein Minenfeld. Aber was soll man machen ;p

Ich will damit auch nicht sagen, dass man heute oder morgen wegmigrieren sollte. Langsam wird es nur immer unangenehmer.

[Badesalz]

Also... was macht (Open)PGP...
PGP sichert den Inhalt auf dem Übermittlungsweg. Es war niemals geplant, daß es etwas anderes tut.

Daß es später auch die Möglichkeit anbot Dateien klassich auch auf dem Datenträger zu verschlüsseln, ist nur eine nette Beigabe.

Nebeneffekt ist der temporäre Schutz (fortlaufend) auch am Ziel, falls der Zugriff auf die Daten auch nur temporär im Mailer stattfindet.
Wenn die Zeit für das Halten der Passphrase abgelaufen ist oder man einfach den Mailer beendet, liegen die Daten auf dem Träger weiterhin nur genauso verschlüsselt wie sie ankamen.

Die Probleme sind für mich extrem künstlich herbeigeredet. Das ist nichts anderes wie den 9600k zu kritisieren, weil er MMX kann.
Übrigens hat man Ripemd-160 in GPG noch viel länger nieder gemacht. Das hält aber weiterhin um Welten besser als SHA ;)

Die Theorie, GnuPG macht nur das was OpenPGP vorschreibt, ist falsch.
Seit Anfang 2015 kann man Fingerprints auch in SHA256 und SHA512 erzeugen. Ja, das ist noch nicht als einer der Standards in OpenPGP definiert.
Grad das zeigt aber wieder die Vorteile des von mir ständig propagierten Ansatzes für offene, freie Gnu GPL Lösungen bei Sicherheitsfragen.
Wird ein Stadardisierungsgremium strategisch durch Uboote sabotiert, braucht man sich nicht zwangsweise am langen Arm verhungern lassen.
Wird später doch noch ein anderes Algo dafür... auserkoren, wird GPG das, aber auch weiterhin SHA-256 Fingerprints verarbeiten können.

Was wirklich mies ist, ist das Massaker mit Keyservern. Das schöne dabei ist aber, daß man in keinster Weise auf sie angewiesen ist. Ich sehe keine weiteren Sicherheitsprobleme dazu kommen, beim Erstkontakt unverschlüsselt nach einem PGP-Key zu fragen.
Ob man das z.B. in Utah so mitbekommt oder sonst durch die Detektion eines PGP-Bodys, ist völlig Jacke wie Hose.

Ich finde solche Diskussionen recht angenehm. Es lässt sich eben kein allzu dicker Nebel erzeugen, daher ist das mit den Rauchgranaten ein eher leichts Spiel. Darüber nachzudenken wer und weswegen Verwirrung stiften möchte, das kann sich allerdings lohnen...
Und je mehr man davon in den Nebelform hört, desto mehr ist man in der Annahme bestätigt, das richtige zu tun. Da finde ich die Satan-Taktik wesentlich pfiffiger ;)

[lumines]

Also... was macht (Open)PGP...
PGP sichert den Inhalt auf dem Übermittlungsweg. Es war niemals geplant, daß es etwas anderes tut.

Da du das fett markierst, gehe ich einmal davon aus, dass du dir dabei sehr sicher bist. Ich habe mir die RFCs zu OpenPGP nie vollständig durchgelesen, aber ich kann weder in RFC 1991, 2440 oder 4880 etwas dazu finden, dass PGP nur den "Übermittlungsweg" sichern soll. Vielleicht kannst du die entsprechende Stelle zitieren und / oder verlinken?

Mir wäre jedenfalls neu, dass OpenPGP als Transportverschlüsselung gedacht war.

Daß es später auch die Möglichkeit anbot Dateien klassich auch auf dem Datenträger zu verschlüsseln, ist nur eine nette Beigabe.

Was meinst du mit "später"? Die RFCs definieren eine lose Sammlung aus Public-Key- und symmetrischer Kryptografie, um daraus ein sehr komplexes Nachrichtenformat zu konstruieren. Nirgendwo wird ein bestimmter Transport vorgeschrieben oder gar selbst definiert. Jedenfalls kann ich das nirgendwo finden.

Die Theorie, Werner macht nur das was OpenPGP vorschreibt, ist falsch.
Seit Anfang 2015 kann man Fingerprints auch in SHA256 und SHA512 erzeugen. Ja, das ist noch nicht als einer der Standards in OpenPGP definiert.
Grad das zeigt aber wieder die Vorteile des von mir ständig propagierten Ansatzes für offene, freie Gnu GPL Lösungen bei Sicherheitsfragen.
Wird ein Stadardisierungsgremium strategisch durch Uboote sabotiert, braucht man sich nicht zwangsweise am langen Arm verhungern lassen.
Wird später doch noch ein anderes Algo dafür... auserkoren, wird GPG das, aber auch weiterhin SHA-256 Fingerprints verarbeiten können.

Kann ich mich also darauf verlassen, dass die Gegenstellen, mit denen ich kommuniziere, wirklich die "richtige" Wahl bei den Algorithmen getroffen haben und sich möglichst nicht am Standard orientieren? Wozu dann überhaupt ein Standard? Wozu überhaupt dann noch PGP?

Kann es vielleicht sein, dass mit PGP jeder seine eigenen Konventionen etabliert? Wenn das wirklich die Lösung sein soll und der Mehrwert eigentlich gar nicht bei OpenPGP als Standard liegt, sehe ich keinen Grund, warum man überhaupt bei PGP stehenbleiben sollte. Das gesamte Format zurückzulassen und auf modernere Alternativen umzusteigen ist da die einzige logische Konsequenz.

Was wirklich mies ist, ist das Massaker mit Keyservern. Das schöne dabei ist aber, daß man in keinster Weise auf sie angewiesen ist. Ich sehe keine weiteren Sicherheitsprobleme dazu kommen, beim Erstkontakt unverschlüsselt nach einem PGP-Key zu fragen.

Wenn man gar kein Web of Trust mit PGP aufbauen will und es nach Trust on First Use benutzt, warum sollte ich dann überhaupt PGP benutzen?

Wie gesagt, ich will hier niemandem PGP madig machen (ich habe es bis vor einiger Zeit schließlich selbst noch aktiv benutzt), aber je mehr man sich solche unangenehmen Fragen stellt, desto weniger Sinn hat für mich PGP ergeben. Man redet es sich schöner als es in Wirklichkeit ist. Viele Konstrukte wie das Web of Trust sind abseits von Laborbedingungen oder historisch gewachsenen Bürokratien wie z.B. Debian einfach pure Theorie. Und sobald man das fallen lässt, bleibt von PGP nicht mehr viel übrig außer eine lose Ansammlung von Algorithmen und unklaren Konventionen.

[Badesalz]

Da du das fett markierst, gehe ich einmal davon aus, dass du dir dabei sehr sicher bist. Ich habe mir die RFCs zu OpenPGP nie vollständig durchgelesen, aber ich kann weder in RFC 1991, 2440 oder 4880 etwas dazu finden, dass PGP nur den "Übermittlungsweg" sichern soll. Vielleicht kannst du die entsprechende Stelle zitieren und / oder verlinken?

Mir wäre jedenfalls neu, dass OpenPGP als Transportverschlüsselung gedacht war.SONDERN? Schreib doch mal Zimmermann an. Ah ja, sorry. Das war PGP, kein OpenPGP. Die haben das komplett zweckentfremdet :usweet:

Kann ich mich also darauf verlassen, dass die Gegenstellen, mit denen ich kommuniziere, wirklich die "richtige" Wahl bei den Algorithmen getroffen haben und sich möglichst nicht am Standard orientieren?Warte. Guter Punkt. Wieviele Implementierungen von OpenPGP - wissen schon, Übermittlungsweg - gibt es eigentlich? Ich gebe offen zu mich damit noch nie beschäftigt zu haben.

Wozu dann überhaupt ein Standard? Wozu überhaupt dann noch PGP?NEIN? :D Das hab ich beim Schreiben mal garnicht geahnt, daß du mit so gewiften Sachen ums Eck kommen wirst :ulol: Und jetzt? Das eine ist schlecht, das andere ist schlecht, s/mime ist explodiert...
Was machen wir jetzt mit der vertraulichen Kommunikation am Rechner? Telegram Desktop? WhatsApp Desktop? Signal Desktop? Threema Web?
Warte mal. Man kann nichts davon benutzen ohne einen Telefon. Richtig? Warum eigentlich?

=====
Kann es vielleicht sein, dass mit PGP jeder seine eigenen Konventionen etabliert?Würde mich wundern. GnuPG stellt nachwievor die Referenz da. An der Stelle ist das aber schon recht wunderbar, daß du "jeder seine eigenen Konventionen" ansprichst.
Kannst du mir über dein Signal eine Nachricht auf mein Threema schicken? Was nochmal ist deine Lösung, wenn das oben gequotete einen faden Beigeschmack erzeugen sollte. Ich bin ganz Ohr.
=====

Wenn das wirklich die Lösung sein soll und der Mehrwert eigentlich gar nicht bei OpenPGP als Standard liegt, sehe ich keinen Grund, warum man überhaupt bei PGP stehenbleiben sollte.Wenn man so überlegt, daß man mit PGP seit 29 Jahren den Übertragungsweg der Email auf gleiche Weise absichern kann, und man mit paar Optionen die Mails von 2.6, auch heute noch entziffern darf - oder mit GnuPG 1.x mit Leuten mit 2.x und vizeversa kommunizieren kann - dann erscheint in dem Fall der Nicht-Standard sich recht standardkonform zu verhalten. Ich weiß, das alleine war im deutschsprachigen Raum noch nie ausreichend. Selbst wenns funktioniert.

Wilkürr entsteht dann, wenn die Implementatoren sich außerhalb des Standards nicht einig werden. Chaos entsteht, wenn Leute die unterschiedlichen Lösungen auch nutzen. BEIDES sehe ich bis heute nicht passieren. Kannst mal was in weiter Auslegung von OpenPGP basteln, womit GnuPG sich langmacht. Niemand wird dich beachten.

Das gesamte Format zurückzulassen und auf modernere Alternativen umzusteigen ist da die einzige logische Konsequenz.Moment. Kein Latein auf dem Bildungsweg gehabt? "modernus" bedeutet wörtlich übersetzt sowas wie "jetzig" oder "heutig". Korrekt übersetzt steht es für neu und neuartig.
Neuartig als Adjektiv sagt nichts darüber aus, ob das Neue besser oder auch nur gut ist. Es ist nur neuartig. Deppen benutzen "modernus" als stilistischen Empfehlungsverstärker. Du bist kein Depp. Lass das mal zukünftig weg. "Modern" bringt hier im Thread keine Pluspunkte.

Wenn man gar kein Web of Trust mit PGP aufbauen will und es nach Trust on First Use benutzt, warum sollte ich dann überhaupt PGP benutzen?Um den Übermittlungsweg abzusichern... Web of Thrust ist eine Option. Keine Voraussetzung für irgendwas.

Wie gesagt, ich will hier niemandem PGP madig machenDoch doch, aber du kannst schon prinzipiell nicht gewinnen. Das ist das angenehme an der Diskussion. Eine funktionierende sichere Lösung ist eine funktionierende sichere Lösung. Dein größtes Problem ist sowieso, daß du keine Alternative parat hälst die "OHNE TELEFON" funktioniert. Ist das soweit korrekt? Du möchtest über dem Gebäude gerne die Abrissbirne schwingen, um? Eine Hundewiese einzurichten?

[iuno]

Ich benutze es nur zur Signaturprüfung, weil die Linux-Distributionen nicht davon wegkommen.
Na, was heisst nicht wegkommen? Ich sehe auch keine Bestrebungen, mangels akutem Bedarf bzw. Handlungsdruck.
Du laedst das Image aus potenziell unsicherer Quelle, beziehst den Key aus einer vertrauenswuerdigen Quelle, und pruefst dann das Image. Wie machst du es bei BSD? Das letzte mal, da ich OpenBSD installiert habe, war es aehnlich, wenn ich mich richtig entsinne, aber das ist eine Weile her. Es sei denn, du bist bereits auf BSD und der pubkey ist schon da.

Selbst wenn ich die Parameter und Funktionsweise von signify komplett vergesse, kann ich mir das in 10min alleine über die Manpage anlesen. Das sind alles enorme Vorteile gegenüber PGP für Signaturprüfungen.

Also, das geht doch problemlos auch mit gpg, da sehe ich ehrlich gesagt das Problem nicht. Man sollte halt schonmal im Leben was von public key crypto gehoert haben, dann reichen 10 Minuten mit gpg+manpage auch locker.


Von welchem Workflow redest du denn genau?
Also zu 90% importiere ich keine fremden Schluessel im Alltag. Ich habe sie schon da und arbeite halt damit. Wenn mich jemand kontaktieren will, bekommt er meinen Key ueber WKD und schickt mir seinen zu. Neue Schluessel muessen dann natuerlich noch verifiziert werden. Ich habe kein wirkliches Web of Trust. Dass mir jemand einen pubkey schickt, der von jemandem signiert ist, den ich kenne, kam auch schonmal vor, ist aber hoechst selten.
Ich sage nicht, dass das alles abdeckt, geschweige denn unendlich skaliert. Danach wurde auch nicht gefragt. Ich habe schliesslich nicht unendlich viele Kontakte und PGP funktioniert hier fuer mich.

Wenn man gar kein Web of Trust mit PGP aufbauen will und es nach Trust on First Use benutzt, warum sollte ich dann überhaupt PGP benutzen?
Die Frage ist: warum nicht?
Warum sollte ich mich stattdessen Signal herumaergern?
Warum soll irgendwas anderes benutzen, wenn gpg schon in git integriert ist?
Warum soll meine Telefonnummer oeffentlich ins Netz stellen (oder eigens eine neue anlegen), damit jemand mich kontaktieren kann? Ich kriege so schon mehr "Spam" ueber Telefon als E-Mails, obwohl mehrere E-Mail-Adressen von mir "oeffentlich" sind und keine meiner Telefonnummern.


Ich will damit auch nicht sagen, dass man heute oder morgen wegmigrieren sollte. Langsam wird es nur immer unangenehmer.

Wie gesagt, ich will hier niemandem PGP madig machen
Keine Sorge. Ich kann ja vieles von dem, was du sagst, nachvollziehen und hoere es mir auch gerne an. Ich bin auch niemand, der sich an etwas klammert. Aber solange es fuer meine Anwendungsfaelle halt auch keine praktikable Alternative gibt, bin ich da noch recht entspannt.

[lumines]

SONDERN? Schreib doch mal Zimmermann an. Ah ja, sorry. Das war PGP, kein OpenPGP. Die haben das komplett zweckentfremdet :usweet:

?

Warte. Guter Punkt. Wieviele Implementierungen von OpenPGP - wissen schon, Übermittlungsweg - gibt es eigentlich? Ich gebe offen zu mich damit noch nie beschäftigt zu haben.

Ich glaube, du solltest dich entweder an die Standardbegriffe halten oder deine Begriffe besser erklären. Ich habe ehrlich gesagt keine Ahnung, wovon du hier schreibst und ob das überhaupt eine Antwort auf meinen Post ist.


Was machen wir jetzt mit der vertraulichen Kommunikation am Rechner? Telegram Desktop? WhatsApp Desktop? Signal Desktop? Threema Web?
Warte mal. Man kann nichts davon benutzen ohne einen Telefon. Richtig? Warum eigentlich?

Du kannst OMEMO problemlos per XMPP nutzen. OMEMO ist praktisch das Signal-Protocol mit einigen XMPP-spezifischen Anpassungen. Es gibt sowohl Desktop- als auch Smartphone-Clients.

Würde mich wundern. GnuPG stellt nachwievor die Referenz da. An der Stelle ist das aber schon recht wunderbar, daß du "jeder seine eigenen Konventionen" ansprichst.

Kannst du mir über dein Signal eine Nachricht auf mein Threema schicken? Was nochmal ist deine Lösung, wenn das oben gequotete einen faden Beigeschmack erzeugen sollte. Ich bin ganz Ohr.

Ich würde einfach wieder einen XMPP-Server für mich und andere einrichten und OMEMO nutzen. Matrix soll auch in Ordnung sein.

Wenn man so überlegt, daß man mit PGP seit 29 Jahren den Übertragungsweg der Email auf gleiche Weise absichern kann, und man mit paar Optionen die Mails von 2.6, auch heute noch entziffern darf - oder mit GnuPG 1.x mit Leuten mit 2.x und vizeversa kommunizieren kann - dann erscheint in dem Fall der Nicht-Standard sich recht standardkonform zu verhalten. Ich weiß, das alleine war im deutschsprachigen Raum noch nie ausreichend. Selbst wenns funktioniert.

Du kannst nur mit Nutzern von alten Versionen kommunizieren, weil dein GPG auf uralte und teilweise vollkommen gebrochene Algorithmen ausweicht. Daher ja mein Einwand: Was nützen die besten Standards, wenn die Nutzerbasis den kleinsten gemeinsamen Nenner vorgibt?

Wilkürr entsteht dann, wenn die Implementatoren sich außerhalb des Standards nicht einig werden. Chaos entsteht, wenn Leute die unterschiedlichen Lösungen auch nutzen. BEIDES sehe ich bis heute nicht passieren. Kannst mal was in weiter Auslegung von OpenPGP basteln, womit GnuPG sich langmacht. Niemand wird dich beachten.

Irgendwie beschreibst du das komplette Gegenteil eines gesunden Standards. Wenn es nur eine Referenzimplementierung gibt und keine andere Implementierung von OpenPGP davon abweichen darf, selbst wenn sie konform zum Standard bleibt, dann läuft etwas vollkommen schief.

Dein größtes Problem ist sowieso, daß du keine Alternative parat hälst die "OHNE TELEFON" funktioniert.

Siehe oben.

[lumines]

Na, was heisst nicht wegkommen? Ich sehe auch keine Bestrebungen, mangels akutem Bedarf bzw. Handlungsdruck.
Du laedst das Image aus potenziell unsicherer Quelle, beziehst den Key aus einer vertrauenswuerdigen Quelle, und pruefst dann das Image. Wie machst du es bei BSD? Das letzte mal, da ich OpenBSD installiert habe, war es aehnlich, wenn ich mich richtig entsinne, aber das ist eine Weile her. Es sei denn, du bist bereits auf BSD und der pubkey ist schon da.

In den OpenBSD-Installationen ist der Public Key für das nächste Release schon enthalten. Sie haben statt extrem langlebigen Schlüsseln eine Kette und erzeugen für jedes Release ein neues Schlüsselpaar. Irgendwo muss man natürlich anfangen, aber so eine Rotation der Schlüssel gibt es bei keiner Linux-Distribution. Irgendwann werden auch da die Schlüssel ausgetauscht oder erneuert, aber das passiert viel seltener. Die Kompromittierung eines Schlüssels hätte viel weitreichendere Folgen als bei OpenBSD.

Also, das geht doch problemlos auch mit gpg, da sehe ich ehrlich gesagt das Problem nicht. Man sollte halt schonmal im Leben was von public key crypto gehoert haben, dann reichen 10 Minuten mit gpg+manpage auch locker.

Alle Studien dazu deuten in eine andere Richtung. "Why Johnny Can’t Encrypt" ist wohl die bekannteste und alle nachfolgenden haben zu keinem anderen Ergebnis geführt.

Ehrlich gesagt würde ich sogar soweit gehen, dass man schneller ist eine äquivalente Lösung selbst mit NaCl oder libsodium zu programmieren als die Manpages von GPG zu verstehen. Und das ist wahrscheinlich kein bisschen übertrieben.

Also zu 90% importiere ich keine fremden Schluessel im Alltag. Ich habe sie schon da und arbeite halt damit. Wenn mich jemand kontaktieren will, bekommt er meinen Key ueber WKD und schickt mir seinen zu. Neue Schluessel muessen dann natuerlich noch verifiziert werden. Ich habe kein wirkliches Web of Trust. Dass mir jemand einen pubkey schickt, der von jemandem signiert ist, den ich kenne, kam auch schonmal vor, ist aber hoechst selten.
Ich sage nicht, dass das alles abdeckt, geschweige denn unendlich skaliert. Danach wurde auch nicht gefragt. Ich habe schliesslich nicht unendlich viele Kontakte und PGP funktioniert hier fuer mich.

Wie gesagt, ich will auch nicht abstreiten, dass es in Legacy-Anwendungen mit etablierten Workflows (was ja durchaus auch bedeuten kann, dass man nur alle Jubeljare neue Keys importiert) funktionieren kann.

Die Frage ist: warum nicht?
Warum sollte ich mich stattdessen Signal herumaergern?
Warum soll irgendwas anderes benutzen, wenn gpg schon in git integriert ist?
Warum soll meine Telefonnummer oeffentlich ins Netz stellen (oder eigens eine neue anlegen), damit jemand mich kontaktieren kann? Ich kriege so schon mehr "Spam" ueber Telefon als E-Mails, obwohl mehrere E-Mail-Adressen von mir "oeffentlich" sind und keine meiner Telefonnummern.

1. Signal ist nicht der einzige Messenger, der das Signal-Protocol benutzt. Ich finde es nach wie vor besser als alles andere, einfach weil es ein funktionierendes Komplettpaket ist und eben gerade nicht jeden Anwendungszweck abdeckt. Der Usability-Sprung von XMPP mit OTR zu Signal war schon enorm. Heute mit OMEMO ist er vielleicht kleiner, aber OMEMO kam einfach für mich zu spät.
2. Ja, das wäre wahrscheinlich eine der wenigen Anwendungsfälle, für die es noch keine Alternative gibt.
3. Siehe 1.

Keine Sorge. Ich kann ja vieles von dem, was du sagst, nachvollziehen und hoere es mir auch gerne an. Ich bin auch niemand, der sich an etwas klammert. Aber solange es fuer meine Anwendungsfaelle halt auch keine praktikable Alternative gibt, bin ich da noch recht entspannt.

Ich habe auch Jahre gebraucht, um von pass wegzukommen, weil es definitiv sehr gut funktioniert hat. Aber selbst dort schreiben aktuell einige Leute wie Filippo Valsorda neue Backends, die nicht mehr auf GPG basieren. Insofern tut sich da schon einiges.

[Badesalz]

Ich glaube, du solltest dich entweder an die Standardbegriffe halten oder deine Begriffe besser erklären. Ich habe ehrlich gesagt keine Ahnung, wovon du hier schreibst und ob das überhaupt eine Antwort auf meinen Post ist.Das heißt also, du bist überall da nicht grad überragend, wo es auf Gefühl und Intuition ankommt? Tanzen z.B.? ;) Ok. Nicht schlimm. Mein Bruder kann sowas auch überhaupt nicht :) Er ist auch ein ähnlicher Gesprächspartner...

Ich würde einfach wieder einen XMPP-Server für mich und andere einrichten und OMEMO nutzen. Matrix soll auch in Ordnung sein.DU würdest? Dann mach das mal. Da warte ich schon ewig drauf, daß ich über Threema Leute mit Signal und Telegram erreichen kann. Und Hunderte Tausende wenn nicht gar paar Millionen warten auch drauf. Mach mal. Breche die vielen Konventionen mal auf.

Du kannst nur mit Nutzern von alten Versionen kommunizieren, weil dein GPG auf uralte und teilweise vollkommen gebrochene Algorithmen ausweicht.Nein? Im Ernst? Da geht es aber nicht um kommunizieren, sondern, daß man an EIGENE uralten Inhalte noch weiterhin rankommt.
Falls man sie so belässt wie sie damals waren, was jedem selbst überlassen ist.
Gegen Unwissenheit schützt man die Leute vor sich selbst, indem man z.B. MD5 liest, aber nicht mehr einfach auch schreibt. Oder am besten all das erstmal im FRONTEND verbirgt.

Daher ja mein Einwand: Was nützen die besten Standards, wenn die Nutzerbasis den kleinsten gemeinsamen Nenner vorgibt?Warum nochmal ist dieser Nenner klein?

Irgendwie beschreibst du das komplette Gegenteil eines gesunden Standards. Wenn es nur eine Referenzimplementierung gibt und keine andere Implementierung von OpenPGP davon abweichen darf, selbst wenn sie konform zum Standard bleibt, dann läuft etwas vollkommen schief.Du mit deinen vermeindlich pfiffigen Fallen. Nein, ich habs natürlich schon wieder nicht kommen sehen :ulol:
Du verlierst dich in der eigenen Poetik. Davor hast du rumgemeckert, daß der Standard an sich garnicht existiert, weil da noch nichtmal steht was OpenPGP ist. Jetzt ist es verkehrt, wenn alle sich an der Referenzimplementierung orientieren, egal wie konform sie damit mit dem Standard gehen. Für dich muss das jetzt wie Win-Win erscheinen, weil egal ob man es auf 0° oder 180° dreht, du kannst beides bequem kritisieren ;)
Das macht halt nur nichts. Die Sache ist sogar noch einfacher, als daß sich alle an eine Sammlung von Regeln halten sollten oder damit klarkommen, der Referenz zu folgen.
Nämlich: So ein Krypto will NIEMAND anfassen. Daher hat sich bisher dein Thema zu Rängeleien wegen dem Fehlen von vielen glasklaren Leitfaden ("Standard") auch noch nicht ergeben.
Sagen wir mal, mit dem Problem welchen du gerne herbeireden möchtest - und welches allgemein keineswegs nur theoretischen Natur ist - haben die Entwickler, die Nutzer und die Endnutzer von OpenPGP bisher noch keine Erfahrungen sammeln können. Für OpenPGP bleiben deine Schreckensszenarios bisher und weiterhin also nur graue Theorie. Sowas als Begründung aufzuführen um das alles wegzuwerfen, ist gelinde gesagt weit hergeholt. Wahrscheinlich muss das aber so...

Wenn man etwas braucht, was GnuPG kann, schreibt man sich das nicht selbst, sondern nutzt GnuPG. Oder Libcrypt. Genauso wie der, der etwas braucht was Boost libraries kann. Der schreibt sich das auch nicht wie er es am tollsten findet. Er nutzt Boost libraries.

Niemand, der es verstanden hat, will damit rumpfuschen. Hier kann man nur verlieren. Letztens hat es so bisschen 7-zip getroffen.

Mit GnuPG geht das zuweilen soweit, daß man das sogar gerne gleich mit den gleichen Einstellungen des Compilers erzeugt wie bei Referenzbin, weil keiner es auf die eigene Kappe nehmen will, zu behaupten überprüft zu haben, das tut mit -O2 genauso wie mit -O3 -fforce-addr -minline-all-stringops usw.

Und du willst an Unzulänglichkeiten im Standard rummeckern? Du kennst das Krypto-Biotop noch nichtmal. Bleib bei deinem Leisten, statt nach Verkehrsregeln zu rufen die auch genau festlegen soleln wie man ins Auto einzusteigen hat.

Siehe obenGutes Stichwort. Siehe du erstmal nach unten...

[iuno]

Ehrlich gesagt würde ich sogar soweit gehen, dass man schneller ist eine äquivalente Lösung selbst mit NaCl oder libsodium zu programmieren als die Manpages von GPG zu verstehen. Und das ist wahrscheinlich kein bisschen übertrieben.
Die Aufgabenstellung war aber nicht, alles durchzuackern, sondern "ich habe einen Schluessel, eine Datei und eine Signatur. Wie ueberpruefe ich, dass alles zusammenpasst?"



Signal ist nicht der einzige Messenger, der das Signal-Protocol benutzt. Ich finde es nach wie vor besser als alles andere, einfach weil es ein funktionierendes Komplettpaket ist und eben gerade nicht jeden Anwendungszweck abdeckt.
Das weiss ich. Ich hatte ja XMPP mit OMEMO oben schon genannt. IM ist fuer mich halt kein E-Mail-Ersatz, ich sehe das nur als Ergaenzung.
Finde ich auch ok. Ich bin ein Fan der Vereinfachung. Ein IM muss nicht alles moegliche andere auch noch koennen. Ich habe aber a) im Moment keine wirkliche Verwendung fuer Signal und b) keine Lust auf derart zentralisierte Kommunikation umzusteigen. Das brauche ich wirklich ueberhaupt nicht mehr.

[lumines]

Die Aufgabenstellung war aber nicht, alles durchzuackern, sondern "ich habe einen Schluessel, eine Datei und eine Signatur. Wie ueberpruefe ich, dass alles zusammenpasst?"

Ich habe gerade einmal schnell eine extrem simple Implementierung mit Python-Cryptography (Version >= 2.6) und Ed25519-Signaturen (https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ed25519/) erstellt. Das hat jetzt vielleicht 2h gedauert und ein Großteil ging dafür drauf, in welchem Format ich die Keys serialisiere und wie ich die Parameter handhabe.

Zum Veranschaulichen habe ich einfach alles im UNIX-Style per stdin / stdout umgesetzt mit nur ein paar wenigen separaten Argumenten:

$ ./keygen.py > id_ed25519
$ ./public_from_private.py < id_ed25519 > id_ed25519.pub
$ ./sign.py testfile < id_ed25519 > testfile.asc
$ ./verify.py testfile testfile.asc < id_ed25519.pub
Valid
$ >testfile
$ ./verify.py testfile testfile.asc < id_ed25519.pub
Invalid signature!

Die Skripte sind im Anhang.

Ich will damit nicht sagen, dass das jemand in dem Zustand benutzen sollte. Es soll nur zeigen, wie simpel die Kernfunktionalität sein könnte, wenn man auf GPG verzichtet.

Außerdem habe ich definitiv weniger Zeit gebraucht das zu implementieren als mir die Doku von GPG durchzulesen.

[iuno]

Ist das jetzt eine reine UI-Frage? Oder was genau ist deiner Meinung nach jetzt so "simpel", die paar Zeilen Python frontend?

Um die Softwarekomplexitaet kann's ja nicht mehr gehen, wenn du python-cryptography heranziehst, was seinerseits von openssl Abhaengt, das erst vor ein paar Jahren ein ziemliches Fiasko erlebt hat.

Insofern koenntest du auch in ein paar Zeilen Python gpg wrappen, um genau dieselbe Funktionalitaet zu erreichen. Gewonnen ist dadurch dann aber nichts.

Außerdem habe ich definitiv weniger Zeit gebraucht das zu implementieren als mir die Doku von GPG durchzulesen.
Das ist doch Quatsch. Keiner, der schonmal eine manpage von innen gesehen und was von public key crypto gehoert hat, braucht 2h um herauszufinden, wie man mit gpg eine Signatur prueft.

[lumines]

Ist das jetzt eine reine UI-Frage? Oder was genau ist deiner Meinung nach jetzt so "simpel", die paar Zeilen Python frontend?

Sowohl das UI als auch die Ergonomie der verwendeten Library. Mit GPG wäre schon das UI in der Form wortwörtlich nicht möglich gewesen, weil sich das GPG CLI je nach Version stark ändern kann.

Um die Softwarekomplexitaet kann's ja nicht mehr gehen, wenn du python-cryptography heranziehst, was seinerseits von openssl Abhaengt, das erst vor ein paar Jahren ein ziemliches Fiasko erlebt hat.

OpenSSL hat massive Fortschritte gemacht. Das OpenSSL von heute kann man nicht mit dem Stand von 2014 vergleichen. Einige Projekte, die kurzfristig zu LibreSSL geswitcht sind, switchen heute auch wieder zurück auf OpenSSL (z.B. Alpine Linux).

Man könnte auch stattdessen libsodium benutzen. Hat keine Abhängigkeit zu OpenSSL.

Insofern koenntest du auch in ein paar Zeilen Python gpg wrappen, um genau dieselbe Funktionalitaet zu erreichen. Gewonnen ist dadurch dann aber nichts.

Auf die Idee sind schon einige Leute gekommen, z.B. das Mailpile-Projekt (ironischerweise auch überwiegend in Python geschrieben): https://www.mailpile.is/blog/2015-02-26_Revisiting_the_GnuPG_discussion.html

Das Mailpile-Projekt arbeitet heute auf Sparflamme, weil sie GPG nie wirklich zufriedenstellend integrieren konnten. Die Nutzung dort ist zwar etwas ambitionierter, aber die Probleme da treffen allgemein auf die Nutzung von GPG zu.

Das ist doch Quatsch. Keiner, der schonmal eine manpage von innen gesehen und was von public key crypto gehoert hat, braucht 2h um herauszufinden, wie man mit gpg eine Signatur prueft.

Wenn man einfach nur mechanisch Befehle abtippt vielleicht schon, aber das Web of Trust zu verstehen ist nicht trivial. Warum man die öffentlichen Keyserver nicht mehr benutzen sollte auch nicht. Nichts davon steht in den Manpages.

Ich habe gerade auch einmal nachgeschaut. Die Manpage für das GPG CLI hat auf meinem System 3378 Zeilen. Daran kann man schon ein bisschen knabbern.

[Badesalz]

weil sich das GPG CLI je nach Version stark ändern kann.Lehrt uns das die Geschichte? Oder was bedeutet "kann"?

Auf die Idee sind schon einige Leute gekommen, z.B. das Mailpile-Projekt (ironischerweise auch überwiegend in Python geschrieben): https://www.mailpile.is/blog/2015-02-26_Revisiting_the_GnuPG_discussion.htmlInteressant. Soweit ich das schnalle geht es da um 2.1, weil sie eben das benutzen wollen. wogegen es mit 1.4 keine solche Probleme gäbe? (es ist laut Werner erstmal nicht absehbar wann 1.4 EOL sein könnte)
Sonst so...
https://lists.gnupg.org/pipermail/gnupg-users/2015-February/052787.html

Ich habe gerade auch einmal nachgeschaut. Die Manpage für das GPG CLI hat auf meinem System 3378 Zeilen. Daran kann man schon ein bisschen knabbern.Sicher, daß es nicht ~591 Zeilen sind?
Mir fehlt das noch in meiner Linksammlung :) Kann ich das bitte haben?

[iuno]

OpenSSL hat massive Fortschritte gemacht.

Das weiss ich, aendert aber nichts an der Tatsache, dass das ganze Konstrukt nicht "simpel" ist.

Ich habe gerade auch einmal nachgeschaut. Die Manpage für das GPG CLI hat auf meinem System 3378 Zeilen. Daran kann man schon ein bisschen knabbern.
Gilt dasselbe wie zuvor gesagt. Man muss das nicht wie einen Roman vorne bis hinten durchlesen, sondern man sucht gezielt nach der Funktion die man braucht.

Ich gebe dir ja recht und kann Einwaende nachvollziehen. Aber mir fehlt nach wie vor die Loesung/Alternative.

[Badesalz]

Denke das ist nicht von der höhsten Relevanz. Es reicht, daß keiner mehr GPG benutzt. Das macht die Welt schon pauschal kleinwenig erträglicher...

[lumines]

Ich gebe dir ja recht und kann Einwaende nachvollziehen. Aber mir fehlt nach wie vor die Loesung/Alternative.

Es gibt z.B. auch noch minisign, das wohl mit signify von OpenBSD kompatibel ist und Implementierungen in verschiedenen Sprachen hat: https://jedisct1.github.io/minisign/

Wahrscheinlich hätte ich das so auch eher machen sollen. Die Keys sind ja so kurz, dass man die als einzeiligen, Base64-kodierten String hin- und herkopieren kann. Das CLI sieht auch in Ordnung aus.

[Badesalz]

Hah ist das schön :rolleyes:
https://blog.fefe.de/?ts=a1e87b6f

[Badesalz]

Wie ich das manchmal hasse immer Recht zu behalten

https://blog.fefe.de/?ts=a157c1a0

[lumines]

Wie kommst du darauf, dass GPG nicht davon betroffen sein wird? Weil Fefe das sagt?

[Badesalz]

GPG kann davon prinzipbedingt nicht betroffen sein.
Wie GPG davon über Bande betroffen sein kann, SPRICHT ER AUCH AN.

[lumines]

Weil natürlich auch niemand GPG nach Trust on First Use nutzt. Sorry, aber da kann ich nur lachen. Es ist doch fast ein Running Gag, dass das Web of Trust rund um PGP / GPG eigentlich nie funktioniert hat.

Das Problem rund um die EU-Resolution ist doch auch gar kein technisches. Wenn nur ein kleiner Kreis von Leuten E2E-Verschlüsselung wirklich sicher nutzen könnte (zu dem ich den durchschnittlichen GPG-Nutzer ehrlich gesagt nicht einmal zählen würde), dann ist der Personenkreis klein genug, dass er sich schon wieder effektiv auf andere Art und Weise überwachen lässt.

Technisch wäre es übrigens auch gar kein Problem das Keymanagement der jeweiligen Messenger robuster gegenüber so einer umfassenden, staatlichen Überwachung zu machen. Man würde einfach ein PAKE-Protokoll um das Keymanagement stricken und die Fingerprints / Keys der anderen Personen darüber separat verifizieren, bevor man kommunizieren könnte.

Nichts anderes hat man damals bei OTR in einer leicht anderen Form gemacht (allerdings ohne diesen neuen PAKE-Protokolle, sondern über das Socialist-Millionaire-Protokoll). Man war mit OTR schon vor 15 Jahren weiter als GPG sicherheitstechnisch jemals gekommen ist.

[Badesalz]

Ah guck. Wurde auch kurz behandelt :rolleyes: Wer braucht web of thrust... Freundeskreise und behördliches (wäre mal was).

Für sowas ist da shalt gedacht. So funtz das auch. Alles andere sind Spinnereien.

https://blog.fefe.de/?ts=a157f758

Aber ok, zum Thema. Welcher Art ist das Problem mit der EU-Resolution? Oder ist es garkein Problem? Du lavierst wieder gewohnt herum, aber ich würde wenigstens 1x etwas genaues von dir erfahren.

[lumines]

Wer braucht web of thrust... Freundeskreise und behördliches (wäre mal was).

Wenn ich kein Web of Trust brauche, dann brauche ich auch kein GPG.

Mich wundert aber auch nicht, dass du eigentlich gar kein Web of Trust nutzt.

Für sowas ist da shalt gedacht. So funtz das auch. Alles andere sind Spinnereien.

Dafür war es eigentlich nie gemacht. Das Ziel war eigentlich immer ein Web of Trust aufzubauen. Das ist aber nie (oder nur in sehr kleinen, geschlossenen Communities wie Debian) passiert. An dem Punkt waren wir schon einmal und daran hat sich eigentlich auch nichts geändert.

Aber ok, zum Thema. Welcher Art ist das Problem mit der EU-Resolution? Oder ist es garkein Problem? Du lavierst wieder gewohnt herum, aber ich würde wenigstens 1x etwas genaues von dir erfahren.

Du darfst gerne auf meinen letzten Post antworten:

Wenn nur ein kleiner Kreis von Leuten E2E-Verschlüsselung wirklich sicher nutzen könnte (zu dem ich den durchschnittlichen GPG-Nutzer ehrlich gesagt nicht einmal zählen würde), dann ist der Personenkreis klein genug, dass er sich schon wieder effektiv auf andere Art und Weise überwachen lässt.

[Badesalz]

Wischiwaschi. Wie immer.

Wenn nur ein kleiner Kreis von Leuten E2E-Verschlüsselung wirklich sicher nutzen könnte (zu dem ich den durchschnittlichen GPG-Nutzer ehrlich gesagt nicht einmal zählen würde), dann ist der Personenkreis klein genug, dass er sich schon wieder effektiv auf andere Art und Weise überwachen lässt.Das wird schwierig drauf zu antworten, weil das in Gänze kontextfrei ist. Es ist zwar richtig, aber ohne Bezug zu der EU-Resolution. Ein Musterbeispiel wie man Wischiwaschi macht ohne etwas falsches zu erzählen. Spannend bleibt es aber trotzdem. Nämlich wenn man darüber nachdenkt was immer wieder der Antrieb für solches sein könnte...

Dafür war es eigentlich nie gemacht.Wischiwaschi. Dafür war es am Anfang nicht GEDACHT, machen kann man das damit ohne Probleme. Wie mit jedem System mit welchem man einen Schlüssel mit anderen Schlüsseln signieren kann.

WebOfThrust baut man sich auf. Oder auch nicht. Dafür gibt es keine generelle Notwendigkeit. Das früher zu bejubeln, trotz des besseren Wissens, war Teil der Arbeit der Saboteure. Die haben schnell erkannt, daß dies mit SKS nur schief laufen kann. Also haben sie die Leute dahin treiben wollen.
Daß man es aber auch anders aufziehen kann, zeigen die neueren Bemühungen. Brauchen, braucht man das keineswegs.

Ich vermute für deine ständige Verwirrtheit zeichnet fortlaufend Jürgen Schmidt verantwortlich (?) Dem darf man schon seit Jahren keine Beachtung bei dem Thema schenken. Ein Uboot, auf einer Mission. Die ihm nun so um die Ohren fliegen wird wie das davor schon s/mime tat.

Niemals solchen Leuten einfach vertrauen.

[lumines]

Das wird schwierig drauf zu antworten, weil das in Gänze kontextfrei ist. Es ist zwar richtig, aber ohne Bezug zu der EU-Resolution. Ein Musterbeispiel wie man Wischiwaschi macht ohne etwas falsches zu erzählen.

Wie meinst du das? Wenn den meisten Nutzern funktionierende E2E-Verschlüsselung in z.B. weit verbreiteten Messengern vorenthalten wird, dann sind Leute deutlich auffälliger, die bewusst deswegen andere Protokolle benutzen.

Wischiwaschi. Dafür war es am Anfang nicht GEDACHT, machen kann man das damit ohne Probleme. Wie mit jedem System mit welchem man einen Schlüssel mit anderen Schlüsseln signieren kann.

Das gesamte PGP-Web-of-Trust-Modell ist eigentlich als Alternative zu klassischen PKIs mit einer oder mehreren Certificate Authorities erdacht worden. In der Hinsicht ist es doch bewusst von dem CA-Modell von z.B. X.509 abgewichen.

WebOfThrust baut man sich auf. Oder auch nicht. Dafür gibt es keine generelle Notwendigkeit. Das früher zu bejubeln, trotz des besseren Wissens, war Teil der Arbeit der Saboteure. Die haben schnell erkannt, daß dies mit SKS nur schief laufen kann. Also haben sie die Leute dahin treiben wollen.

Es gab also Saboteure? Erzähl mir bitte mehr.

In der Wikipedia wird doch sogar Phil Zimmermann selbst zitiert: https://en.wikipedia.org/wiki/Web_of_trust

Ich vermute für deine ständige Verwirrtheit zeichnet fortlaufend Jürgen Schmidt verantwortlich (?) Dem darf man schon seit Jahren keine Beachtung bei dem Thema schenken. Ein Uboot, auf einer Mission. Die ihm nun so um die Ohren fliegen wird wie das davor schon s/mime tat.

Niemals solchen Leuten einfach vertrauen.

Ok, Boomer.

[Badesalz]

Wie meinst du das?Das war ein Einwuirf was mit dem was folgte, und dem was vorausging, nichts zu tun hat. Jedenfalls erkenn ich das nicht.

Das gesamte PGP-Web-of-Trust-Modell ist eigentlich als Alternative zu klassischen PKIs mit einer oder mehreren Certificate Authorities erdacht worden.Und dann? Kann man nutzen, funzt, wenn man Authorities braucht, weil Authorities ihre Signierung verlangen, man muß es aber nicht nutzen.
Ja, natürlich. Wenn alle E2E nutzen, fällst du nicht auf. Wenn nur wenige es nutzen, weil die anderen kein Bock auf sowas und E2E ist nur gut wenns vom Himmel fällt, kanst du die Nutzer raussuchen. Weil, eine z.B. PGP-Mail erkenst du am Header. Und wenn die Zahl überschaubar ist, kannst du sie hacken. Und dann anders überwachen oder, ab und zu naschauen was sie so treiben...

Die Medallie mit CertAuthorities hat aber einen Pferdefuß. Authorities = Zentralisierung. Was Sachen schon per Definition, theoretisch, unsicherer macht. Und dann kannst du die Sicherheit dieser "Zentralen" (Firmen) per Gesetz wegschiessen. Mit Generallschlüsseln ist jede Krypto so im Eimer wie ein Cisco-Router der über Masterpasswörter verfügt.

Und nun sieht man nicht nur theoretisch, wie fragil das ist. Sobald du die Infrastruktur für dein Krypto nicht AUCH MAL komplett und autark in Eigenverantowrtung fahren kannst, bleibt es fragil.
Und PGP (GnuPG) kann eben beides.

Ok, Boomer.Wie tief muß ich denn noch gehen, in diesen Dialogen? Und wie oft mich dabei noch fragen, warum ich mir diesen Narzysmus überhaupt so oft ziehe...
Boomer gehen nur bis zu den 60er. Das wäre eher was für meine Mutter :up:

Ok, Generation L.

[lumines]

Ja, natürlich. Wenn alle E2E nutzen, fällst du nicht auf. Wenn nur wenige es nutzen, weil die anderen kein Bock auf sowas und E2E ist nur gut wenns vom Himmel fällt, kanst du die Nutzer raussuchen. Weil, eine z.B. PGP-Mail erkenst du am Header. Und wenn die Zahl überschaubar ist, kannst du sie hacken. Und dann anders überwachen oder, ab und zu naschauen was sie so treiben...

Genau das meinte ich, falls das nicht so klar war.

Die Medallie mit CertAuthorities hat aber einen Pferdefuß. Authorities = Zentralisierung. Was Sachen schon per Definition, theoretisch, unsicherer macht. Und dann kannst du die Sicherheit dieser "Zentralen" (Firmen) per Gesetz wegschiessen. Mit Generallschlüsseln ist jede Krypto so im Eimer wie ein Cisco-Router der über Masterpasswörter verfügt.

Und nun sieht man nicht nur theoretisch, wie fragil das ist. Sobald du die Infrastruktur für dein Krypto nicht AUCH MAL komplett und autark nur auf deinem eigenen System fahren kanst, bleibt es fragil.
Und PGP (GnuPG) kann eben beides.

Du holst ganz schön weit aus. Eine PKI ist einfach ein vollkommen anderes Modell als das Web of Trust. Eine PKI hat auch nicht zwangsläufig etwas mit Zentralisierung zu tun. Praktisch jedes größere Unternehmen betreibt eine oder gar mehrere, interne PKIs. So ziemlich alle modernen Protokolle wie gRPC setzen irgendeine Form von authentifizierter Verschlüsselung voraus und ob man eine externe CA nutzt oder seine eigene CA für die interne Kommunikation aufzieht, spielt ja keine Rolle.

Davon abgesehen basieren Messenger wie Signal oder WhatsApp für ihre E2E-Verschlüsselung nicht auf einer klassischen PKI und nutzen auch gar keine langlebigen Schlüssel. Für ihre Transportverschlüsselung nutzen sie auch nicht die Web-PKI. Das kann man sehr leicht selbst überprüfen: https://www.ssllabs.com/ssltest/analyze.html?d=cdn.signal.org&hideResults=on&latest

Deshalb ist GPG genau so wenig vor dieser EU-Resolution geschützt wie WhatsApp oder Signal, eben weil dort ein Eingriff in die Protokolle angedacht ist (oder das jeweilige Protokoll / Nachrichtenformat einfach verboten wird).

[Badesalz]

Die Forensoft hat den Link für die Darstellung schonmal passend gekürzt... :uup:
"https://www.ssllabs.com/ssltest/anal...ults=on&latest"

Nochmal, in slowmo…
Wenn man die Kryptoinfrastruktur komplett aus der Hand gibt, kann jemand kommen und es wegschießen. Einerseits über Uboote in der Wirtschaft, wenn man sich so anschaut was aus PGP geworden wäre, würde es kein GnuPG geben.

Andererseits eben per Gesetze mit welchen man es sabotiert.
Wogegen man sich aktuell auch nicht wehren kann, es sei denn man bringt die FDP auf >50% (was imho irgendwie auch keine allgemein tolle Idee wäre).

Deswegen ist es immer wichtig sich mehrere Wege und Optionen warmzuhalten - gerne auch ohne sie aufeinander zu hetzen... - und es nicht mit dieser katastrophal kindlichen Naivität angehen. Und auf Leute vom Schlage eines Jürgen Schmidts reinfallen...