Betriebsystem

[ciruZ]

Hm, meine Linux Distribution ist nicht in der Liste drin und OpenBSD fehlt auch (Laptop).

Bis auf (unter anderem) BSD...

Geht bestens mittels compat_linux.

Warum denn noch ein Decoder? Der aktuelle Linux Decoder klappt doch gut. Und n GUI ist nur lästig. Beim CLI macht man sich einfach ein Script und braucht nur noch otr *.otrkey tippen.

PS: Warum fragen, welche Distribution? Source .tar.gz machen, dann können die Distributionen selber Pakete bauen. Und jeder kanns aufs Betriebssystem seiner Wahl portieren. Ne native OpenBSD Binary wär schon besser als das original Ding mittels compat_linux.

[ciruZ]

Das Verfahren heißt Blowfish und lässt sich überall nachlesen. Es werden lediglich ein paar Blöcke getauscht. Und den Key gibts vom OTR Server nach ner Anfrage via HTTP an ein PHP. So, jetzt hab ich gesagt, wies geht, jetzt is nix mehr mit Security by Obscurity, der Source kann raus . Security by Obscurity hat eben noch nie funktioniert. Erst recht, wenn die Binary überhaupt nicht gegen Disassemblen und Debuggen geschützt ist.

Der OTR Decoder läuft übrigens schon seit Jahren über compat_linux.

PS: Wo kann man deine BSD Version finden?

[JennyMiller]

Das Verfahren heißt Blowfish und lässt sich überall nachlesen. Es werden lediglich ein paar Blöcke getauscht. [...]

So weit nichts Neues, die Frage ist nur, wie die Blöcke verwürfelt werden ;-) Und die neue Key-Abfrage hab ich auch noch nicht kapiert. Beim alten Decoder wurde ja einfach der Dateiname übermittelt und es gab den Key zurück. Beim neuen sind das vermutlich irgendwelche Hashes. Den ganz neuen Decoder hab ich noch gar nicht ausprobiert

[ciruZ]

Dannn heißts halt den neuen Decoder abwarten und den durch nen Disassembler jagen und anschließend was als OpenSource schreiben. Gut, daß wir nicht in Amerika sind, da dürfte man sowas nicht .

[undo]

PS: Wo kann man deine BSD Version finden?

Nirgends :). Ich habe den auf die Schnelle gestrickt und solche Dinge wie Benutzername und Kennwort stehen fest im Code drin. Weil ja jetzt bald das neue Verfahren kommt, mache ich mir nicht mehr die Mühe, den alten Dekoder zu veröffentlichen.

[Mr. S]

Bitte einmal lesen:
http://www.otrforum.com/showpost.php...40&postcount=2
http://www.otrforum.com/showthread.php?t=20057

@ciruZ
Ich weiss wie leicht es ist den OMR-Decoder zu hacken, man hat mir das einmal eindrucksvoll demonstriert! Nur beachte bitte einmal den Schaden den du verursachst, wenn du Leuten die Möglichkeit gibst, zu dekodieren ohne das Verfahren einhalten zu müssen! Dann wird OTR nämlich illegal. Daraus resultieren Klagen und Ermittlungen gegen die Betreiber und die Nutzer. Bei Tauschbörsen werden ja auch nicht nur die Betreiber sondern auch die Nutzer verklagt. Ich halte normalerweise auch nichts davon Closed-Source zu benutzen, aber in diesem Fall geht es erst einmal nicht anders!

[ciruZ]

Der Source ist doch eh nicht das Problem. Jeder, der nen Sniffer bedienen kann, merkt: Einmal die Antwort vom Server abfangen, nen eigenen HTTP Server aufsetzen der die selbe Antwort zurück gibt und in der /etc/hosts (die Hosts-Datei gibts auch unter Windows!) den Host von OTR auf 127.0.0.1 legen. Für den HTTP-Server reicht sogar schon netcat. Hab ich selber schon gemacht, als mein Rechner instabil lief, damit ich die Files auf jeden Fall dekodieren kann.

Man sieht, OpenSource würde nichts daran ändern, daß jemand, der will, einfach seinen eigenen OTR Server aufsetzt. Es könnte sogar jemand einen öffentlichen Server aufsetzen, auf dem alle Keys gesammelt werden. So ne Seite könnte sogar die Hosts-Datei anbieten und beschreiben, wie man sie installiert, sodaß es wirklich jeder hinkriegen würde.

Das Problem ist wie man sieht garnicht der Source, sondern vielmehr das Verfahren an sich. Man sollte sich da einfach ein besseres Verfahren überlegen. Z.B. so:

Jeder User kriegt einen Pubkey und einen privaten Key. Den privaten Key hat nur der User. Der Server hat alle Pubkeys. So, wenn der User jetzt eine Aufnahme macht, dann wird die ID des Pubkeys des Users in eine Liste getan. Anschließend wird das ganze mit nem symmetrischen Algorithmus (z.B. AES) verschlüsselt. Der Key vom symmetrischen Schlüssel wird anschließend mit RSA verschlüsselt - einmal für jeden User, der aufgenommen hat.

Auf diesem Wege kann ein User das File nur entschlüsseln, wenn er es wirklich aufgenommen hat und der AES Key mit RSA für seinen privaten Key verschüsselt wurde. Das ganze könnte man z.B. via GPG lösen. Das File kann man jetzt natürlich auch noch mehrmals entschlüsseln, allerdings wird es doch bedeutend weniger Leute geben, die tatsächlich ihren privaten Key weitergeben. Und die Login-Daten kann man auch jetzt weitergeben und so wen anders auch noch Dekodieren lassen (2x Dekodieren geht ja immer).

[undo]

Klingt gut, hast du mal n Link dazu?

Sorry, bin gerade vor ein paar Minuten aus dem Urlaub nach Hause gekommen und muß mich erstmal ums Auspacken und ein Abendessen kümmern :). Aber Google findet zu dem Thema einige sehr interessante Publikationen.

Wenn das wirklich so geht, dann könnte man das ganze eigentlich sogar OpenSource machen :).

Absolut. Das ist auch mein Ziel.

[Taube]

Die Mehrleistung wäre minimal. Es wird ja nur der AES key mit RSA für mehrere Keys verschlüsselt. D.h. es wären ein paar Byte, die für jeden User, der aufgenommen hat, einmal verschlüsselt würden. Das dürfte von der Zeit her garnicht auffallen, die dürfte dafür draufgehen, das eigentliche File mit AES zu verschlüsseln.

Und was ist mit der Wishlist?

[Raus]

Und was ist mit der Wishlist?

Ergänzend: Und mit den Mirrors wäre dann Schluß?

Oder verstehe ich hier grundsätzlich was falsch?