AES Datenübertragung C#

Wozu? Mir erschließt sich der Sinn nicht. Außerdem ist unklar was du nun 
genau gemacht hast und was dein Ziel ist.

1. Wieviele Clients soll es geben?
2. Wie soll der Schlüssel sicher an die Clients übermittelt werden, wenn 
die Clients gegenseitig anonym bleiben sollen?
3. Darf der Server die Identität der Clients kennen?

Mein Vorschlag für ein einfaches Multi-User-System mit 
vertrauenswürdigem(!) Server bei dem die Clients lediglich die IP des 
jeweils anderen nicht wissen dürfen würde so aussehen:

Voraussetzung
1. Der Server verfügt über ein digitales Zertifikat
2. Clients nutzen zur Kommunikation mit dem Server TLS
3. Der Server vergibt an jeden Client eine eindeutige ID sowie einen 
einzigartigen, zufälligen AES-Schlüssel

Anwendung:
1. Clients verbinden sich per TLS zum Server, durch Prüfung des 
Zertifikats wird dessen Identität und Authentizität sichergestellt
2. Client A teilt dem Server mit, dass er mit Client B kommunizieren 
möchte.
3. Der Server sendet Client A den Schlüssel von Client B
4. Der Server teil Client B den Kommunikationswunsch mit und übermittelt 
ihm den Schlüssel von Client A
5. Bei der Kommunikation verschlüsselt Client A und mit dem Schlüssel 
von Client B und entschlüsselt mit seinem Schlüssel A. Client B 
verschlüsselt mit dem Schlüssel von Client A und entschlüsselt mit 
seinem Schlüssel B.

Das lässt sich jetzt noch beliebig weiter verfeinern, z.B. indem nicht 
direkt die Schlüssel von A und B verwendet werden sondern abgeleitete 
Session-Schlüssel, dadurch sind diese nur für eine Session gültig und 
der Originalschlüssel kann nicht von anderen Teilnehmern missbraucht 
werden, da er nur dem jeweiligen Client und dem Server bekannt ist. 
Voraussetzung hier: Server und Client sind in der Lage jeweils die 
gleiche Schlüsselableitung durchzuführen.

Viele Grüße
Daniel

Nein, aber das hat Fred ja schon gesagt.

Sebastian N. schrieb:
> Es sollte nur einen server und einen client geben.
> Ich will mit dem client den server fernsteuern, vorerst will ich aber
> nur dateien übertragen.

Dann nimm TLS mit Client-Authentisierung und tunnel dein 
Übertragungsprotokoll dadurch. Genau für solche Anwendungsfälle wurde 
TLS entworfen.

Irgendwas Eigenes zu basteln ohne über tiefere Krypto-Kenntnisse zu 
verfügen ist grob fahrlässig.

Sebastian N. schrieb:
> Ist die grundidee der verschlüsselten Übertragung oke?

Noch ein Nachtrag, die Grundidee etwas zu verschlüsseln ist nie verkehrt 
;)

Das Problem ist eben, wie du schon gemerkt hast, dass es mit 
Verschlüsselung alleine nicht getan ist. Die Verschlüsselung an sich ist 
eigentlich trivial. Man nehme einen (idealerweise verbreiteten und 
standardisierten) Algorithmus wie AES und ver-/entschlüssele damit 
Daten. Normalerweise kann man hier (Implementierungsfehler mal außen 
vor) nicht viel falsch machen. Die Herausforderung liegt leider an 
anderen Stellen:

1. Wie erzeugt man sichere Schlüssel?
2. Wie verteilt man Schlüssel sicher an die einzelnen Teilnehmer?
3. Wie sichert man die Authentizität der einzelnen Teilnehmer?
4. Wie sichert man die Authentizität/Integrität der übertragenen Daten?
5. Wie sichert man das System gegen Kompromittierung von Schlüsseln?
6. Wie sichert man das System gegen betrügerische Teilnehmer?
7. Usw. usw.

Daher auch mein Vorschlag mit TLS, da dir hierdurch schon einmal ein 
paar Sorgen genommen werden. Insbesondere kannst du damit schon einmal 
sicherstellen, dass jeder Teilnehmer über eine sichere Verbindung zum 
Server verfügt UND dass die Authentizität des Servers verifiziert werden 
kann, die Clients also dem Server vertrauen können.

Sofern es erlaubt ist, dass der Server die übertragenen Daten lesen kann 
bist du hier dann auch schon fast fertig, denn die verschlüsselte 
Übertragung wird ja bereits bereits per TLS erledigt, der Server muss 
also nur noch dafür sorgen, dass die Daten empfangen und dann zum 
richtigen Teilnehmer weitergeleitet werden.

Darf der Server die Daten nicht lesen wird es etwas komplizierter. Hier 
hatte ich in meinem vorigen Vorschlag einen Denkfehler, denn wenn der 
Server als Key Distribution Center arbeitet (also Schlüssel verteilt und 
speichert) kann er ja nach wie vor die Kommunikation mitlesen, wenn er 
möchte. Hier müsste man dann auf Clientseite mit digitalen Zertifikaten 
oder aber z.B. mit Diffie-Hellman-Schlüsselaustausch arbeiten. Letzterer 
ist jedoch ohne weitere Absicherung über Signaturen oder MACs anfällig 
für Man-in-the-middle-Angriffe.

