Protecting Texture UUIDs

[Profaitchikenz Haiku]

One way for safe updates is to have a link_message event in the script that will receive messages to change the existing contents of a list of texture UUIDS or add new ones.

This is done by dropping an extra script into the object. The new script sends link messages giving details of the revisions to the textures in the other script. After it has sent all the link messages it deletes itself, leaving just the original script with the revised list.

Because the update method is a script it can be given out to owners of objects with no-modify set so that people cannot see the contents, thus the UUIDS of the textures will remain concealed.

[Pedlar Decosta]

Hi Prof. I do use llRemoteScriptPin() for updates and sometimes use so called 'helper scripts'. But considering I use the Reset Function to update network details, the only way to store the lists would be hard coded into the scripts. I could use a notecard for the network channel, thereby not needing to reset the scripts, but I'm not sold on the idea of not having the data hardcoded. ***** happens and people reset scripts and that would render the product useless. That is why I am thinking a mod script the creators can use to hardcode the lists, that they then set as no mod before they sell the product (keeping the UUIDs hidden), is the best way to tackle it from that angle.

I know people hate notecards, but in this case they don't have to change a bunch of settings, just paste the chat log readout into a notecard and deposit that into the prim. I've got a version using the XTEA encryption and one using the llBase64() with 'salt' function as suggested by MollyMews. The XTEA is actually not as bad as I thought for time and the Base64 is a couple of seconds faster, but not as secure. I'm faltering on working out a way of scrambling as Wulfie suggested since I cannot  yet find any method of actually breaking up strings except by an elaborate use of llParseString2List using all of the ASCII itself as separators. This doesn't seem feasible to me, but then I knew nothing at all about encryption until a week ago lol.

[Wulfie Reanimator]

48 minutes ago, Pedlar Decosta said:

I'm faltering on working out a way of scrambling as Wulfie suggested since I cannot  yet find any method of actually breaking up strings except by an elaborate use of llParseString2List using all of the ASCII itself as separators. This doesn't seem feasible to me, but then I knew nothing at all about encryption until a week ago lol.

Here's an incredibly lazy (and simple / clear) way of breaking up a UUID and swapping it in 4 sections of 8 characters.

default
{
    state_entry()
    {
        key uuid = "779e1d56-5500-4e22-940a-cd7b5adddbe0";
        llOwnerSay((string)uuid + " (start)");

        list no_dashes = llParseString2List(uuid, ["-"], []);
        string uuid_simple = llDumpList2String(no_dashes, "");
        llOwnerSay(uuid_simple); // "779e1d5655004e22940acd7b5adddbe0", string length: 32

        list sections;
        sections += llGetSubString(uuid_simple, 0, 7); // "779e1d56"
        sections += llGetSubString(uuid_simple, 8, 15); // "55004e22"
        sections += llGetSubString(uuid_simple, 16, 23); // "940acd7b"
        sections += llGetSubString(uuid_simple, 24, 31); // "5adddbe0"

        string scrambled;
        scrambled += llList2String(sections, 3);
        scrambled += llList2String(sections, 2);
        scrambled += llList2String(sections, 1);
        scrambled += llList2String(sections, 0);
        llOwnerSay(scrambled); // "5adddbe0940acd7b55004e22779e1d56", string length: 32

        string final_uuid;
        final_uuid += llGetSubString(scrambled, 0, 7) + "-";
        final_uuid += llGetSubString(scrambled, 8, 11) + "-";
        final_uuid += llGetSubString(scrambled, 12, 15) + "-";
        final_uuid += llGetSubString(scrambled, 16, 19) + "-";
        final_uuid += llGetSubString(scrambled, 20, -1);
        llOwnerSay(final_uuid + " (end)");
    }
}

Obviously, you can use smaller sections, and order them in any way you want. As long as you always use the same order and do it in the exact opposite way when converting strings back.

And since the UUID format is very static, you wouldn't actually need to use any lists or list functions. You could pretty much directly build the final UUID from the original, using only llGetSubString. I have no energy right now to code something efficient rather than something that's easy to understand.

Here's the actual output too:

779e1d56-5500-4e22-940a-cd7b5adddbe0 (start)
779e1d5655004e22940acd7b5adddbe0
5adddbe0940acd7b55004e22779e1d56
5adddbe0-940a-cd7b-5500-4e22779e1d56 (end)

