sichere Verschlüsselung in .net

Gonger96 schrieb:

Unkackbar ist garnichts.

Theoretisch ja, in der Praxis kann man aber sagen, dass Verschlüsselungen bei richtiger Implementierung und guter Stärke unknackbar sind, wenn man es realistisch als Mensch betrachtet.

Grüße

Joa, ich sprach auch von theoretisch. Der Key wird ja immerhin noch vom Speicher begrenzt und ist somit endlich. Praktisch ist wieder ganz was Anderes .

Ich hätte da auch noch mal eine Frage: Welche Funktion haben p und g? Sind das einfach nur zwei zufällig generierte Zahlen von 0-n, oder haben die ine spezielle Bedeutung?

Gonger96 schrieb:

Welche Funktion haben p und g

p muss eine Primzahl sein und g ein Erzeuger einer zyklischen Gruppe der primen Ordnung p. Und nein, ich hab keine Ahnung was das bedeutet.

MVN050 schrieb:

gibt es von MS bzw für .net auch eine Lib mit dem Hellmen?

Jap, hab ich weiter vorne bereits verlinkt.

Ich hab zumindest keins parat, aber ich denke da wird sich leicht was zu finden lassen, sowas ist ja mittlerweile ein Standardproblem der Cryptographie.

Schnapp dir einfach den RSACryptoServiceProvider, sollte das einfachste sein und gibt auch ein Beispiel. Speziell für den Multiserver wäre mir da nichts bekannt, aber es läuft am Ende ja auch bloß auf eine Byteübertragung hinaus.

Problem dabei ist, dass der Client vorher den öffentlichen Schlüssel kennen muss, weil der sonst auf dem Weg manipuliert werden kann. Wenn es wirklich sicher sein muss, wäre meine Empfehlung SSL.
msdn.microsoft.com/de-de/libra….sslstream(v=vs.110).aspx

Thunderbolt schrieb:

SSL

Ist in dem Fall nicht notwendig, weil der öffentliche Schlüssel auch ruhig einem potentiellen Angreifer bekannt sein darf, er kann also vorher auch einfach in Klartext übertragen werden.
Außer natürlich du möchtest auch noch den Client authentifizieren, in dem Fall ist die Verschlüsselung aber in SSL enthalten und eine separate Verschlüsselung ist gar nicht mehr nötig.

Artentus schrieb:

einem potentiellen Angreifer bekannt sein darf

Nein, es geht darum, dass ein Angreifer den Schlüssel auf dem Weg vom Server zum Client verändert und dadurch die, als sicher betrachtete, Verbindung abhören kann.

Genau das bedeutet Authentifizieren.

Ich möchte ja in den seltensten Fällen den Client (verbindungsseitig) authentifizieren. Vielmehr soll die Serveridentität überprüft (authentifiziert) werden. Und bevor man sich etwas (möglicherweise unsicheres) selbst bastelt, greift man lieber auf SSL/TLS zurück.

werft doch einfach nen 4096-Bit starken Schlüssel in den Quellcode des Clients. Der Ist zum einen stark genug um in den nächsten Jahren nicht konventionell gebrochern zu werden(hoffentlich halten sich die Quantencomputer noch ne weile zurück), zum anderen ist dann der Client Authentifiziert. Kanns der Server nicht entschlüsseln, ists kein passender Client. Natürlich kann sich dann jeder zum Server verbinden, aber niemand kann den Schlüssel auf dem Weg manipulieren.

Wie schon gesagt wurde, bei Diffie Hellmann geht es nicht um die Verschlüsselung, sondern um die festlegung zweier Partner (Alice & Bob ) auf einen gemeinnsamen Schlüssel. Dieser könnte dann z.B. für AES benutzt werden.

Meine Idee ist folgende:
Jeder Client hat ein und den selben Public RSA-Key. Nur der Server kennt den Private Key. Dadurch können die Clients dem Server schreiben, und nur der Server kann es auslesen. Was also machen wir damit? Der Client generiert einen zufälligen AES-Schlüssel verschlüsselt ihn per RSA und schickt diesen an den Server. Dieser Schlüsselt das nun auf und "schaltet" auf AES um.
Grob gesagt, ist das ein "kleines" SSL/TLS bei dem Certificate-Pinning angewendet wird(Public Key dem Client im vorraus bekannt).

MVN050 schrieb:

du sagtest doch das erstmal 3 "Schlüsselzahlen" übertragen werden müssen und der Server mit dem "Gemeinsamen Schlüssel" dann seine Daten Verschlüsselt

Hängt halt davon ab, ob du symmetrisch oder asymmetrisch verschlüsseln willst.
Eine symmetrische Verschlüsselung erfordert einen Austausch des Schlüssels, z.B. eben Diffie-Hellman, der recht kompliziert werden kann.
Asymmetrische Verschlüsselungen brauchen das nicht, deswegen empfand ich diesen Weg für einfacher. Hier musst du allerdings u.U. dafür sorgen, dass sich die Verbindungspartner authentifizieren.