Zukunftstauglichkeit von Schlüssel-Algorithmen bei gpg

Dann will ich mich mal vordrängel, weil ich gerade online bin und weil bis zum Fußball noch ein paar Minuten Zeit sind. Bin mal gespannt, was die anderen dazu sagen. Es gibt hier ja durchaus ein paar Leute, die sich damit auskennen.

Wir benutzen ECDSA schon eine Weile sporadisch. Allerdings nur in einem kleinen Kreis, weil kaum jemand bei der Verschlüsselung mit macht. Das wird bei dir vermutlich nicht anders sein.

Ein paar Punkte, die es zu bedenken gilt. ECDSA wird seitens GnuPg erst ab Version 2.1 unterstützt. Enigmail verlangt inwischen GnuPG 2. Das sollte kein Problem sein. Aber wenn einer deiner Partner noch auf einer alten Version mit 1.x sitzt, klappt es mit dem nicht. Das wäre vielleicht ein Grund, ihn mal zum Upgrade zu bewegen.

Openkeychain unterstützt die Curve 25519 soweit ich weiß ich nicht, oder nicht immer. Brainpool geht. Was verwenden deine Partner? Das müsstest du in jedem Fall zunächst in Erfahrung bringen. Gleiches gilt für die Freemailer wie GMX und Web,de, die ja ebenfalls eine Verschlüsselung anbieten. ECDSA ist aber schon eine Weile verfügbar. Die Chance ist bestimmt nicht schlecht.

Du weißt, dass ECDSA für die Signatur und den asymetrischen Teil, also den Schlüsselaustausch zuständig ist? Der eigentliche Inhalt ist symetrisch verschlüsselt. Damit hat ECDSA nichts zu tun. Der Austausch der Schlüssel ist aber natürlich gerade das Kritische.

Die Schlüssel selbst sind kürzer. Das ist ein weiterer Vorteil, spielt aber in der Mail-Praxis kaum eine Rolle.

Bleibt die Frage, vor wem du dich schützen willst. Die bekannten Polypen und private Hacker werden auch deinen RSA-Schlüssel nicht knacken. Die Jungs von der NSA auch nicht. Die würden sich deshalb den Key auf anderem Weg beschaffen. Dann ist es egal, ob du RSA oder ECDSA verwendest.

Zitat von generalsync

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.

Soweit ich weiß sind die der NIST spezifiziert und standardisiert. Manche haben Bedenken, dass es darin eine Hintertür der NSA geben könnte. Mir wäre das ziemlich egal.

Für die erwähnte Curve 25519 besteht dieser Verdacht bisher nicht. Sie ist spezifiziert aber leider noch nicht standardisiert.

Wie du schreibst, es könnte also immer noch passieren, dass sie gar nicht der Nachfolger wird.

Diese Kurve ist aber sowieso nicht kompatibel zu ECDSA sondern benötigt das Verfahren Ed25519.

Zitat von generalsync

Der "Sicherheitsgewinn" von ECC ist darüber hinaus umstritten

Beziehst du dich auf Geschichte der NIST-Kurven? Oder kennst du andere Gründe, aus denen die Sicherheit von ECC umstritten sein könnte?

Nach meinem Verständnis hat ECC an sich keinen Sicherheitsgewinn gegenüber RSA. Soweit ich weiß sind beide Verfahren derzeit absolut sicher. Das Sicherheitsniveau hängt an der Schlüssellänge. Die ist bei ECC für gleiches Niveau kürzer. Oder umgekehrt, bei gleicher Schlüssellänge wäre das Niveau bei ECC höher. Man kann aber bei RSA durch die Wahl der Länge dasselbe Niveau erreichen. Für normale Anwendersollte das in Bezug auf das Signieren von Mails tatsächlich völlig egal sein. Im IOT könnte der Unterschied eine Rolle spielen.

Zitat von Drehmoment

ECDSA ist aber schon eine Weile verfügbar. Die Chance ist bestimmt nicht schlecht.

Da war ich wohl zu optimistisch. Ich habe per Suche zumindest für GMX und Web,de nichts finden können, wonach sie ECDSA unterstützen würden.

