Beiträge von generalsync

Zitat von ArtGee

Auch wenn das mit Outlook nicht vergleichbar ist, müsste eine solche Zielgruppe doch groß genug sein, eine wahrscheinlich längst vorhandene Lösung für Android nur noch auf iOS anzupassen.

Ich glaube du Unterschätzt da die Komplexität (oder die Kosten von Softwareentwicklung im Allgemeinen). Android und iOS haben abgesehen von einigen Bedienkonzepten keine Gemeinsamkeiten: die App muss in einer anderen Programmiersprache geschrieben werden (lies: von Grund auf neu geschrieben werden), einem anderen Bedienkonzept gehorchen und technisch völlig andere Schnittstellen bedienen.

Im Gegensatz zu Android, Thunderbird und selbst Outlook ist die Schnittstelle für Kalender und Kontakte meines Wissens darüber hinaus stärker eingeschränkt. Generell erlaubt Apple viele Dinge nicht, die auf anderen Platformen als selbstverständlich gelten. Genauer angesehen habe ich mir das jedoch nicht, aber auch bei Android sind für eine zuverlässige Synchronisation einige Workarounds nötig.

Zitat von Drehmoment

Damit sollte doch eigentlich alles klar sein, oder nicht?

Ich weiß nicht wie das im konkreten Fall aussieht, aber die Spezifikation eines Primitivs (wie z.B. einer Kurve) und die Spezifikation der Einbettung des Primitivs in ein Protokoll (z.B. PGP) stehen i.d.R. in zwei unterschiedlichen Dokumenten. Es klang mir so, als hätten die gpg-Entwickler nicht öffentlich und/oder vollständig spezifiziert, wie man aus den PGP-Datenblöcken die korrekten Parameter für die notwendige Operation auf der Kurve ableitet (also wie man die Kurve in PGP einbettet). Dafür ist die Spezifikation der Kurve natürlich wichtig (und wohl vorhanden), aber alleine nicht ausreichend.

Zitat von Drehmoment

Soweit ich weiß, werden 8k-Keys erst ab GnuPG 2.1.x unterstützt. [...] Du würdest auf jeden Fall einige Mailpartner ausschließen.

Also ein aktuelles gpg stable (1.4.x) und gpg modern (2.0.x und 2.1.x) arbeiten bei mir wunderbar mit 16k-Keys.

Du meinst vermutlich die Schlüsselerzeugung, die ging nämlich mindestens vor ein paar Jahren wirklich noch nicht mit >4k. Dafür musste man gpg patchen, d.h. mit einem größeren Maximum neu kompilieren. Die so erstellten Keys konnten aber danach auch im "normalen" gpg ohne Patch und auf gängigen Keyservern genutzt werden. Es könnte aber natürlich dennoch einige Clients geben, die damit Probleme haben.

Alternativ soll es wohl auch über den Batch-Modus gehen, habe ich nicht getestet.

Ob das Maximum inzwischen angehoben wurde habe ich nicht verfolgt, aber bei mir gibt es noch ein 4k-Limit (2.2.4, gentoo). Ob und wie 8k-Keys mit einer GUI erzeugt werden können, bin ich ebenfalls überfragt (aber so schwer ist das CLI auch wieder nicht: gpg --full-gen-key, dann Enter).

Zitat von Drehmoment

Frage mal bei generalsync nach, ob sein Programm auch mit iPhone funktioniert.

Nein, GeneralSync unterstützt derzeit nur Android und alle gängigen PC-Betriebssysteme. Ob und wann iPhones unterstützt werden ist noch offen.

Ohne Server wüsste ich auch nichts was Du nicht schon getestet hättest. Bleibt also eigentlich nur ein CardDAV-Server (das kann auch der PC sein, auf dem Thunderbird läuft); ist aber in jedem Fall ein bisschen Konfigurationsaufwand, und ob und wie gut das ganze auch offline läuft kann ich nicht beurteilen. Alternativ das iPhone verkaufen und ein Android-Gerät nehmen...

Zitat von Drehmoment

GnuPG die Kurve 25519 bereits unterstützt, obwohl sie noch nicht offiziell standardisiert ist. Dieser Schritt gefällt mir sehr gut. Handeln statt Rumzuppeln!

Mir gefällt das überhaupt nicht, wenn ich die verlinkte Diskussion richtig verstehe. Ich habe das ganze aber im Fall von gnupg und cv25519-Verschlüsselung nicht ernsthaft verfolgt, daher allgemein formuliert:

