Frage:
RSA vs. DSA für SSH-Authentifizierungsschlüssel
jrdioko
2011-07-09 04:22:01 UTC
view on stackexchange narkive permalink

Wenn Sie SSH-Authentifizierungsschlüssel auf einem Unix / Linux-System mit ssh-keygen generieren, haben Sie die Wahl, ein RSA- oder DSA-Schlüsselpaar zu erstellen (mit dem Typ -t ).

Was ist der Unterschied zwischen RSA- und DSA-Schlüsseln? Was würde jemanden dazu bringen, einen über den anderen zu wählen?

@Bhanu Der Standardwert von "ssh-keygen" aus OpenSSH 6.3p1 ist 2048 Bit. Lesen Sie die Antworten unten, und Sie werden auch feststellen, dass 2048 Bit ausreichend sind.
Ich verstehe wirklich nicht, warum der Vorschlag lautet, "den schnellsten Schlüssel zu wählen". Ich würde denken, man würde den langsamsten Schlüssel wählen wollen, dessen Knacken am längsten dauern würde; vorausgesetzt, die Authentifizierung wird wirklich nur einmal durchgeführt und man kann warten, bis die Authentifizierung für die "Echtzeit" -Zeit abgeschlossen ist, die für eine Funktion benötigt wird.
Der Grund, warum wir DSA haben, ist, dass RSA früher Patente hatte.Daher wurde DSA in Open Source-Tools implementiert.Jetzt sind alle Patente von RSA abgelaufen.Es ist also kein praktischer Vorteil, DSA gegenüber RSA zu verwenden.Tools behalten die Unterstützung für Abwärtskompatibilität bei und es gibt keinen Grund zum Entfernen, da es sich auch um eine gute Krypto handelt
Acht antworten:
emboss
2011-07-09 21:11:49 UTC
view on stackexchange narkive permalink

Entscheiden Sie sich für RSA.

DSA ist schneller für die Signaturgenerierung, aber langsamer für die Validierung, langsamer beim Verschlüsseln, aber schneller beim Entschlüsseln und die Sicherheit kann als gleichwertig mit einem RSA-Schlüssel gleicher Schlüssellänge angesehen werden. Das ist die Pointe, jetzt eine Rechtfertigung.

Die Sicherheit des RSA-Algorithmus basiert auf der Tatsache, dass die Faktorisierung großer Ganzzahlen als "schwierig" bekannt ist, während die DSA-Sicherheit basiert auf dem Problem diskreter Logarithmus. Heutzutage ist der schnellste bekannte Algorithmus zum Faktorisieren großer Ganzzahlen das General Number Field Sieve, auch der schnellste Algorithmus zum Lösen des diskreten Logarithmusproblems in endlichen Feldern, modulo eine große Primzahl p, wie für DSA angegeben.

Wenn nun die Sicherheit als gleich angesehen werden kann, würden wir natürlich den Algorithmus bevorzugen, der schneller ist. Aber auch hier gibt es keinen eindeutigen Gewinner.

Sie können sich diese Studie ansehen oder, wenn Sie OpenSSL auf Ihrem Computer installiert haben, openssl speed ausführen Code>. Sie werden sehen, dass DSA beim Generieren einer Signatur schneller arbeitet, beim Überprüfen einer Signatur mit derselben Schlüssellänge jedoch viel langsamer. Die Überprüfung ist im Allgemeinen das, was Sie schneller sein möchten, wenn Sie z. mit einem unterschriebenen Dokument. Die Signatur wird einmal generiert - es ist also in Ordnung, wenn dies etwas länger dauert -, aber die Dokumentensignatur wird möglicherweise viel häufiger von Endbenutzern überprüft.

Beide unterstützen eine Form der Verschlüsselungsmethode, RSA out of the Box und DSA mit einem El Gamal. DSA ist bei der Entschlüsselung im Allgemeinen schneller, bei der Verschlüsselung jedoch langsamer, bei RSA ist es umgekehrt. Auch hier möchten Sie, dass die Entschlüsselung hier schneller erfolgt, da ein verschlüsseltes Dokument möglicherweise mehrmals entschlüsselt wird.

In kommerzieller Hinsicht ist RSA eindeutig der Gewinner. Kommerzielle RSA-Zertifikate werden viel häufiger eingesetzt als DSA-Zertifikate. P. >