There's no way anybody could determine how the final UUID was generated unless they were able to see the input and the output. Even then, it would take a relatively keen eye to notice that the contents don't actually differ, besides the order.

Edited August 1, 2020 by Wulfie Reanimator

[Pedlar Decosta]

So I played around with the code you provided Wulfie, chopped and changed it and used a couple of different tactics to obscure the real uuids (hopefully even from those who read this thread), and integrated it into my scripts, put them alongside each other in the same network and tested to see which one is fastest. Scrambling and the Base64 encryption were a little faster than the XTEA. However, now that I have a scrambled uuid that is the same size as a real key, I can safely put them back into the other lists, dropping the notecard lines down from 6 to 3, which will save a bit of time too.

But. and here's the but - you said this is a lazy way of doing it Wulfie, which implies it is not how a fastidious or diligent person would do it and leaves me thinking that if it was your code, you wouldn't do it that way. That concerns me a little bit. I do my best to make my scripts solid, reliable and dependable to do what it is you want them to do with little fuss and low to no lag. So if I add encryption I expect it to be 'fit for purpose'.  I have 3 working versions, XTEA, Base64 and something resembling Wulfies scrambing. A question to you Wulfie and others who know more than me about the subject matter, "which would you use if you had to encrypt the uuid's in notecards ?" Bearing in mind that the object is purely to keep the keys safe so as not to breach usage rights and/or to protect the creators own work, and obviously only from an inworld  perspective. By the way, in case you are wondering, yes, I think I probably have some level of OCD

[Qie Niangao]

21 hours ago, Pedlar Decosta said:

My scripts then allow the creator to get a readout of all those visual parameters in their chat log using a Texture Generator. It allows them to even use advanced materials, so a possible 3 textures per face plus all the incidentals. The readout then is copied into a notecard and named something appropriate.

That's all necessary because a script can't write a notecard and we have nowhere else to keep a bunch of data in a way that's handy for transfer.* But since these creators are having to copy text into a notecard, it wouldn't be a huge leap for them to instead copy text into a script. This would involve a small "leap" for you, though: instead of spooling the text to chat, you'd need to do a little http_response readout in XHTML so the creators could copy it from their browser windows. The basics for that are pretty simple and the approach obviates any encryption -- and of course speeds loading compared to reading notecards, and the generated scripts can store the data already structured for use as parameter lists for llSetLinkPrimitiveParamsFast, making the texture changes practically instantaneous.

Beyond "the basics" there are some Javascript tricks that can help generate longer readouts, but you probably won't need them for "reasonably" complex objects -- and really, notecards have finite length, too.

This approach would expose some runtime "paint the texture" code to the creators, if they don't have that already. Maybe the menu engine, too, depending how you're handling that. The real limiting factor, though is the 64K memory limit on those generated scripts. This could mean needing several such scripts to define all the textures for a single object (as you might select among several notecards), and it's poor form to need all that script memory sim-resident all the time, even if you only have one of them set running at a time.

__________________
*Experience KVP persistent store could serve for this if it weren't so restrictive about where it can be used, but that's a different timeline.

[Wulfie Reanimator]

6 hours ago, Pedlar Decosta said:

But. and here's the but - you said this is a lazy way of doing it Wulfie, which implies it is not how a fastidious or diligent person would do it and leaves me thinking that if it was your code, you wouldn't do it that way. That concerns me a little bit. I do my best to make my scripts solid, reliable and dependable to do what it is you want them to do with little fuss and low to no lag. So if I add encryption I expect it to be 'fit for purpose'.

The reason I called it "lazy" was because I put no effort into optimizing it at all, or even checking how fast or slow the method was. I'd say it was lucky that my lazy code was faster than at least one of the real encryption methods.

The code I showed has basically 4 steps:

1. Remove dashes
2. Cut sections
3. Reorder the sections
4. Build the final UUID

But instead, if I was being non-lazy about it, it would just be:

1. Build the final UUID

6 hours ago, Pedlar Decosta said:

I have 3 working versions, XTEA, Base64 and something resembling Wulfies scrambing. A question to you Wulfie and others who know more than me about the subject matter, "which would you use if you had to encrypt the uuid's in notecards ?" Bearing in mind that the object is purely to keep the keys safe so as not to breach usage rights and/or to protect the creators own work, and obviously only from an inworld  perspective. By the way, in case you are wondering, yes, I think I probably have some level of OCD

