Frage:
Verschlüsselung - sollte ich RSA oder AES verwenden?
Ben
2011-12-18 05:48:59 UTC
view on stackexchange narkive permalink

Mein Modell ist eines, bei dem ich mehrere Clients habe, die mit einigen (aber nicht allen) anderen Clients sprechen möchten.

Alle Nachrichten werden über einen Server gesendet.

Nur die beiden miteinander kommunizierenden Clients sollten die Nachricht kennen. Daher sollten der Server UND die anderen Clients nicht in der Lage sein, herauszufinden, welche Nachricht gesendet wurde.

Die Kommunikation zwischen zwei Clients kann mehrmals am Tag beginnen und enden.

Nachrichten sind Klartextnachrichten mit möglicherweise unbegrenzter Länge, aber wahrscheinlich weniger, denken Sie an Nachrichten im SMS-Stil.

Wie soll ich unter diesen Umständen die Nachrichten verschlüsseln? Es macht mir nichts aus, zusätzlichen Code zu schreiben, wenn dies zu einer besseren Geschwindigkeit oder Effizienz führt.

Ich kenne die groben Grundlagen der Funktionsweise von RSA und AES, kann aber nicht herausfinden, was am besten ist.

Wenn Sie ein öffentliches / privates Schlüsselpaar für RSA generieren, gibt es eine Situation, in der Sie ein neues Paar generieren müssten? Oder kann ein Client einen öffentlichen Schlüssel haben und jedem, der mit ihm sprechen möchte, denselben Schlüssel geben, und nur er kann (jemals) die Nachrichten lesen, aber er speichert den öffentlichen Schlüssel für alle zukünftigen Nachrichten?

Oder sollte ich einen separaten symmetrischen AES-Schlüssel für zwei Clients haben und diesen einfach teilen, wenn der Kontakt zum ersten Mal initiiert wird, und diesen für immer verwenden. Gibt es wieder Umstände, unter denen dies erneut generiert werden müsste?

Wie würde ich die Schlüssel speichern, damit sie bestehen bleiben, wenn der Client abstürzt / herunterfährt / neu startet?

RSA ist ein Verschlüsselungsalgorithmus mit öffentlichem Schlüssel (asymmetrisch), während AES ein Algorithmus mit symmetrischem Schlüssel ist. Die beiden Algorithmen arbeiten sehr unterschiedlich, und häufig verwendet ein Kryptosystem beide Algorithmen. Beispielsweise kann ein Kryptosystem RSA verwenden, um Schlüssel sicher auszutauschen, während AES verwendet wird, um die tatsächlichen Nachrichten zu verschlüsseln.
Ich frage aus Sicht der Implementierung, der Programmierseite der Dinge ... welchen Algorithmus soll ich die Verschlüsselung von Nachrichten programmieren, wie programmiere ich die Speicherung von Schlüsseln.
@Ben, Möglicherweise möchten Sie auch einen aktiven Lauscher in Betracht ziehen, bei dem entweder der Server oder ein anderer Client vorgibt, der Empfänger der Nachricht zu sein. Ich weiß nicht, wie wahrscheinlich dies bei Ihrem Modell ist, aber etwas zu beachten. Tatsächlich könnte der Lauscher die Nachricht dann an den tatsächlichen Empfänger weiterleiten, und andererseits weiß ich nicht, ob der tatsächliche Empfänger den geänderten Fingerabdruck des Absenders erkennen würde.
Fünf antworten:
#1
+46
Gilles
2012-01-23 23:43:21 UTC
view on stackexchange narkive permalink

Weder noch, es sei denn, es ist beides. Sie stellen die falsche Frage. Sie sollten zu diesem Zeitpunkt nicht an einen kryptografischen Algorithmus denken, sondern an ein kryptografisches Protokoll.

Kryptografische Protokolle sind schwer zu entwerfen und eine häufige Quelle für Sicherheitslücken. Sie verstehen die Kryptografie mit öffentlichem Schlüssel nicht vollständig und sind daher nicht bereit, sie in Ihrem eigenen kryptografischen Protokoll zu verwenden.