Aber ich habe das Killer-Argument für das Ende gespeichert: man ssh-keygen sagt, dass ein DSA-Schlüssel genau 1024 Bit lang sein muss, um mit NISTs FIPS 186-2 kompatibel zu sein a>. Obwohl theoretisch längere DSA-Schlüssel möglich sind (FIPS 186-3 erlaubt dies auch ausdrücklich), sind Sie dennoch auf 1024 Bit beschränkt. Wenn Sie die Überlegungen in diesem [Artikel] berücksichtigen, sind wir mit 1024 Bit für RSA oder DSA nicht mehr sicher.

Heute sind Sie mit einem RSA 2048- oder 4096-Bit besser dran Schlüssel.

Entschuldigung, Sie haben in mehreren Punkten etwas falsch gemacht. DSA ist in einem endlichen Feld der Größe _p_ definiert, wobei _p_ eine große Primzahl, _nicht_ eine Potenz von 2 ist. In Bezug auf den diskreten Logarithmus ist ein endliches Feld der Größe _2 ^ 1024_ schwächer als ein endliches Feld der Größe _p_ mit a spezifischer Algorithmus (von Coppersmith entwickelt), der schneller als Index Calculus ist. Das aktuelle FIPS 186 ist FIPS 186-3, und dieses erlaubt DSA-Schlüssel, die länger als 1024 Bit sind (und `ssh-keygen` kann 2048-Bit-DSA-Schlüssel herstellen). Bei SSH (Client-Seite) geht es nicht um Verschlüsselung, sondern nur um Signaturen.
Obwohl FIPS-3 größere Schlüssellängen zulässt, muss der aktuelle ssh-keygen (Fedora 15) * nicht * -> ssh-keygen -t dsa -b 2048 -> DSA-Schlüssel 1024 Bit groß sein. Obwohl SSH nur Signaturen beinhaltet, denke ich, dass es immer noch relevant ist, auf den Unterschied hinzuweisen. Sie haben Recht damit, dass DSA auf Zp definiert wird. Ich werde das ändern. Vielen Dank für Ihre Bemerkungen!
oh ja, `ssh-keygen` lehnt derzeit DSA-Schlüssel ab, die länger als 1024 Bit sind. Früher gab es jedoch eine Version (wie in OpenBSD integriert), die größere DSA-Schlüssel zuließ.
@Thomas, heißt "openssl gendsa". (Das Schlüsselformat ist das gleiche.)
* DSA [...] ist schneller beim Entschlüsseln * ist nicht ganz richtig: DSA kann nur signieren / validieren, es ist keine Verschlüsselung eingebaut.
@emboss:I versteht diese Antwort nicht. DSA ist KEIN Verschlüsselungsschema. Es ist ein Signaturvalidierungsschema
Der Link zu dem Artikel, der erklärt, warum 1024 Bit nicht ausreichen, scheint zu fehlen. Können Sie bitte eine angeben, da ich daran interessiert war, warum?
Gilt das Ende 2014 noch?
@emboss Wenn Sie die OpenSSL-Bibliothek direkt in Ihrem Programm aufrufen, können Sie tatsächlich DSA mit mehr als 1024 Bit erhalten.
@pablox so ziemlich ja, je paranoider 4096-Bit-RSA-Schlüssel verwendet werden. ed25519 (siehe Shnatsels Antwort) mag für einige eine Option sein, aber es wird wahrscheinlich noch einige Jahre dauern, bis man sicher davon ausgehen kann, dass jeder Host, auf den sie zugreifen möchten, dies unterstützt.
Es gibt auch das GnuPG darüber, warum RSA 4096 nicht die Standardeinstellung ist (https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096). Es geht im Grunde genommen um: "Weil es uns fast nichts gibt und uns ziemlich viel kostet."
Zum Generieren von DSA-Schlüsseln, die größer als 1024 sind, kann das PuTTYgen-Tool von PuTTY auch DSA-Schlüssel beliebiger Größe generieren. Ich habe gerade einen 20480-Bit-SSH-2-DSA-Schlüssel generiert. Eigentlich bin ich gerade dabei. Es scheint eine Weile zu dauern (wie in ungefähr 20 Minuten und immer noch).
@PaŭloEbermann Was meinst du damit, dass DSA nur unterschreiben / validieren kann?
@jayarjo Ja, DSA ist kein Verschlüsselungsalgorithmus, sondern nur ein Signaturalgorithmus.(Es gibt Verschlüsselungsalgorithmen auf der Basis verwandter Mathematik, z. B. ElGamal, aber sie sind nicht DSA.)
DSA kann jetzt zur Verschlüsselung verwendet werden: https://www.thesecuritybuddy.com/encryption/dsa-vs-rsa/
Shnatsel
2013-12-10 22:42:41 UTC
view on stackexchange narkive permalink

