Zukunftstauglichkeit von Schlüssel-Algorithmen bei gpg

    • Betriebssystem + Version: Linux / Win
    • PGP-Software / PGP-Version: 2.1

    Hallo,


    ich möchte mir einen neuen gpg Schlüssel erstellen und diesen neben TB auf Win/ Ubuntu auch unter K9+Openkeychain nutzen.


    In den letzten Jahren gab es einige Fortschritte mit neuem Algorithmen, insbe. die Verwendung elliptische Kurven.


    Hat jemand von Euch Erfahrungen mit dem produktiven Einsatz vom ECDSA Algorithmus? Ich bin mir unsicher, ob der (vermeintliche) Gewinn an Sicherheit damit erkauft wird, dass die neuen Schlüssel ggf noch Kinderkrankheiten/unentdeckte Schwachstellen bzw. mangelnde Kompatibilität aufweisen.



    Markus

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

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

  • Hallo Markusm12,

    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.

    so sehe ich das auch. Neben dem wovor / vor wem kannst Du Dir noch die Frage stellen wie lange sollen die Daten geschützt werden. Schließlich werden mit steigender Rechenleistung die Möglichkeiten des Brute Force besser. Heute dauert es theoretische 1 Million Jahre Deine Daten zu entschlüsseln, schon "übermorgen" braucht der beste Rechner "nur" zwei Wochen. Jede Verschlüsselung ist also irgendwann in der Zukunft einmal knackbar. Die Frage ist, wer sich den Aufwand für Deine Daten macht.


    Für den privaten Gebrauch sehe ich hier keinen entscheidende Sicherheitsgewinn (natürlich, wenn ich unwichtige Daten leicht und wichtige Daten stark verschlüssel, habe ich schon eine Information gegeben).


    Gruß

    slengfe

    Meine Beiträge sind subjektiv und manipulativ, erheben Anspruch auf Allwissenheit und können Spuren von Ironie oder Sarkasmus enthalten.


    Windows 10 Professional 64 Bit | Thunderbird 64 Bit | Firefox 64 Bit | Avira Free Security Suite | Fritzbox 7490

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

    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.

    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.


    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.

  • 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 noch (relativ) jung,

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

    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.

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

    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?

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


    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.

  • Hallo,


    ich hätte gar nicht erwartet, bei dem Thema auf soviel Resonanz zu stoßen.


    Die Frage des Bedrohungsszenario ist sicherlich gerechtfertigt, als normaler Privatanwender ist man vmtl nicht durch gezieltes Ausforschen betroffen. Andererseits entwickelt sich auch die Möglichkeiten zum Entschlüsseln stetig weiter, sodass es (mittelfristig ?!?) durchaus als möglich erscheint, verschlüsselte Daten massentauglich zu entschlüsseln.


    Ich möchte den Schlüssel auch für mein posteo Konto nutzen, da es Eingangsverschlüsselung, Schlüsselaustausch und autocrypt ermöglicht. Leider ersehe ich nicht, ob der Schlüssel dazu einem bestimmten Typ entsprechen muss.


    Grundsätzlich denke ich auch, dass man einem etablierten Code mehr Vertrauen schenken sollte als einen völlig neuen System (ok, neu ist hier relativ). Die Frage ist hier vermutlich, ab welchen Zeitpunkt man ECC gleiche Zuverlässigkeit/ Vertrauen bescheinigt, mit der man aktuell RSA begegnet.

    Bliebe zu hoffen, dass die Etablierung von ECC schneller geschieht, als die potentielle "Knackbarkeit" von RSA voranschreitet.


    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?


    Markus

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

    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.

  • 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/…en-3221002.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.

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


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

    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.

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


    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.


    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.

  • Ich habe nichts dagegen, wenn das Thema etwas verbreitert wird.


    Eine konkrete Frage an Euch noch:

    Wie sieht der Ablauf zum Erstellen von 8k RSA Schlüsseln aus? Kann ich das nur im Terminal oder gibt es eine Win/Linux GUI, die das unterstützt?



    Markus

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

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

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

  • (aber so schwer ist das CLI auch wieder nicht: gpg --full-gen-key, dann Enter)

    Also gpg 2.1 bei Win und Ubuntu machen bei mir die gleiche Aussage, dass bei 4096 Schluss ist.

    Zu OpenKeyChain habe ich gelesen, dass die damit erstellten Schlüssel automatisch eine Länge von 3k haben.

    Ja, in den Standardeinstellungen sind RSA 3072 voreingestellt. Neben 4096 bit werden auch ECC P256, 521 und EdDSA angeboten




    In der Summe gibt es also keine "einfache" Option größere Schlüssel zu erzeugen.

    (oder ich habe Eure Aussagen falsch verstanden)


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

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

  • Gibt es denn Server die ECDSA anbieten?


    Beispielsweise liefert De-Mail von der Telekom maximal die Cipher Suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp384r1 (TLS1.2).


    Also elliptische Kurven nur für den geheimen Schlüsselaustausch.


    mfg Volker


    Edit: Ich habe deinen folgenden inhaltlich identischen Beitrag gelöscht. graba, Gl.-Mod.

    PGP Schlüssel auf öffentlichen Schlüsselservern
    PGP Key ID (RSA 1024): 0xBE556595
    MD5 Fingerprint: BE46 138F DF90 B019 CBF0 EE36 2F30 9775

    Einmal editiert, zuletzt von graba ()