Server Help

ASSS Questions - Friction?

Anonymous - Sun Apr 18, 2004 3:07 am
Post subject: Friction?

Any chance on setting an ambient friction level? That could be useful in some servers...

Qndre - Sun Apr 18, 2004 11:02 am
Post subject: Re: Friction?

HackSlasher wrote:

Any chance on setting an ambient friction level? That could be useful in some servers...

Not yet, but already made a (useless) suggestion. Priit won't implement such a function in his client although I've already written a piece of code which would do it. Look at this thread:

https://forums.minegoboom.com/viewtopic.php?t=2321

My client will come out in some times (maybe a year or two) and it will be highly customizable. So with that client you'll be able to write a plugin and include it (and force users without that plugin out).

Cyan~Fire - Sun Apr 18, 2004 2:47 pm
Post subject:

The only problem is that your code is in a different language than Continuum.

Qndre - Mon Apr 19, 2004 8:30 am
Post subject:

Cyan~Fire wrote:

The only problem is that your code is in a different language than Continuum.

Different language? Isn't Continuum written in C? The real problem is that it would take a client change.

Well, you could use it with my client, if it's a bit successful if it's completed (it isn't yet)! I'm also writing an enhancement for subgame2 which would allow Metaspace encryption but force VIE clients out without changing subgame2 itself (yes - I've already written another (optional) encryption - it has a key length of 48960 bit - that's very strong). The enhancement will come in a kind of "overlay-plugin" which modifies the network packets sent by subgame2.

Mine GO BOOM - Mon Apr 19, 2004 10:23 am
Post subject:

Qndre wrote:

it has a key length of 48960 bit - that's very strong

So you know, key length is not a good indicator of the strength of an encryption. If you made a key length of 1 million bits, but all it did was XOR with the data, its insanely weak. If you have a key length of 1024 bits, but the formula for this encryption was well proven in math and theory, then the encryption is very secure.

Before you attempt to make your own encryption, I seriously recommend you read a bunch of books on encryption and take a few very high level math courses. Making a new encryption is harder than hacking someone else's, as you have to find every possible way your own encryption could be attacked, including things most won't ever look for, like a flawed random number generator (Netscape's SSL was attacked this way a while ago).

Cyan~Fire - Mon Apr 19, 2004 5:44 pm
Post subject:

You wrote your friction function in C-script. Continuum is written in C++. It's like saying Java and Javascript are the same language.

Smong - Tue Apr 20, 2004 9:20 am
Post subject:

The piece of code is not for ctm anyway, it's for metaspace.

Cyan~Fire - Tue Apr 20, 2004 5:48 pm
Post subject:

Qndre wrote:

Priit won't implement such a function in his client although I've already written a piece of code which would do it.

Mr Ekted - Tue Apr 20, 2004 6:10 pm
Post subject:

Yes, as if someone could even come close to writing drop-in code for a system they have never seen.

Mine GO BOOM - Tue Apr 20, 2004 10:47 pm
Post subject:

Mr Ekted wrote:

Yes, as if someone could even come close to writing drop-in code for a system they have never seen.

Priit did pretty damn good for Subgame, but then again, he understands computers, machine code, network design, and at least can make a Hello World in C that doesn't require a 11meg runtime file download.

Mr Ekted - Wed Apr 21, 2004 12:06 am
Post subject:

I wasn't talking about Priit, I was talking about Qndre's friction code.

Dr Brain - Wed Apr 21, 2004 9:32 am
Post subject:

Oh No! MGB is taking up Qndre's habbit of quoting things and saying something totally unrelated in his post.

Mine GO BOOM - Wed Apr 21, 2004 10:19 am
Post subject:

He said someone, which did not imply any specific person. Just wanted to mention that it is possible, though improbable, that Qndre can succeed.

Mr Ekted - Wed Apr 21, 2004 2:22 pm
Post subject:

I was replying to:

Qndre wrote:

Priit won't implement such a function in his client although I've already written a piece of code which would do it.

Qndre - Thu Apr 22, 2004 11:23 am
Post subject:

Mine GO BOOM wrote:

So you know, key length is not a good indicator of the strength of an encryption.

Yes. My encryption takes a value, leftshifts it several times and then upshifts it (every result of a leftshifting or upshifting is taken as a part of the new key). It uses feedback and finally (if key seems to become too periodic) is does something like "x²" (while x is an 8-bit value taken out of the key). You get a very very unperiodic keystream but it's just "data xor keystream xor feedback".

Mine GO BOOM wrote:

it is possible, though improbable, that Qndre can succeed

With the CTM encryption probably not but it's becoming a very very good VIE client. Already developped a DLL plugin interface (like MERV has) to use the client as a BOT as well.

Mr Ekted - Thu Apr 22, 2004 3:52 pm
Post subject:

Qndre wrote:

...something like x squared...

Note that multiplication in encryption is bad. Every time either value has a lower bit of zero, you are forcing zeros to shift into the right side. So after 8 multiplies, the lower byte is all zero, effectively reducing the key size. I suggest you stick with addition/subtraction, xor, and table lookups.

D1st0rt - Thu Apr 22, 2004 6:05 pm
Post subject:

Mine GO BOOM wrote:

at least can make a Hello World in C that doesn't require a 11meg runtime file download.

I love that

Qndre - Fri Apr 23, 2004 11:11 am
Post subject:

Mr Ekted wrote:

[..]
Note that multiplication in encryption is bad. Every time either value has a lower bit of zero, you are forcing zeros to shift into the right side. So after 8 multiplies, the lower byte is all zero, effectively reducing the key size. I suggest you stick with addition/subtraction, xor, and table lookups.

Yes... I always look at the result of my keystream generator to check if there is a pattern which makes obvious how the encryption works or would make the encryption weaker or the key easier to guess. It doesn't have an obvious pattern at the moment.
_
The key itself doesn't change (it changes with the data because of the feedback, it changes with every byte because the key is very long but it doesn't change from session to session), that's one of the greatest problems at the moment. I have to find a way to make the encryption key variable and just valid for one session or even changing it within a session, but I'm already working on such a solution.
_
The biggest problem at the moment is that I forgot how to convert a Long to a String (something with RtlMoveMemory kernel function but I don't know how exactly it works).

Mr Ekted - Fri Apr 23, 2004 2:43 pm
Post subject:

Qndre wrote:

[..]
The biggest problem at the moment is that I forgot how to convert a Long to a String (something with RtlMoveMemory kernel function but I don't know how exactly it works).

In BASIC? You want to take a long, and turn it into a string with 4 bytes the same as they are in the long?

Cyan~Fire - Fri Apr 23, 2004 4:30 pm
Post subject:

Instead of checking to see if the keystream is repeating itself (which will turn out very flawed), you should design a formula that will prevent it from doing so. It will be much easier than trying to sync random changes between client and server.

Qndre - Sat Apr 24, 2004 5:23 am
Post subject:

Cyan~Fire wrote:

Designing such a formula is very difficult. My keystream repeats after 48960 bit (6120 byte) at the moment (doesn't matter very much because there is a feedback which makes it look random).

Changing the key after XXXX packets won't be difficult because I only have to send a 00 FF KK KK packet out (KK KK is the 16-bit key seed). The packet itself is of course also encrypted (with the old key).

My server system (or the proxy/plugin between an existing subgame2 and METASPACE) will also change the key. (I'll write a plugin or a proxy to decode META encryption and encrypt it with VIE encryption, so you have a kind of solution for let CTM in and META, but not VIE. (VIE is allowed at the server side then but there is a program in between which forces CTM or META encryption (CTM is just passed-through, META is decrypted with META encryption and encrypted with VIE)
Direct access to the server will be made impossible so you have to access it through the proxy.

Mr Ekred wrote:

In BASIC? You want to take a long, and turn it into a string with 4 bytes the same as they are in the long?

Yes. But calculations like dividing the LONG into multiple bytes aren't possible (or very complicated) because BASIC can't manage unsigned 32-bit values but only unsigned 31-bit values or signed 32-bit values.
_

Qndre wrote:

I've written a very cool new protocol and I'm just modifying the subgame2 to support it. The additional features in this protocol will be great. Everthing which is unsupported at the moment will run through a 0x00FE (additional features packet) or 0x00FF (META encryption keychange packet). This will make subgame supporting kinds of DLL plugins and keep new capabilities open (like third dimension coordinates or so).

Code: Show/Hide

0x00FE - Additional Features Packet (METASPACE only)

Offset Length Parameter
0 2 Header (0x00FE)
2 2 Feature ID
4 ... Parameters of the new feature

0x00FF - META Encryption Keychange Packet (METASPACE only)

Offset Length Parameter
0 2 Header (0x00FF)
2 2 16-bit key seed

Cyan~Fire - Sat Apr 24, 2004 10:53 am
Post subject:

Uhhh wait, exactly how are you modifying subgame2?

Smong - Sat Apr 24, 2004 11:02 am
Post subject:

He's just using a proxy ATM, but I expect he will try and make something like fix.dll after a lot of roundabout question asking.

Qndre - Sat Apr 24, 2004 1:21 pm
Post subject:

Smong wrote:

He's just using a proxy ATM, but I expect he will try and make something like fix.dll after a lot of roundabout question asking.

No. I won't binary-hack the subgame2!

Quote:

[..]
My server system (or the proxy/plugin between an existing subgame2 and METASPACE) [..]

With the proxy thing you are right. The other thing is a new server system - complete from the scratch (like ASSS is - but my system will have less functions I guess).

Cyan~Fire - Sun Apr 25, 2004 10:51 am
Post subject:

I'm confused though. If you're just going to be using a proxy, then it'll still appear as VIE to subgame...

Qndre - Sun Apr 25, 2004 11:40 am
Post subject:

Cyan~Fire wrote:

I'm confused though. If you're just going to be using a proxy, then it'll still appear as VIE to subgame...

That's right! You allow VIE and let the proxy connect. Direct access to subgame2 will be refused so no VIE client can join if you don't want it.

nintendo64 - Sun Apr 25, 2004 6:21 pm
Post subject:

He is just simply controlling what gets in and out of Subgame2, for Qndre is a good idea, it's cleaner than writing-code on the fly, or calling a dll inside the target process.

Here are some links, Qndre, in case you want to have more functionality on Subgame2.

http://its.mine.nu/html/re/essays/dracon-add.html
http://its.mine.nu/html/re/essays/dracon-add2.html

-nintendo64

Qndre - Mon Apr 26, 2004 7:26 am
Post subject:

nintendo64 wrote:

[..]
Here are some links, Qndre, in case you want to have more functionality on Subgame2.

http://its.mine.nu/html/re/essays/dracon-add.html
http://its.mine.nu/html/re/essays/dracon-add2.html

-nintendo64

Thanks.

Cyan~Fire - Mon Apr 26, 2004 6:47 pm
Post subject:

I really doubt whether anyone will want to run a Qndre-hacked subgame2 for their server. Also, I really doubt whether many zone sysops will care enough about your client to personally add users to the VIP list.

Qndre - Tue Apr 27, 2004 8:07 am
Post subject:

Cyan~Fire wrote:

I can also run the VIE encryption on the client-side. But that would mean that they'd have to allow VIE clients. And that's what they won't do because they have armageddon-like panic of cheaters.

Cyan~Fire - Tue Apr 27, 2004 6:34 pm
Post subject:

Qndre wrote:

And that's what they won't do because they have armageddon-like panic of cheaters.

Uhhh, my point?

Mr Ekted - Tue Apr 27, 2004 8:39 pm
Post subject:

Qndre is implying that our paranoia over cheating is unfounded.

CypherJF - Tue Apr 27, 2004 8:53 pm
Post subject:

rotfl! SS 1.35 :/

Mr Ekted - Tue Apr 27, 2004 10:47 pm
Post subject:

Changing the key on the fly means there could be many packets that do not properly decrypt. Do you plan to allow either key for a period of time after the key change is sent?

nintendo64 - Tue Apr 27, 2004 11:08 pm
Post subject:

Mr Ekted wrote:

Changing the key on the fly means there could be many packets that do not properly decrypt. Do you plan to allow either key for a period of time after the key change is sent?

i never thought about it, but ekted's right!, Qndre i don't think such encryption scheme will work for the proxy.

-nintendo64

Mr Ekted - Tue Apr 27, 2004 11:45 pm
Post subject:

If the encryption method is sound, trust it to stand on its own. If you need to change keys because the first key isn't good enough, then the second one isn't good enough either.

Qndre - Wed Apr 28, 2004 9:00 am
Post subject:

Mr Ekted wrote:

Changing the key on the fly means there could be many packets that do not properly decrypt.

You're right. I haven't realized it yet because I've only tested the client on the LAN and there the packet order doesn't usually get mixed-up (only one server to pass), but if you play on the internet, packets may come in another order than sent. Someone told me that CONT also changes the "scrty1" after some time or after some bytes sent. Client has to send the new key about 20 packets before it's used and server should use it if this "key-latency-period" (20 packets or so) is over. Thanks for recognizing and telling this problem.

Mr Ekted wrote:

If the encryption method is sound, trust it to stand on its own. If you need to change keys because the first key isn't good enough, then the second one isn't good enough either.

Like I said: CONT also changes the key in-session. And the encryption not bad only because it does. But changing the key will prevent it from being calculated using a known-plaintext attack (feedback doesn't really prevent keys from being attacked).
_
Another thing about the unreliable UDP protocol:
If the keystream continues, and doesn't restart for every packet (which would make it very weak) the decryption may also fail! Example:

Code: Show/Hide

Sent ("Byte #" and "Key for Byte #")
Key: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22
Data:01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22

Recieved
Key: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22
Data:07 01 02 03 04 05 06 08 15 16 17 09 10 11 12 13 14 18 19 20 22 21
- DECRYPTION WILL FAIL -

But if keystream is the same for every packet, it isn't very secure.
_
This means that the proxy and the client also have to put an unencrypted ID in front of every packet and decrypt traffic in the correct order (a bit like the VIE reliability layer works).

Mine GO BOOM - Wed Apr 28, 2004 10:00 am
Post subject:

Qndre wrote:

Someone told me that CONT also changes the "scrty1" after some time or after some bytes sent. Client has to send the new key about 20 packets before it's used and server should use it if this "key-latency-period" (20 packets or so) is over.
...
CONT also changes the key in-session. And the encryption not bad only because it does. But changing the key will prevent it from being calculated using a known-plaintext attack (feedback doesn't really prevent keys from being attacked).

What did you learn from the last time? Don't trust what everyone says 100%. Whomever told you this knows very little about the encryption Continuum uses. I suggest you look into this a bit more, and you'll see that Continuum in fact uses the same key the whole time, and doesn't change as long as your connected. Granted, the server key may change if you restart the zone, but the server/client key does not change while you are connected.

Want real evidence? Log the packets that go around, and enter a zone that does not have reliable public messages (important!). This way, you can send the same packet twice, at different time intervals. So, type "Hello" and see that packet (or to make it easier to find, make it nice and long message so you only have to find the 100+ byte packet.) Now do some other things, and send that same message. Encrypted packet is the same.

Note this doesn't work for other packet types, because the data that is being encrypted isn't consistent over two intervals, either the timestamp changes (positions) or the reliable ID changes. This does work for laggy clients, ones in which will send the same position packet twice over a small delay, but this won't help prove your key-changing question.

Mr Ekted - Wed Apr 28, 2004 11:21 am
Post subject:

It is possible to design an encryption algorithm that can be restarted at the beginning of every UDP packet, that is also very resistant to plain text attack. Think about the way hashes work: every bit of the input affects every bit of the output.

One of the easiest ways to see how bad VIE encryption is, is to send 2 almost similar text messages and look at the encrypted packets. Like:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab

You will see that only the last byte of the packet is different, and only different by 1 bit as expected. This is very poor. With s good algorithm, the above 2 text messages would encrypt to completely different "streams" and be unrecognizable from each other.

Qndre - Wed Apr 28, 2004 11:28 am
Post subject:

Mine GO BOOM wrote:

[..]
What did you learn from the last time? Don't trust what everyone says 100%. Whomever told you this knows very little about the encryption Continuum uses. I suggest you look into this a bit more, and you'll see that Continuum in fact uses the same key the whole time, and doesn't change as long as your connected.
[..]

Right. "scrty1" doesn't change either... My chat-friend just found some code/data inside CONT which could be able to do so. But he wasn't sure if this code is used. Since I think you are very sure about that the key doesn't change, I'll try to do more "research" on that "constant" key.

Mr Ekted wrote:

Such algorithms are very difficult to create. You need to hide the encryption key to decrypt the data somewhere within the data itself (so that it can be calculated out of the data) because sending a key through an encrypted connection will make everyone which knows current key knowing the other key as well. I guess the best way is to make the keystream generator and encryption algorithm strong enough so that a keychange isn't required and that it would take ages to calculate the key using a known-plaintext attack. Maybe a new kind of feedback that spans over much of data and changes with the data itself or so.
_
Sorry for bringing this thread so far off topic. It was once a server question about friction.

Cyan~Fire - Wed Apr 28, 2004 4:40 pm
Post subject:

You know, if your dencryption is good enough, you don't need to change the key.

Qndre wrote:

My chat-friend just found some code/data inside CONT which could be able to do so. But he wasn't sure if this code is used.

Your chat friends in the past have turned out to be liars. Don't trust them.

Jackmn - Wed Apr 28, 2004 8:42 pm
Post subject:

Why not just use a cipher that's generally accepted to be secure?

Something like RC4, working with the Diffie-Hellman key exchange and key signing.

Ultimately the best option is just to use a tried-and-true encryption library; then you don't have to worry about encryption security.

At any rate, it's extremely unlikely that you will iron out a bullet-proof encryption system on your own in your free time. Entire teams of mathmaticians and programmers can take years to do that.

Mr Ekted - Wed Apr 28, 2004 11:02 pm
Post subject:

Also, if your algorithm is greater than 56-bit symmetric key, and you plan on having it available (download source or binaries) on servers in the US, you basically need NSA "permission". This is seriously fucked up, but it's true.

Mine GO BOOM - Wed Apr 28, 2004 11:19 pm
Post subject:

Mr Ekted wrote:

Link to source, such as a newspaper, congress online, or on NSA's site?

Mr Ekted - Wed Apr 28, 2004 11:48 pm
Post subject:

http://www.bxa.doc.gov/encryption/default.htm

It's really cryptic stuff, but everyone I've asked interprets it basically the same way.

Qndre - Thu Apr 29, 2004 10:11 am
Post subject:

Mr Ekted wrote:

1. I am coming from Germany. Here are also some laws which no one needs and which get annoying but you are allowed to develop and use strong cryptography here (not sure but why shouldn't you?).

2. Do you think that VIE had a permission for their encryption (520 byte - 4160 bit) or Priit has a permission for his encryption (2x 80 byte - 1280 bit (2x because there is a 80 byte (640 bit) key for S2C and a 80 byte (640 bit) key C2S))?

Mine GO BOOM - Thu Apr 29, 2004 12:10 pm
Post subject:

Qndre wrote:

Do you think that VIE had a permission for their encryption (520 byte - 4160 bit) or Priit has a permission for his encryption (2x 80 byte - 1280 bit (2x because there is a 80 byte (640 bit) key for S2C and a 80 byte (640 bit) key C2S))?

VIE uses only a 4 byte encryption. Priit helped with creating Kazaa, and thus I'm pretty sure he wouldn't care about US laws at all either. Even so, Continuum still uses only a 4 byte key. Still wondering where you get your numbers...

Qndre - Thu Apr 29, 2004 3:41 pm
Post subject:

Mine GO BOOM wrote:

[..]
VIE uses only a 4 byte encryption.
[..]
Still wondering where you get your numbers...

It's the length of the keySTREAM (not of the key).

Dr Brain - Thu Apr 29, 2004 4:58 pm
Post subject:

Yet again Qndre decides to reply to something totally unrelated.

Mr Ekted - Thu Apr 29, 2004 5:01 pm
Post subject:

Qndre, it's the length of the key. If a 32-bit key creates the keystream, then there are only 2^32 possible keystreams. That is the point. This can be brute-forced by any desktop system in less than an hour if you know the algorithm.

Qndre - Fri Apr 30, 2004 8:35 am
Post subject:

Mr Ekted wrote:

Mr Ekted - Fri Apr 30, 2004 3:02 pm
Post subject:

Qndre wrote:

Hmm is that acceptance or dismissal?

Dr Brain - Fri Apr 30, 2004 3:17 pm
Post subject:

Yes.

Smong - Fri Apr 30, 2004 4:36 pm
Post subject:

http://bash.org/?36672

D1st0rt - Fri Apr 30, 2004 6:37 pm
Post subject:

rofl, did you see the messy desk?