SI (RSA-CIDE) / CIDE und eMule und eMule Mod's ?

[stern]

Was ist den jetzt in eMule Orginal Integriert worden ?

was kommt in Orginal eMule ?


welcher eMule Mod Unterstützt was ?



Diese Fragen Stelle ich weil Mandroid in LC jetzt CIDE nutzt.

und damit ich nicht 2 oder Dreimal von neuen anfangen muss mit Credit sammeln.

[Xman]

ganz einfach:
alle Mods und original haben in den neuen Versionen SI. (Ausnahme plus Mod)

LC und enkeyDEV benutzen neben SI auch noch CIDE.

Angaben ohne Gewehr (liegt im Waffenschrank)

[Usul]

Man sollte natürlich in diesem Atemzug auch erwähnen, das die meisten (oder sogar alle?) CIDE-Mods die normale SUI-Methode nicht mehr akzeptieren. Des weiteren wird es CIDE so schnell nicht im Original-Emule geben, die Entwickler behalten die Sache aber im Auge. Ich freue mich jetzt schon. Da kommt endlich mal in der offiziellen Version sowas wie eine Leecher-Prävention rein, und dann kommen die Modder und wollen alles noch viel besser und sicherer machen, aber dafür inkompatibel. Tolle Sache, echt . Trägt natürlich wunderbar zur Verwirrung bei, und schuld sind natürlich wieder die anderen.

Edit: Ich gebe hier niemanden die Schuld für irgendetwas, aber so, wie es jetzt ist, SUI und CIDE inkompatibel, ist es einfach nur Sch***e, egal, wem man die Schuld geben will.

[Vip2002]

Usul,

das ist interessant, ich hatte CIDE als Erweiterung verstanden.
Ist es wirklich so, dass CIDE inkompatibel zu SUI ist?

Wenn ich CIDE nutze ist mir klar, dass nur CIDE Clients bei mir Credits erwerben können. Das finde ich absolut sinnvoll. Wenn ich Dich richtig verstehe können aber Clients, die nur SUI unterstützen mich in diesem Fall eindeutig identifizieren.

Sprich obwohl sie SUI haben erkennen Sie meinen key nicht als meinen, weil ich CIDE einsetze.

Das wäre nicht so gut, denn aus meiner Sicht der einzige Grund einen Mod mit CIDE einzusetzen wäre der, dass nur noch secure Clients Credits erwerben können. Aus meiner Sicht ist in diesem Punkt SUI zu vorsichtig, wenn schon ein Schritt in diese Richtung, dann mit allen Konsequenzen!

[Usul]

Vip2002,

Fakt ist auf jeden Fall, wenn du einen CIDE-Client benutzt und ein SUI-Clients sich bei dir authentifizieren will, klappt das nicht, er wird als nicht authentfiziert geführt, wie ein pre0.29b-Mod auch. Allein das ist schlimm genug, da die meisten noch kein CIDE haben (und auch nicht haben werden, da es ja nicht so schnell im Original drin sein wird). Alle, die sich extra wegen SUI nen neuen Client gezogen habe, weil der sicherer ist, werden von CIDE wieder abgewiesen.

Wie die Kompatibilität andersrum ist, weiß ich jetzt nicht genau, ob du dich mit CIDE bei einem normalen SUI-Client sicher authentifizieren kannst.

Hab nochmal auf emule-project nachgeschaut, aber nichts genaues gefunden. Hat aber für mich den Anschein, das man sich mit CIDE gegenüber SUI-Nutzern authentifizieren kann. Dann wäre es aber ebenfalls etwas unfair, da man dann mit CIDE bei denen Credits sammeln kann, aber die SUI-Clients können bei CIDE keine Credits sammeln.

[Edol]

Usul, das ist nicht der Fall.
Triffst du mit CIDE auf einen SUI Client ------> Identifikation neg., kann keiner von beiden beim jeweils anderen Credits sammeln

[Usul]

Zitat von Edol

Triffst du mit CIDE auf einen SUI Client ------> Identifikation neg., kann keiner von beiden beim jeweils anderen Credits sammeln

Wenn das so ist, ist das ja der dümmste aller möglichen Fälle, keiner hat was davon.

[-jester-]

eDEV
The enkeyDev team decided to convert the authentication system of CIDE to RSA SecureHash's. The result is a protocol compatible with 29b/29c with some critical constraints added. *THIS* will be easier to implement in the official version...

Basically the RSA-CIDE fixes the SecureHash implemented in 29b/29c by requiring:

USERHASH = MD4(PUBLIC_KEY)

