Asynchrone Verschlüsselung mit C

C++ Forumbot

Dieser Thread wurde von Moderator/in rüdiger aus dem Forum ANSI C in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Balu Jr. schrieb:

Könnte man eine solche Verschlüsselung, d.h. verschlüsselte Kommunikation denn auch mit selbsterzeugtem Code realisieren. Die Vorschläge sind ja nun vorgefertigte Librarys.
ICh meine also mit den standard Socket-etc.-Funktionen ein Netzwerk erstellen und die dann folgende Kommunikation selbst absichern. Also selbst einen Private und Public Key erstellen und damit per XOR (meine ICh wäre das doch) Datenstrom ver- und beim empfänger wieder Entschlüsseln? Könnte man gegebenenfalls eine eigene Methode realisieren?

muss es unbedingt asymmetrisch sein? symmetrische algos sind einfacher und du kannst dir selbst was ausdenken, das (zwar nicht geheimdiensten aber) dem 0815-hacker kopfzerbrechen bereitet. zum rumspielen: http://www.cryptool.com/

hustbaer

Balu Jr. schrieb:

Könnte man eine solche Verschlüsselung, d.h. verschlüsselte Kommunikation denn auch mit selbsterzeugtem Code realisieren. Die Vorschläge sind ja nun vorgefertigte Librarys.

Ja, klar. Wobei ich allerdings die Verschlüsselung selbst immer von einer fertigen Library machen lassen würde. Sowas selbst zu schreiben macht IMO garkeinen Sinn. Viel zu kompliziert und fehleranfällig.

ICh meine also mit den standard Socket-etc.-Funktionen ein Netzwerk erstellen und die dann folgende Kommunikation selbst absichern.

Wenn ich dich richtig verstehe müsstest du dazu bloss die Daten vor dem Senden bzw. nach dem Empfangen durch eine Verschlüsselungs-Library stopfen. Dann kannst du die Daten trotzdem "selbst" über "rohe" Sockets verschicken, oder sonstwie übertragen, wie du eben lustig bist.

Also selbst einen Private und Public Key erstellen und damit per XOR (meine ICh wäre das doch) Datenstrom ver- und beim empfänger wieder Entschlüsseln? Könnte man gegebenenfalls eine eigene Methode realisieren?

Funktionen zum Erstellen von Keys für RSA oder Elliptic-Curve gibts in einigen Verschlüsselungs-Libraries, wie z.B. der Crypto++.
Ich frage mich allerdings wie du mit Hilfe von RSA oder EC Daten mit XOR verschlüsseln willst

Was normalerweise gemacht wird, ist, dass man mit Hilfe von RSA oder EC zu Beginn der Verbindung einen Key aushandelt (z.B. verwendet man RSA/EC zum Versenden von Zufallsdaten, aus denen sich beide Seiten dann den Key ausrechnen). Diesen Key verwendet man dann um die Daten mit DES, IDEA, AES oder sonstwas zu verschlüsseln.

Block-Cipher wie eben DES, IDEA, AES lassen sich mit relativ einfachen Transformationen in einen Stream-Cipher umwandeln, so dass man dann einen "nicht geblockten" Byte-Stream damit verschlüsseln kann. Dazu handelt man dann entweder zusätzlich zum Key noch einen IV (Initialisierungs-Vektor) aus, oder verwendet den Key gleichzeitig als IV, oder berechnet den IV aus dem Key. Oder man nimmt einen fixen IV, und überträgt, bevor man mit den "Nutzdaten" anfängt, noch ein paar hundert Byte zufällige Daten (die man durch den Stream-Cipher stopft, um den Zustand des Stream-Chipher zu "randomisieren"). BTW: Der IV ist ein zusätzlicher "String" (Datenblock), den du zum Initialisieren des Stream-Chipher brauchst.

p.S.: falls du es nicht weisst oder nicht ganz verstanden hast: mit RSA bzw. EC kannst du nicht einfach beliebige Daten (mit beliebiger Grösse) verschlüsseln. Du kannst bloss eine einzige Zahl verschlüsseln, und die obere Grenze für diese Zahl ergibt sich aus der Schlüssellänge. Soweit ich weiss kann diese Zahl niemals grösser als der Key sein - bzw. muss sogar um einige Stellen kürzer sein. Mit einem 384 Bit EC Key kannst du also keine 512 Bit Zahl verschlüsseln. Und das Verschlüsseln & Entschlüsseln mit RSA bzw. EC ist *sehr* langsam.
Daten in z.B. 256 Bit Stücke zu zerteilen, und diese dann mit EC zu verschlüsseln macht also kaum einen Sinn - viel zu langsam. Davon abgesehen müsste man zusätzlich etwas einbauen, was dafür sorgt, dass gleiche Datenblöcke nicht immer zum selben Ergebnis führen (RSA und EC sind ja genau wie Block-Cipher "stateless"). Letzteres wäre zwar ganz einfach zu machen, aber der Punkt "viel zu langsam" bleibt, und ist IMO für so ziemlich alle Anwendungen das unausweichliche KO Kriterium.

p.p.S.: du kannst OpenSSL auch verwenden OHNE den Socket/Stream-Layer von OpenSSL zu nutzen. D.h. du kannst "direkt" auf die Verschlüsselungs-Funktionen zugreifen. Falls du C++ verwendest, und den Kommunikation- sowie Handshake-Teil sowieso selbst implementieren willst, würde ich dir allerdings eher die Crypto++ empfehlen. Ist C++ und hat IMO das wesentlich sauberere/schönere Interface.

hustbaer schrieb:

Block-Cipher wie eben DES, IDEA, AES lassen sich mit relativ einfachen Transformationen in einen Stream-Cipher umwandeln, so dass man dann einen "nicht geblockten" Byte-Stream damit verschlüsseln kann....

ist hier beschrieben: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

hustbaer

+fricky schrieb:

hustbaer schrieb:

Block-Cipher wie eben DES, IDEA, AES lassen sich mit relativ einfachen Transformationen in einen Stream-Cipher umwandeln, so dass man dann einen "nicht geblockten" Byte-Stream damit verschlüsseln kann....

ist hier beschrieben: http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

Ja, ich weiss, daher bin ich auch nicht weiter darauf eingegangen WIE man das macht
(Nur wie man zu dem dazu nötigen IV kommt - weiss nicht ob das dort nicht vielleicht auch beschrieben ist, könnte sein, aber egal.)

Moin

Vielleicht sind wir ein Wenig vom Thema abgekommen, da es mir nicht um die Verbindung geht, sondern nur um die Verschlüsselung. Aber hier ist (wenn es stimmt) ein Killerargument für mich:

hustbaer schrieb:

p.S.: falls du es nicht weisst oder nicht ganz verstanden hast: mit RSA bzw. EC kannst du nicht einfach beliebige Daten (mit beliebiger Grösse) verschlüsseln. ...

Um etwas genauer auf das Problem einzugehen:
Die Kommunikation ist asynchron und unidirektional. Die Partner können keine Schlüssel aushandeln. Der Gedanke war nun, da ein Zertifikat existiert, den PrKey zum Verschlüsseln zu verwenden und den PuKey zum entschlüsseln. Ich weiss, dass hier die Sinnhaftigkeit nicht ganz unumstritten ist, aber es existieren Vorgaben, die ich (noch) nicht ändern kann.

Beim schreiben kommt mir gerade die Idee einen RandomKey zu erzeugen, damit den Text synchron zu verschlüsseln und den RandomKey asynchron verschlüsselt mitzuschicken...

G,
Hannes

hustbaer

Es heisst symmetrisch und asymmetrisch, das ist nun schon 10x richtig hier geschrieben wurden, nur du schreibst es immernoch falsch

Und was meinst du mit "asynchron" (bezogen auf die Kommunikation jetzt)? Ist Zustellung nicht garantiert? Ist die Reihenfolge nicht garantiert? Oder meinst du etwa nur dass du asynchrone IO Funktionen zur Kommunikation verwendest?

Und falls Reihenfolge/Zustellung nicht garantiert ist, ist es dann schlimm wenn der Empfänger am Anfang mal 10 oder 100 Pakete nicht entschlüsseln kann? Dann könntest du nur alle N Pakete den Schlüssel mitschicken.

Wenn du nämlich für jedes einzelne Paket einen neuen symmetrischen Key erstellst, und den dann per RSA/EC verschlüsselst ... wird das alles wie erwähnt sehr sehr langsam werden. Teste das mal, das kann echt *laaaange* dauern.

Und nochwas: wenn du viele asymmetrisch verschlüsselte Keys verschickst, bietet sich wohl EC an, da EC (verglichen mit RSA) bei gleicher Sicherheit mit viel kürzeren Keys auskommt (und daher auch viel kürzere Ciphertexte ausspuckt).

Ja. Sorry. Jetzt merk ichs auch. Die Verschlüsselung ist asymmetrisch.

Die Kommunikation ist asynchron und die Auslieferung garantiert.

hustbaer schrieb:

Und nochwas: wenn du viele asymmetrisch verschlüsselte Keys verschickst, bietet sich wohl EC an, da EC (verglichen mit RSA) bei gleicher Sicherheit mit viel kürzeren Keys auskommt (und daher auch viel kürzere Ciphertexte ausspuckt).

Werd mir das ECC mal anschauen.
Bin erstmal froh, dass es wohl fertige Libs gibt, die man als Grundlage nehmen kann. Doku scheint ja eher sperlich gesät zu sein, was das openssl angeht, aber darüber müsste ich mir bei der Implementation zum Glück keine Gedanken machen...

hustbaer schrieb:

Wenn du nämlich für jedes einzelne Paket einen neuen symmetrischen Key erstellst, und den dann per RSA/EC verschlüsselst ... wird das alles wie erwähnt sehr sehr langsam werden. Teste das mal, das kann echt *laaaange* dauern.

ich würde vielleicht was fertiges nehmen, sowas wie z.b. AES-CCMP (wird von WPA verwendet). das ist sehr schnell und man kann z.b. bei laufender kommunikation jederzeit neue keys erzeugen (wenn man will, muss man aber nicht).
http://standards.ieee.org/getieee802/download/802.11i-2004.pdf
(wie's geht steht unter: 8.3.3.1 CCMP overview)

Ich habe jetzt nochmal Rücksprache gehalten.
Verschlüsselung und Signatur wurden am Anfang sehr synonym verwendet.
Mir hat halt die Verschlüsselung (bzw. die Geheimhaltung der Keys) Sorgen bereitet.

Was eigentlich gefragt ist, ist eine Signaur, da hauptsächlich sichergestellt werden soll, dass der Absender berechtigt ist. Also Nutzdaten "hashen", mit PrKey verschlüsselt anhängen (ggf. sogar das PublicZertifikat).
Auf der anderen Seite Zertifikat prüfen, hash entschlüsseln und vergleichen.

Die openssl Libs sollten für das Verschlüsseln des Hashes ja geeignet sein, aber wisst ihr wie es mit der Validierung des Zertifikats über einen Zertifikatssore aussieht? Wir verwenden eine kdb (über gskit/keytool). Für Java habe ich APIs geshen, die man verwenden kann, habt ihr Erfahrungen damit in C?