pretty Easy Privacy – kurz: p≡p – ist ein Projekt des Softwarearchitekten Volker Birk und des Chaostreff Winterthur in der Schweiz. Es will, dass verschlüsselte und anonyme Kommunikation nicht nur „good“, sondern auch „easy“ ist. In einem Gastbeitrag erklärt Volker, wie, warum und wo noch Hilfe notwendig ist. Er wird auch auf Volkers Blog und der Projektseite von p≡p erschienen.
pretty Easy Privacy – Lasst uns Whatsapp verschlüsseln! Und Facebook-Nachrichten. Auch mit Outlook. Nein, wirklich!
TL;DR
p≡p will den Default für textbasierende Nachrichten ändern, und zwar von unverschlüsselt und transparent auf anonymisiert und verschlüsselt. Dabei soll es egal sein, ob SMS, WhatsApp-Nachricht, Mail, – Hauptsache ist, der Nutzer muss gar nichts mehr dafür tun, um verschlüsselt zu kommunizieren. p≡p befindet sich in der Entwicklung, dafür braucht es Geld. Das Indiegogo-Crowdfunding ist heute gestartet.
Das Problem
Was sich abgedreht anhört, hat einen sehr ernsten Hintergrund. Inzwischen sind wir beim CCC Zürich bei der 11. Kryptoparty. Kurz: die Resonanz ist großartig. Die Leute lieben es und bekommen Service von Nerds mit Herz und einer Engelsgeduld. Nur: was nützt es? Es nützt. Aber der Impact? Wir erreichen so nicht einmal 1% der Internetnutzer. Der Cypherpunk gilt als gescheitert. Aber ist er das? Muss er das sein?
Eine Crypto-App nach der anderen, eine Crypto-Box, ein Crypto-Webdienst nach dem anderen schießt wie Pilze aus dem Boden. Ich begrüße alle davon. Jedem, der so ein Projekt macht, wünsche ich allen Erfolg, den er je haben kann. Aber wieder: der Impact? Die Leute nutzen nach wie vor Whatsapp, Facebook, Instagram & Co. Ein Crypto-Projekt mit 200.000 Nutzern gilt als erfolgreich. Das sind 0.0002 Milliarden. Zum Vergleich: Whatsapp hat 0.6 Milliarden und geht weiter auf die 1 Milliarde zu. Was tun, sprach Zeus?
Wir müssen das Problem neu denken. Wir müssen da agieren, wo die Leute sind. Und das bedeutet eben, wir müssen Whatsapp verschlüsseln. Und Facebook-Nachrichten. Aber eben auch E-Mail. Und SMS. Und alles das, was die Leute tatsächlich nutzen. Und das Verschlüsseln alleine reicht nicht, lange nicht. Das muss ganz anders werden.
Deshalb hat sich eine Gruppe von Leuten gebildet, die das Problem lösen will. Das Motto lautet: pretty Easy privacy, p≡p. Denn Good ist sie schon, die Privacy. Aber Easy muss nun großgeschrieben werden. Und sie muss endlich dort greifen, wo die Leute wirklich kommunizieren.
p≡p ist also nicht noch eine neue Crypto-App. p≡p ist der Versuch, den Standard für textbasierende Nachrichten im Internet zu ändern: von unverschlüsselt und transparent für die Überwacher auf anonymisiert und verschlüsselt. Cypherpunk eben. Wie geht das?
Das Problem des Verschlüsselns liegt für die meisten Menschen nicht darin, dass sie keine Software finden, mit der man verschlüsseln kann. Sondern darin, dass sie es auch damit nicht können, weil sie es nicht verstehen. Das ist ein deutlicher Hinweis, dass mit der Software was nicht stimmt. Um genau zu sein, mit deren Nutzerschnittstelle. Wenn es nur ganz wenige können, ist die offensichtlich schlecht. Machen wir uns nichts vor: sie ist furchtbar.
„Lege Dir erst einmal ein Schlüsselpaar an. Nein, nimm mindestens 2048 bit RSA, besser 4096.“ Hä? Wieso geht das wieder nicht?
„Schlüssel abgelaufen.“ Aha. Und nun?
So kann es mit PGP nicht weitergehen, da hat Matthew Green ganz recht.
Die grüne Statusanzeige zeigt, dass die Kommunikation verschlüsselt stattfindet und die Teilnehmer sich vertrauen.
Die Idee
Man kann PGP richtig benutzen, das wissen viele der Leser hier genau. Und sie wissen auch, wie genau. Warum schreibt man das nicht einmal auf? Nein, nicht als Bedienungsanleitung, sondern als Protokoll. Und dann schreibt man es nochmal. In Quellcode, als Engine. Das ist die p≡p-Engine. Die p≡p-Engine ist keine Crypto-Engine. Sie ist eine Crypto-Benutz-Engine. Als Backends unterstützt sie GnuPG und NetPGP. Das kann man sich in etwa so vorstellen:
Der Nutzer installiert das p≡p-Outlook-Plugin. Das installiert automatisch auch GPG4Win, da auf der Platte noch keins gefunden wurde. Der Nutzer startet Outlook und will eine neue Mail schreiben. Im Hintergrund arbeitet die p≡p-Engine: Hat der Nutzer schon ein Schlüsselpaar? Wie heißt die eigene Mailadresse, die hier verwendet wird? Sie stellt fest, es gibt noch kein Schlüsselpaar und erzeugt eines.
Die Mail geht an alfred@neuman.com und die p≡p-Engine fragt sich hinter den Kulissen: Haben wir einen Public Key für alfred@neuman.com? Scheinbar nicht, aber man könnte auf einem Keyserver nachsehen. Da liegt ein Key und der wird sofort importiert. Wenn der Nutzer in Outlook auf „Senden“ drückt nimmt p≡p den öffentlichen Schlüssel von Alfred, verschlüsselt die Mail und hängt den eigenen öffentlichen Schlüssel hinten dran. Dann wird die Mail verschickt.
In der Vorversion auf pep-project.org sieht, dass das schon heute funktioniert. Die Unterstützung von anderen Mailclients und Messaging-Programmen kommt bald dazu.
Der Spread
Ein großes Problem bei allen Cryptoprojekten ist: Wie kriegt man die Benutzer dazu, das Zeug zu verwenden? Man muss sich klarmachen, dass es völlig unterschiedliche Benutzer gibt:
Auf der einen Seite gibt es die Unternehmen. Die lechzen nach Verschlüsselung. Und scheitern. Weil es zu kompliziert ist. Easy game to play. Aber wir brauchen „Enterprise Features“: Key Escrow zum Beispiel. Und wir brauchen die Software für Systeme wie Microsoft Outlook, und nicht nur (aber auch) für andere freie Software wie z.B. Kolab, das in der nächsten Release p≡p mit ausliefern wird. Denn Georg Greve, Kolab-Chef und FSFE-Gründer, ist mit an Bord bei p≡p. Weitere Groupware ist herzlich willkommen! Wir haben bereits drei Pilotprojekte mit p≡p für Outlook. Den Quellcode findet Ihr auf der Homepage.
Denn p≡p ist das, zu 100%: Freie Software unter GPL. Ja, es ist eine Dual License angedacht. Unternehmen sollen das incl. Service kaufen können. Denn das wollen Unternehmen oft: einen Vertragspartner. Also haben wir die p≡p Security SA in Luxembourg gegründet. Und die bietet Unternehmenssupport. Redhat ist Vorbild.
Bei Privatleuten ist das anders. Falls die überhaupt noch mailen, dann oft im Webmailer. Deshalb brauchen sie Ganze als Browserplugin, am besten gleich mit Google-Mail-Unterstützung. Aber Privatleute brauchen noch mehr: sie kommunizieren über Whatsapp & Co. Also muss p≡p nicht nur E-Mails können. Wir schreiben an RFCs, nicht nur an einer. Und implementieren. Es gibt ja bereits OpenWhatsapp. Und eine Facebook-Messaging-API.
Das sind die beiden Hauptgründe, mit denen p≡p Endbenutzer dazu kriegen will, p≡p zu mögen:
1. Konvergenz. Heute haben viele nicht nur eine Messaging App. Auf meinem iPhone sind es fünf. Der eine hat vier (einschließlich SMS/iMessage und E-Mail), der andere sechs oder sieben. Die p≡p App sorgt dafür, dass alle Nachrichten in einer App ankommen. Und dass man hier wieder nur „antworten“ oder „neue Nachricht“ klicken kann, und die Nachricht geht über den sichersten verfügbaren Kanal raus. Man kann sogar damit twittern. Der Fallback, falls eine Verschlüsselung nicht möglich ist, ist das unverschlüsselte Senden. Das geschieht ohne Rückfragen, aber mit einer leicht verständlichen und gut sichtbaren Farbmarkierung für den Benutzer.
2. Synchronisation. p≡p synchronisiert alle Endgeräte eines Benutzers ohne dass er viel konfigurieren muss. Dafür müssen die Geräte eine gemeinsame E-Mail-Adresse kenne, über die ein in Textnachrichten implementiertes Protokoll läuft. Synchronisiert werden nicht nur Schlüssel und Trust, sondern auch Kontakte und Termine. Das funktioniert, indem p≡p einen Diff in SQL als E-Mail-Anhang an die eigene Adresse schickt, verschlüsselt mit dem eigenen Schlüssel. Damit wandern diese Daten nicht mehr in die „Cloud“.
Der Punkt 3, die Sicherheit, ist bei der Nutzerakzeptanz „nur“ ein Nebenargument. Technisch ist es jedoch alles andere als das. Wenn beide Seiten p≡p haben, macht p≡p noch etwas anderes. Dann leitet es den gesamten Nachrichtenverkehr um – über GnuNet und damit anonymisiert und hart verschlüsselt. Mit Perfect Forward Secrecy. Ja, auch Whatsapp-Nachrichten. Die dann keine mehr sind.
Warum das alles?
Weil sich jetzt etwas ändern muss. Weil es so nicht mehr weitergehen kann. Wir müssen die Hardware zurück erobern. Und die Systeme. Und den Nachrichtenverkehr. Denn die Ciscos, die kriegen wir nicht zurück. Die gehören denen. Lösen wir jedoch jene Aufgaben, so können sie die Ciscos behalten. Es dann ist es trotzdem nicht mehr so schlimm für uns.
Deshalb habe ich für die nächsten drei Jahre vor, p≡p zu machen. Bisher ist aller Code von mir, aber mittlerweile ist auch mein Freund Edouard Tisserant mit im Spiel. Und ich hoffe, dass es gar nicht noch drei Jahre dauern muss, bis wir die wichtigsten Plattformen mit p≡p versehen konnten. Sondern dass das viel schneller geht.
Dafür brauchen wir eure Hilfe und die könnt ihr uns auf verschiedenen Wegen geben: Macht mit beim Crowdfunding und helft uns, Entwickler bezahlen zu können. Unterstützt die p≡p engine in Eurer Freien Software. Und tragt das Projekt ideell mit. So, wie Ihr eben könnt und wollt. Wir freuen uns über jede Unterstüzung, die wir kriegen können. Danke jetzt schon dafür!
Vielen Dank für den grossen Effort! Aber wird das so etwas? Beim Überfliegen bin ich erst einmal tüchtig erschrocken:
Georg Greve, dessen Kolab von Nicolas Mayencourt/Dreamlab finanziert und kontrolliert wird?!
Matthew Green sagte nicht, SO könne es mit PGP nicht weitergehen. Sondern er sagte zu recht, es könne mit PGP nicht, also GAR NICHT weitergehen (It’s time for PGP to die)! Ich fürchte, daran wird p≡p scheitern, wenn man es mit Sicherheit ernst meint (und am ≡, das völlig an der Zielgruppe vorbei geht).
Kolab hat zugesagt, die pEp engine zu verwenden und in den Standard mit einzubauen. Ich werde sie nicht davon abhalten, im Gegenteil.
Georg kontrolliert Kolab schon selber, denke ich. Wenn Dir Kolab nicht gefällt, Du musst es nicht nutzen. pEp ist mit Kolab nicht verwandt und nicht verschwägert bis auf den Punkt, dass Georg das Projekt gut findet und für uns “Spread the word” macht.
Die Entwicklung von pEp ist wie folgt finanziert bisher: ich hab mir drei Jahre Zeit genommen, komplett auf eigene Kappe. Mein Freund Edouard hilft mir jetzt, unentgeltlich. Und wenn das Courdfunding klappt, gibt’s weitere Entwickler. Ein halbes Mannjahr hab ich jetzt investiert. Was dabei heraus gekommen ist, kannst Du ja selbst testen.
Mit PGP wird es weitergehen. Da liegt Green falsch. Denn das kann man z.B. verwenden, um einen Einmalkey zu tauschen und dann Perfect Forward Secrecy zu implementieren. Auf Basis von GnuNet, also über einen Anonymisierungsdienst.
Und genau das wird pEp auch machen.
> Georg kontrolliert Kolab schon selber, denke ich.
Yup. Gemeinsam mit den Mitarbeitern, die ebenfalls am Unternehmen beteiligt sind.
Wir entwickeln alle unsere Technologien als Freie Software. Im Upstream, wo dieser existiert. Das gilt auch für die unterstützte Version. Und manchmal helfen wir auch, den neuen Upstream zu etablieren. In der Beziehung ist Kolab aus demselben Holz geschnitzt wie pEp.
Und da Volker zudem weiss was er tut unterstütze ich gerne so gut ich kann.
Das Projekt ist eine klasse Idee und ich wünsche den Entwicklern ganz ehrlich viel Erfolg und hoffe, dass dieses Projekt ausreichend Unterstützung erfährt.
Danke!
Ich kann jetzt bereits sagen, das ist der Fall. Ich bin vom positiven Rücklauf überwältigt, den ich auf den Datenspuren erfahren habe. Dass es im Netz auch einen Shitstorm geben wird von Leuten, die erstmal alles schlecht finden, ist mir ehrlich gesagt so bewusst wie egal.
Wer wissen will, was pEp leisten kann, lädt sich halt mal die Outlook-Preview herunter, und schaut selber. Die funktioniert nämlich bereits. Und sie dürfte die mit Abstand am einfachsten zu benutzende Möglichkeit sein, Mails zu verschlüsseln. Man klickt nämlich auf “Senden”, der Rest geht automatisch.
Danke Dir, dem Team und den Supporten (in die ich mich eben eingereiht habe)! Lass Dir und lasst Euch den shitstorm egal sein!
Wo gibt’s diesen Shitstorm denn überhaupt zu bewundern?
Hallo Volker
Wenn ich mir eure Funktionsbeschreibung durchlese steht das meiner Meinung nach im Widerspruch zu den http://www.openpgp-schulungen.de/kurzinfo/schluesselqualitaet Aussagen. Wäre schön, wenn Du etwas dazu sagen könntest.
LG
Togijak
@Togijak: bitte werde konkret, auf was Du Dich beziehst. Dann kann ich gerne darauf eingehen.
Hallo Volker
Das war keine Kritik sondern nur eine Frage und sie bezog sich zum Beispiel auf „Wenn man keine entsprechenden Vorkehrungen trifft, dann werden bei der Schlüsselerzeugung (und danach allen Änderungen am Schlüssel) SHA-1-Signaturen erzeugt. Man benötigt dafür die Option cert-digest-algo, sinnvollerweise in der Konfigurationsdatei; also etwa cert-digest-algo SHA256 oder cert-digest-algo SHA512“ Ein weiterer Punkt der mir dabei in den Sinn kam ist „Die Computer, auf denen Schlüssel verwendet werden, sind geradezu dramatisch unsicher. Nicht nur der eigene, sondern auch der des Kommunikationspartners. Die Daten sind nur so sicher, wie das schwächste Glied in der Kette.“ und daran kann auch pEp nichts ändern, was für mich bedeutet, dass sich Nutzer über den Aspekt häufig nicht im Klaren sind und deshalb glauben könnten, dass ihre Kommunikation nun sicher sei obwohl das eben aus besagten Gründen nicht garantiert ist.
Abschließend nochmal – ich finde das Projekt klasse und wünsche ihm allen Erfolg der Welt, denn alles was der Überwachung schadet, den Überwachern das Leben ein Stück schwerer macht, ist ein Schritt in Richtung Freiheit.
Togijak
@Togijak: erst einmal: bitte äussere ruhig Kritik, wenn Dir etwas auffällt. Niemand bei pEp ist so dumm nicht zuzuhören, wenn jemand anderes ein Argument hat (das wär ja noch schöner).
Zu Deinen Punkten:
»Wenn man keine entsprechenden Vorkehrungen trifft, dann werden bei der Schlüsselerzeugung (und danach allen Änderungen am Schlüssel) SHA-1-Signaturen erzeugt.«
SHA-1 ist ja ein Algorithmus für kryptographische Hashes. Es kann zur Erstellung eines Message Digest genutzt werden. Bei OpenPGP kommt es z.B. beim Schlüssel-Signieren vor. Davon will pEp ganz weg.
Der Grund, weshalb pEp keine Schlüssel signiert (und somit auch kein Web-of-trust erstellt) ist, dass damit das Kontaktenetzwerk der Benutzer offen gelegt wird. pEp verwendet stattdessen Peer-to-peer trust management unabhängig von GnuPG in einer SQLite-Datenbank auf ~/.pEp_management.db (Unix, Linux, etc.) bzw. %LOCALAPPDATA%\pEp\management.db (pEp for Outlook, siehe Preview) oder %APPDATA%\pEp\management.db (pEp Enterprise edition).
Falls Du auf die Signatur der pEp_for_Outlook_preview.zip anspielst – hier ist es eine Frage der Interoperabilität. Unglücklicherweise unterstüzen nicht alle PGP-Implementierungen bereits moderne Hash-Algorithmen wie RIPEMD-160.
Die Frage, wie wir mit dem Problem umgehen, ist übrigens noch ungeklärt. Das hängt ganz davon ab, was andere Implementierungen in naher Zukunft machen wie z.B. Symantec PGP. Sandro testet eine Menge solcher Implementierungen, u.a. PGP selber.
» “Die Computer, auf denen Schlüssel verwendet werden, sind geradezu dramatisch unsicher. Nicht nur der eigene, sondern auch der des Kommunikationspartners. Die Daten sind nur so sicher, wie das schwächste Glied in der Kette.” und daran kann auch pEp nichts ändern, was für mich bedeutet, dass sich Nutzer über den Aspekt häufig nicht im Klaren sind und deshalb glauben könnten, dass ihre Kommunikation nun sicher sei obwohl das eben aus besagten Gründen nicht garantiert ist.«
Dazu drückt pEp eine besondere Haltung aus: wir empfehlen dringend, das Home oder Profil, am besten den ganzen Datenträger zu verschlüsseln, und ein gutes Login-Kennwort zu verwenden: https://xkcd.com/936/ Da kommt übrigens auch die Idee mit den Safewords her.
Wir planen, bei pEp für Windows-Plattformen einen TrueCrypt-Fork gleich mitzuliefern, dessen Installation dann vorgeschlagen wird, sobald es sich um eine Home Edition von Windows handelt. Für alle anderen Plattformen wird das pEp-Setup prüfen, ob Home, Profil oder Datenträger bereits verschlüsselt sind. Falls nicht, werden wir das empfehlen.
Letztlich kann auch pEp nicht alle Computer sicher machen, sondern nur die Kommunikation zwischen diesen. Aber pEp beruht schon auf einer Idee, wie das Endanwender endlich erreichen können, dass Ihr Computer nicht mehr so unsicher ist:
1) Datenträger verschlüsseln (MacOS X: FileVault, Windows: Bitlocker oder TrueCrypt-Fork bei Home Edition, Ubuntu: Home-Verschlüsselung etc.)
2) Als Kennwort Monroe folgen: https://xkcd.com/936/
3) Im Browser Einmalkennwörter (für jede Seite ein anderes) verwenden, und direkt im Browser speichern (wir werden das vermutlich auch mit synchronisieren)
4) pEp für die Kommunikation einsetzen
Das macht die bisherige Situation sicher nicht schlechter, sondern eher viel, viel besser.
»Abschließend nochmal – ich finde das Projekt klasse und wünsche ihm allen Erfolg der Welt, denn alles was der Überwachung schadet, den Überwachern das Leben ein Stück schwerer macht, ist ein Schritt in Richtung Freiheit.«
Danke!
Ich finde es auch immer Klasse, wenn Menschen sich Ideen einfallen lassen, um anderen sichere Kommunikation nahe zubringen. Bei dieser sehe ich aber ein rießiges Problem: Das Projekt macht sich abhängig von den Firmen. Einerseits müssen sie auf jede Änderung im original Programm (Outlook, Whatsapp, FB) reagieren und andererseits müssen die Firmen erstmal damit einverstanden sein.
Das Beste Beispiel dafür ist Whatsapp, gerade bei jüngeren mittlerweile eine sehr beliebte Kommunikationsplattform. Whatsapp ist in der Vergangenheit sehr konsequent gegen jeden vorgegangen, der versucht hat Whatsapp zu erweitern/verbessern oder sonstwas mit dem Program zu machen. Der erste Blogeintrag bei OpenWhatsapp spricht das Problem deutlich an: http://openwhatsapp.org/blog/2014/02/13/mass-dmca-takedowns-whatsapp/
Ich weis nicht, ob die Übernahme von FB an der Strategie was geändert hat, aber ich kann mir derzeit nicht vorstellen, dass Whatsapp mit so einem Projekt einverstanden wäre. Und Whatsapp würde ich bei Jüngeren noch vor dem FB-Messanger oder eMail sehen, wenn es um Kommunikation geht.
Ich kann Dich beruhigen, pEp ist nicht abhängig von irgendwelchen Firmen.
pEp hat ein Transportsystem, um zu verschlüsseln, was da ist. Da werden unterschiedliche Transporte implementiert. Angefangen hab ich in der Preview schlicht damit, die Outlook-MAPI zu nutzen.
Nun gibt es Transporte wie E-Mail, die über die RFCs faktisch genormt sind. Also halte ich mich an die Norm.
Leider sind Transporte wie Whatsapp oder Facebook nicht genormt. Bei Whatsapp muss man reversen, das hat das OpenWhatsapp-Projekt gemacht, entsprechend hängen wir uns da dran (ohne den Code zu verwenden, weil wir den in der Engine in C brauchen, ist also ein Rewrite). Das wird Arbyte geben, weil man das nachpflegen muss.
Bei Facebook ist es so, dass es eine offizielle API gibt. Die nutzen wir erst einmal. Allerdings stellt Facebook grade um. Gut, der Facebook-Transport geht mit.
Aber auch wenn einer der Transporte wegfällt, bleibt pEp nutzbar.
Das größte Problem an einfacher und nutzerfreundlicher Verschlüsselung ist denke ich die Key-Verwaltung. Wenn ich das richtig verstanden habe wird bei p=p auf Key Server gesetzt.
Was passiert wenn sich der Key eines Nutzers ändert (zB durch Geräteverlust)? Muss der neue Key dann manuell akzeptiert werden? Wird es eine Möglichkeit geben Keys über einen Seitenkanal zu überprüfen und als verifiziert zu markieren (nur für power-user)?
Ich habe leider kein Outlook und kann die Preview daher nicht testen…
pEp setzt nicht auf Keyserver.
Sondern pEp versucht abwärtskompatibel zum Web of Trust auf den Keyservern zu sein. Das heisst:
In der Standardeinstellung (die einzige, die in der Preview verfügbar ist) benutzt pEp die Keyserver lesend, aber niemals schreibend. Stattdessen werden die Keys als Dateianhänge ebenfalls peer-to-peer verteilt.
Durch die (geplante) Synchronisation werden unterschiedliche Geräte dasselbe Keypair benutzen. Geht ein Gerät kaputt oder fällt sonstwie aus, ist der Key immer noch da – auf allen anderen Geräten. pEp nutzt dabei, dass viele Leute ein Smartphone und ein Pad oder ein Laptop haben. Gibt’s ein neues Gerät, kommt das in die Gruppe, und bekommt den Key.
pEp wird deshalb auch eine Funktion haben “Unverschlüsseltes Gerät verloren”. Dann wird revoked und neu erstellt, auf allen Geräten in der Gruppe.
@Volker: Inzwischen halte ich mich von PGP-Keyservern so weit wie möglich fern, denn ausser bei pgp.com liegen dort vor allem Key-Leichen – von mir und vielen anderen … ist das für Dich ein Thema?
Ja.
Ich sehe es wie Du, Keyserver sind keine gute Idee. Während des Übergangs nutzt pEp sie noch lesend, später gar nicht mehr.
Die Leichen sind oft nicht so schlimm, weil sie nämlich meist abgelaufen sind (“expired”). Keys, die gar nicht oder zu lange nicht ablaufen, könnte pEp ignorieren. Da das eine Heuristik ist, wird die in ein paar Fällen auch schieflaufen. Da muss man dann eben manuell sagen, dass man einen anderen Key will.
Wichtig ist, dass diese Fälle
a) selten sind
b) nicht bei Neunutzern auftreten, sondern nur bei Leuten, die bisher schon was mit PGP gemacht haben.
heise Security (http://www.heise.de/security/meldung/Verschluesselung-fuer-Alle-Mit-PEP-die-Kosten-der-Ueberwachung-steigern-2391141.html) und die NZZ (http://www.nzz.ch/mehr/digital/pretty-easy-privacy-pep-volker-birk-leon-schumacher-1.18383774) haben so darüber berichtet, dass „normale User“, wie ich, es auch verstehen :)
PS:
Unterstützt habe ich das Projekt bereits.
Danke!
Man kann die Entwickler in ihrem ambitionierten Projekt nur bestärken und wenn möglich sogar unterstützen. Jedes Tool, jedes Projekt das den Menschen die ihre Privatsphäre zu verbergen haben hilft, gehört gefeiert.
Allerdings entstand – zumindest für mich – beim Lesen des Artikels der Eindruck bisherige Konzepte fielen eher in die Kategorie „complicated“ statt „good“ Privacy. Insbesondere Enigmail in Verbindung mit Gpg4win finde ich allerdings sehr leicht verständlich und liebevoll erklärt (Gpg4win sogar mit jeder Menge scheinbar eigens dafür erstellter Grafiken). Und immerhin wurde Gpg4win durch deutsche Steuergelder vom BSI finanziert. Wieviel „easier“ es da noch werden soll kann ich mir fast nicht vorstellen.
Der Ansatz des plattform-, software- und geräteübergreifenden Einsatzes ist hier allerdings wahrlich das Sahnehäubchen und wohl der Mammutteil des Projektes.
Sollte von der Entwicklerseite jemand an dem Post hier vorbeistolpern: Wird es „nur“ die easy-Variante geben oder auch so etwas wie Experteneinstellungen – also für die Leute, die wissen was sie tun und das auch selber tun möchten. Schlüssellänge, Algorithmus, Ablaufdatum, Serverupload ja oder nein und dergleichen?
Für das Projekt alles erdenklich Gute und maximal möglichen Impact ;-)
kryptische Grüße
RvB
Erst einmal etwas zu GPG4Win:
Das Projekt ist grossartig. pEp wäre auf der Windows-Plattform ohne GPG4Win gar nicht möglich. Und deshalb ist GPG4Win auch auf pep-project.org prominent verlinkt, direkt neben GnuPG selber.
Was haben die GPG4Win-Leute falsch gemacht? Meiner Ansicht nach rein gar nichts.
pEp ersetzt nicht GPG4Win. Übrigens installiert die Preview GPG4Win gleich mit, und verwendet es, falls es noch nicht installiert war. pEp ist schlicht etwas anderes.
GPG4Win ist eine vollständige GnuPG-Implementierung für Windows. Und eine gut gepflegte dazu (siehe den letzten Bug, die Beta, die’s sofort gab, und dann das schnelle Release). Wir werden alles upstream geben, was wir hier erweitern.
Aber das ist eben genau das, was pEp macht: es bedient GPG4Win. So wie es immer GnuPG bedient. Man kann sagen, pEp ist eher eine Alternative zum GPA und zu Kleopatra (die ja wechselseitig Alternativen sind).
Die Preview liefert übrigens GPA mit, weil sie noch nicht alle Funktionen hat. Du findest GPA im Menü P≡P in Outlook mit der Preview.
Zu Deiner letzten Frage: Es wird einen dicken Einstellungsdialog geben. Ich hab die Entwicklung dieses Dings mal auf “nach der Preview” verschoben ;-)
Danke für die guten Wünsche!
Hallo Volker
Mich würde die Whatsapp-Verschlüsselung noch genauer interessieren. Du schreibst, dass ihr reversen wollt. Das verstösst aber gegen die TOC von WhatsApp (und anderen Diensten). Was tut ihr, damit eure Nutzer nicht plötzlich von WhatsApp gebannt werden?
Wir reversen nicht Whatsapp. Sondern wir verwenden die Informationen aus http://openwhatsapp.org/ (um genau zu sein, die von Yowsup https://github.com/tgalal/yowsup ) – vermutlich haben die Whatsapp reversed. Edouard machte den Witz “do I really reverse reversed code” als Anspielung auf die dürftige Entwicklerdoku von OpenWhatsapp. Bei Whatsapp ist es das beste, was wir gefunden haben.
Bei Facebook Messages sieht es besser aus, dort können wir die offizielle API von Facebook verwenden: https://developers.facebook.com/docs/graph-api/reference/v2.1/message
Wieso verstösst das gegen die TOC von Whatsapp? Wer sagt überhaupt das diesen rechtskräftig durch die Entwickler zugestimmt wurde? Haben die Entwickler ÜBERHAUPT dieser TOC zugestimmt? JA/NEIN? Sind diese TOC überhaupt rechtlich legal? JA/NEIN?
Hier also mal keinen FUD verbreiten!
Ich hoffe ich kann einen, zwei drei existierende Schlüssel importieren, und diese dann in allen Instanzen nutzen, sodass ich, je nach Zweck und Kommunikationspartner, von jeder eMail-Adresse aus jede meiner Schlüssel zum Signieren und Verschlüsseln nutzen kann.
Nützt sonst garnix, wenn ich für jede App und jede eMail-Adresse einen eigenen Schlüssel „brauche“.
pEp basiert vollständig auf GnuPG. Entsprechend kannst Du selbstverständlich Schlüssel importieren. Es kommt aber noch besser: falls Du GnuPG bereits verwendest, musst Du gar nichts tun. Denn pEp nutzt die bereits vorhandene GnuPG-Installation, und installiert nur dann selbst eine, wenn vorher keine da war.
Sehr geiles Projekt. Ich wünsche euch viel Glück und spende auch nen Happen.
Was ist nach der crowdfunding Aktion zur Finanzierung eines schnellen Fortschreitens geplant?
Erfahrungsgemäß ebbt die Begeisterung der Funder wieder schnell ab. Irgendwann werden die $50k auch weg sein aber das Projekt mittendrin.
Mich begeistert pEp gar nicht. Ich finde es schade, dass hier Ressourcen versenkt werden. Warum ein Verschlüsselungssystem weiterführen und in einer Monsterlösung verkomplizieren statt auf neue Lösungen wie Axolotl (das „verbesserte“ OTR aus TextSecure) und die Unix-Philosophy („Write programs that do one thing and do it well.“) zu setzen? Vor allem dann, wenn die Voraussetzungen doch gegeben sind:
> „Aside above-mentioned projects like Axolotl and TextSecure — which pretend to be text messaging systems, but are really email in disguise…“
– http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html
Auch scheint PGP im Widerspruch zu den Anforderungen privater Kommunikation zu stehen. Abgesehen von der „Forward-Secrecy“ die wohl irgendwie „Auf Basis von GnuNet“ (pEp Entwickler Volker Birk, siehe Kommentar oben) eingebaut werden soll, ist das Irre an PGP doch, dass man jede Nachricht unterzeichnet und dem Gesprächspartner die Möglichkeit gibt, Dritten gegenüber kryptographisch zu beweisen, dass man diese Nachricht geschrieben hat. Um das mal runter zu brechen: Das wäre so, als würde man bei jedem privaten Gespräch ein Tonband mitlaufen lassen und darauf hoffen, dass keiner der Gesprächspartner seine Tonbandkopie verliert oder missbraucht.
Auf diese grundlegende Unzulänglichkeit von PGP für die private Anwendung haben nicht nur die OTR-Entwickler hingewiesen (https://otr.cypherpunks.ca/otr-wpes.pdf). Auch der im Artikel zitierte Matthew Green („[…] for all the good PGP has done in the past, it’s a model of email encryption that’s fundamentally broken.“) auf dessen Artikel auch Bruce Schneider verweist (https://www.schneier.com/blog/archives/2014/08/the_problems_wi_4.html) wie auch die TextSecure Entwickler inklusive Moxie Marlinspike („If it’s ‚like PGP,‘ it’s wrong. PGP is our spirit guide for what not to do.“, https://github.com/WhisperSystems/TextSecure/blob/master/contributing.md).
Bitte meinen Kommentar von @ 19:15 löschen. Danke :)
Mich begeistert pEp gar nicht. Ich finde es schade, dass hier Ressourcen allokiert werden. Warum ein Verschlüsselungssystem weiterführen und in einer Monsterlösung verkomplizieren statt auf neue Lösungen wie Axolotl (das “verbesserte” OTR aus TextSecure) und die Unix-Philosophy (“Write programs that do one thing and do it well.”) zu setzen? Vor allem dann, wenn die Voraussetzungen doch gegeben sind:
> “Aside above-mentioned projects like Axolotl and TextSecure — which pretend to be text messaging systems, but are really email in disguise…”
– http://blog.cryptographyengineering.com/2014/08/whats-matter-with-pgp.html
Auch scheint PGP im Widerspruch zu den Anforderungen privater Kommunikation zu stehen. Abgesehen von der “Forward-Secrecy” die wohl irgendwie “Auf Basis von GnuNet” (pEp Entwickler Volker Birk, siehe Kommentar oben) eingebaut werden soll, ist das Irre an PGP doch, dass man jede Nachricht unterzeichnet und dem Gesprächspartner die Möglichkeit gibt, Dritten gegenüber kryptographisch zu beweisen, dass man diese Nachricht geschrieben hat. Um das mal runter zu brechen: Das wäre so, als würde man bei jedem privaten Gespräch ein Tonband mitlaufen lassen und darauf hoffen, dass keiner der Gesprächspartner seine Tonbandkopie verliert oder missbraucht.
Auf diese grundlegende Unzulänglichkeit von PGP für die private Anwendung haben nicht nur die OTR-Entwickler hingewiesen (https://otr.cypherpunks.ca/otr-wpes.pdf). Auch der im Artikel zitierte Matthew Green (“[…] for all the good PGP has done in the past, it’s a model of email encryption that’s fundamentally broken.”) auf dessen Artikel auch Bruce Schneier verweist (https://www.schneier.com/blog/archives/2014/08/the_problems_wi_4.html) wie auch die TextSecure Entwickler inklusive Moxie Marlinspike (“If it’s ‘like PGP,’ it’s wrong. PGP is our spirit guide for what not to do.”, https://github.com/WhisperSystems/TextSecure/blob/master/contributing.md).
Der Ansatz ist goldrichtig. Der Normaluser ist derzeit deswegen völlig ignorant gegenüber der Überwachung (NSA, BKA und Co), weil er auf elektronische soziale Kommunikation nicht verzichten will, aber nicht sicher kommunizieren kann. Lässt sich das mit einem Klick (oder Touch) ändern, wird er’s tun. Und von anderen verlangen, dass sie es auch tun.
Das Problem der fehlenden Abstreitbarkeit sehe ich auch, aber Abstreitbarkeit wäre ein Hindernis für verlässliche Kommunikation, wie sie im Geschäftsverkehr unabdingbar ist. Falls sich pep mit PGP so implementieren lässt, wie oben dargestellt, würde es wohl sogar die Anforderungen an die qualifizierte Signatur erfüllen und sich damit zur Abgabe rechtlich verbindlich Willenserklärung eignen. Das wäre ein bahnbrechender Fortschritt.