llRSAEncrypt / llRSADecrypt
needs info
Bugs Larnia
Right now, LSL has a bunch of one-way hash functions and an llSignRSA/llVerifyRSA function. What I am not yet seeing (and would like to have in case communications need more security) are functions to encode
and
decode a string (aside things like llXORBase64 which, let's face it, is not the pinnacle of security).Therefore I am proposing the following functions
string llRSAEncrypt(string plain_text, string hash_algorithm, string rsa_private_key);
string llRSADecrypt(string cipher, string hash_algorithm, string rsa_public_key);
Since the RSA architecture is clearly in place for the sign/verify functionality, code-wise this might hopefully not be insurmountable. I don't know if such a protocol might be too much for current LSL limitations, but it would make quite a difference in creating more secure communication if the phrases sent/received are not fixed and therefore might not be known in advance.
Thank you for your consideration.
Log In
Kathrine Jansma
I would recommend against putting RSA primitives into the language. It tends to be a serious footgun. Your suggested function signatures kind of prove the point. RSA does not need any "hash algorithm" for encryption, and putting the parameter into both sets is kind of odd and error prone.
99.99% of LSL programmers will just shoot themselves in the foot when handed RSA primitives like that.
Some construction like NaCls / libsodium "crypto_box" is much more sane and useable. It selects all the hard stuff for you and has a super easy to use API that just works (e.g. https://nacl.cr.yp.to/box.html).
For script to script communication, you basically just need some functions to setup some opaque shared context and then a encrypt/decrypt function that handles the details.
Like, why bother with RSA encryption, if you could just say:
string ciphertext = llProtectData(key context, integer ctxtype, string cleartext);
Where ctxtype could be for example "OWNER" and context would be the uuid of some avatar. Or ctxtype could be "GROUP" and context would be the group. Or whatever other ctxtypes were useful.
and then, in the right context thats checked automatically:
string cleartext = llUnprotectData(string ciphertext);
Jeremy Duport
Kathrine Jansma I don't disagree that people will probably use RSA incorrectly in some instances, but that shouldn't mean hamstringing LSL with an 'encryption' (generous) approach completely incompatible with everything outside the ecosystem and which LL have implicit backdoor access to.
Kathrine Jansma
Jeremy Duport Agreed it would not solve the issue of communicating with outside services in an encrypted fashion. TLS should do that already in many cases.
LL runs the servers. Obviously they always have an implicit backdoor to the encryption. That is even theoretically unfixable. Not even homomorphic encryption would help you much, unless you tried to use SL as a (terribly performing) server for some external services.
You could do expensive remote attestation and hardware stuff for signatures, if LL exposed the AWS HSM stuff. But thats probably not worth it.
Whats the threat analysis? Who is the attacker you want to protect against. What attack do you want to prevent? If it is LL, you have already lost.
That said: Yes, there is some small room for RSA signatures and less so for RSA encryption, to communicate with external services that have strange APIs that require some kind of RSA. Those usecases can probably solved in 90% of the cases with some relay service running on some cheap stock webserver somewhere in the cloud.
V
VriSeriphim Resident
along with what Jeremy Duport said, RSA and similar are primarily for key distribution over unsecured channels. Usually between independent entities.
Once both/all your endpoints have the key(s), you use AES (or other "high performance") encryption for actual data transfer.
So a practical use case would be:
- Generate transmission key
- Encrypt t-key using RSA (or similar) and the recipient's public key
- Recipient decrypts the t-key using its private key
- Sender begins encrypting data with t-key and sending the encrypted data
- Recipient begins receiving and decrypting the data using the t-key
Of course, if you control both/all endpoints, you may have alternative secure means to update the transfer keys.
An LLEncrypt/LLDecrypt that supports AES (and maybe other symetric algorithms) and various public/private key algorithms like RSA, various elliptic curve algorithms and maybe others.
But not just RSA. RSA (and a few others) will be broken once quantum computers become truly practical. (Maybe they are, already. NSA, MI6 and other TLAs have been working on this for a very long time and we don't know how far they have achieved.)
Bugs Larnia
VriSeriphim Resident Once quantum computing becomes practical, all current encryption will soon be useless, but I am not against other algorithms.
I suggested RSA since LL already but the architecture in place to generate they signatures, so I thought we'd have a bigger chance of success.
V
VriSeriphim Resident
Bugs Larnia
Actually, AES256 is still considered quantum resistant. A quantum attack on it would be roughly equivalent to a brute force attack on AES128. There may be other symmetric key algorithms that have similar resistance. The main quantum threat for AES and other symmetric key algorithms is Grover's Algorithm. On a quantum computer, this algorithm provides a quadratic speed increase over ordinary brute force.
For Public/Private key encryption, so far, the Kyber Crystal algorithm has been provisionally chosen in the US by the NIST. Not sure about other countries.
For now, still makes sense to implement RSA for LSL. Should also implement AES, which I recall is well supported in Mono (in general - obviously, LL would have to chose a suitable Mono AES library and integrate it)
Jeremy Duport
VriSeriphim Resident
I could get behind the llencrypt/decrypt thing since it's more future friendly than bloating the function library, although given the number of possibly useful things, variations on inputs, and wanting useful outputs, their signatures would both basically have to just be
list out (list in)
🙃Jeremy Duport
Bugs Larnia Rider Linden
The main use cases as I see it are securing traffic between scripts in world and securing traffic between scripts and remote hosts, which at the moment is still very much a roll-your-own mess of expensive hashing and nonce generation in usercode. Built in encryption is something I've wanted for a long time, however I wouldn't pick RSA. (Tangentially I wouldn't pick RSA for signatures either given ed25519 exists, but so it goes).
Being symmetric, AES would be much preferable in these roles. Not only that, the AES-NI instruction set is available on all of the x86 AWS options, making it instantly and hugely less burdensome on regions than RSA (not to mention not having to replicate big string keys in all the scripts involved). It's not just faster and lighter - it's also more secure. AES 128 is security level equivalent to RSA
3072
, and there is no RSA equivalent to AES 256 because RSA scales very badly.Personally, I'd like to see AES-256-GCM-SIV in play if we get a built in encryption option. It's future-tough, forgiving, and
fast
- although if it's too heavy, 128 is still fine. If it's good enough for TLS 1.3...Bugs Larnia
Jeremy Duport I can get behind that. The main reason I went for RSA in my requerst is that they already had the stuff in place for the signing which may have made it more likely for LL to pick up the suggestion.
I'd be happy for AES to be used instead.
Rider Linden
needs info
Bugs Larnia Can you please outline your use case?
Bugs Larnia
Rider Linden
When two scripts in two different objects need to share information that needs to be protected, there is currently not really a way to do that.
Channels can be sniffed and while we can send a signature to verify the information, the plaintext information is still able to be intercepted.
We have plenty of one-way hashing, but that presumes that the receiving end knows which messages are sent. If the sent message is variable, then we cannot use hashing to secure it, since the receiving script will not be able to read it.
In our sims The Faery Crossing, for example, we have a security system that I created in which a HUD communicates with orbs. The orbs are deeded and take care of the banning/unbanning, booting, adding/removing to lists etc.
This communication between HUD and orb needs to be protected, so that it cannot be abused by third parties to hijack those orbs. Since the offender's avatar key is sent along, we cannot use hashing.
Signature will offer some level of protection, but the information we send to activate the orb is still open to attack.
Having the option to create encrypted communication between HUD and orb would greatly increase operational security.
You can also use encryption to ensure data protection to remote hosts as Jeremy Duport said, to ensure that that communication is harder to penetrate as it leaves the Second Life realm.
Ghost Menjou
Bugs Larnia While I am not against this function, you can add the hash at the end of the string you're sending with a seperator.
Generally what I do to prevent replay attacks is use unix time with a short. This guarantees the message is authentic and not faked by a third party. Specifically llHMAC, don't use other hashing functions as they are well. not HMAC.
You basically include your info + time.
You send info,time,hash over the clear wire and then on the other side build up the hash with info and time and compare it to received hash using the same hidden private key.
Additionally build in a check if time isn't outside of a short window.
This is the whole use case behind HMAC really.
Sure, offender uuid would be plain text but who cares, person's gonna know he's banned anyways.
Bugs Larnia
Ghost Menjou Making sure a message is authentic is not that hard. However, if you want to make sure that the message content itself cannot be intercepted and read, we do not have tools for that unless the message(s) sent are static.
Ghost Menjou
Bugs Larnia I am aware, but the particular use case mentioned was more of a call for HMAC which we have, but I do understand the need for encryption and fully support this canny.
Bleuhazenfurfle Resident
Encryption generates binary data, which LSL strings can't handle. So we'd have to have it encoded as hex or b64 or something.
Bugs Larnia
Bleuhazenfurfle Resident Yes, I should have mentioned that, sorry. Thanks for picking up on that!