Eine (ggf. selbst geschriebene) Spezifikation zu implementieren bevor sie zum Standard erhoben wird, ist sinnvoll und wichtig. Auf diese Weise gibt es für den jungen Standard auch gleich eine Referenzimplementierung. Aber: eine Implementation ohne Spezifikation ist selten eine gute Idee, wenn es um Datenformate geht.

Man sollte sich erst unabhängig von der Implementation über das Format Gedanken machen und das Ergebnis davon in Form einer Spezifikation festhalten. In dem Zuge sollte man sich auch über Vor- und Nachteile gegenüber aktuellen und alternativen Formaten nachdenken, und etwaige Designprobleme früherer Formate berücksichtigen. Idealerweise kommen hierbei auch andere Implementationen zu Wort (sofern es um offene Standards geht). Wenn eine weit verbreitete Implementierung ohne solche Überlegungen "Fakten schafft", behindert sie i.d.R. die Weiterentwicklung aller anderen (da eine bessere Spezifikation nicht mehr so einfach etabliert werden kann, wenn Produktivsysteme bereits mit einem inkompatiblen Format arbeiten).

Zitat von Drehmoment

Die Präsentation nennt Gründe, u.a. das Misstrauen gegenüber der NIST und natürlich auch den hier besprochenen Umstand, dass RSA noch sicher ist, es also keinen harten Grund gibt.

Bei Kryptografie ist Misstrauen imho ein harter Grund. Letztendlich geht es schließlich bei Verschlüsselung und vor allem bei Signaturen um Vertrauen. Wie du ja bereits erwähnt hast: im besten Fall ist ECC mit den aktuell gängigen Kurven ungefähr gleich sicher wie RSA. Warum sollte man also eine Lösung nutzen, die gleiche Sicherheit bietet aber weniger Vertrauen genießt und derzeit weniger Kompatibel ist?

Die Präsentation liefert ja auch die Antwort dazu: weil es Performance bringt oder man "mal was neues" testen will. Das sind die zwei einzigen Punkte für ECC. Testen macht sicher Spaß, aber ist nicht wirklich relevant. Performance interessiert nur einige wenige große Player – alle anderen haben an anderer Stelle proportional größere Performanceprobleme¹. Bei Zertifikaten ist ECC darüber hinaus nur für den Aussteller von Vorteil, die Verifikation einer Signatur ist dagegen deutlich aufwändiger als RSA (bei gängigen Schlüssellängen).

Ich selbst nutze daher derzeit ECC (mit den NIST-Kurven) nur sparsam dort, wo ECC seine Vorteile auch ausspielen kann (oder ich von Dritten dazu gezwungen werde). Bestes Beispiel ist TLS: der Schlüsselaustausch für den Sitzungsschlüssel ist über ECDH deutlich effizienter als via DH und damit insbesondere für Mobilgeräte stromsparender. Ich habe trotzdem ein bisschen Bauchschmerzen dabei, aber da sehe ich einen Sinn.

Bezüglich des Henne-Ei-Problems:

Da es bereits ECC gibt, werden die besseren Kurven nicht überall zügig implementiert (Argument: die neuen Kurven brauchen neuen Code, und wir unterstützen doch schon ECC!). Die alten Kurven genießen allerdings besagtes Misstrauen, und werden daher noch langsamer adaptiert als es ohnehin geht, solange das alte Verfahren nicht gebrochen wurde.

__

¹ bei TLS hat sich ECDH aber dennoch durchgesetzt, da es inzwischen schlicht die Standard-Einstellung ist. Dort kommen die Vorteile aber auch in besonderem Umfang zum Tragen.

OT-Fortführung von Empfohlener Algorithmus für Schlüssel - Verwendung elliptischer Kurven.

Zitat von Drehmoment

Hältst das für ein Risko, das uns in absehbarer Zukunft betreffen wird? Ich halte das derzeit für sehr ferne Zukunftsmusik. Ein echter Quantencomputer scheint mir noch weit, weit entfernt.

Ich bilde mir nicht ein, das "Risiko" beurteilen zu können.

Wenn man jedoch ein grundlegendes Primitiv tauscht (z.B. RSA durch ECC ersetzt) ist das eine langfristige Entscheidung, die Standards für viele Jahrzehnte beeinflussen wird. Damit geht auch ein Stück weit eine Lähmung einher: die imho besseren Kurven haben es jetzt sehr schwer, überhaupt genutzt zu werden. "Gute" ECC-Implementierungen werden also noch einige Jahre brauchen, die ECC-Umstellung ist noch lange nicht abgeschlossen.

