ECC, Quanten & Datenreichtum (OT aus "Empfohlener Algorithmus für Schlüssel - Verwendung elliptischer Kurven")

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


    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... ;)

    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.

  • 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.

    Ist das nicht ein bisschen ein Henne-Ei-Problem? Die einen kommen mit weiteren Standards nicht in die Pötte, die anderen verweigern sich quasi der Benutzung der vorhandenen Kurven.


    Die Betriebssysteme, egal ob Windows, macOS oder Android, die Browser, Apache, Java, der Thunderbird, ..., alle unterstützen ECC schon lange. Wenn auch meist nur die NIST-Kurven, vor allem P-384.

    Die CAs bieten entsprechende Zertifikate an, auch Let's encrypt ist dabei. Es benutzt sie nur kaum jemand. Ich habe in den letzten Tagen mal bei den Webseiten, die ich besucht habe, darauf geachtet. Keine einzige benutzt ein ECDSA-Zert.


    Ich habe eine Präsentation von Symantec aus 2015 gefunden. Dort findet sich eine gute Zusammenfassung der Situation. Demnach haben in 2015 nur etwa 2% der Webseiten ECDSA benutzt.

    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.


    https://csrc.nist.gov/csrc/med…session2-andrews-rick.pdf


    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.

    Ja, die Idee gefällt mir gut. Ich genieße des Komfort eines Familienservers. (Übrigens über ein OpenVPN, das nicht auf ECDSA setzt, obwohl das unterstützt wird. Muss ich mal bei meinen Eltern anmerken ;-)).

    Wenn ich den Service nicht hätte, käme deine Lösung durchaus infrage. Wobei ich meinen Kalender dann nicht mehr so einfach mit der Familie teilen könnte. Bin ja nicht so oft zuhause. Deshalb wäre ein deutscher Provider wohl meine Wahl.

    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.

    Absolut. Vielleicht lässt sich das Problem durch stetes Bewustmachen etwas abmildern. Ich glaube, viele Leute wissen gar nicht, was sie alles über sich preisgeben und dass diese Informationen natürlich auch verwendet werden.

    Ceterum censeo polypos rerum privatarum esse delendos!

    Frei nach Cato dem Älteren

    (Werter Herr T. , ich hoffe, ich habe da keinen Bock eingebaut.)

  • 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.

  • Bezüglich des Henne-Ei-Problems:

    Ich habe gestern Abend bei einem Bier noch mit einem Freund ein wenig über die Thematik geplaudert.

    Zum Henne-Ei-Problem, muss ich mein Meinungsbild etwas anpassen. Den Bequemlichkeitsfaktor als Hindernis hatte ich überbewertet.


    Neben der Frage des Vertrauens in die Kurven des NIST sind die technischen Probleme bei der Implementierung größer als ich dachte.

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

    OpenKeyChain unterstützt diese Kurve leider noch nicht. Damit hat man. soweit mir bekannt, derzeit keine Möglichkeit, die Kurve für Mail auf dem Smartphone zu benutzen.

    Das scheint aber wirklich nicht am guten Willen der Entwickler zu liegen. Wir haben gestern ein paar Postings, u.a. von Daniel Schürmann Vincent Breitmoser, gefunden. Die arbeiten wohl schon länger daran und kämpfen mit mangelnder Dokumentation usw. , auch in GnuPG.

    https://github.com/open-keychain/open-keychain/pull/2053

    Ceterum censeo polypos rerum privatarum esse delendos!

    Frei nach Cato dem Älteren

    (Werter Herr T. , ich hoffe, ich habe da keinen Bock eingebaut.)

  • 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).

  • Aber: eine Implementation ohne Spezifikation ist selten eine gute Idee, wenn es um Datenformate geht.

    Weißt du, wie das genau abläuft? Die Kurve ist laut Wikipedia "von der IETF als RFC 7748 standardisiert." Damit sollte doch eigentlich alles klar sein, oder nicht? Was fehlt denn da noch?

    Ich habe die Kritik in dem OpenKeyChain Posting eher als Kritik daran verstanden, dass nicht klar ist, wie genau das im GnuPg implementiert wurde.

    Ceterum censeo polypos rerum privatarum esse delendos!

    Frei nach Cato dem Älteren

    (Werter Herr T. , ich hoffe, ich habe da keinen Bock eingebaut.)

  • 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.

  • 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).

    So habe ich es auch verstanden. Die Proleme, die in OpenKeyChain auftreten, hängen nicht mit der Kurve und deren Standardiserung zusammen, sondern mit der Dokumentation seitens GnuPg.

    Ceterum censeo polypos rerum privatarum esse delendos!

    Frei nach Cato dem Älteren

    (Werter Herr T. , ich hoffe, ich habe da keinen Bock eingebaut.)