Difference between revisions of "Secure User Identification"

From AMule Project FAQ
Jump to: navigation, search
m (Fixed Typos and Removed Version Tag)
m (Corrected Spelling of Deutsch in language selection)
 
Line 1: Line 1:
<center>'''English''' | [[Secure_User_Identification-de|German]]</center>
+
<center>
 +
'''English''' |  
 +
[[Secure_User_Identification-de|Deutsch]]
 +
</center>
  
 
== What is Secure User Identification (SUI) ? ==
 
== What is Secure User Identification (SUI) ? ==

Latest revision as of 15:25, 4 August 2008

English | Deutsch

What is Secure User Identification (SUI) ?

Clients in the network are identified by a unique value called user hash. This user hash is stored in the preferences.dat file and is used to grant earned credits with other users. aMule (like eMule) can use an asymmetric encryption to avoid exploiting or manipulating other user hash values. The method uses a private and a public key to ensure a correct and unique identification on other clients.

Secure User Identification can be turned on in Preferences -> Connection (since aMule 2.x, version 2.0.3 has it under Preferences -> Security). It is recommended to use it.

The identification process

The following describes how two clients supporting SUI identify each other. If the identification fails, the client which detects the failure should ban the other client.

First aMule start

When you start aMule for the first time, it will create a 384-bit RSA private key (which will be stored in cryptkey.dat). This file should be kept forever, since losing it will make you lose all your credits.

First meeting

When aMule connects to a client supporting SUI, it expects this client to send it's public key (it's user hash) along with a random number, while aMule will do right the same. If the public key it gets is unknown, it will store it in clients.met (only the public key, not the random number) so that it will be possible to identify that client next time it meets it.

Identificating

When a client wants to identify to another client, it will send to this latter client a digital signature created from it's own private key, the public key of the other client and the random value the other client sent.

The other client will do the same.

Validating an identification

When the remote client get's this signature, it will check if it is created from the your public key and the random value it sent, and then check if it suits it's own private key. If both checks succeed, your client will be successfully identified on that client.

Of course, your client will do exactly the same with the digital signature it gets from the remote client.