Ich befürchte eine ähnliche Situation bei Post-Quantum-Crypto: die Umstellung wird Jahrzehnte dauern. Was man so hört, sind Quantencomputer derzeit (zumindest im zivilen Bereich) noch nicht annähernd so weit. Es gibt sogar Stimmen, die die physikalische Machbarkeit generell bezweifeln (d.h. Quantencomputer könnten generell und unabhängig von Aufbau nicht in den benötigten Größen existieren). Außerhalb ziviler Forschung war man jedoch in der Vergangenheit häufiger einige Jahre weiter, insofern könnte ich mir schon vorstellen, dass die Quantenrechnerei innerhalb von 20 oder 30 Jahren zumindest für manche Anwender verfügbar wird. Und dann natürlich auch rückwirkend aufgezeichnete Kommunikation entschlüsselt wird.

Kein wirklicher Grund zur Panik, aber vielleicht ein Grund, schon jetzt darüber nachzudenken, wie man das Problem aus der Welt schaffen könnte. Etwaige neue Verfahren sollten ja einige Jahre vor dem Quantencomputer selbst etabliert sein, und ohne Druck etablieren sich neue Techniken nur sehr langsam. Und das Szenario "mit Druck" will ich mir nicht ausmalen...

Zitat von Drehmoment

Ich weiß nicht, wie man sich technisch gegen die Kraken schützen kann.[...] Ende-zu-Ende-Verschlüsselung sperrt die Neugieren vom Inhalt aus. Das ist immerhin etwas. [...] Sie haben aber immer noch die Metadaten. Außerdem wissen sie aus anderen Quellen, wer sich wann wo aufhält, wen er trifft, was er einkauft, wie sein finanzieller Status ist, wo er wohnt usw. . Wir haben die totale Wanze ja stets dabei.

Damit beantwortest du ja eigentlich schon selbst die Frage: man muss bei der "totalen Wanze" ansetzen und der Sammelei einen Riegel vorschieben. Wobei ich zusätzlich argumentieren würde, dass neben Smartgeräten auch viele andere alltägliche Dinge ein Problem darstellen, z.B. widersprechen die Wenigsten einer Nutzung Ihrer Daten zu Werbezwecken, die inzwischen in fast jedem Vertrag drin steht. Rechtlich geht inzwischen einiges, wenn man als Individuum aktiv wird und widerspricht. Die Zusammenführung verschiedener Quellen sollte man damit zumindest bei europäischen Firmen unterbunden bekommen. Eine technische Garantie gibt es aber natürlich nicht.

Dazu kommt, dass die kommerziellen Kraken i.d.R. sehr genau beschreiben, welche Daten sie speichern. Ob das nun legal ist oder nicht mal dahingestellt – aber der Nutzer kann sich theoretisch vor der Nutzung eines Dienstes informieren, was mit seinen Daten passiert. Es ergibt sich die technische Schutzmöglichkeit Nummer 1: problematische Dienste einfach nicht nutzen. Dort fallen dann weder Daten noch Metadaten an – Problem gelöst?

Macht natürlich fast niemand und es gibt soziale Monopole (z.B. Facebook), deren Nichtnutzung in manchen Personenkreisen zu sozialer Ächtung führen kann. Nicht jeder ist bereit, für Datenschutz auf Kontakt zu Menschen aus diesen Kreisen zu verzichten. Bei vielen Diensten ist Nichtnutzung aber wirklich eine sinnvolle Option und/oder es gibt bessere Alternativen. Zumindest kann man oftmals einen Anbieter mit sympathischerer Datenschutzerklärung finden.

Und wenn es noch keine Alternative gibt, lässt sich vermutlich eine entwickeln. So versuche ich das bei GeneralSync: Kalender und Kontakte dezentral und automatisch auszutauschen war lange Zeit nicht möglich. Aber inzwischen habe ich meine Kalender und Kontakte komfortabel auf allen Geräten. Aus Nutzersicht ist das (bis auf die Einrichtung) genauso bequem wie über die Cloud oder einen eigenen Server. Ich glaube, dass da auch in anderen Bereichen viel geht. Ob die Zahlungsbereitschaft da ist, um das zu finanzieren, kann ich aber natürlich noch nicht sicher beurteilen, derzeit ist GeneralSync noch in einer kostenlosen Beta. Das Feedback das ich zu dem Thema bislang bekommen habe stimmt mich aber eher positiv.