Auf hoher Ebene ist Ihr Modell für die Kryptografie mit öffentlichem Schlüssel (z. B. RSA) zugänglich ). Lassen Sie jeden Client seinen eigenen privaten Schlüssel haben und veröffentlichen Sie seinen öffentlichen Schlüssel für den anderen Client. Der private Schlüssel eines Clients ändert sich im Laufe der Zeit nicht, es sei denn, der Client wurde kompromittiert. Symmetrische Kryptographie (z. B. AES) würde hier nicht gut skaliert, da jedes Paar von Clients einen eigenen geheimen Schlüssel haben müsste.

Verwenden Sie nach Möglichkeit vorhandene Software. Das Implementieren kryptografischer Protokolle ist fast so schwierig wie das Entwerfen. Für ein Modell, bei dem Clients gelegentlich Nachrichten im E-Mail-Stil aneinander senden, ist GnuPG ein Tool, das gut funktioniert. (Verwenden Sie für bidirektionale Kommunikation SSL / TLS.)

Rufen Sie für den täglichen Betrieb zum Senden einer Nachricht gpg auf. verschlüsseln Sie mit dem öffentlichen Schlüssel des Empfängers und unterschreiben Sie dabei mit dem privaten Schlüssel des Absenders. Überprüfen Sie beim Empfang einer Nachricht die Signatur anhand des öffentlichen Schlüssels des angeblichen Absenders und entschlüsseln Sie ihn mit dem privaten Schlüssel des Empfängers. Mit anderen Worten, senden Sie mit gpg --sign --encrypt -r NAME_OF_RECIPIENT und empfangen Sie mit gpg --verify , gefolgt von gpg --decrypt

Das verbleibende Problem ist das der Schlüsselverteilung. Nachdem ein Client sein Schlüsselpaar generiert hat, muss er die anderen Clients darüber informieren und verteilen, ohne dass der öffentliche Schlüssel während der Übertragung von einem Angreifer abgefangen und ersetzt werden kann. Wie dies zu tun ist, hängt stark von Ihrem genauen Szenario ab. Vernachlässigen Sie nicht die Sicherheit dieses Teils.

Wenn sich das Aufrufen von GnuPG als zu langsam herausstellt, sollten Sie eine leichtere, möglicherweise hausgemachte Implementierung eines ähnlichen Protokolls in Betracht ziehen (vom E-Mail-Bereich-Overhead zum SMS-Bereich-Overhead). Unter der Haube generiert GnuPG für jede Nachricht einen symmetrischen Schlüssel, da die Kryptografie mit öffentlichen Schlüsseln für große Nachrichten teuer ist. Der Public-Key-Algorithmus wird nur zum Verschlüsseln des symmetrischen Schlüssels und zum Signieren eines Digests der Datei verwendet. Sie sollten diesem Modell folgen. Bei Verwendung von AES für die symmetrische Verschlüsselung ist SHA-256 als Digest-Algorithmus und RSA als Public-Key-Algorithmus eine gute Wahl.

"und mit dem öffentlichen Schlüssel des Empfängers entschlüsseln." sollte es nicht sein "und mit dem privaten Schlüssel des Empfängers entschlüsseln."?
@Gilles Tolle Antwort, sehr hilfreich, danke!Schauen Sie sich "The Double Ratchet Algorithm" an, um AES-256 zu verwenden und gut zu skalieren, wenn nicht bereits.
DH sollte mit AES verwendet werden.RSA kann schlicht und einfach allein verwendet werden.Der Digest-Algorithmus wird sowieso immer benötigt.
#2
+20
JB Nizet
2011-12-18 05:59:06 UTC
view on stackexchange narkive permalink

Wie bereits von In silico gesagt, dienen RSA und AES zwei unterschiedlichen Zwecken. AES ist ein schneller Algorithmus, mit dem eine ganze Konversation verschlüsselt werden kann. Aber es gibt ein Problem: Wie kann man entscheiden, welcher Schlüssel zwischen zwei Parteien verwendet werden soll, ohne dass die anderen es wissen?

