Encrypting llSay Type Ouput

Is it possible to Encrypt llSay type output?

As in to send a message to a user near by thats encrypted from the other users(Instant Message cannot be used).

I've done MD5 before in other languages, but with it requiring a comparison the other end, the other end wont know the message it's being sent and even if it did, another user could just send a message using the MD5 hash that was outputted.

Already using a - channel.

Any ideas?

The receiver always has to know how to decipher the message, or even that the message is enciphered in the first place. If you want to check-out public-key encription, key-exchange techniques, etc. I'd start by searching google for 'encryption'. It's a big subject so just as I start i'd need to know why you can't use IM and what the objective is.

Hi.

The scripts echoing the message to many users in the same region, so without a lot of scripts to get round the sleep with instat messages.

Is there any two way encryption build into LSL? or user created functions?

or even of way of like

HASH&message

then parsing it and if Hash is correct then use the message else disgard, but again someone could just copy the hash.

I have no idea what you mean by this. MD5 is a secure hash ("message digest", not an encryption method, so I don't know why you mentioned it. You can't use MD5 to encypher a message.

I'd post more, but gotta run.

how secure does it need to be? if you are just trying to obfuscate the message convert to base 64 and back, if it really needs to be secure from things like playback attacks, you need authentication, not encryption. there are scripts on the library for both.

But wouldn't auth fail, since you would be passing, a password, hash or not through chat?

I think what everyone here is trying to say is that you can't just do this on the fly. The listening end needs to know to expect a certain authentication. Ie a password. You would not be sending the password in plaintext, you'd have to encrypt it somehow.

See this wiki article:
http://wiki.secondlife.com/wiki/Authenticated_Chat

auth can be as simple as

if (llGetCreator( vKeySpeaker ) == "Nyx Alsop's key here"

or

if (some_special_number | llGetSubString( (string)vKeySpeaker, 1, 5 ) == other_special_number)

to much more complex systems outlined in the forums

(and fwiw there are MD4&5, SHA1&2, and XTEA implementations on the LSL_Portal library page as well as AES implementations on the forums)

but the general rule is you only need encryption if the actual data being sent is sensitive (RL info, CC numbers, etc)... if it's just instructions, authentication is all you need, since without it, even if the message is known, the information is useless.

PS
I looked for a post in which strife outlined a solid auth example but I can't find it... may be too old. but it boiled down to md5 with a secret manipulation before hand.

That's not how secure authentication works. The password is not sent in cleartext; it's encyphered using a "Non-Repeating Value" (NRV), something like the current time or a challenge string, to avoid replay attacks. In the Wiki example, the sender's key is used instead to avoid replay attacks. (If someone copies and pastes the text, their key won't match the original sender's key, so the MD5 check will fail.)

For us to help you more, you need to tell us what it is you're trying to do.

I'm sending some information via llRegionSay to multiple agents to an attachment they wear, but I need it so someone else can't find the channel and send outputs to there HUDs.

You can have the HUD script use the key id parameter from the listen event to authenticate the speaker; check it against a (list of) valid speaker key(s). Better still, use the key of a single valid speaker when you call llListen.

The hud also talk to each other

Oops, sorry, missed that bit

ETA: how does the system work, in general terms? For instance, do HUDs come and go as they please, or does everyone meet up for a pre-game briefing?

It's all in one sim, and the huds go as they please.

A basic explanation of encrypted chat using steganography, time validation, speaker authentication and a simple Ceasar cypher. Now you can't use this, because I've told everyone the secret, oops!

1. In this encryption everything will be sent as what appears to be keys. This is the steganography, hidden-writing, in that hopefully we'll misdirect hackers into interpreting all the chat AS keys, instead of the text that it is. So: start with a key as a string

"00000000-0000-0000-0000-000000000000"

2. Including time (llGetTimestamp()) in the sent message can make it only valid within a timeframe of, say, 2s to allow for SL chat-lag. Putting the characters of the time together would make it too recognisable so in your implementation predefine a character-sequence in the blank key-grid for each of its characters (The whole lot (YYYY-MM-DDThh:mms.ff..fZ) isn't necessary, just take the hh, mm and ss, possibly 100th/s).

"000m0000-0hs0-0000-0m00-00h0000000s0"

3. Speaker authentication works in roughly the same way. Take, say, 8 characters from the object's key and insert them into the sent message at predefined positions. This enables the receiver to check that the message actually did come from who it claims to have done.

"030m0005-0hs0-0170-4m00-00h6020080s0"

4. Now, from a message of 36 characters you can now insert the (next) 18 characters of your actual message You don't want to put in the actual text, however, so use a Caesar cypher to 'displace' each character to another. Julius Caesar is traditionally meant to have used a key of 3 - that is each character was replaced with the one 3 to the right in the alphabet (A->D, B->E, ... W->Z, X->A, Y->B, Z->C). As with the time and speaker you should also predefine positions for these so that the letters are not in sequence in the sent message. Here is 'Hello World' (KHOORZRUOG - by convention all text is made uppercase and spaces are excluded, but that's up to you).

"0cZmOO0e-0hsH-UagR-dmG0-K0hf0bR0h0sO"

5. As a 'tidy' stage, if you are using a fixed message-size like this you should use a 'stop-code' and randomise any remaining zeros. This is to prevent the interceptors being able to identify unused parts of the grid. Here I am using the stop-sequence a) message > 17 characters, none required (because it occupies the whole grid). b) message = 17 characters, none, because the single zero is as good as any random one. c) message < 17 characters use "AA" after the message and then a random sequence

"AcZmOOfe-chsH-UagR-dmGA-K4hfGbR2hasO"

So - now you know how it's done and can see all the steps, how easy is it to get 'Hello World' (or even HELLOWORLD) back out of that

Then it seems that the link Tharkis Olafson posted is exactly what you want: origin authentication using a shared secret.

This security though obfuscation is probably good enough for many SL scripts, where the threat of someone hacking it is low. It's utterly useless if the threat of attack is significant.

Absolutely, Lear. I was just trying to illustrate some encryption techniques, not suggest anyone use them - Ceasar cypher especially!