Nicht alles wird sich vollständig dezentral machen lassen, aber in Verbindung mit rechtlichen Barrieren denke ich schon, dass ein "vernünftiges" Level an Privatsphäre machbar ist, ohne auf Komfort im Alltag verzichten zu müssen. Allerdings liegt ein solches Leben natürlich nicht im Interesse der Kraken.

Das Hauptproblem ist also aus meiner Sicht weniger die Technik als die "blinde" Verwendung von Diensten, die (unter anderem) mit Daten bezahlt werden. Und das ist ein gesellschaftliches Problem. Und wie es so schön heißt: gesellschaftliche Probleme lassen sich nicht (nur) mit Technik lösen.

Zitat von Drehmoment

Bei allem Getue um zukünftige Quantencomputer und die bereits vorhandenen Super-Computer herkömmlicher Bauart, ist es doch so, dass Kosten und Aufwand immens sind. Für die E-Mails von Lieschen Müller viel zu hoch.

Im Bezug auf "herkömmliche" Supercomputer ist das richtig, solange keine neuen Angriffe gegen RSA gefunden werden.

Wenn ein Quantencomputer mit für Shor's Algorithmus ausreichender Größe, Zuverlässigkeit, etc. existieren würde (das ist ja theoretisch noch gar nicht geklärt), würde er das Knacken aber so effizient machen, dass es im Vergleich zu den Einmalkosten (Quantencomputer entwickeln und bauen) lächerlich preiswert wäre, alle (!) E-Mails zu entschlüsseln. Mindestens Geheimdienste mit Vorratsdatenspeicherung von verschlüsselten Inhalten würden dann auch vor Lieschen Müller nicht halt machen.

Und wenn die Daten erst einmal irgendwo entschlüsselt rumliegen, können sie auch leaken / von Dritten abgegriffen werden. Dazu muss man den Diensten gar keine böse Absicht unterstellen, da arbeiten halt auch nur Menschen.

Pessimisten könnten natürlich auch auf die Idee kommen, das solche Quantencomputer auf nichtstaatliche Stellen mit ähnlichen oder größeren Budgets und ähnlichem oder größerem Interesse an Daten ebenfalls eine gewisse Anziehungskraft ausüben würden.

Zitat von Drehmoment

Nach meiner persönlichen Meinung geht die größte Gefahr sowieso nicht von Behörden und Diensten, wie der NSA, aus. Die Gefahr kommt aus einer ganz anderen Ecke. Sie ist kommerziell, nahezu völlig unreglementiert und scheint viele dennoch überhaupt nicht zu stören.

Ja und nein: die Behörden bergen imho eine größere politische Gefahr, da von einem staatlichen Aktor Gesetze bewusst missachtet werden, und dieses Verhalten anschließend ohne ernsthafte inhaltliche Diskussion legalisiert wird. Ein solches Vorgehen gefährdet die Gewaltenteilung und damit die Gesellschaft als Ganzes. Das ist allerdings völlig unabhängig von der technischen Frage nach Schlüssellängen.

Die Sammelwut kommerzieller Marktteilnehmer ist dagegen sicherlich für Individuen derzeit die größere "direkte"/"sichtbare" Bedrohung – und diejenige, gegen die man sich technisch einfacher schützen kann: idealerweise mit E2E-Verschlüsselung und – soweit möglich – dem direkten Austausch zwischen eigenen/vertrauenswürdigen Geräten, z.B. mit einem eigenen Server, Syncthing oder GeneralSync (bei letzterem bin ich natürlich als Entwickler befangen).

Auf diese Weise minimiert man auch Metadaten, die ja oftmals noch wertvoller sind als die Inhalte selbst. Dafür muss man natürlich i.d.R. wieder mit Geld statt Daten bezahlen. Unterm Stich wird es vermutlich dennoch preiswerter, da Nutzerdaten vor allem verwendet werden, um dem Nutzer an anderer Stelle Geld aus der Tasche zu ziehen...

Um es aber nochmal auf die eigentlich von Markusm12 gestellte Frage zurückzukommen: der von dir verlinkte heise-Artikel bringt unsere Diskussion dahingehend nochmal auf den Punkt (Stand: Juni 2016):

Zitat von heise Security

Fazit: Das Minimum für sicheres RSA und DH sind 2048 Bit; neue PGP-Schlüssel sollte man mit 4096 Bit erzeugen. Schon mittelfristig brauchen wir Alternativen.

Aus meiner Sicht hat sich daran bislang nicht viel geändert.

Zitat von Markusm12

Ich möchte den Schlüssel auch für mein posteo Konto nutzen