So, should someone try to use another's userhash, he'll also have to use the same public key, but this way he will not be able to authenticate for he has not the private key to do it.
Other changes take care of:
- create anyway the public key, if it does not exist (also with auth disabled)
- changing the current userhash accordingly to the new rule (this reset also your credits towards other users)
- deleting previously saved public keys (assigned to untrustable userhashes - old method)
- other minor changes
In the verbose log you will see old 29b/29c emules identifying, but not passing the userhash check. The public key will be temporarily used and finally deleted. This is normal: since they have untrustable userhash they cannot have credits.

Aber:

eDEV
Another note: if you launch RSA-CIDE once, your userhash will be changed and your public key created (if necessary). Further execution of ANY 29b/29c standard emule (non RSA-CIDE) will allow you to be authenticated also towards RSA-CIDE clients. Your new userhash will grant it. Of course this delete your credits.

[Anonymous]

hab ja letzte woche schon geschrieben das es mist ist wenn jetzt zweigleisig entwickelt wird und sich beide systeme untereinander ausschließen.

[stern]

eDEV, welches die enkeyDev mannschaft entschied, das Authentisierungssystem von CIDE in RSA SecureHashs umzuwandeln.

Das Resultat ist ein Protokoll, das mit 29b/29c mit einigen kritischen addierten Begrenzungen kompatibel ist.

* DIESES * ist einfacher, in der amtlichen Version einzuführen...,

Im Allgemeinen regelt das Rsa-cide das SecureHash, das in 29b/29c eingeführt wird,

in dem er erfordert: USERHASH = MD4(PUBLIC_KEY) so, jemand versucht,

eines anderen userhash zu benutzen, muß er auch den gleichen allgemeinen Schlüssel verwenden,
aber auf diese Weise, das er nicht in der Lage IST,

für ihn zu beglaubigen, hat nicht den privaten Schlüssel zum Tun er.

Andere Änderungen kümmern um:
- verursachen Sie irgendwie den allgemeinen Schlüssel, wenn es besteht nicht (auch mit dem auth gesperrt)
- das gegenwärtige userhash zur neuen Richtlinie (dieses Zurückstellen auch Ihre Gutschriften in Richtung zu anderen Benutzern) dementsprechend ändernd

- die vorher gespeicherten allgemeinen Schlüssel löschend (zugewiesen untrustable userhashes - alte Methode)

- andere geringfügige Änderungen im ausführlichen Maschinenbordbuch sehen Sie alte emules 29b/29c zu kennzeichnen,
aber die userhashüberprüfung nicht zu führen. Der allgemeine Schlüssel wird vorübergehend verwendet und gelöscht schließlich.

Dieses ist normal: da sie untrustable userhash haben, können sie nicht Gutschriften haben.




eDEV
eine andere Anmerkung: wenn Sie Rsa-cide einmal ausstoßen,
wird Ihr userhash geändert und Ihr allgemeiner Schlüssel verursacht (wenn notwendig).
Weitere Durchführung JEDES Standardemule 29b/29c (nicht Rsa-cide) erlaubt Ihnen, in Richtung zu den Klienten Rsa-cide auch beglaubigt zu werden.
Ihr neues userhash bewilligt sie.
Selbstverständlich diese Löschung Ihre Gutschriften.

übersetzt mit Google .de

[cyrex2001]

hier ist auch noch ein thread dazu!
cyrex2001

[stern]

cyrex2001,

hier wollte ich ja auch nur wissen welcher mod was hat.

und somit fallen die beiden leider erstmal raus:

LC Neuste Version und die von DEV

[cyrex2001]

Zitat von stern

Was ist den jetzt in eMule Orginal Integriert worden ?

sui!
Ornis+ hat dazu, auch schon was gepostet!
cyrex2001

[Edol]

Zitat von stern

und somit fallen die beiden leider erstmal raus:

LC Neuste Version und die von DEV

Wieso fallen die beiden raus?
Wenigstens bei LC gibt es die Möglichkeit CIDE zu deaktivieren, es würde mich wundern, wenn es die Möglichkeit nicht auch bei Dev geben würde.

[Vip2002]

Hier wird einiges durcheinander geworfen
CIDE ist nicht gleich RSA-CIDE

RSA-CIDE ist, wie mir jetzt erklärt wurde nur eine Erweiterung von SUI, die sicherstellt, dass nur der rechtmässige Inhaber des hashes diesen auch registrieren kann.

CIDE wird auch von den Developpern nicht mehr unterstützt.
Ich persönlich bin mittlerweile vom Konzept RSA-CIDE überzeugt und hoffe, möglichst viele Modder oder noch besser die offizielle Version würde es integrieren.

Der LamerzChoice unterstützt übrigens RSA-CIDE, nicht CIDE