Suche Unterstützung für verschlüsselten p2p Chat

[MaxUpload]

Hi liebe Progger,
kennt sich jemand mit p2p Chats aus? Ich habe eine Verschlüsselung entwickelt die ich gerne in einen Chat integrieren würde, nur leider fehlt mir immo noch da know how um so einen Chat umzusetzen. Lediglich eine normale Client Server Lösung würde ich gerade noch so hinbekommen wenn ich mich ein wenig mehr mit Threads befasse. Ich würde jedoch eine p2p Lösung bevorzugen, also wenn jemand weiterhelfen kann wäre ich sehr dankbar.

P.S.: Ideal wäre C# gern auch mit Hilfe von NET Klassen, aber C++ wäre natürlich auch OK.

Anbei ein Screenshot von einer Simulation wie das Ergebnis mal aussehen soll. Natürlich würde auch nicht dagegen sprechen diese Verschlüsselung in den eMule IRQ einzubauen.

MfG

Max

[tHe WiZaRd Of DoS]

Sofern du nur Client<--->Client chatten willst bietet es sich doch an einfach direkt einen Socket aufzumachen und darüber auszutauschen?
Oder brauchst du die Möglichkeit nach Clients zu suchen?

Da würde es sich anbieten ein Clientregister via Server zu machen und dann auf o.g. System umzusteigen sobald ein Chatpartner gewählt wurde.
Verstehe grade nicht wozu du das willst... btw. gibt es schon fertige Messenger, die du dir evtl. ansehen könntest: CryptoCat, Bitwise IM, Chatsecure, GAIM, Retroshare, ...

[MaxUpload]

Also wenn ich mal so über deine Worte nachdenke hast du wohl recht für's erste macht eine Client <->Client Direktverbindung mehr Sinn. Mein Ziel ist es ja einen Chiffrier - Algorithmus auf seine Sicherheit zu testen bzw. denn Schlüsselaustausch überhaupt ersteinmal zu entwickeln. Mein erster Gedanke war das in einen p2p Client einzubauen um eine möglichst große Userzahl als Tester zu erreichen, aber bei näherem darüber nachdenken werden dann wohl so Sachen wie:

"Dein Algorithmus ist völlig unsicher ich habe mich mit Remote - Desktop auf den Rechner meines Kumpels gehackt ( ) und konnte alles mitlesen." ...bei rauskommen.

Ausserdem habe ich dann mehr damit zu tun die p2p Verbindung sicher zu machen als mich auf das wesentliche nämlich die Chiffrierung zu konzentrieren.

Wenn das dann alles fertig ist und vielleicht ein paar Liebhaber gefunden hat kann man immernoch darüber nachdenken es in einen p2p Chat zu integrieren und dann wahrscheinlich sinniger weise eher in einen vorhandenen einzubauen.



Also benötige ich nur noch ein paar fähige Tester die den Algorithmus testen...also versuchen ihn zu knacken. Da denke ich dann aber doch eher an ein paar Hacker, als an eine riesen Comunity.


Trotzdem danke erstmal für deinen Denkanstoß.

MfG

Max

[tHe WiZaRd Of DoS]

Also grade in eMule dürfte sich das recht leicht integrieren lassen... du brauchst ja nur ein Flag dass dein Chat unterstützt wird und evtl. deinen PublicKey (oder du schickst bei Support als erste Message den Key) und dann kann es losgehen.
Ich weiß natürlich nicht wie genau das momentan ablaufen soll, aber das wäre IMHO so machbar.
Hackbar? Kommt auf den Algorithmus an.

[MaxUpload]

OTP mit Private Key.....soweit so gut und auch nichts Neues....die Private Keys werden verschlüsselt ausgetauscht und das ist das eigentliche Sicherheitsrisiko, also die eigentliche Herausforderung. Ich habe da eine gute Idee wie das sicher funktionieren könnte und möchte die einfach mal testen. Das war's dann eigentlich auch schon, also ansich recht unspektakulär. Ein sicherer Austausch der Schlüssel ist genau genommen das einzig Spektakuläre an der Geschichte.

[tHe WiZaRd Of DoS]

Aha, jut... wie gesagt, der Muli würde sich anbieten

[MaxUpload]

Wenn es soweit ist würde ich mich sehr über eine Kurzeinweisung freuen .
Wird Emule überhaupt noch genutzt? Die einschlägigen Foren sind ja so ziemlich Tod. Ich glaub die Jugend von heute shared anders . Oh, man ich glaub wir werden alt.

MfG

Max

[MaxUpload]

OK ein einfacher Client to Client Chat steht...dann werde ich mich morgen mal an die ganz harte nuss machen und das protokoll für den schlüsseltausch auf die beine stellen. ich darf nur meine informatik klausur nicht aus den augen verlieren, nicht das ich die vergeige vor lauter proggerei.

