Now I see that decoding makes data to be 4 bytes aligned. Need to find workaround for this situation.

It's because XTEA is a block cipher and block size is 4 bytes.
There are a lot of ways to pad data and then remove padding correctly, may be we need to choose one them
https://en.wikipedia.org/wiki/Padding_%28cryptography%29#Byte_padding
https://www.di-mgt.com.au/cryptopad.html

I guess that the best way is to use PKCS7 (https://en.wikipedia.org/wiki/Padding_%28cryptography%29#PKCS7)

Or even better way, (thanks stm#9360 from discord) -- just leave padding as is.
If someone need his own better padding - he can pad data himself and not allow MTA to pad zeros to the end.

I've thought that encoding/decoding compatibilty will be lost for data that was passed in previous MTA versions, so it's a problem.

What can be done:

• Add padding in source code
• Throw off the burden of padding on scripters

In both cases scripters must be informed about this change.

Wiki example on this page shows how to handle binary data

Wiki example on this page shows how to handle binary data

That was the main reason to fix teaDecode in a first place. TEA/XTEA should work with any data, and problem with wrong decoding only present in MTA.
Besides, full data manipulation with wiki example is:

• Encoding: data -> base64 (from script) -> TEA/XTEA (in source) -> base64 (in source)
• Decoding: data -> base64 (in source) -> TEA/XTEA (in source) -> base64 (from script)

This is not good at all.

As @Necktrox has suggested it's better to keep teaDecode as it is and make separated functions for encryption/decryption, like

encodeString(string algorithm, string input, table options)
decodeString(string algorithm, string input, table options)

I agree that this way will be far better than lost compatibility.

@ccw808 but with using base64 it doubles file size.
Okay if we don't want to lost backward compatibility, we can use here lua_pushlstring but before pushing we can trim all trailing zero bytes, instead of using lua_pushstring which cut off all after first found zero byte. So now we have both, backward compatibility, and the possibility to use teaEncode/teaDecode with byte data directly.
And if you worried about what if someone will encrypts data that have a lot of trailing zeros and it matters - again, he can pad the data himself and not allow MTA to eat any trailing zero in the end.

Fixing teaEncode is good idea because of ~30% of file size overhead when using b64, but IMO native AES support would be much better for binary files anyway.

Need to decide:

• Should function be backward compatible?
• Should it care about padding?
• Or leave it as it is and make new one?

@4O4 not 30%, full 100%, it doubles size.

@Elengar I was talking about additional size overhead introduced by the Base64 itself and it's known for a fact that it's always around 30%. teaEncode adds the rest ;)

I agree with @Necktrox's suggestion of new functions like encodeString/decodeString

Anyone. Watch last PR commits

Look at the passwordHash function and use an option table (with a key member for TEA) instead of the key string.

Hello, I'm a creator one of the biggest Russian project https://smotramta.ru/ with average daily online about 1000 players. Now we have a lot of custom replaced models and I think this pull request will be very useful for us, because so we can develop our project without fear that someone can steal all our models.

Proof: https://image.ibb.co/mF0FpR/online.jpg

What with Travis? It is frozen?

Looks like it. I've restarted the job.

Looks fine, should be merged after a test.