Alles in allem, ich würde es lassen und vorläufig noch auf ECDSA-Schlüssel verzichten.

Zitat von slengfe

Die Frage ist, wer sich den Aufwand für Deine Daten macht.

Ja, genau das ist die Frage. Von der NSA glaubt man zu wissen, dass sie verschlüsselte Daten speichern, um sie vielleicht in der Zukunft irgendwann einmal entschlüsseln zu können. Ich kann mir nicht vorstellen, dass sie das mit Mail von Hänschen Drehmoment machen. Und selbst wenn ... .

Bei den Polypen ist das anders. Die hätten gern (und bekommen leider auch) jetzt schon möglichst alles, was sie über uns sammeln können. Sie haben nur wenig davon, in 20 Jahren zu erfahren, was meine Freundin und ich uns heute schreiben. Sie wollen schließlich jetzt verdienen. Und heute können sie die Mails nicht lesen. Dass wir in Beziehung zu einander stehen, wissen sie natürlich längst anhand all der anderen Daten. Da ist Mail-Verschlüsselung nur ein Tropfen auf dem heißen Stein. Und trotzdem freue ich mich über jedes Bit, das sie nicht bekommen.

Zitat von generalsync

ECC ist noch (relativ) jung,

Ja, wirklich relativ. Die ersten Spezifikationen von Brainpool gibt es seit mehr als 10 Jahren.

Zitat von generalsync

Man kann aber sicherlich darüber streiten, ob und in welchen Zeitrahmen Quantencomputer überhaupt realistisch sind... das ist aber eine andere Diskussion.

Ja, zumal man in einer ähnlich hypothetischen Diskussion dann auch darauf verweisen könnte, dass wir irgendwann mal auf Quantenbasis (durch Verschränkung) absolut abhörsicher kommunizieren können. Im Gegensatz zu Quantencomputern kann man das bereits heute, wenn auch nicht für praktische Zwecke.

Zitat von generalsync

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

Die Spezifizierung längerer Schlüssel gibt es bereits seit 2010, brainpoolP512r1 und brainpoolP512t1 mit jeweils 512 Bit. Siehe RFC 5639. Die 512 Bit entsprechen dem Sicherheitsniveau 256, also einem RSA-Schlüssel mit 15360 Bit. NIST hat eine 521-Bit-Kurve standardisiert.

Wenn man wollen würde, könnte da längst etwas gehen. Man müsste vielleicht auch nicht auf die Standardisierung warten sondern könnte vorangehen und den Standard quasi schaffen. Bei der Curve 25519 waren die Entwickler von GnuPG das Warten offenbar auch leid und haben sie implementiert.

Zitat von generalsync

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.

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

Zitat von generalsync

Für alltägliche Dinge halte ich 4096 Bit derzeit noch für sinnvoll.

Wer möchte, kann sich hier eine Schätzung abholen: https://www.keylength.com/en/compare/

Nach derzeitigen Stand halten alle dort erwähnten Organisationen RSA 4096 auch für das nächste Jahrzehnt für sicher.

Dabei sollte man beachten, dass seriöse Schätzungen nicht weiter als vielleicht 10 oder 20 Jahre in die Zukunft reichen, weil die technologische Entwicklung immer wieder mal für die eine oder andere Überraschung sorgen kann. Siehe Bills 640 kB.

Auch empfehlenswert ist ein Artikel aus der iX: https://www.heise.de/security/artik….html?seite=all

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. Ein schöner Satz aus dem Artikel:

Zitat

Das Knacken von Diffie Hellman mit 1024 Bit ist grob geschätzt mit Hardware für etwa 100 Millionen US-Dollar möglich. Das klingt viel – ist mit dem Budget der NSA aber durchaus bereits realistisch. Und die Hardware wird immer schneller.

Wohlgemerkt, dabei geht es um das Brechen eines Schlüssels in überschaubarer Zeit (die leider nicht genannt ist). Der hat auch nur 1024/80 Bit.

