What is the UUID of the rezzing object that rezzed me?

If I'm rezzing ojects for which I want to communicate with each other through listens filtered on thier UUIDs I need both to know each other's UUID. I know that:

llRezObject triggers the object_rez event, passing the new object's key to any script in the rezzing object.

So the rezzer can get the key of the object it just rezzed BUT -- Is there some automatic way for the newly rezzed object to get it's rezzer's ID? I don't see this anywhere, and the parameter you can pass to a rezzed object is an integer.

Am I missing something here?

I can think of some hacky ways to get the rezzer's UUID to the newly rezzed object but I don't like any of them. Is there something in the Wicki I'm just not seeing? It would be optimal if the technique for obtaining the UUID was secure.

Any feedback greaty appreciated. Thank you!

Off the top of my head, have the llRezObject() pass a random channel number to the rezzed object's start_param. The rezzed object listens on that channel for the parent to send the parent's UUID (in the parent's object rez_event so you know the child is live) and then they forget the channel number.

I tested the llFrand function a whlie back and it approached crypto quality randomness. I suspect that llFrand draws from the Linux /dev/random entropy pool.

That is one of the solutions I tried yesterday, and it works. I'm looking for something even more secure. Any other ideas?

Not sure what you mean by secure in this scenario?

If you want to make sure somebody else isn't guessing the random channel and hi-jacking your communications just make sure you're comparing owners:

listen(integer channel, string name, key id, string message) {
    if (llGetOwnerKey(id) == llGetOwner()) {
        // do stuff
    }
}

Yep, lock the scripts in a concrete box and don't let them run... total security

Or, could you explain why this is not sufficient security for your purposes? Yes, there is a window where a rogue script could conceivably guess (p ~ 10^-30) the random number and intercept the UUID, but, the parent knows the UUID of it's child and can llListen(..., "", childUUID, "" so it would be impossible for anyone but the child to talk to the parent.

If you are looking to do external financial transactions, you should look at llMD5String and read up on crypto.

Rock n Roll that will work!

And yes I was concerned with channel guessing, even though random would be a hard nut to crack, I won't accept any holes. This is good enough. If someone wants to hack their own stuff then more power to them.

Thank you much.

I like the idea of locking the script in a concrete box and not allowing it to run =c).

I understand it would be impossible for anyone but the child to talk to the parent ... but it's the parent talking to the child I am concerned with and YES I am concerned with that (although unrealistic chace) of a channel guess.

I believe if you can plug a hole, no matter how small then plug it.

I've looked at crypto and don't see where it can help for this scenario. If you can give me a way to ensure even the owner of the objects can not hack the "UUID hand off" (or what ever you want to call it) in any way at all (crypto included), then yes I'll even take it that extra mile.


Thanks guys.

At what cost? You use Wifi? WEP is crackable. You use SSL to buy stuff on the web too? Crackable. You put your scripts on the SL servers? A recently found exploit made the code readable to suffciently motivated, bored, and malicious players. Again, as you haven't said what you are working on, I can't tell what you are trying to protect against.

But if I really wanted your code, would you turn down US$5000 for it (i.e. social cracking)? Probably not. I fear you are being overzealous about this detail.

Yes there is a cost/benifit limit but when something can be done within those limits there is no reason not to do it. =c).

The solution provided for my purposes is adequate. Although I might use a random number for which certain digits will be torn out (on both ends) and used/obuscated as a key and the others as the channel. What ever algo I use on both ends might help prevent an owner from hacking thier own objects. But I might not take it that far, as you said cost/benifit.

I was simply stating that ... And I'll add to it ... (if at apropriate cost), this can be more secure then bring it on.

There is nothing wrong with that

um, I'll take the $5000 *grin*.

fyi

I'm just making a multi player game, but I put quality into everything I make. To ensure a child object knows whom it's parent was is important to the game. There is nothing wrong with building quality even into games within games. It's worth the effort.

To paraphrase my coding elegance idol - Brian Kernighan - get the code working first and then worry about adding code to guard against the 1 in a billion chance of someone finding the random channel you are using for 1 second of inter-object comms.

Doing bit manipulations on the results of llFrand will not make it more random as it is already quite random. If you wanted to ensure that that 10^-9 chance of someone snagging the open channel, your parent and child could share a secret key and sign their messages to each other so that even if i snagged your channel, I wouldn't be able to forge a valid message.

Put much more pragmatically, you are making a game. Wouldn't it be cooler to see it work a little sooner rather than later? Yes, you are making the classical engineering tradeoff between every feature you can think of and time, but this is supposed to be fun.

Happy coding.

Thank you Malachi Petunia. You are smart and I value you input. I hope you're around the next time I have a question for this forum. I've learned from you =c)