Im Moment ist die Frage etwas weiter gefasst: RSA vs. DSA vs. ECDSA vs. Ed25519 . Also:

Eine Präsentation auf der BlackHat 2013 legt nahe, dass erhebliche Fortschritte bei der Lösung der Komplexitätsprobleme erzielt wurden, deren Stärke DSA und einige andere sind Algorithmen sind gegründet, so dass sie sehr bald mathematisch gebrochen sein können. Darüber hinaus kann der Angriff möglicherweise (aber schwieriger) auch auf RSA ausgedehnt werden.

In der Präsentation wird vorgeschlagen, stattdessen die Kryptographie mit elliptischen Kurven zu verwenden. Die von OpenSSH unterstützten ECC-Algorithmen sind ECDSA und seit OpenSSH 6.5 Ed25519.

OpenSSH unterstützt nur NIST-Kurven für ECDSA und gemäß In dieser Studie sehen diese Kurven für NSA-Hintertüren wirklich verdächtig aus. Und wenn die NSA sie bereits knacken kann, ist es für andere nicht so schwer zu knacken, wie es eine richtige Kurve wäre. Ed25519 ist dasselbe, aber mit einer besseren Kurve, daher ist es die sicherste Wette, dass der zugrunde liegende Algorithmus mathematisch gebrochen ist.

Außerdem haben DSA und ECDSA eine unangenehme Eigenschaft: Sie erfordern einen Parameter, der normalerweise k genannt wird, um vollständig zufällig, geheim und eindeutig zu sein. In der Praxis bedeutet dies, dass, wenn Sie von einem Computer mit einem schlechten Zufallszahlengenerator und z. Wenn dasselbe k zweimal verwendet wird, kann ein Beobachter des Datenverkehrs Ihren privaten Schlüssel herausfinden. (Quelle: Wikipedia auf DSA und ECDSA, auch dies).

Das Fazit lautet:

  • Verwenden Sie niemals DSA oder ECDSA
  • Ed25519 ist wahrscheinlich mathematisch am stärksten (und auch am schnellsten), wird aber noch nicht allgemein unterstützt. Als Bonus ist der private Schlüssel standardmäßig stärker verschlüsselt (Kennwortschutz) als andere Schlüsseltypen.
  • RSA ist die beste Wahl, wenn Sie Ed25519 nicht verwenden können .
