majqq

teaEncode/base64/encodeString

Recommended Posts

Hi. I have some question about those encoding functions.

I use teaEncode with base64 for encoding my files (dff, txd, col), the problem is the size of file. Wiki suggests, that i should use encodeString instead.

- What's difference between teaEncode and encodeString?

- What does base64?

- Does encodeString is less secure than teaEncode?

Share this post


Link to post

Hi!

teaEncode and encodeString are the same. encodeString uses teaEncode.

Base64 creates a uniqe character sequence out of data, which can be decoded to retrieve the data. It just makes files into characters and vice versa. Size does not change. It has to store the same amount of data, It's just a string now.

1st answer.

  • Like 1

Share this post


Link to post
14 minutes ago, WorthlessCynomys said:

Size does not change. It has to store the same amount of data, It's just a string now.

Of course it changes the size.

Original file size: 3.07 MB (random generated text)

encodeString: 3.07 MB
encodeString with base64: 4.10 MB
teaEncode: 4.10 MB
teaEncode with base64: 5.46 MB
 
Edited by gubi
  • Like 1

Share this post


Link to post
1 minute ago, gubi said:

Of course it changes the size.

Original file size: 3.07 MB (random generated text)

encodeString: 3.07 MB
encodeString with base64: 4.10 MB
teaEncode: 4.10 MB
teaEncode with base64: 5.46 MB
 

That's a fair point.

  • Haha 1

Share this post


Link to post

What's about security then?

teaEncode, teaEncode + base64 looks like it uses some kind of obfuscation, or i am wrong?

Share this post


Link to post
57 minutes ago, majqq said:

base64 looks like it uses some kind of obfuscation

 

It makes the data portable across different applications and storing solutions. In some cases your raw data can break the application, while it will not in the base64 format. For example you can embed with this format images(png/jpg/svg) within your HTML and CSS files. Also it is widely supported by W3C across the web.

Edited by IIYAMA
  • Like 1

Share this post


Link to post
On 07/11/2019 at 13:22, IIYAMA said:

 

It makes the data portable across different applications and storing solutions. In some cases your raw data can break the application, while it will not in the base64 format. For example you can embed with this format images(png/jpg/svg) within your HTML and CSS files. Also it is widely supported by W3C across the web.

Still not sure if i should stay with teaEncode or replace it with encodeString, do you know maybe if there any cons if we gonna compare encodeString to teaEncode, what about protection, should i worry about that, if am gonna replace it?

Share this post


Link to post
1 hour ago, majqq said:

Still not sure if i should stay with teaEncode or replace it with encodeString, do you know maybe if there any cons if we gonna compare encodeString to teaEncode, what about protection, should i worry about that, if am gonna replace it?

It is to me unclear what format the algorithm could be beside tea. So I personally probably wouldn't use it yet, unless I know all the options.

But to really answer your question, I don't think there is a big difference at the very end. You are still having 1 key and both functions are provided by MTA.

 

More layers of protection will not help you unless you can make sure that the steps are harder to trace back.

One way is to combine client storage with a network message.

 

1 extra step to make it harder

  1. The client has a RAW key.
  2. The server has a key.
  3. The server sends his key.
  4. The client just before decrypting uses the server key to change the RAW key in to the real key.

 

This way the client can't decrypt the files without being connected to your game server. (at least if the key isn't network sniffed before)

 

Why should the client have a key in the first place?

If the server sends the only key every time over, there is more risk in it being network sniffed.

 

And don't forget you can use the player serial as salt.

This information can't be network sniffed when it is only implemented clientside.

 

3 risks you have to counter

Edited by IIYAMA
  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.