Personally, I would design the product so that I would not have to use notecards for storage. Or in the worst case, at least not "sensitive storage" like UUIDs, even if that meant I could only have a limited number of "sets" or the sets could only save a limited number of information.

I might even play around with the idea of using more scripts for additional read/write storage, and only turning them on temporarily when the main script is about to interact with them.

5 hours ago, Qie Niangao said:

it's poor form to need all that script memory sim-resident all the time, even if you only have one of them set running at a time.

I got called out from the future.

Edited August 1, 2020 by Wulfie Reanimator

[Pedlar Decosta]

I didn't actually offer a "none of the above" choice Wulfie lol. But fair enough. Can someone explain to me what the perils are that are apparently associated with using notecards ?  I am happy to learn about the suggestion of http responses etc, to hard code it. Heck I'd prefer it if there was no copying and pasting at all, and maybe that's the way to go. But before I go down those roads, why is it many coders don't like notecards to begin with ?

[Mollymews]

looking at the tool from a non-scripters pov

we have a user (who is not a scripter) whose object can have multiple links, faces, colors, opacities, textures, mappings, etc

what I think works best for this kind of user is when they type into a notecard what they want. People are used to doing this: AO, dance HUD, AVSitter, rezzer boxes, etc

you design some format for this

what your tool can then do is read in their notecard and obfuscate/encrypt the contents, chatting out the result, from where the user can copy pasta it into another notecard for inclusion in their sale product

the user would provide their own passphrase to the obfuscator tool

[Wulfie Reanimator]

1 hour ago, Pedlar Decosta said:

Can someone explain to me what the perils are that are apparently associated with using notecards ?  I am happy to learn about the suggestion of http responses etc, to hard code it. Heck I'd prefer it if there was no copying and pasting at all, and maybe that's the way to go. But before I go down those roads, why is it many coders don't like notecards to begin with ?

Notecards have some inherent limitations.

A notecard's maximum size is 65536 bytes. All of the content could be on a single line as there's no line-length limit.

But scripts can only read the first 255 bytes of a line. So.. you can write a line that is longer than a script can read, but not know about it. 

But each line takes over 0.1 seconds to read, and then you must process the line.

And to read 257 lines (65536/255) sequentially, it would take you an absolute minimum of 26 seconds, or more if the lines were shorter.

To bypass that, you would need multiple scripts reading the same notecard.

Everything else aside, notecards are just plain slow. Useful but slow. 

[Pedlar Decosta]

5 hours ago, Mollymews said:

what your tool can then do is read in their notecard and obfuscate/encrypt the contents, chatting out the result, from where the user can copy pasta it into another notecard for inclusion in their sale product

the user would provide their own passphrase to the obfuscator tool

That is sort of what I did, but I never thought of encrypting the entire set of data using a unique passphrase chosen by the user Molly. What a wealth of knowledge and idea you are. Thanks. I'll definitely give this some consideration.  Err, but one question.... I love pasta and I make great homemade pasta myself...but never used it to glue code into a notecard lol

[Pedlar Decosta]

4 hours ago, Wulfie Reanimator said:

Notecards have some inherent limitations.

A notecard's maximum size is 65536 bytes. All of the content could be on a single line as there's no line-length limit.

But scripts can only read the first 255 bytes of a line. So.. you can write a line that is longer than a script can read, but not know about it. 

But each line takes over 0.1 seconds to read, and then you must process the line.

And to read 257 lines (65536/255) sequentially, it would take you an absolute minimum of 26 seconds, or more if the lines were shorter.

To bypass that, you would need multiple scripts reading the same notecard.

Everything else aside, notecards are just plain slow. Useful but slow. 

Hi Wulfie. Well, as you know I'm not putting 257 lines in one notecard and the data is not going to be truncated by design. My main goal is user friendliness. That being said I am already playing around with the ideas that you and others have suggested. I have got heaps of great tips and advice from this thread already. So thank you, and everyone else

[Pedlar Decosta]

I thought I'd give an update on this topic. I was using Wulfie's scrambling option (albeit somewhat altered) and that would be great if no one else was going to use it. However it occurred to me, when I happened to scrambled some words, that anyone with the software can use a known unscrambled key to easily figure out how those characters were scrambled. So the fact that they could do this, means scrambling is not a real security option in this instance unfortunately. So I will change it to something that completely transforms the keys, so they are unrecognizable. Fortunately, I have a few options, not the least of which have been discussed in this thread.

Edited August 20, 2020 by Pedlar Decosta