Der Provider ist für PGP unwichtig, solange du einen Client nutzt (wie z.B. Thunderbird). Wenn du deinen privaten Schlüssel im Webmailer nutzen willst – und du die damit einhergehende zusätzliche Angriffsfläche in Kauf nimmst – muss der Key natürlich vom Webmailer unterstützt werden. Da kenne ich mich aber nicht aus, ggf. den Support bei Posteo bemühen.

Zitat von Markusm12

Ich kann mit Kleopatra bzw Thunderbird als GUI "nur" maximal 4096 bit RSA Schlüssel erzeugen. Macht mehr keinen zusätzlichen Gewinn oder wird es zu unpraktikabel?

Die Empfehlung von vor über 10 Jahren ist, Keys größer als 4096 bit aus Performancegründen nicht zu verwenden. Die Oberflächen halten sich bis heute an diese alte Empfehlung, auch wenn der Standard und die meisten Implementationen mit größeren Schlüsseln umgehen können (aber vermutlich nicht alle!). Gerade bei schwächeren Endgeräten wird es bei 16384 bit aber auch heute noch noch spürbar langsam.

Es ist wie immer also eine Frage der Abwägung: mehr Bits sind sicherer, langsamer und ein kleines bisschen weniger kompatibel. Ob die zusätzliche Sicherheit von Keys mit mehr als 4096 Bit viel bringt ist aber umstritten: wenn ein Angreifer 4096 erfolgreich angreifen kann, kann er in vielen Szenarios auch größere Keys brechen (Quantencomputer, RSA generell gebrochen, ...). Keys unter 2048 gelten als nicht mehr zeitgemäß.

Für alltägliche Dinge halte ich 4096 Bit derzeit noch für sinnvoll. Wenn du den Key primär als Zertifizierungsstelle nutzen willst und/oder langfristig viele Beglaubigungen sammeln willst und einen gewissen Hang zur Paranoia hast sind auch 8k oder gar 16k vertretbar, solange nur kleinere Subkeys für alltägliche Aufgaben genutzt werden. Mehr als 16k würde ich auf keinen Fall nehmen, da wird es wirklich unpraktikabel.

Zitat von Drehmoment

Wenn man wollen würde, könnte da längst etwas gehen.

Da bin ich ganz bei dir. Ich habe bislang nicht den Eindruck, dass die größeren Kurven genutzt werden, daher sprach ich von "akademisch".

Dazu kommt, dass ich die NIST- und auch Brainpool-Kurven nicht wirklich angeschaut habe, da diese (zumindest in manchen Varianten, ich bin da gerade nicht ganz drin) bekannte Schönheitsfehler aufweisen die mit Courve25519 und Co. gelöst wurden.

Zitat von Drehmoment

Ich nehme an, das beziehst du auf die Verschlüsselung allgemein, nicht auf deine privaten E-Mails?

Ich meine das prinzipiell für Schlüssel, die langfristig unverändert genutzt werden sollen. Das trifft insbesondere für den Primärschlüssel bei PGP zu, aber auch für Root-Keys von CAs, etc.

Zitat von Drehmoment

Oder kennst du andere Gründe, aus denen die Sicherheit von ECC umstritten sein könnte?

ECC ist noch (relativ) jung, wenn auch die diskreten Logarithmen schon länger ihr Unwesen treiben. Dazu kommt, dass sie strukturell komplexer sind. Das sind beides gute Gründe, um ECC zunächst zu misstrauen. Iirc gibt demenstprechend auch weniger (mathematische) Sicherheitsgarantien als bei RSA, sowas braucht einfach Zeit und Aufmerksamkeit. Letztere hat ECC inzwischen aber durchaus, das Argument wird also von Jahr zu Jahr schwächer.

Darüber hinaus bietet weder RSA noch ECC schutz vor Quantencomputern, ECC schneidet dort sogar noch schlechter ab. Man kann aber sicherlich darüber streiten, ob und in welchen Zeitrahmen Quantencomputer überhaupt realistisch sind... das ist aber eine andere Diskussion.

Viel wichtiger ist aber aus meiner Sicht aber ein viel banalerer Unterschied: ECC nutzt nicht nur absolut gesehen kürzere Schlüssel, sondern derzeit auch relativ zu RSA kürzere Schlüssel: bei ed25519 haben private Schlüssel um die 255 bit, das entspricht für RSA bei aktuell bekannten Angriffen ~3000 bit. "Normale" PGP-Keys in meinem Umfeld nutzen mit 4096 bit längere und damit sicherere Schlüssel. Und bereits 4096 bit halte ich für einen primären PGP-Key der einige Jahrzehnte^{(modulo Quantencomputer)} halten sollte für zu eng bemessen. Sollten neue Angriffe bekannt werden, kann sich das Verhältnis natürlich in beide Richtungen verschieben.

