encryption for chat?

do you guys know of some clients or additional programs (somthing like SL Proxy perhaps) that will keep chat encrypted while it hasn't reached it's destination? (for IMs only the two people would get the data, but if it is open chat/group IMs/IM conferences, those without the propper public key (or whatever system is used) would get the text scrambled with encryption), the decryption would only happen locally, meaning the data would be safe while moving on the internet (not sure what would be the strongest encryption/decryption system that can run on LSL scripts without performance becomming an issue, so I dunno if it would e possible to have scripted objects "understand" those encrypted msgs or not)


and talking about privacy and such, not 100% related to my previous question but anyway, I've heard that there is law awaiting approval here in my country that would force the internet providers here to store the data sent by their clients (not sure about the data received), how would this interact with laws about privacy and such in other countries and things like contracts etc? (not sure if any of you would know how to answer this, but I felt like asking anyway), I find unlikelly it will be approved, things like copyrighted material and busyness secrets and such are often transmitted thru the internet and it would probably be illegal for the providers to keep copies of that, dunno, but I would like to learn the most about this as possible just in case, both for curiosity and to try to be prepared in case this gets wrongly used against me or someone I know.

ps:does voice chat leave people's machines encrypted? (I think Skype has it like that, not sure) or if it is intercepted anyone can hear what was spoken the same waya s the intended receiver?

I use an Ovaltine secret decoder ring. =^-^=

....

Oh... Hmmm... I don't really see a real encoding system existing. Nor do I see a need. But, that's just me. (=_=)y

Given the possibilities for (primarily illegal and at best potentially suspect) misuse, I could see Linden Lab being very unhappy indeed if such programs could be used within, or in conjunction with Second Life.

You're kidding, right?

That's the same BS excuse used by the US government when they classified encryption as a "munition" and had Draconian export laws restricting even the printed publication of source code. Philip Zimmerman (PGP) was instrumental in obviating such stupidity.

Encryption is for the people. Any assumption that its use is for "primarily illegal and at best potentially suspect misuse" is dangerous at best, and follows the "presumed guilty" model.

I use encryption for 100% legal purposes all the time, thank you very much, and, likely, so do you (Got HTTPS?).

Most likely, LL doesn't care one way or the other, nor should they.

I've not heard of any complete products to encrypt chat/IM traffic but there is an XTEA encryption implementation in the scripting library forum. It would be easy to create a chat/IM encryption system with it.

If you are looking for industrial grade encryption, your best bet is to go outside of SL and use one of the available public key systems (e.g. pgp / gpg, etc) as LSL doesn't really have the horsepower to do really strong encryption.

Sounds like a good project for an opensource viewer. Of course both parties would have to be using a viewer modified the same way. You could maybe add a preferences field for a chat encryption key, then where you have the 'say' and 'shout' buttons, have a toggle for the encryption on and off. Then the parties could exchange the encryption key in IM or something, toggle encryption, and everyone else would just see 'gibberish' chat.

I don't know how feasable it would be to implement, but if I wanted such a feature, that's the way I'd want it done.

-Atashi

I'm bowing out of this discussion before it gets started. Clearly I don't have enough knowledge of the subject and will be outgunned on every point.

Have a good one

If SL is being touted as a platform for virtual business conferences and meetings, I, for one, would consider this a requirement. Neither illegal nor nefarious. Just Simple business protection.

If I had to guess which of your two opinions of LL's attitude to encryption was more likely to be more accurate I would suggest Skell's probably was.

I would agree with the rest of your post, Talarus, but it seems to me that Skell wasn't talking about the rights and wrongs in principle, but the practical implications to LL of yet another high-profile complication getting in the way of their potential exit strategy.

Pep (How does encryption interact with the IGNORE and mute functions?)

I would think there wouldn't be an issue there, just the messages would be getting encrypted, not the name or the UUIDs of the avatars sending them

perhaps the exchange of keys could be done somewhat automaticly by using a system like an "authorized list", you would add people to it kinda like how you do with the friends list and the clients would automaticly exchange the keys between each other

Yes, Tal, encryption is for your protection.

So are (or so they tell us) the chat and IM logs maintained by LL. Those logs are used to adjudicate ARs, among other things.

If we have encrytped communication in SL, the griefers and those up to shady stuff are sure to use it, even more so than the honest, upstanding majority of residents.

Therefore, if any encryption scheme is implemented/allowed in SL, my guess is that LL would require that they have access to the keys... for their OWN protection, if nothing else.

And of course, that makes any encryption worth exactly...oh, say, 5,000 Quatloos.

Well, you probably would guess wrong. LL open-sourced the viewer, and they have a very liberal mindset with respect to things like encryption and allowing bots, mods, and third-party viewers full, unfettered access to the same grid that their viewer connects to.



I am speaking from both principle AND practice. Philip Zimmerman didn't publish the PGP source code in PRINTED BOOK form "in principle". He REALLY did it, for practical reasons, because he believed in the principle of free and supportive use of encryption by private individuals everywhere in practice.

There are no "illicit implications" to the use of encryption technology. You use it every time you log into Second Life or even use parts of the SL website. Its use is commonly accepted by most non-oppressive government regimes to be in line with a basic human right to privacy.