Auch wenn die Hardware immer schneller wird, für die E-Mails normaler Nutzer besteht da sicher vorerst keine Gefahr. Es werden auch nur wenige gleich Industrie- oder Staatsgeheimnisse zum Inhalt haben und besonders guten Schutz benötigen.

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.

Zitat von generalsync

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

Das stimmt. ECC zu benutzen, hat immer noch die erwähnten Hindernisse.

Ich finde die Diskussion trotzdem interessant und würde sie gern fortführen, sofern du oder andere (überraschend wenig Resonanz bis jetzt) auch Interesse haben. Vielleicht kann man den Part ja auch abtrennen.

Zitat von generalsync

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),

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. Wenn ich mir anschaue, welchen Aufwand selbst führenden Quantenphysiker, wie Rainer Blatt erbingen müssen, um durch Verschränkung wenige QBits zu erzeugen.

Das, was Google und die NASA von D-Wave haben, ist gut für Schlagzeilen, aber nach allem, was dazu öffentlich bekannt ist, ist das kein wirklicher Quantencomputer und kann den Shor deshalb schon rein prinzipiell gar nicht ausführen.

Zitat von generalsync

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: i

Die großen privaten Datensammler verfügen über noch mehr Daten als Dienste und unterliegen nahezu überhaupt keiner Kontrolle. Sie legen nicht einmal die Algorithmen offen, nach denen sie uns täglich bewerten.
Du kennst sicher das totale Überwachungsprogramm, das in China ab 2020 anlaufen wird. Die bedienen sich auch der dortigen privaten Sammler, weil die die nötigen Daten bereits haben und weiterhin bekommen. Da muss der Staat selbst gar nicht sammeln sondern nur bezahlen.

Da ist mein Vertrauen in unseren Staat doch groß genug. Den sehe ich überhaupt nicht als eine Gefahr an. Und sollte ich mich da irren, dann wären meine E-Mails eine geringe Sorge. Dann hätten wir ganz andere Probleme.

Ich weiß nicht, wie man sich technisch gegen die Kraken schützen kann. Soweit es E-Mail und das Thema hier betrifft hast du Recht. Ende-zu-Ende-Verschlüsselung sperrt die Neugieren vom Inhalt aus. Das ist immerhin etwas. Deshalb bin ich auch ein Freund von Verschlüsselung.

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. Unsere Fingerabdrücke und Fotos von uns haben sie auch.

Sie können im stillen Kämmerlein längst schon das mit uns machen, was in China bald Programm ist: Sie verfolgen uns mehr oder weniger lückenlos und belohnen bzw. sanktionieren unser Verhalten. Bei uns geht es dann zum Beispiel über Versicherungstarife, den Auschluss bei einer Kreditanfrage.

Damit läufst du wohl in eine ähnliche Falle. Soweit ich weiß, werden 8k-Keys erst ab GnuPG 2.1.x unterstützt. Ob Openkeychain damit umgehen kann, weiß ich nicht. Du würdest auf jeden Fall einige Mailpartner ausschließen.

Zitat von generalsync

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.

Ja, du hast Recht. Das Problem betraf wohl nur das Erstellen. Zu OpenKeyChain habe ich gelesen, dass die damit erstellten Schlüssel automatisch eine Länge von 3k haben. Was ja gegenwärtig auch noch absolut genügt. Ob man längere Schlüssel importieren kann, weiß ich nicht.

Ich würde das auf jeden Fall zunächst überprüfen, bevor ich einen 8k-Schlüssel wählen würde.

Zitat von Markusm12

Kann man darauf Ableiten, dass die Entwickler hierfür gar keine Notwendigkeit sehen bzw. für die Zukunft stark Richtung ECC tendieren?

Das weiß ich nicht. Ich vermute schon, dass ECC die absehbare Zukunft ist.

Was du aber ableiten kannst, das ist, dass die RSA-4k-Schlüssel derzeit noch locker für die nächsten 10 bis 20 Jahre als sicher gelten.

Ich mache mir da jedenfalls keinen Kopf und kann deshalb gut auf 8k verzichten. ECC hätte den Reiz der Moderne, die damit verbundenen Nachteile sind es mir aber derzeit nicht wert.