"Größere" Kurven für ECC (z.B. M-511/Curve511187 mit ~511 bits) werden jedoch derzeit nur akademisch betrachtet, für PGP gibt es meines Wissens noch keine Implementierung, geschweige Spezifikation / Standardisierung.

ECC ist in gpg derzeit noch hinter dem --expert switch verborgen, da in der Praxis massive Kompatibilitätsprobleme bestehen (insbesondere unterstützten gpg 1.4, manche Keyserver und iirc auch PGP überhaupt keine elliptischen Kurven, und selbst wenn Kurven unterstützt werden können diese oftmals nur für Signaturen verwendet werden). Dazu kommt, dass die m.E. sinnvollen Kurven noch gar nicht vollständig für PGP spezifiziert wurden, das Schlüssel-Format könnte sich also nochmal ändern. Sofern du ausschliesslich mit gnupg-Modern-Nutzern kommunizierst mag es funktionieren, ansonsten eher nicht.

Der "Sicherheitsgewinn" von ECC ist darüber hinaus umstritten, ECC ist vor allem schneller und die Schlüssel kleiner. Diese Vorteile merken insbesondere Serverbetreiber mit tausenden Zugriffen pro Minute, aber bei einigen PGP-Mails pro Tag auf einem normalen PC oder Smartgerät fällt das kaum ins Gewicht.

Neben Cloud und eigenem Server kann man z.B. über WLAN / LAN auch direkt synchronisieren; das bietet sich an, wenn man sein Adressbuch nicht an Datenkraken schicken will, aber auch keinen eigenen Server nutzt / nutzen will.

Am besten kenne ich mich naturgemäß mit dem von mir entwickelten GeneralSync (derzeit kostenlose Beta) aus, damit können Adressbücher (und Kalender) innerhalb desselben Netzwerks automatisch synchronisiert werden. Eine Synchronisation via Internet benötigt in diesem Falle jedoch zusätzliche Konfiguration.

Zitat von Gordy66

In den 2 Bildern im Anhang kann man sehen, dass in der Adressliste unter Nachname der Anfang der Email-Adresse steht

Die Spalte "Name" enthält nicht den Nachnamen, sondern den Anzeigenamen. Um einen Kontakt zu identifizieren, wird fast immer der Anzeigename verwendet. Dieser sollte daher alle Namensbestandteile enthalten, die in der Praxis verwendet werden.

Im gezeigten Kontakt ist der Anzeigename leer, daher wird er aus der E-Mail-Adresse abgeleitet. Wenn ein neuer Kontakt angelegt wird, trägt Thunderbird den Anzeigenamen jedoch eigentlich automatisch ein. Eventuell wurde er absichtlich entfernt?

MinTrayR funktioniert bei mir (gentoo, xfce 4.12) nach Anwendung von diesem Pull-Request (eine XPI hängt am dritten Kommentar, sofern du nicht selbst builden willst). Könnte also gehen, auch wenn es wohl mit manchen Distributionen und/oder Desktop-Umgebungen Probleme gibt.

Grüße

[OT]

Zitat von Drehmoment

Ich sprach nur von signatory trust. Und da wird mir nur "Absolutes Vertrauen" in Grün angezeigt. Selbst "Volles Vertrauen" bleibt noch blau.

Signatory trust ist entweder "vertraut" oder "nicht vertraut". Dazwischen gibt es nichts. Im Gegensatz zu owner trust, kannst du signatory trust nicht direkt einstellen!

Die Begriffe "absolut", "voll", "gering" und "kein" werden ausschließlich für owner trust verwendet. Einem Key "volles" Vertrauen (=full owner trust) auszustellen wirkt sich erst aus, wenn einem seiner UIDs anderweitig signatory trust zugewiesen wurde. War der Balken davor blau (signatory trust: "nicht vertraut"), bleibt der Balken also auch weiterhin blau. Owner trust in einen Key hat also in den meisten Fällen keine Auswirkungen auf signatory trust in die UIDs desselben Keys.