RSA kann die Lösung dafür sein. Wenn jeder Teilnehmer den öffentlichen RSA-Schlüssel jedes anderen Teilnehmers hat, kann jeder eine verschlüsselte Kommunikation mit jedem anderen starten (unter Verwendung des öffentlichen Schlüssels des anderen Teilnehmers) und sich für einen geheimen AES-Schlüssel entscheiden. Sobald der AES-Schlüssel festgelegt ist, kann der Rest der Konversation mit AES verschlüsselt werden. Um Teilnehmer B zu beweisen, dass es wirklich A ist, das ihn ansprechen möchte, kann eine digitale Signatur verwendet werden.

Was ich beschrieben habe, ist Grosso Modo, was der SSL-Handshake macht, wenn ein Browser eine Verbindung mit einem SSL-fähigen Webserver herstellt.

Hallo, ich frage mich nur ... warum kann sich der Client nicht einfach mit RSA unterhalten, da er bereits zur Entscheidung über den Schlüssel für AES verwendet wird?Liegt es daran, dass RSA irgendwie nicht zum Austausch geheimer Nachrichten geeignet ist?Vielen Dank.
Der erste Grund ist, dass RSA viel langsamer ist, der zweite ist, dass seine Größe begrenzt ist.Weitere Details finden Sie hier: http://security.stackexchange.com/questions/33434/rsa-maximum-bytes-to-encrypt-comparison-to-aes-in-terms-of-security
#3
+6
Andrew White
2011-12-18 05:56:03 UTC
view on stackexchange narkive permalink

Verstehe das nicht falsch, aber ...

Ich kenne die groben Grundlagen der Funktionsweise von RSA und AES, kann aber nicht herausfinden, was am besten ist.

Wenn Sie nur die Grundlagen kennen, sind Sie möglicherweise (noch) nicht die richtige Person, um dieses Problem zu lösen. Sicherheit ist einer der Bereiche, in denen Sie sehr besonders und vorsichtig sein müssen, sonst machen Sie Ihr gesamtes Sicherheits-Setup ungültig.

Außerdem glaube ich nicht, dass wir genug Informationen haben, um Sie zu informieren eine richtige Antwort. Die Geschäftsverträge über Sicherheitserwartungen müssen im Voraus bekannt sein.

In den meisten Fällen verlassen Schlüssel aus Sicherheitsgründen niemals den Computer, auf dem sie generiert wurden. Wenn Sie also Informationen "teilen" möchten, verwenden Sie einen öffentlichen Schlüssel Aus rein sicherheitstechnischer Sicht ist die Lösung in der Regel die richtige Wahl. Die Ausnahme ist, wenn Sie einen symmetrischen Schlüssel auf sichere Weise freigeben können, z. B. indem Sie den Schlüssel auf einem physischen Medium an die Person senden.

Ich glaube nicht, dass Geschäftsverträge jemals Verschlüsselungsdetails enthalten, und sie sollten in den meisten Fällen auch nicht verwendet werden, da Geschäftsbenutzer möglicherweise veraltete / unangemessene Technologien wählen. In der Antwort von @Gilles finden Sie eine kurze Antwort: "Weder noch, es sei denn, es ist beides" ... und die Protokollauswahl ist jetzt am besten anwendbar.
#4
+4
Binyamin Sharet
2011-12-18 05:56:41 UTC
view on stackexchange narkive permalink

Grundsätzlich ist die Verwendung der Verschlüsselung mit öffentlichen Schlüsseln (wie RSA) viel teurer als die Verwendung der Verschlüsselung mit symmetrischen Schlüsseln (wie AES). Wenn viele Nachrichten von einer zur anderen übertragen werden, ist dies besser Verwenden Sie einen symmetrischen Schlüssel.

Jetzt kann die Erstellung und der Austausch des symmetrischen Schlüssels mithilfe der Verschlüsselung mit öffentlichem Schlüssel erfolgen.

Zum Beispiel:

