xored schrieb:

Wie sicher das ganze ist, kann ich nicht sagen, der Datenverkehr ist jedoch mit Rijndael verschlüsselt

Rijndael ist ein symmetrisches Verfahren. Das setzt voraus, dass der Schlüssel entweder bekannt ist, oder dem Kommunikationspartner über einen abhörsicheren Kanal übermittelt wird. Du hast dich wohl für die erste Variante entschieden, denn du kompilierst schließlich alle Verschlüsselungsinformationen auf beiden Seiten ein.
Das ist problematisch, denn diese Informationen liegen blank. Mit NET-Assemblies haben wir sogar den Spezialfall, dass der Code zunächst in eine Zwischensprache (IL-Code) übersetzt wird, die noch sehr leicht nachzuvollziehen ist. Mit einem NET-Reflector kann ich mir die Information einfach an der jeweiligen Stelle anschauen und kann dann den Datentransfer problemlos entschlüsseln.

xored schrieb:

Das Passwort im Source würde ich ebenfalls verschlüsseln.

Selbes Spiel. Du kannst deine Verschlüsselungsinformation so oft wie du willst im Source verschlüsseln und zur Laufzeit wieder entschlüsseln, das hat aber nur einen sehr geringen Mehrwert. Auch diese Information liegt wieder im Sourcecode und ist von einem potentiellen Angreifer sehr leicht zu finden.
Leider gibt es immer wieder Fälle bei denen Entwickler versuchen sicherheitskritische Informationen im Sourcecode zu verschleiern und öffnen dadurch ein riesiges Sicherheitsleck in ihrer Anwendung.

Was ich dir versucht habe mit vielen Sätzen zu beschreiben:
Benutze nicht immer wieder aufs Neue den ein und selben Schlüssel, sondern generiere für jede Session einen neuen Schlüssel der dem Kommunikationspartner mitgeteilt wird.
Benutze kein symmetrisches Kryptoverfahren, wenn du keinen zweiten abhörsicheren Kanal hast um den Schlüssel sicher auszutauschen.
Benutze stattdessen besser ein asymmetrisches Verfahren wie RSA, welches auf dem Diffie-Hellman-Schlüsselaustausch basiert, um Daten "sicher" zu übertragen.

Was mir beim überfliegen deines Codes aufgefallen ist, dass du jedes Mal aufs neue Streams erzeugst, nur um genau einen String zu verschlüsseln bzw. entschlüsseln. Ist meines Erachtens nicht wirklich performant und du vergisst auch die Ressourcen der ganzen Streams freizugeben über deren Dispose() - Methode.
Ich hätte wohl für eine Session genau einen AesCryptoServiceProvider und jeweils eine Instanz der für die Implementierung notwendigen Streams angelegt und dann am Ende jeder Session/Programmausführung die Ressourcen freigegeben. Das Problem hier ist wohl, dass du die Kryptofunktionen unbedingt in ein separates Modul auslagern wolltest, weshalb du gar nicht um die Reinstanzierung herumkommst. Du könntest das über eine Klasse regeln, die das kapselt.

Zum eigentlichen Registrierungs -bzw. Loginvorgang kann ich noch ein paar Worte loswerden.
Deine Steuerbefehle kodierst du als Strings, ist jetzt nicht wirklich schön, da das wohl zum Lernen dienen soll ist das ok.
Ich würde mir wohl ein kleines Protokoll überlegen, um das Datenaufkommen zu reduzieren. (Strings wie "/register [...]" sind zwar leserlich aber sorgen gleichzeitig dafür, dass deine Pakete um ein Vielfaches größer sind als sie eigentlich müssten)
Du generierst für jedes Paket einen Zufallsstring, den du Packet-ID nennst. Brauchst du das wirklich? Jede Client-Server-Verbindung erhält doch ihren eigenen Stream und du schickst ja sowieso sequentiell. Datenpakete werden also immer in der richtigen Reihenfolge versendet, kommen auch so an und werden auch so abgearbeitet. Das könntest du ja mal überdenken. Ich habe mir deinen Code nicht viel näher angeschaut, deshalb weiß ich nicht ob du evtl. auf Pakete referenzieren müsstest, sodass ein solches Vorgehen von Nöten wäre.

Ich hoffe ich konnte dir evtl. ein paar Gedankenanstöße liefern, die dich in deinem Vorhaben weiterbringen.
Vielleicht haben meine geistigen Ergüsse ja auch zur Diskussion angeregt, wer weiß

xored schrieb:

Danke dir, aber ich arbeite eigentlich nur mit c++

Das hat ja nichts mit der Programmiersprache zu tun. Es ging hier nicht um Syntax, sondern um Semantik. Ich bemängele dein Verfahren.

xored schrieb:

werde dieses Projekt wohl nicht weiterführen. Für leute die das brauchen, die können das natürlich verwenden

Das ist schade. Die Implementierung öffnet Angreifer Tür und Tor, wenn ein solches Programm publiziert wird. Editiere deinen Post wenigstens dahingehend, dass du darauf aufmerksam machst wie unsicher das Ganze ist. (am besten in Caps, fettgedruckt und knalliger Farbe)