Ausnahme: absolutes Vertrauen (=ultimate owner trust) wird auch ohne vorher bestehenden signatory trust wirksam, dementsprechend wird der Balken hier direkt grün, auch ohne dass eine UID beglaubigt wurde (jeder Key beglaubigt sich selbst). Die Keys mit absolutem Vertrauen sind also deine Eintrittspunkte in das Web of Trust, jeglicher signatory trust lässt sich also auf mindestens einen absolut vertrauten Key zurückführen.

Enigmail macht also (zumindest in deinem Beispiel) alles genau richtig, da selbst bei vollem Vertrauen noch kein signatory trust besteht.

Wenn weiterer Diskussionsbedarf zu dem Thema besteht, sollte dafür aber ein anderer Thread verwendet werden. Die Enigmail-Farben haben schließlich nur bedingt etwas mit der Änderung einer E-Mail-Adresse zu tun.

[/OT]

[OT]

Wir kommen gerade etwas vom Thema ab, ich denke für eine längere Diskussion von Enigmail oder Keyservern sollte man in ein anderes Thema ausweichen. Dennoch eine kurze Bemerkung:

Zitat von Drehmoment

Solange der Schlüssel bekannt und gültig ist, erscheint alles von "Unbekannt" über "Explizit kein Vertrauen" bis hin zu "Volles Vertrauen" in Blau. Lediglich "absolutes Vertrauen" erscheint in Grün.

Enigmail sollte eigentlich blau ausschließlich bei unvertrauten Schlüsseln verwenden.

Beachte aber, dass "(signatory) trust" (Vertrauen in die Identität des Schlüsselinhabers) und "owner trust" (Vertrauen in Beglaubigungen des Schlüsselinhabers) zwei unterschiedliche Dinge sind. Für die Balkenfarbe ist nur signatory trust entscheidend (die Frage ist: "ist diese E-Mail tatsächlich von der Person?"), nicht aber owner trust. Für die Beurteilung einer Beglaubigung eines anderen Keys ist dagegen nur owner trust relevant ("ist diese Beglaubigung vertrauenswürdig?"). Direkt einstellen kannst du nur owner trust:

• absolut (ultimate): "Ich vertraue den Beglaubigungen, selbst wenn die Identität nicht gesichert ist"
• voll (full): "Ich vertraue den Beglaubigungen in Kombination mit signatory trust"
• gering (marginal): "Ich vertraue den Beglaubigungen in Kombination mit signatory trust und weiteren Beglaubigungen anderer Aussteller"
• kein (none) / Standard: "Ich ignoriere Beglaubigungen von diesem Aussteller, selbst wenn für diesen signatory trust besteht"

Wenn du einer User-ID vertrauen willst, solltest du diese daher beglaubigen (mit deiner eigenen, absolut vertrauenswürdigen Identität). Anschließend wird der Balken grün, denn die User-ID erhält durch deine Beglaubigung signatory trust. Owner trust sollte zusätzlich dann gesetzt werden, wenn du Beglaubigungen dieser Person vertrauen willst, und auch dann i.d.R. nicht auf absolut, sondern höchstens auf voll. Absolutes Vertrauen sollte eigenen Keys vorbehalten sein.

[/OT]

Zitat von Drehmoment

Mich würde deine dazu Meinung interessieren. Hältst du das für ein Problem?

Ich fände es besser, wenn die Leiste in diesem Fall nicht grün werden würde. Aber wie du richtig sagst ist es kein größeres Problem, da die Signatur-UID korrekt angezeigt wird. Auf der anderen Seite: rot ist definitiv zu viel. Entweder blau (wie für korrekte unvertraute Unterschriften), oder noch besser ein Zwischenstatus (gelb? grün mit deutlicher Warnung?). Es gibt schließlich legitime Anwendungen, der Nutzer muss nur bemerken, dass er sich nicht auf das "Von"-Feld verlassen sollte.

Beispiel für eine legitime Anwendung: eine Mailingliste leitet PGP-signierte E-Mails mit veränderten Headern weiter. Das "Von"-Feld enthält die Adresse der Mailingliste, der Body samt Signatur kommt jedoch vom eigentlichen Sender.

Zitat von Hanisch

Wieso willst Du einem Schlüssel, dessen ursprünglich zugeordnete e-Mail Adresse nicht mehr existiert, das Vertrauen entziehen?

Ich vermute, er will nicht dem Schlüssel, sondern der User-ID das vertrauen entziehen. Auf deine "neue" User-ID auf demselben Schlüssel hat dieser Schritt keine Auswirkung. Eventuell würde er dir sogar eine neue Beglaubigung für die neue User-ID ausstellen.

