it-swarm-eu.dev

Verschlüsselung - sollte ich RSA oder AES verwenden?

Mein Modell ist eines, bei dem ich mehrere Kunden habe, die mit einigen (aber nicht allen) der anderen Kunden 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 täglich beginnen und enden.

Nachrichten sind Klartext mit möglicherweise unbegrenzter Länge, aber wahrscheinlich viel weniger. Denken Sie an Nachrichten im Stil von SMS).

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.

Gibt es eine Situation, in der Sie ein neues Paar generieren müssten, wenn Sie ein öffentliches/privates Schlüsselpaar für RSA generieren? 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 einen Umstand, unter dem 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?

39
Cheetah

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 öffentlichen Schlüsseln 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 öffentlichen Schlüsseln (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 Client-Paar 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 .)

Also: Für den täglichen Betrieb rufen Sie zum Senden einer Nachricht gpg auf, verschlüsseln 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 empfange 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 selbst erstellte Implementierung eines ähnlichen Protokolls in Betracht ziehen (vom Overhead des E-Mail-Bereichs bis SMS) Unter der Haube generiert GnuPG für jede Nachricht einen symmetrischen Schlüssel, da die Kryptografie mit öffentlichem Schlüssel für große Nachrichten teuer ist. Der Algorithmus mit öffentlichem Schlüssel wird nur zum Verschlüsseln des symmetrischen Schlüssels und zum Signieren eines Digests der Datei verwendet sollte diesem Modell folgen. Mit AES für die symmetrische Verschlüsselung ist SHA-256 als Digest-Algorithmus und RSA als Public-Key-Algorithmus eine gute Wahl.

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.

19
JB Nizet

Versteh 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 Ihnen eine richtige Antwort zu geben. 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, ist eine Lösung mit öffentlichen Schlüsseln aus rein sicherheitstechnischer Sicht normalerweise 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.

6
Andrew White

Grundsätzlich ist die Verwendung der Verschlüsselung mit öffentlichem Schlüssel (wie RSA) viel teurer als die Verwendung der Verschlüsselung mit symmetrischem Schlüssel (wie AES). Wenn viele Nachrichten von einer zur anderen übertragen werden, ist es besser, eine symmetrische zu verwenden Schlüssel.

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

Zum Beispiel:

Jeder Client verfügt über 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 hascht jede Seite diese beiden Zahlen und verwendet das Ergebnis als Schlüssel, um die Daten von nun an zu verschlüsseln/entschlüsseln.

3
MByD

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 's PRIVATEM Schlüssel
  3. Alice verschlüsselt es erneut mit Bob 's PUBLIC key
  4. Alice sendet die Ergebnisse an Bob.

Dann:

  1. Bob erhält (angeblich) eine Nachricht von Alice
  2. Bob entschlüsselt es mit Bob 's PRIVATEM Schlüssel
  3. Bob entschlüsselt es erneut mit Alice 's PUBLIC key
  4. Wenn alles gut geht, liest Bob die Nachricht.

Hinweis:

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

Es ist etwas schwieriger, beide Attribute mit AES zu erhalten.

2
Jesse Chisholm