mfg

max

[MaxUpload]

OK der Chat läuft...weitere Screenshots gibt's unter Twitter. Er ist leider noch recht benutzerunfreundlich, das liegt hauptsächlich am UDP Protokoll. Bis jetzt muss man die Schlüssel von Hand Synchronisieren. Hört sich zwar wilder an als es ist man baut mit beiden Clients eine Verbindung auf und dann initialisiert einer von beiden die Schlüssel - Synchronisation. Da UDP nicht verbindungsorientiert ist weiß ich gerade nicht so wie ich anders feststellen könnte das beide Clients miteinander verbunden sind, außer der User sagt es halt indem er auf Sync Key klickt. Das ist zwar OK wenn beide Clients auf einem Rechner laufen, aber für die Inet Variante brauch ich noch was anderes.

Wenn ich keine Lösung finde werde ich wohl den Client auf TCP umstellen. Da kann ich ja dann den Socket einfach abfragen ob er connected ist.

MfG

Max

[tHe WiZaRd Of DoS]

UDP bietet sich da ja nicht grade für an, da geht ja auch leicht was verloren.
Andere "sichere" Chats (z.B. in Jitsi) machen es ja auch so: man verbindet sich und sync'ed dann die Keys, natürlich erst nach Sync ist die Verbindung dann auch wirklich sicher.

[MaxUpload]

Der Chat war ja nur eine Testumgebung für die Sicherheitsfunktionen. Ich hatte erst die Leetsocket Klasse genutzt da dort bereits einige Filesharing Komponenten wie Chunk Verwaltung enthalten sind, aber der Klassencode war mir dann doch ein wenig zu Beta um damit sinnvoll testen zu können. Den UDP Chat hatte ich noch rumliegen . Aber es sollte nicht das Problem sein den auf TCP umzustellen und dann kann man sagen

if(sock.isConnected){Sync_Key();}

Also jetzt erstmal auf TCP umstellen.
Dann auf der Empfängerseite(Server) auf Multithreading umstellen, damit man auch mit mehreren Clients gleichzeitig chatten kann.
Und zu guter Letzt muss dann ja spätestens noch ein Passwortschutz rein und das senden von Nicknames unterstützt werden.

Oha das ist noch ne Menge Arbeit.

Aber ich denke bereits jetzt lässt sich der Text nicht decrypten. Was natürlich bleibt ist die Möglichkeit die Verbindung zu stören um den Chat unbrauchbar zu machen und die Datenpackete so zu manipulieren das auf der anderen Seite nur noch unbrauchbarer Müll ankommt.

Das wird sich wohl nie zu 100% verhindern lassen, aber evtl. kann man bis zu einem bestimmten Grad eine Fehlerkorrektur einbauen.



MfG

Max

[MaxUpload]

Hallo,
es ist soweit die erste Beta ist fertig. Bitte beachtet für den Download das Bild im Anhang, damit ihr nicht auf irgend welche Werbebanner reinfallt (Sorry, einen besseren Hoster habe ich auf die Schnelle nicht gefunden.)

File-Upload.net - OTP-Chat.zip

Ich weiß noch nicht ob ich den Chat tatsächlich selbst in Emule einbauen werde, aber wenn die ersten Probleme behoben sind werde ich auf jeden Fall den Source Code zur Verfügung stellen, damit sich die Emule Modder richtig austoben können .

P.S.: Ich würde mich über jedes Feedback freuen, besonders über sicherheitsrelevante Probleme welche ihr glaubt gefunden zu haben.

Viel Spaß damit...euer Max

[aalerich]

Zitat von MaxUpload

Mein Ziel ist es ja, einen Chiffrier - Algorithmus auf seine Sicherheit zu testen ...

Autsch!

Der Algorithmus ist Deine Entwicklung? Respekt!
Aber in jedem Falle ist ein Einsatz im Muli völlig ungeeignet, seine Sicherheit zu testen. Daß die Implementierung technisch funktioniert hat ja nichts mit der Sicherheit der Verschlüsselung zu tun. Genau genommen glaube ich nicht, daß Du überhaupt die Möglichkeit hast, die Sicherheit des Algorithmusses wirklich zu testen. Die ganz wenigen freien (also nicht für die verschiedenen STASIs arbeitenden) Fachleute haben wohl weder Zeit, noch Lust, einen von Dir entwickelten Algorithmus halbwegs gründlich zu prüfen. In der Zeit, in der sie Deinen Algorithmus prüfen, können sie mit anderen Sachen eine Viertelmillion verdienen ...