Zur Begründung: weil das die Nutzer, die meinen Beglaubigungen vertrauen, so von mir erwarten.

Zumindest meine Keysigning-Richtlinie (die ja öffentlich an meinen Beglaubigungen hängt) beinhaltet die der E-Mail-Adresse und einer Option, ungültig gewordenen User-IDs das Vertrauen zu entziehen. Eine User-ID mit falscher E-Mail-Adresse ist also entsprechend meiner Policy ungültig. Wenn ich über eine ungültige, nicht-zurückgerufene User-ID Kenntnis erlangen würde, würde ich deren Beglaubigung zurücknehmen. Im Gegensatz zum Anwendungsfall von @Drehmoment würde ich jedoch sagen, dass das vor allem für Keyserver-Nutzer relevant ist: ansonsten wird das Update schließlich nicht in absehbarer Zeit verteilt.

Es mag andere Menschen mit anderen Keysigning-Policies geben (z.B. "Ich prüfe nur Namen, nicht aber E-Mail-Adressen oder Kommentare") und viele Nutzer verwenden überhaupt keine explizite Richtlinie (letztendlich also "Ich signiere, was mir subjektiv richtig erscheint"). Diese Menschen haben eventuell andere Anforderungen an eine gültige User-ID.

Und das ist ja gerade das schöne an PGP: jeder Nutzer kann (bzw. muss) selbst auswählen, welchen anderen Nutzern (incl. deren impliziten oder expliziten Keysigning-Richtlinien) die Möglichkeit zugestanden wird, vertrauenswürdige Signaturen auszustellen.

Zitat von Hanisch

Mit meiner Signatur gebe ich an, wo dieser Schlüssel unter welcher Bezeichnung nun zu holen ist und wie er zu benutzen ist mit meinen neuen e-Mail Adressen.

Wofür benutzt du dann Keyserver? Du könntest den Key doch auch einfach in den Anhang oder auf einen X-beliebigen Webspace packen, wenn er ohne deine persönliche Anleitung nicht genutzt werden soll? Ich habe das einige Jahre so gemacht, das hat super funktioniert (aus Angst von Keyserver-Spam).

Wenn ich mich recht entsinne, soll die Outlook-Import-Funktion in den aktuellen Beta-Versionen von Thunderbird wieder funktionieren. Eventuell funktioniert sie da ja zumindest ausreichend gut, um zumindest den von Thunderbird unterstützten Teil der Kontakte zu übernehmen?

Zitat von Drehmoment

Tools, die den Export gleich in eine Datei durchführen können. Vielleicht geht das sogar mit dem gleichnamigen Sync-Tool von generalsync.

Wenn die Outlook-Integration fertig ist, können mit GeneralSync gemeinsame Adressbücher für Thunderbird und Outlook angelegt werden, die auch mit anderen Geräten synchronisiert werden können (z.B. Android-Smartphones oder -Tablets). Im Gegensatz zu einem regulären Import gehen so von der Zielanwendung nicht unterstützte Daten nicht verloren, sondern stehen weiterhin für die Verwendung in anderen Anwendungen bereit. Zusätzliche Exportfunktionen in Dateien sind jedoch derzeit nicht geplant, dafür können sowohl Exportmöglichkeiten von Outlook als auch die von Thunderbird genutzt werden.

Die Adressbuchfunktion der Outlook-Integration ist bereits weitgehend fertig, an den Kalendern bin ich aber noch dran. Es gibt derzeit noch keine öffentliche Testversion, da bislang weder ein Installationsassistent noch eine Update-Funktion bereitsteht. Ich hoffe, dass ich bis Mitte des Jahres soweit bin.

Zitat von Hanisch

was bei neu generierten Schlüsselpaaren nicht wäre

Ein neues Schlüsselpaar stand doch gar nicht zur Debatte? User-Ids können unabhängig vom Primärschlüssel angelegt und zurückgezogen werden, ohne den Fingerabdruck zu ändern. Beglaubigungen der alten User-Id "verliert" man natürlich, diese gelten jedoch ohnehin nicht für die neue User-Id und bleiben auch nach dem Widerruf sichtbar.

Enigmail und andere Clients prüfen (derzeit) tatsächlich nicht, ob die Absender- und Signaturadresse übereinstimmen. Wenn du ohnehin allen deinen Gesprächspartnern "von Hand" deine neue Adresse bekannt gibst, kann es also aus deiner Sicht eventuell von Vorteil sein, weiterhin die alte User-Id zu behalten und mit ihr zu signieren.

Grüße!