Ed25519 verwendet kein zufälliges * k * (es leitet es stattdessen vom privaten Schlüssel und der Nachricht ab), daher benötigen Sie nur ein PRNG, um den Schlüssel zu generieren, aber nicht zum Signieren. Mit DSA und ECDSA schlagen viele Implementierungen fehl, da das PRNG schlecht ist, aber es gibt Möglichkeiten, es zu implementieren, damit es schlechte PRNGs überlebt, beispielsweise durch Verwendung der deterministischen Variante von Pornin.
Die jüngsten Fortschritte beim diskreten Logarithmus waren ein kleines charakteristisches Feld. Es gibt keine offensichtliche Möglichkeit, es über Hauptkennfelder oder RSA an DSA zu übertragen. RSA und DSA über Primfeldern sind in Bezug auf die Sicherheit wahrscheinlich näher beieinander als DSA über Primfeldern gegenüber DSA über kleinen charakteristischen Feldern. Fortschritte beim Factoring oder DL können auftreten, müssen jedoch weit über die jüngsten Fortschritte hinausgehen. Daher ist es unnötig, DSA und / oder RSA wegen dieser Fortschritte aufzugeben. Es ist genauso gut möglich, dass jemand das ECC bricht.
Ja, es stört mich zu hören, wie jemand "DSA aufgeben" sagt. Ich bin weder Mathematiker noch die meisten Benutzer von Kryptografie mit öffentlichen Schlüsseln, aber ich würde etwas nur aufgeben, wenn es eine wirklich unmittelbare Bedrohung gibt, und würde sicherlich nichts relativ Neues annehmen, bis es ausgiebig vor Ort getestet wurde und als sicher erwiesen. Woher wissen wir, dass dieser Benutzer nicht die NSA ist, die sagt, dass die NSA DSA und ECDSA leichter brechen kann, so dass wir zu Algorithmen wechseln, die sie brechen können? Oh, diese lästigen Geheimdienste werden Sie umhauen!
Verwenden Sie [Ed25519] (https://en.wikipedia.org/wiki/EdDSA) oder [RSA] (https://en.wikipedia.org/wiki/RSA_%28cryptosystem%29) mit 4096-Bit-Schlüsseln. Siehe auch die gut verbreitete [Secure Secure Shell] (https://stribika.github.io/2015/01/04/secure-secure-shell.html) Beschreibung.
@bitsum Das [RNG-Problem] (http://meyering.net/nuke-your-DSA-keys/) ist real und "unmittelbar bevorstehend". OpenSSH kann nur 1024-Bit-DSA-Schlüssel generieren, die zu schwach sind. Es können zwar 2048- und 3072-Bit-Schlüssel [von OpenSSL generiert] verwendet werden (https://digitalelf.net/2014/02/using-2048-bit-dsa-keys-with-openssh/), aber das ist ein großer Aufwand. Ab OpenSSH 7.0 ist [DSA standardmäßig deaktiviert] (http://www.openssh.com/legacy.html). Siehe auch [meine Antwort zum Stapelüberlauf] (https://stackoverflow.com/questions/2821736/whats-the-difference-between-id-rsa-pub-and-id-dsa-pub/27855045#27855045). Willst du bewährt? Verwenden Sie 4096-Bit-RSA.
@AdamKatz Wenn ich mich ein Jahr später nähere, bin ich geneigt, Ihnen zuzustimmen. Die Möglichkeit, dass ein gebrochenes oder anderweitig unzureichendes RNG ein Hauptziel ist, ist für DSA ein klares Anliegen. Im Gegensatz zu meinem vorherigen Kommentar habe ich vor einigen Monaten die Verwendung von DSA selbst eingestellt.
Thomas Pornin
2011-07-10 03:12:57 UTC
view on stackexchange narkive permalink

In SSH spielt auf Client-Seite die Wahl zwischen RSA und DSA keine große Rolle, da beide eine ähnliche Sicherheit bei gleicher Schlüsselgröße bieten (verwenden Sie 2048 Bit und Sie werden zufrieden sein).

In der Vergangenheit unterstützte Version 1 des SSH-Protokolls nur RSA-Schlüssel. Als Version 2 definiert wurde, war RSA noch patentiert, sodass die Unterstützung von DSA hinzugefügt wurde, sodass eine patentfreie Open-Source-Implementierung erfolgen konnte. Das RSA-Patent ist vor mehr als 10 Jahren abgelaufen, sodass Sie sich jetzt keine Sorgen mehr machen müssen.

Theoretisch kann es in bestimmten Situationen zu Leistungsproblemen mit dem einen oder anderen kommen: Wenn der Server sehr klein ist Auf einem Computer (z. B. einem i486) werden Clients mit RSA-Schlüsseln bevorzugt, da das Überprüfen einer RSA-Signatur weniger rechenintensiv ist als das Überprüfen einer DSA-Signatur. Umgekehrt ist eine DSA-Signatur kürzer (normalerweise 64 Byte gegenüber 256 Byte). Wenn Sie also nur eine sehr geringe Bandbreite haben, würden Sie DSA bevorzugen. Wie auch immer, es wird Ihnen schwer fallen, diese Effekte zu erkennen, geschweige denn sie für wichtig zu halten.

Auf dem Server wird ein DSA-Schlüssel bevorzugt, da dann der Schlüsselaustausch a verwendet vorübergehender Diffie-Hellman-Schlüssel, der den Weg für "Perfect Forward Secrecy" ebnet (dh wenn ein Bösewicht den privaten Serverschlüssel stiehlt, kann er frühere Verbindungen, die er aufgezeichnet hätte, immer noch nicht entschlüsseln).

Können Sie das Risiko der Verwendung eines RSA-Schlüssels auf der Serverseite erläutern?
@jrdioko: Beim Verbinden wird ein Sitzungsschlüssel mithilfe eines Schlüsselaustauschmechanismus wie RSA (Verschlüsselung) oder Diffie-Hellman eingerichtet. Auf dem Server wird ein entsprechender privater Schlüssel verwendet. Wenn dieser Schlüssel vorübergehend ist (im laufenden Betrieb generiert, nur im RAM gespeichert, nach der Verwendung verworfen), ist er vor späterem Diebstahl geschützt. Wenn der Serverschlüssel (der permanente, in einer Datei gespeicherte) nur für Signaturen bestimmt ist (z. B. DSA-Schlüssel), sind Sie sicher, dass der Schlüsselaustauschschlüssel vorübergehend ist (der öffentliche Schlüssel wird dann vom Server signiert), und das ist gut.
Kann man DHE nicht auch mit RSA-Signatur verwenden?
@Paŭlo: Tatsächlich wird bei SSHv2 immer DHE verwendet, auch mit einem RSA-Schlüssel. Die Verwendung eines DSA-Schlüssels ist nur eine einfache Möglichkeit, um sicherzugehen, dass Sie PFS erhalten, da es nicht anderweitig verwendet werden kann.
OpenSSH speichert die RSA-Schlüssel der SSH-Versionen 1 und 2 in verschiedenen Dateien, und 1 ist standardmäßig nicht mehr aktiviert. Es wäre schwierig, Version 1 versehentlich zu verwenden - zumindest in OpenSSH.
lxgr
2013-08-30 03:35:24 UTC
view on stackexchange narkive permalink

Ein weiterer wichtiger Vorteil von RSA gegenüber DSA und ECDSA besteht darin, dass Sie niemals einen sicheren Zufallszahlengenerator zum Erstellen von Signaturen benötigen.

Um eine Signatur zu generieren, benötigt (EC) DSA einen Wert, der muss zufällig, geheim / unvorhersehbar sein und kann nie wieder verwendet werden. Wenn eine dieser Eigenschaften verletzt wird, ist es möglich, den privaten Schlüssel aus einer oder zwei Signaturen wiederherzustellen.

Dies ist zuvor geschehen (einmal mit einem fehlerhaften Patch des OpenSSL PRNG) in Debian und einmal mit einem Fehler in der SecureRandom-Implementierung von Android) und ist ziemlich schwer vollständig zu verhindern.

Mit RSA wäre in diesen Situationen nur Ihr kurzlebiger Sitzungsschlüssel kompromittiert worden, wenn der tatsächliche Authentifizierungsschlüssel Paare wurden zuvor mit einem ordnungsgemäß gesetzten PRNG erstellt.

Theoretisch gibt es eine Möglichkeit, (EC) -DSA-Signaturen von der Nachricht und dem privaten Schlüssel abhängig zu machen, wodurch ein Total vermieden werden kann Fehler im Falle eines defekten RNG, aber bis dies in Ihren SSH-Client integriert wird (es gibt derzeit keine OpenSSL-Release-Version mit dem Patch), würde ich definitiv RSA-Schlüssel verwenden.

Über diesen Vorteil sprechen Sie - wir alle wissen jetzt, dass der RSA-Zufallszahlengenerator nicht so zufällig ist. Ich weiß nicht, ob es wichtig ist, aber trotzdem ...
@rxt ist ein tangentiales Problem. Es ist das Standard-RNG in einem bestimmten Produkt, das von RSA, dem Unternehmen, verkauft wird. Dies hat nichts mit dem ursprünglichen RSA-Kryptoprotokoll mit öffentlichem Schlüssel zu tun.
CuriousFab
2015-09-10 20:52:27 UTC
view on stackexchange narkive permalink

Da ich als OpenSSH-Benutzer nicht viel über Kryptografie weiß, würde ich mich an eine einfache Tatsache halten: In http://www.openssh.com/legacy.html heißt es, dass SHA1 jetzt deaktiviert ist Standardmäßig, weil es als schwach angesehen wird:

OpenSSH 7.0 und höher deaktiviert in ähnlicher Weise den Public-Key-Algorithmus ssh-dss (DSA) . Es ist auch schwach und wir empfehlen gegen seine Verwendung.

Tom Leek erklärte dies in „[Warum OpenSSH DSA-Schlüssel veraltet hat] (http://security.stackexchange.com/a/112818/66454)“: Einfach ausgedrückt, ist dies eine Folge ihrer eigenen Codierungspraxis und der Unfähigkeit, auf Augenhöhe zu bleibenmit den aktuellen Standards.
Das Lesen im März 2017 gibt diesem Kommentar ein neues Licht.SHA1 wurde gebrochen, daher hat OpenSSH eine gute Entscheidung getroffen, SHA1 abzulehnen.Also denke ich, ich werde ihnen vertrauen, wenn sie DSA ablehnen.
robmuh
2014-02-09 23:13:34 UTC
view on stackexchange narkive permalink

Die Mathematik spielt möglicherweise keine Rolle. Dieser Thread scheint vor Snowden zu sein. Hier ist ein Reuters-Artikel vom 20. Dezember 2013:

(Reuters) - Als wichtiger Bestandteil einer Kampagne zur Einbettung von Verschlüsselungssoftware, in die sie weit verbreitet sein könnte Laut Reuters hat die US-amerikanische National Security Agency einen geheimen Vertrag über 10 Millionen US-Dollar mit RSA abgeschlossen, einem der einflussreichsten Unternehmen der Computersicherheitsbranche.

Dokumente, die vom ehemaligen NSA-Auftragnehmer Edward Snowden durchgesickert sind, zeigen dies Die NSA hat eine fehlerhafte Formel zur Erzeugung von Zufallszahlen erstellt und veröffentlicht, um eine "Hintertür" für Verschlüsselungsprodukte zu schaffen, berichtete die New York Times im September. Reuters berichtete später, dass RSA der wichtigste Distributor dieser Formel wurde, indem es in ein Software-Tool namens Bsafe integriert wurde, das zur Verbesserung der Sicherheit in PCs und vielen anderen Produkten verwendet wird.

Bisher wurde RSA nicht bekannt gegeben 10 Millionen US-Dollar für einen Deal, bei dem die NSA-Formel als bevorzugte oder Standardmethode für die Nummerngenerierung in der BSafe-Software festgelegt wurde, so zwei mit dem Vertrag vertraute Quellen. Obwohl diese Summe dürftig erscheint, machte sie mehr als ein Drittel des Umsatzes aus, den die betreffende Abteilung bei RSA im gesamten Vorjahr erzielt hatte, wie Wertpapieranmeldungen belegen.

Während dieses Wissenschaftsfreitags Podcast Ira fragt Matt Green, Martin Hellman (Erfinder der Public Key Cryptography) und Phil Zimmerman (Erfinder von PGP), was ihrer Meinung nach die NSA geknackt hat:

(um 17: 26)

Ira : Was sind einige der Dinge, in die die NSA eingebrochen ist?

Matt stark>: Wir haben also eine Reihe von Dingen gehört, die wir wahrscheinlich für echt halten können. … Zufallszahlengeneratoren… wir wissen, dass NSA durch NIST… sehr wahrscheinlich Türen in einige dieser Standardalgorithmen zurückgesetzt hat, die es ihnen ermöglichen, diese Systeme im Wesentlichen vollständig zu zerstören.

Ira : Sie meinen, die NSA hat diese Hintertüren geschaffen?

Matt : Das ist genau richtig. NIST arbeitet also mit NSA zusammen - und das ist gesetzlich vorgeschrieben. Wir dachten, die NSA würde NIST helfen, indem sie sicherere Standards für Amerikaner entwickelt. Wir vermuten jetzt - und haben starke Beweise zu glauben -, dass die Situation genau das Gegenteil war; dass NIST verwendet wurde, um Standards herauszugeben, gegen die die NSA verstoßen könnte.

Angesichts dieser jüngsten Enthüllungen scheint die Stärke der Algorithmen weitgehend irrelevant zu sein. RSA scheint ein privates Unternehmen gewesen zu sein, das irgendwie von der NSA gekauft wurde, und DSA wurde von NIST selbst gegründet, was nach Ansicht dieser Experten größtenteils eine Front für die Kryptoforschung der NSA darstellt.

Mit anderen Worten, es ist wirklich so Es spielt keine Rolle, ob Sie die Zufallszahlengeneratoren verwenden, die mit so ziemlich jedem modernen Computer geliefert werden, wie dies OpenSSH und andere tun.

Wählen Sie den aus, der für das, was Sie wollen, am schnellsten ist. In meinem Fall verwende ich denselben Schlüssel für viele Dinge, sodass die schnellere Generierungsgeschwindigkeit von DSA weniger wünschenswert ist. Vielleicht besteht auch eine wilde Chance, dass RSA tatsächlich eine unabhängige Entität von NIST und NSA war, während wir wissen, dass DSA von NIST erstellt wurde.

Ich persönlich verwende nur 1028-Bit-Schlüssel, weil, wie wir gesehen haben Es spielt wirklich keine Rolle, es sei denn, jemand stellt Anforderungen an Sie, der immer noch glaubt, dass größere Schlüssel Sie schützen. Das Ganze ist größtenteils nur ein Ärger für jeden, der einbrechen möchte.

Meinetwegen. Ich habe die relevanten Zitate hinzugefügt und einen Teil des Audios transkribiert. Danke für die Erinnerung.
Sicherlich meinst du 1024-Bit-Schlüssel?
Ihre Antwort ist nicht ganz konsistent. Sie mischen Fakten über ein RNG, das von der Firma RSA entwickelt wurde und anscheinend manipuliert wurde, und über die öffentlichen / privaten Schlüsselalgorithmen namens RSA (entwickelt von den Gründern der oben genannten Firma). Der RSA-Algorithmus (mit ausreichend großen Schlüsseln) kann nur dann leicht beschädigt werden, wenn Sie einen monsteroptimierten Cluster oder einen Quantencomputer haben. DSA wird möglicherweise von NIST veröffentlicht (ich habe es nicht überprüft), aber die NIST-Veröffentlichung wird auch von anderen unabhängigen Kryptographen überprüft. Zum Beispiel warnten sie vor dem zweifelhaften RNG, das von NIST genehmigt wurde.
Die Tatsache, dass das BSAFE-Produkt von RSA Inc Dual EC DRBG als * Standard * (nicht einmal der einzige angebotene) Zufallszahlengenerator verwendet, hat * überhaupt nichts * mit den Sicherheitseigenschaften des RSA * -Algorithmus * oder den Sicherheitseigenschaften von zu tunJede Software, die nicht für die Verwendung von BSAFE entwickelt wurde oder wird.Wenn Sie Verschwörungstheorien herumwerfen wollen, machen Sie zumindest Ihre Fakten richtig.Es gibt genug, um die NSA (und viele andere Geheimdienste auf der ganzen Welt) dafür verantwortlich zu machen, und es gibt gute Gründe, RSA für den Ausfall verantwortlich zu machen, ohne dass Ansprüche geltend gemacht werden müssen, die in der Realität keine Grundlage haben.
fpmurphy
2011-07-09 19:57:23 UTC
view on stackexchange narkive permalink

RSA und DSA sind zwei völlig unterschiedliche Algorithmen. RSA-Schlüssel können bis zu 4096 Bit groß sein, wobei DSA genau 1024 Bit betragen muss (obwohl OpenSSL mehr zulässt). Laut Bruce Schneier "sind sowohl DSA- als auch RSA-Schlüssel mit gleicher Länge in der Schwierigkeit, sie zu knacken, nahezu identisch."

FIPS 186-2 beschränkte den Modul auf 512 bis 1024 Bit. Das 2009 veröffentlichte überarbeitete FIPS 186-3 beschränkt den Modul jedoch auf 1024, 2048 oder 3072 Bit.
user37069
2014-01-13 15:21:32 UTC
view on stackexchange narkive permalink

Das Problem mit ECDSA sind nicht so viele Hintertüren. Bernstein / Lange erwähnen ausdrücklich, dass die Kurven-Kryptoanalyse nicht bestimmte Kurven, sondern Kurvenklassen angreift (siehe Folie 6).

Das Problem bei ECDSA ist, dass NIST-Kurven schwer zu implementieren sind korrekt (dh konstante Zeit und bei ordnungsgemäßer Überprüfung) im Vergleich zu Curve25519. OpenSSL verfügt über eine zeitkonstante P256-Implementierung, sodass OpenSSH in dieser Hinsicht sicher ist.

Wenn Sie sich immer noch Sorgen um NIST-Kurven machen, hat OpenSSH kürzlich die Unterstützung für das Ed25519-Schema hinzugefügt



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...