Jeder Client hat ein privat-öffentliches Schlüsselpaar, und der öffentliche Schlüssel wird auf dem Server gespeichert. Wenn zwei Clients eine Kommunikationssitzung starten, nimmt jeder den öffentlichen Schlüssel des anderen vom Server und sendet eine verschlüsselte Nummer an den anderen. Dann hasht jede Seite diese beiden Zahlen und verwendet das Ergebnis als Schlüssel, um die Daten von nun an zu verschlüsseln / entschlüsseln.

Ich verstehe dieses Prinzip, was ich wissen möchte, ist, dass der symmetrische Schlüssel jedes Mal generiert werden muss, wenn die Kommunikation beginnt, oder dass ich sicher bin, jeden Tag denselben Schlüssel für dieses Kundenpaar zu verwenden.
Ich würde vorschlagen, nicht denselben Schlüssel auch nur für zwei Nachrichten zu verwenden, sondern einen Zufall mit der Nachricht zu übergeben und einen Hash des vorherigen Schlüssels mit diesem Zufall zu verwenden, um den Nachrichtenschlüssel zu erstellen.
#5
+2
Jesse Chisholm
2015-08-21 03:22:22 UTC
view on stackexchange narkive permalink

Wenn Sie den PUBLIC / PRIVATE-Stil (RSA mit ausreichenden Bits :) verwenden, können Sie die Art der sicheren Kommunikation einrichten, die Sie folgendermaßen beschreiben:

  1. Alice schreibt eine Nachricht
  2. Alice verschlüsselt es mit Alice PRIVATE Schlüssel
  3. Alice verschlüsselt es erneut mit Bob PUBLIC key
  4. Alice sendet die Ergebnisse an Bob.
  5. ol>

    Dann:

    1. Bob erhält eine Nachricht ( angeblich) von Alice
    2. Bob entschlüsselt es mit Bob s PRIVATE -Taste
    3. Bob entschlüsselt es erneut mit Alice strong PUBLIC -Taste
    4. Wenn alles gut geht, liest Bob die Nachricht.
    5. ol>

      Hinweis:

  • Bob ist der einzige, der diese Nachricht lesen kann.
  • Bob weiß ohne Zweifel, dass sie von Alice stammt.

Beide Attribute mit abrufen AES ist etwas kniffliger.

