Using llXorBase64() correctly

[Psistorm Voxel]

I've made use in the past of llXorBase64StringsCorrect() in order to apply a mild encryption to some messages. Security concerns aside, when reading up on this function again today - as well as on the new llXorBase64() - I saw a caveat mentioning this:

During the conversion to a byte array the last (bitcount % 8) are discarded from both str1 and str2.

This has me wondering. The wiki doesn't clarify much beyond this point, but to me this reads that data can be lost for certain string lengths. This might explain hard to trace bugs that some of my customers have been seeing.

The question now is: Assuming str1 is my data and str2 is my "password", should I always pad str1 to avoid losing data from it upon decryption? Again, the wiki hints at discarded data, but is very unclear what this actually means for practical use, at least to my eyes. So a bit of a better explanation would be much welcome so that I can improve my implementation if necessary :)

[TheG0t]

http://wiki.secondlife.com/wiki/LlXorBase64#Implementation

seems very in depth on the use of this and how SLS treats the arrays  and examples of its use with both SLS and PHP along with a few snip examples.

[Psistorm Voxel]

Hiya,

 

first of all thanks for the reply. Though I already did read the implementation section, and while i admit that I may be missing the forest for the trees here, I couldn't find a conclusive answer to the simple question: Can this function lose the last few bits of a message, as in, should I pad every message I send to guard against this possibility? Or will input always match output despite certain bits being discarded?

[steph Arnott]

what is the reason for its usage?

[Psistorm Voxel]

Essentially mild obfuscation. I have a script that puts out data to the user, and I simply want to obfuscate the message as base64 encrypted string. I'm not worried about people trying to break it as much as just giving the user a simple block of text to copy/paste. Another use is object to object communication, to obfuscate texture UUIDs.

I've used llXorBase64StringsCorrect() with the latter in the past, for a texture application system, but some customers ran into errors that I had trouble reproducing. I've started to wonder if those errors are because bits from the arrays are being discarded and whether padding would prevent that.

[steph Arnott]

ok, think in that case i would use a trigonometry eqauation rather than base. Else cut the message into parts.

[irihapeti]

is a number of reasons why we can get problems

i just start with the basic one, by a way to begin. (it might not be this, I just use to start the convo)

without seeing your algo then I think that the basic issue could be caused by the message and secret using different ranges of characters/symbols

example

message in range [0..3]. secret in range [0..1] 

message = 0. secret = 0.  encode: 0 xor 0 mod 2 = 0. decode: 0 xor 0 mod 2 = 0
message = 1. secret = 0.  encode: 1 xor 0 mod 2 = 1. decode: 1 xor 0 mod 2 = 1
message = 2. secret = 0.  encode: 2 xor 0 mod 2 = 0. decode: 0 xor 0 mod 2 = 0. err
message = 3. secret = 0.  encode: 3 xor 0 mod 2 = 1. decode: 1 xor 0 mod 2 = 1. err

message = 0. secret = 1.  encode: 0 xor 1 mod 2 = 1. decode: 1 xor 1 mod 2 = 0
message = 1. secret = 1.  encode: 1 xor 1 mod 2 = 0. decode: 0 xor 1 mod 2 = 1
message = 2. secret = 1.  encode: 2 xor 1 mod 2 = 1. decode: 1 xor 1 mod 2 = 0. err
message = 3. secret = 1.  encode: 3 xor 1 mod 2 = 0. decode: 0 xor 1 mod 2 = 1. err

+

to avoid this then when using xor-like functions then ensure that both message and secret are in the same range, or ensure that the modulus uses the higher range bound and not the lower. e.g magnitude 4 and not magnitude 2 as above
 
uuids for example, as chars are in the [0..15] range (magnitude 16). So the secret should be at least in this range [0..15] (mag. 16) also. Or greater [0..31] (mag. 32) [0..63] (mag. 64) etc. If was me in this uuid case, then I would also strip out the "-" symbol from the uuid before encoding, and restore after decoding

 

eta: magnitude

[steph Arnott]

SL is not a bank.

[irihapeti]

---

steph Arnott wrote:

SL is not a bank.

---

is computer programming

how functions like xor actual work, and what we need to consider when using them in our own scripts, and what the issues are when the decoded outputs are not what our present understandings lead us to think they might be