Bester Verschlüsselungs- und Signaturalgorithmus für GnuPG: RSA / RSA oder DSA / Elgamal? [geschlossen]


46

Ich habe diese relativ alte Frage gefunden, ob RSA oder DSA der bevorzugte Algorithmus zum Signieren und Verschlüsseln mit GnuPG ist.

Bei Verwendung gpg --gen-keysind die beiden relevanten Optionen entweder "RSA und RSA" oder "DSA und Elgamal". Welches ist besser? Was sind die Vor- und Nachteile für jeden? Hat sich seit 2009 etwas geändert?


fanden diese Beiträge auch hilfreich: linuxquestions.org/565242#2986414 und lists.gnupg.org/022764
RubyTuesdayDONO

Antworten:


73

Vertrauenswürdige Empfehlungen

Als zum Zeitpunkt des letzten Beitrags noch Debatten über die Änderung von Standardalgorithmen im Webarchiv stattfanden, die weitgehend übereinstimmten, wurde die Umstellung auf RSA 2k-Schlüssel als Standard durchgeführt.

Debian empfiehlt die Verwendung eines 4k-RSA-Schlüssels in seinem Dokument über die Verwendung von Unterschlüsseln und der Readme-Datei zu Debian -Schlüsseln . Die überwiegende Mehrheit von ungefähr drei Vierteln der Schlüssel im Schlüsselbund der Debian-Entwickler ist (noch) DSA / Elgamal (gezählt durch Durchsuchen der gpg-Ausgabe).

In einem Interview mit iX (eine deutsche Zeitschrift für Computerwissenschaften, Ausgabe 11/2013, ebenfalls kostenlos online verfügbar ) empfiehlt der Erfinder von PGP Phil Zimmermann "mindestens 3 KB Länge bei Verwendung von RSA", obwohl 1 KB Schlüssel noch nicht defekt sind. Aber sie sind "in Reichweite von Angreifern, die reich an Ressourcen sind".

In Bezug auf Sicherheit

Momentan gilt, dass beide als sicher für angemessene Schlüsselgrößen gelten (4 KB für RSA empfohlen, 2 KB für DSA2 erforderlich, ansonsten verwenden Sie DSA1, das SHA-1 verwendet ).

Schauen Sie sich zur Auswahl einer RSA-Schlüssellänge eine Übersicht über die tatsächliche Stärke von NIST an (S. 64). Es ist leicht zu erkennen, dass die Stärke nicht linear mit der Schlüssellänge (und der Rechenzeit) wächst, sodass doppelte Größe nicht "doppelte Sicherheit" bedeutet.

Es gab ein Problem mit der DSA-Implementierung von OpenSSL unter Debian , aber dies wurde durch die Verwendung falscher Zufallsdaten verursacht und hätte auch mit RSA passieren können.

Wahl zwischen RSA und DSA2

pro RSA

  • RSA ist weiter verbreitet, obwohl es im OpenPGP-Standard nicht erforderlich ist. Alle wichtigen Implementierungen können damit umgehen. DSA2 (noch) nicht
  • RSA bietet eine viel schnellere Signaturprüfung

pro DSA2

  • Kleinere Signaturen, aber trotzdem klein; für E-Mail und Codesignatur wohl zu vernachlässigen
  • Schnellere Schlüsselerstellung (kann für stromsparende und eingebettete Geräte wie Handys und Router relevant sein)
  • Etwas schneller zum Signieren

Meine eigene Entscheidung

Als ich kürzlich einen neuen OpenPGP-Schlüssel erstellte, entschied ich mich für 8k RSA für Primärschlüssel und 4k RSA als Unterschlüssel für den täglichen Gebrauch. RSA-Signaturen sind sowieso schnell zu überprüfen, und die riesigen 8-KB-Signaturen werden nur zum Signieren anderer Schlüssel verwendet, aber 8 KB sollten für eine wirklich lange Zeit als ausreichend angesehen werden. 4k ist in Ordnung für einen aktuellen Unterschlüssel, da es billig ist, ihn zu widerrufen, ohne alle Ihre Signaturen zu verlieren.

Das Erstellen dieses 8k-Schlüssels dauerte auf meinem Core 2 Duo T9300 ungefähr 20 Minuten. Nehmen Sie sich also Zeit und erledigen Sie einige Arbeiten (zum Zuführen der Zufallsquelle).


0

Während ich mich für einen 4K-RSA-Hauptschlüssel mit einem 3K-RSA-Signaturunterschlüssel und einem 4K-El-Gamal-Verschlüsselungsunterschlüssel entschieden habe. Der einzige Grund, warum ich zu diesem Zeitpunkt keinen höheren Hauptschlüssel gewählt habe, ist die Tatsache, dass Benutzer mit mobilen Geräten häufig mit den größeren Schlüsseln zu kämpfen haben.

Natürlich habe ich größere Schlüssel für bestimmte Zwecke, aber das ist normalerweise nicht für die Kommunikation mit anderen gedacht.


1
Warum El-Gamal für die Verschlüsselung?
Code_monk
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.