Nimm einen etablierten Algorithmus.

Liebe Grüße
aalerich

[MaxUpload]

Hi aalerich,
dass der Algorithmus zeitnah in eMule eingebaut wird halte ich ebenfalls mittlerweile für unlogisch.

Zeitverschwendung ist es jedoch nicht, da Kryptografie und Chiffrierung Gegenstand meines Studiums ist und das Thema sehr theoretisch ist finde ich diese praktische Anwendung sehr nett zur Auflockerung und Befeuchtung dieses doch sehr trockenen Stoffes.
Der Chat findet bei mir auf Arbeit sehr viel anklang, da er quasi nicht installiert wird. eine kleine 56k große EXE und man kann ungestört zwischen den Büros kommunizieren.

Ich denke es wird ein kleines Chat Tool werden mit sehr privaten Chat Rooms in welchen Filesharing zwischen den Clients untereinander und/oder mit Daten auf einem Server möglich sind.

Wir haben viele Programmierer die oft kleine Programme austauschen müssen was momentan hauptsächlich über VPN passiert. Ich persönlich halte VPN z.B. in China nicht für sonderlich sicher, aber das ist meine persönliche Meinung.
Genauso sehe ich das bei etablierten Algorithmen. Nehmen wir z.B. RAS welches theoretisch nur mit enormen Rechenaufwand knackbar ist. Praktisch schrupft dieser Rechenaufwand jedoch auf ein handelbares Maß, wenn ich davon ausgehe (wovon ich ausgehe) das z.B. der NSA die Algorithmen für die Erzeugung dieser Zufallszahlen infiltriert hat.

Natürlich wird auch mein Chat keine Sicherheit gegen Geheimdienste liefern, da ich davon ausgehe, dass man Microsoft nicht umsonst finanziell unterstützt hat und eh auf dem Bildschirm mitlesen kann, also wozu entschlüsseln wenn ich direkten Zugriff auf den Desktop habe.

Selbst wenn jemand den Aufwand betreibt und ein eigenes kleines Betriebssystem kreiert nur um einen sicheren Kommunikationsweg zu haben... wer sagt uns denn das die Hardware Made in USA nicht schon längst entsprechende Backdoors liefert.


Also lange Rede kurzer Sinn, es wird keine Sicherheit gegenüber irgendwelchen Geheimdiensten geben welche bereits in sämtlichen Herstellerfirmen Einfluss nehmen.

Bestenfalls kann man sich gegen irgendwelche Skriptkiddies oder 0815 Hacker eines Konkurrenzunternehmens schützen.

MfG

Max

[aalerich]

Hallo Max,

ok, wenn das eines Deiner Studienthemen ist, dann kannst Du ja auch Meinungen von Fachleuten einholen, die qualifiziert einen Algorithmus beurteilen können.

Und was Deinen sonstigen Pessimismus angeht: Ganz so übel sehe ich es noch nicht. Die Hardwareinfiltration läuft ja nicht direkt beim Hersteller, sondern die Hardwarelieferung wird auf der Straße abgefangen, die Geräte werden verseucht und dann an den Empfänger geschickt. Wenn AVM also in China fertigen läßt, können wir uns wohl noch relativ sicher fühlen.

Snowden hat sich mal darüber geärgert, daß er trotz allem unverschlüsselte emails bekommt. RSA ist der Standard für Mailverschlüsselung, seine Frustration über die Ignoranz seiner Mitmenschen wäre sinnlos, wenn es ein einfaches Einfallstor gäbe. Insofern halte ich RSA für einigermaßen sicher.

All die kühlen Windows 7-Nutzer mögen doch mal in der Liste der Dienste nachsehen, was der Dienst "Software Protection" schönes macht. Und zwar ganz offen, völlig unverhohlen ... Dennoch wird das Mitlesen nicht so ganz einfach sein, denn die Daten müssen ja irgendwie zur STASI. Bei Daten, die von uns gewollt versandt werden, ist das kein Problem, die werden auf dem Wege irgendwo abgefangen. Wenn Rechner aber ungebeten zu telefonieren anfangen, wird es schwierig.

Und prinzipiell sollten wir nicht so einfach resignieren. Ein klein wenig kann man immer machen. Z.B. Mülldaten erzeugen. Es gab mal ein kleines Progrämmchen, das sinnlose Zeichenfolgen in google eingab und alle aufgelisteten Seiten besuchte, um die Festplatten der Spitzel mit "(Vorrats)Daten" zu füllen. Leider lief es nicht stabil, aber die Idee fand ich witzig.

Wie dem auch sei, ich denke, da geht noch so einiges. Man kann den Spitzeln das Leben schon noch deutlich erschweren.

Liebe Grüße
aalerich