Ich war nicht der Downvoter, aber ich vermute, es war für Folgendes: (1) Aufrufen der Signatur "Verschlüsseln [der Nachricht] mit Alices privatem Schlüssel" und Überprüfen durch "Entschlüsseln [der Nachricht] mit einem öffentlichen Schlüssel" und Handeln wie es ist eine verschlüsselte Nachricht. Zum Signieren von Nachrichten hashen Sie die Nachricht zuerst kryptografisch und verschlüsseln dann den Hash der Nachricht mit Ihrem privaten Schlüssel. Zur Überprüfung der Nachricht entschlüsseln Sie den Hash mit dem öffentlichen Schlüssel des anderen und vergleichen ihn mit dem Hash der entschlüsselten Nachricht. Sie haben zuerst einen Hash, da RSA nur auf Nachrichten reagieren kann, die kleiner als N sind. RSA-2048 kann nur 256 Bytes verschlüsseln.
(2) Lehrbuch RSA (c = m ^ e mod N und m = c ^ d mod N) weist Mängel und Schwachstellen bei der direkten Verschlüsselung von Nachrichten auf. Daher sollten Sie eine Hybridverschlüsselung verwenden - verschlüsseln Sie die Nachricht mit symmetrischer Verschlüsselung (z. B. AES) mit einem neuen Zufallsschlüssel und hängen Sie dann den verschlüsselten AES-Zufallsschlüssel mit dem öffentlichen RSA-Schlüssel des Empfängers an, um ihn mit einem sicheren Auffüllschema wie [OAEP] zu verschlüsseln. (https://en.wikipedia.org/wiki/Optimal_asymmetric_encryption_padding). (Ihr kniffligerer AES-Kommentar hat mir fast nicht gefallen - aber wenn Alice und Bob nur Personen mit einem gemeinsamen Sym-Schlüssel sind, haben sie die gleichen Garantien).
@drjimbob re: (1) Eigentlich habe ich NICHT über "Signieren" gesprochen. Das OP wollte, dass die gesamte Nachricht verschlüsselt wird. Was ich beschrieben habe, verschlüsselt die gesamte Nachricht. Der Aspekt des "Signierens" ist ein Nebeneffekt, nicht das Hauptziel, dies zu tun, da das OP nicht nach Authentifizierung, sondern nur nach Datenschutz gefragt hat. Betreff: (2) Die Verwendung eines Hybridsystems ist für die Effizienz besser, vereinbart. Das Festhalten an einem PUBLIC / PRIVATE-Schlüsselschema bedeutet, dass nichts über einen anderen Kanal geteilt werden muss. re: _AES knifflig_ nur, weil Sie wirklich ein Hybridsystem verwenden müssen, um einen sicheren Kanal zum Teilen des Schlüssels zu erhalten.
@drjimbob Auch das vom OP beschriebene System ("Think SMS Style Messages") eignet sich nicht für den Hybrid Style. Es gibt keine Möglichkeit (wie in TCP / TLS), den Kanal offen zu halten und die Verschlüsselungsprotokolle zu ändern. Außerdem macht die Größe der Nachrichten die PUBLIC / PRIVATE-Algorithmen weniger belastend. Kaum mehr als Sie für die erste Stufe des Hybridschemas benötigen würden.
Das System-OP beschreibt Anfragen zur Unterstützung von "Klartext mit möglicherweise unbegrenzter Länge". Lehrbuch RSA macht das nicht oder hat kein Schema, wie Nachrichten, die größer als der Modul des Schlüssels sind, sicher aufgeteilt werden können. weil Sie in der Praxis immer Hybrid-RSA verwenden, da es schneller und sicherer ist. Ein kurzes Beispiel, warum Ihre Methode der doppelten Verschlüsselung mit sehr kleinen RSA-Schlüsseln (6-Bit-Primzahlen für 12-Bit-RSA) nicht funktioniert, um die Verwendung von Lehrbuch-RSA zu vereinfachen. Der öffentliche Schlüssel von A ist: (N = 3127, e = 3) und der private Schlüssel von A ist (N = 3127, d = 2011). Der öffentliche Schlüssel von B (N = 1927, e = 3) und der private Schlüssel von B (N = 1927, d = 1227).
Sie können für jede Nachricht mit einem Wert von 0 bis N-1 prüfen, wir haben die Identität "(m ^ e% N) ^ d% N == m" für beide Schlüsselpaare. Versuchen wir nun eine kurze Nachricht "m = 11" mit Ihrem Schema. Wir verschlüsseln mit dem privaten Schlüssel von A und erhalten 2707. Der nächste Schritt ist problematisch, da 2707 größer als N von B ist. A bemerkt dies nicht und verschlüsselt diesen Wert mit dem öffentlichen Schlüssel von B, um 1272 zu erhalten. A sendet 1272 an B, der entschlüsselt es mit seinem privaten Schlüssel, um 780 zu erhalten, das mit dem öffentlichen Schlüssel von A entschlüsselt wird, um m '= 1607 zu erhalten, was nicht 11 ist (dieses Schema funktioniert jedoch mit beispielsweise m = 12, m = 13).
Hervorragender Punkt - Ich hatte nicht daran gedacht, die Schlüssel so klein zu machen, dass sie nicht die Zwischenprodukte für eine Nachricht enthalten. (Vielleicht hätte ich aggressiver mit meinem ** ausreichenden Bit ** -Kommentar umgehen sollen.) Betreff: "A merkt es nicht" - Man hofft, dass der Code es merkt, selbst wenn Alice es nicht tut. :) Man würde hoffen, dass der Code Aufhebens machen und sich beschweren würde. Aber still weiterzumachen, als ob alles in Ordnung wäre, ist ein Fehler an sich. Und es fällt mir schwer, gleichzeitig mit unendlich langen Nachrichten an SMS zu denken. @drjimbob, Vielen Dank für das Detail Ihrer Antwort.


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