As for "yet another high-profile complication getting in the way of their potential exit strategy", what does THAT mean? Encryption isn't high-profile anything anymore. What exit strategy are you talking about?



It wouldn't interact any different than non-encrypted communications. Identification/authentication and message encryption are two separate functions.

I'd love to implement it as an SLProxy plugin if someone could educate me on how you should pass encryption keys to one another and stuff. That topic's always eluded me a bit.

My only take would be the detrimental effect on the immersion experience encrypted text in open chat might have. I have nothing against encryption itself, only the effect of the coded text itself on my environment.

It appears that I don't need to encrypt plain text for it not to be understood . . .

Pep (Just because you are paranoid doesn't mean that they AREN'T out to get you)

just view it as a foreign language

Haha ... that thought actually crossed my mind But no, it wouldn't look like French, it would look like garbage. The immersion factor is very important to the viability of most any virtual environment; this occurance would certainly detract from the experience.

With an asymmetric, private/public key encryption, there wouldn't really be any trick to distributing the key.
At its simplest, somebody could write their public key in their profile, and you just cut'n'paste that to your proxy you when want to establish a secure connection to that person.
Alternately, you could have a proxy inject a "request public key" command as a special message in IM, and have the proxy at the receiver react to that command when it sees it in IM, automatically responding with a special line containing the public key, which can then be used for further communication.
That way, you can query other people's proxies for their public key, building a cache of avatar UUID/public key pairs.

So your proxy just catches any outbound messages, checks if they should be encrypted, and if so, does it using the public key of the avatar it is meant for, prefixing the message with some signal that it is encrypted, and fires it off to the normal IM system.
When the IM is received by the client in the other end, the proxy catches the prefix, recognizing it as an encrypted message, and decrypts the content using the person's private key.

This is how something like the OTR (Off-The-Record) plugin/proxy for various IM systems work. The automatic distribution of public keys (answering an IM request for it) would rely on the IMs being *authoritative*; i.e. that the message is actually from whom the protocol claims it is from, and as such relies on the protocol not being spoof-able. Otherwise, an attacker can pretend to be somebody else, and hand you a false public key, to listen in on the messages, possibly bouncing them onwards to the intended receiver with his correct key, doing a "man-in-the-middle" attack. But it would require that the attacker is already eavesdropping on your IMs on protocol level, doing a dedicated attack against you, which is probably well beyond the scope of a basic "I do not want my readable logs stored on a disk somewhere" privacy measure. (Something like SSL encryption, which also relies on asking the receiver for its public key when initiating communication, uses several additional layers to validate and tamper-proof the public key, including checking against 3rd party authorities.)

So bottom line; for basic "don't store or transmit my messages in a readable format", just distribute the public keys using the IM system itself. To provide authentication and integrity against a dedicated attack, you'd need additional validation of the keys, and possibly a two-way encryption.

And yes, please don't use it in open chat!

At most only the metadata about the connections and such.
I.e. who is connecting to who, protocol, duration, amount of data etc.

To log the actual data itself would require huge amounts of new disks or truckloads of tapes being brought into the datacenters of the service providers each day.

The amount of actual data passing thru the service providers is horrendous.

I am a little confused about the purpose of the post. If you are looking for secure communications for a business avenue, such as a business meeting, etc....why not just hold the meeting/discussion in a group conference. Even if the people attending are not in the same groups, you can quite simply drag all wanted members into the conference window, thereby effectively shutting out anyone you do not want listening in. The conference can then be held in either text/voice or both with no one in the surrounding area being any the wiser. As a matter of fact, the parties involved do not even need to be in the same sim, much like a teleconference.

If the point of the post was simply to give the effect of security/encryption of openchat channel 0 then I hate to burst the bubble but regardless of how you implement that type of system via LSL, Linden Lab Employees do have access to all and I mean all of your inventory (ie, the hud or device you would be using to cypher/decypher the text) thereby making such communication non secure.

I, of course am not saying that any LL employee would do such a thing in a malicious fashion. I am simply stating that the illusion of complete communication security is just that, an illusion...so just be aware of that if you were to make such a system, which can be done fairly easily.

it would probably not be done with lsl, at least not the person to person part, the concern isn't about the messages being intercepted in world but off world

The company I work for, which is one of the big ones with a huge presence in SL, has prohibited any talk of company confidential matters and client business inside of SL for the very reason that it passes thru the LL servers.
Not because we especially distrust LL, but as a matter of principle and because the information then goes outside of our control.
Only stuff which is publically available anyway, can be spoken about inside SL.

I'm sure it wouldn't be all that hard really, if one knew how to modify clients in the first place. I would use something like GPG to encrypt all messages before they left your local machine, have some sort of flag applied to encrypted IM sent so that people using the right clients could have it automatically decrypted after it arrived (assuming you had each other's keys properly) and have a system which automatically looked for a public key which someone had pasted into their profiles, perhaps as a pick, to grab that. It could also be applied to notecards, reading and writing, though it is a lot easier to do that by hand.

Another thought that I had using GPG was digitally signing important notecards, for things like contracts or legal statements, so that if altered it would be clear that that was not the original text. You can quite easily do that now by hand as well.

If that is your primary concern, then you should not even be considering sending privileged information through SL. The security chain is only as strong as its weakest link and SL is a doozie of a weak link.

Especially when the plaintext already has obtuse and obfuscated content.