-------- Original-Nachricht -------- Datum: Sat, 13 Jan 2007 11:41:21 +0530 Von: Jeethu Rao <[EMAIL PROTECTED]>
> > - Cspace is not decentral, it needs a tachion server for creating an RSA > key and it needs the Cspace-ID for the taychion server to launch the > application. We need to change this. > > > Though there is a hint of truth to what you're saying, its not entirely > true. This is probably the 3rd time I'm explaining this on cspace-users. Hi Jeethu, good to know your not dead here on the list. > The central server is there just to maintain a persistent mapping > between the Public Keys and the key-ids. There was no way we could > implement atomic increments (like an autoincr field in a DB) securely in > the DHT, and thus we had to use a centralized server for this. not understood, do you mean, it is needed to establish a secure dht, then if done, we can get rid of the server? > This does > not compromise the security of CSpace in any way. This one time > registration process with the *cspace-id* can be made optional, and we > haven't made > it yet. Well, till know tachyion does know any Ip adress and any Nicname and any RSA-key for the nickname. This is not at all decentral. We even could not use cspace without tachyion, we are far away to be a gnutella style network. Would it then be possible to create an RSA-Key without a server? So that we seperate bootstrapping the dht and registration/RSA-Key-Creation? I think it is good to have short numbers we can communicate on telephones, but what about a wesite, entering the CSpace ID and getting the RSA-Key back. Then Cspace can work totally without Cspace-ID, and we can use always the RSA-key, the ID-Should be just a helping box, to identify the RSA-Key. Second: would it be possible, to share the RSA-key = Cspace-ID in a match-atabase on the DHT ? So like emule kademlia, I search for the Cspace-ID and get the RSA-Key back out of the DHT, so the match could be made decentral as well. OK Fake Clients then could provide fake matches, but this should be not a problem, as users only do this if they reinstall a system or are on vacations travelling. and if they chat then, they do get the right nic-name from the client or not, this should identify wrong matches. So get rid of this server and be owner of a network, not a messenger. > And the application does not need to connect to the central server, > every time its launched. The central server is only used after creating > a new key pair and while adding a new user with a keyid (you can always > enter the public key directly and avoid the connection to the central > server) > OK, but how, if I cannot launch the application without the cspace-ID and the server is connected... > > - The question for security is as well, if you permit user "sreeram", if > then a fake could use VNC or your PC, so the RSA-Key has to be inserted > into the permission and not the nicname. > > > This simply is not possible because of the following constraints: > All nick names in a users buddy list are guaranteed to be unique > For any new user whose pub key is not in the user's buddy list, > CSpace adds a "unknown-" prefix to his nickname Right, I know, but it would be possible to code a client, which is not interpreting the nic-name to the saved RSA-Key for this buddy, then we would have a problem for this clone. This is why the process has to be, to insert the RSA-Key for permissions. Maybe it is just a gui question to have a window for each buddy to set the permissions or not, or a matrix with radio-butons which sets the permissions for each saved buddy in the buddylist, Ok. This has no priority. In my eyes, as the time is short and sreeram offers no deverlopment to it till now, we neew a real serverless RSA-Creation and implmenetation and if oyu like a so called Csapce-ID-nummer maybe stored in a DHT for getting the RSA-Key match. As the DHT bootstraps. the RSA-Key should be searchable with the Cspace-ID to add buddies. Last idea is to port it to java. you said, that it is not easy to port it woth jython.org to java, but if third party is interested in this, we should et least have the basic work done, which is the Serverless RSA-Key-Creation. As java is now as well open source, jython would be perfect to port the application and then we as well need no linux or other ports. just my 2 cents: Serverless RSA-Launch and java porting. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer _______________________________________________ cspace-users mailing list cspace-users@tachyon.in http://tachyon.in/cgi-bin/mailman/listinfo/cspace-users
