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.

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.

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.

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.

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