Encryption needed for emailing objects?

I have been looking at vendors in these forums and was curious if emails that go to server objects, like to give items that are payed for by a vendor, will need encryption stuff?
I had the understanding that emails work on a different communication and did not need encryption.

Just curious,
Thanks

There was a well known case a couple years ago, when a server/vendor system was hacked to give away free content because the information was not encrypted. Yes, you need it.

No, encryption is not needed in this case. The thing you need here is authentication. It works like this. Have the vendors and your server share a secret key:

string SECRET1="..."; // use exactly 64 characters, use ascii only
string SECRET2="..."; // same again

if you send a message authenticate it using llMD5String like this:

integer nonce = llGetUnixTime(); // to generate a nonce on sender side
string hash = llMD5String(SECRET1 + llMD5String(SECRET2 + message, nonce), 0);

send the message, hash and nonce in an e-mail. At the server you do the same hashing again and compare the resulting hash with the one sent, also check the nonce, if it has a sane value, it is the actual UTC time probably off by some seconds. To counter replay, check, if the same nonce and hash was used before. Also try to not use the same nonce again for another message.

If you're using exactly 64 ascii characters for your both secrets, this hashing is very hard to crack, as MD5 has a block size of 64 characters.

I would say yes. If there is a chance someone can get the key to your server, then they could send spoofed emails to it. Being in proximitiy to the server and sending out a sensor is all that's required. Of course they would have to know what to send, but a clever one could figure that out if they were determined. Encrypting will ensure it's that much harder to fake.

than you ken for the simplest auth code I have ever seen in my life... bloody brill =)

Sorry, encryption doesn't ensure anything that it's hard to fake. When someone can intercept some encrypted messages, they can make out, which parts need to be changed for different things. The thing that is more important is, to detect, if a message came from an authentic vendor. There keyed hashing of the message is, what authenticates the vendor to the server. Encryption would just obscure the message, but an authenticated message is enough to ensure, that it isn't fake.

For my code, the both secrets SECRET1 and SECRET2 should be different. That they are nested makes it hard to reverse it. If it was a single llMD5String it would be easy to crack, as the hash could be reversed using the message and that could reveal the intermediate state of the secret. Also, a nonce is unsuited to be used as authentication, it's just a thing to add salt to the hash, like giving it an ID or running number.

For LSL uses, a single MD5 pass is more than sufficient, and doesn't eat up sim resources as much. Of course, if you're paranoid, use more than one pass (same thing applies to encryption, too, btw). Since there is literally no known way of intercepting object->object emails (except possible through social engineering, but that gets around ALL algorithmic security precautions anyway, or hacking LL's servers, which renders all attempts at security mute), reversing secret from a message and a hash (a lot more complex than being let on) isn't an issue.

You can get authentication in encryption as well, using a cipher operating mode (OCB, for example) or through the use of embedded reliability secrets. In those cases, you can't "fake" it unless you have the same exact key. With a decent block cipher (like AES), you can easily make it so that the communication is both secure AND reliable. It's a mute point, though, since there is no effective encryption in LSL to speak of. Also, in most cases, you don't need to obscure the data, but if you did, simple authentication obviously wouldn't work.

I do authentication in my vendors and secure systems as well, since that is the best that can be gotten for the time being.

Secret length is important, but secret content and randomness is even moreso. "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" is arguably less secure than "kl&8s;A1".

While I get your point, I have to disagree that someone would know what to change in an encrypted message. Encryption means just that, it's encrypted, unreadable. You would have to first be able to decrypt it before even having a chance at studying what to change. then you would have to know how to properly encrypt it back before sending. I would suggest that the authentication could just as easily be broken as the encryption. So both are just as valid.

neither one is particularly superior, but auth is easier to implement... both are subject to replay if there isn't sometype of cyclic/increment & check built in.....

I don't need to know what something says to do replay, I just repeat whatever I got... hence "replaying the message"

Q: the well know case mentioned above... this was interception of IN_WORLD llEmail calls? or are we talking about some man-in-the-middle type meddling on the web?

No, email calls were not intercepted. It was a vendor system that lots of people use. The hack was apparently figured out by someone playing around with their own vendor/server and then realizing, if I know the key of someone else's vendor I just need to email that vendor the right message and get free stuff.

The vendor was updated to include some form of encryption or authentication and the problem was solved.

:macks her forehead:: makes sense, especially if the communication is/was generalized like "give AvKey item 1" and the fact that owner info isn't exposed to the email event (because it accepts e-mail from outside sl I suppose)