Letztenendes kommt es also darauf an, welches Sicherheitsniveau du 
benötigst und welcher Teilnehmer im System was machen darf. Ist der 
Server vertrauenswürdig und darf alles mitlesen, dann brauchst du im 
Prinzip nur TLS und kannst deine Nutzdaten dann im Klartext darüber 
tunneln.

Daniel H. schrieb:
> Normalerweise kann man hier (Implementierungsfehler mal außen
> vor) nicht viel falsch machen.

Haha!

Nimm du mal OpenSSL her und stricke aus der API was sicheres zusammen.

Das kannst du nicht. Das kann ich nicht. Und niemand sonst hier im 
Forum.

Und deswegen gibt es mittlerweile Libraries mit High-Level-APIs für 
Normalsterbliche wie uns: Keyczar. cryptlib. NaCl.

Beitrag nicht gelesen und/oder nicht verstanden?

Genau von selber Stricken habe ich abgeraten. Das von dir (aus dem 
Zusammenhang gerissene) Zitat bezieht sich allein darauf, dass die reine 
Durchführung der Verschlüsselung einfach ist und man nicht viel falsch 
machen kann wenn man standardisierte Algorithmen wie z.B. AES nutzt. Das 
ist aber eben nicht alles, was man berücksichtigen muss.

Stefan Rand schrieb:
> Nimm du mal OpenSSL her und stricke aus der API was sicheres zusammen.

Wie kommst du auf OpenSSL? Habe ich das irgendwo erwähnt? Ehrlich gesagt 
bist du der erste, der dieses Wort hier im Thread gepostet hast. 
Vielleicht den Beitrag wieder nicht richtig gelesen/verstanden? Dir ist 
schon bewusst, dass ich TLS nur das Protokoll ist?

Stefan Rand schrieb:
> Und deswegen gibt es mittlerweile Libraries mit High-Level-APIs für
> Normalsterbliche wie uns: Keyczar. cryptlib. NaCl.

Und OpenSSL ist eine Low-Level-API oder was? Nur weil du damit nicht 
umgehen kannst heißt das nicht, dass andere es nicht können.

Das nächste mal bitte erst nachdenken, bevor du deine überheblichen 
Worte in die Tastatur hackst.

Sebastian N. schrieb:
> Ist das folgende der richtige Ansatz:

Das sieht schonmal gut aus, aber im Detail habe ich es mir jetzt nicht 
weiter angeschaut.

Daniel H. schrieb:
> Beitrag nicht gelesen und/oder nicht verstanden?

Dafür, daß du keine Ahnung hast, riskierst du aber ne dicke Lippe.

> Genau von selber Stricken habe ich abgeraten. Das von dir (aus dem
> Zusammenhang gerissene) Zitat bezieht sich allein darauf, dass die reine
> Durchführung der Verschlüsselung einfach ist und man nicht viel falsch
> machen kann wenn man standardisierte Algorithmen wie z.B. AES nutzt. Das
> ist aber eben nicht alles, was man berücksichtigen muss.

Haha.

Zeig mal, wie du AES implementierst.

AES ist verdammt schwierig zu implementieren, wenn man Timing-Attacken 
ausschließen will.

> Stefan Rand schrieb:
>> Nimm du mal OpenSSL her und stricke aus der API was sicheres zusammen.
>
> Wie kommst du auf OpenSSL? Habe ich das irgendwo erwähnt? Ehrlich gesagt

Mir war nicht klar, daß du Krypto selbst implementieren willst. Aber daß 
jemand so idiotische Ideen hat, damit muß man auch nicht rechnen.

Und so ziemlich jeder, der nach gut abgehangenen und reviewten 
Krypto-Primitiven mit Bindings in so ziemlich alle Sprachen sucht, nimmt 
OpenSSL. Oder was würdest du nehmen, außer natürlich deinem 
Eigen-Gefrickel?

> Vielleicht den Beitrag wieder nicht richtig gelesen/verstanden? Dir ist
> schon bewusst, dass ich TLS nur das Protokoll ist?

Du bist TLS nur das Protokoll. Soso. Stell die Flasche weg.

> Stefan Rand schrieb:
>> Und deswegen gibt es mittlerweile Libraries mit High-Level-APIs für
>> Normalsterbliche wie uns: Keyczar. cryptlib. NaCl.
>
> Und OpenSSL ist eine Low-Level-API oder was? Nur weil du damit nicht

Ja, ist es.

Sag mal, hast du überhaupt schonmal grob gehört, was NaCl oder Keyczar 
sind und machen?

> umgehen kannst heißt das nicht, dass andere es nicht können.

Ja, ein paar Leute können das. Du und ich nicht.

> Das nächste mal bitte erst nachdenken, bevor du deine überheblichen
> Worte in die Tastatur hackst.

Ich finde es schön, daß ich dich so aufregen konnte.

Mehr als ad-hominem kommt von dir aber eh nicht, deshalb: Tür zu! Von 
außen!

Stefan Rand schrieb:
> Tür zu! Von außen!
Richtig. Zankt euch per PN weiter. Es bringt auch nichts, wenn jeweils 
der Eine den Post vom Anderen meldet...

Hallo,

warum gräbst du den Thread nach neun Tagen wieder aus nachdem hier nun 
Ruhe herrschte?

Ich hab ihm eine PN geschrieben und meinen Standpunkt dargelegt, darauf 
kam seither keine Reaktion, also ist die Sache für mich gegessen, ich 
gehe nach wie vor davon aus, dass wir hier ein massives Missverständnis 
hatten.

Viele Grüße
Daniel