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.

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

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.

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

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.