[317] Cryption

Hey,

I just wanted to have a small discussion about the way,
the server handles the cryption module..

Since as far i can see the server loads the cryption module twice per client!!!

Now i edited the client to use 1 key instead 1 for incoming 1 for outgoing.

That isn't really needed though as using 2 modules shouldn't be that big of a problem.

But ok here's the deal currently the 317 servers.
generate a key for each new connection.
The client sends it back + a client key + 50 stuff..
So its the server key but increased with 50 yeah ..

We could just remove the whole client sending the keys but oh well..

Lets just keep the client the same.
As the problem lies with the server.

Why not generate 1 key at server startup??
Now for each user store his cryption values seperate.
And before handling a incoming packet set the cryption values to those of the user and run the getNextKey function and then read the values again from cryption into the user values.

so you will only have 1 cryption for incoming and 1 for outgoing.
By editing the client you could set incoming + outgoing to the same key so just 1 cryption module is used :)??

Shouldn't this speed the servers up by a load + save memory ?

Security!
Now so far i can see the security isn't really compromised.
As the opcodes are still random just not per client but per server restart.

its 5:45 am
Well yeah its that time in 15minutes i promised to call my gf to make sure shes awake on time :p.
I didn't feel like sleeping but am tired as hell right now!

Much the same as you, shattered as hell.

Anyway, I really don't like messing around in the clients, though I suppose the time will need to come eventually so we can work out what's going on where!

As for the crytion, you said it was no less secure as before, but I thought was the exact idea of the cryption class, it had to be done to make sure it was secure :ehh:

You may be right, but given that it's been in pservers since the dawn of day, I would be very cautious of removing it without being fully certain that 2 people couldn't end up corrupting eachother somehow. (how this would happen i'm unsure, as technically they have their own socket anyway :|)

Well they still have separate sockets :).
And the cryption will still be used but the key will not rotate as much.

having a static outgoing key that rotates every retart or x hours is definitely okay, but I don't think using hte same incoming key in the client is a good idea. we couldn't change the key unless you pushed a client update to all the users. The incoming key will always be similar to the outgoing key, so set the static key outgoing and working with the incoming key being varied will work fine without any overhead

So just 2 cryption modules ?

wha?what do you mean by two modules?

I just call it modules as of lazy ness :p.
But i guess the english word is instances ?
You load the cryption class twice instead twice for each player.

I may contemplate looking into this, however it won't be on my main priority of things to check, unless anyone has working proof of these concepts :P

Client related cryption, not something i'm so fond of!

Quote:

---

Originally Posted by ThuGie

I just call it modules as of lazy ness :p.
But i guess the english word is instances ?
You load the cryption class twice instead twice for each player.

---

OOOOOOOOOOOHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

Well I think that's stupid as well. Basically what I thought of doing is accociating the client's "cipher" in the player object. I mean, that player corresponds to that client, so it makes sense. I'd have a statically instanced version of the Cipher class and having the keys held by the client object, whether it be in the client class or the player class.

The server key is going to be static from our discussion, so keeping a new instance of the same key wouldn't make much sense anyway. And it's stupid to have an object just for a key, so throw it in where other player values and client information is stored

Ghost it seems you get what i'm talking about :D yay!!
In VB6-Scape i only load the cipher once and store the cipher details per client :).

And for the key it doesn't have to be static just randomize it at server start up before you init the cipher

I think you misunderstand. In Java, the static keyword just means that there can only be 1 instance of that key; we cannot duplicate that object. that's why I like static instancing, only one class object when it's necessary

ah i see and yeah :).
So you agree that the way its being done all this time is wrong ?
And just cpu/memory consuming for no real reason ?

Well a lot of WL things were done wrong, as it was intended on being single-user gamelplay for bot testing. This is just one of the great modernizations that we can do to make it a worthy source. Just to prove it, I'm writing a whitescape source from hell, with proper client managing, an event manger rather than a process thread, and special libararies to simplify my server needs. I'd tell you it, but I wanna get it working before talking shit :p

I'm confused on what is being said in the thread (hey, that rhymes). However, don't explain it to me because you'd just waste your time.

OffTopic:
I haven't had internet for 2 months now and I haven't been able to get any updates as to what has been happening lately. And I also forgot some things with Java. I have been coding a 508 though. Removing this, adding that. Running out of ideas.