Closed SoniEx2 closed 6 years ago
Some additional notes: Signing may be overkill. HMAC might also work just fine. Can also use Scrypt or something, but that might be about as overkill as Ed25519 signatures...
Not sure if there is a concept of "overkill crypto" tho. You'd think stronger crypto is always better...
Just encrypting Sha hash with AES would be enough. As for security considerations I'm not actually sure, but just appending signature to the blob looks good enough to me.
@magik6k HMAC is simpler as it only requires a hash function.
Also who even rolls their own crypto (MAC in this case)? D:
Am I the only one who cares about this?
Actually I like this idea, no need to bump, but I'll add feature suggested, and i'll let sangar decide if it is feature accepted/open-for-adoption
I suppose that could work, in principle. Is it worth it though? What are the actual, practical use-cases?
Saves space, loads faster (might wanna compile the OpenOS .lua files when installing - and/or add a cache to it, altho that'd be much more complex), etc.
The EEPROMs would get to fit a bit more Lua code than they currently do, I think. Assuming they still work the same way - I haven't played this mod in ages...
I'd use it for swap space memory
Ok so, assuming HMAC:
If string: (use cases: stored procedures or something)
If stream (function): (use cases: loading from file)
nil
, empty string, no value), compare the calculated HMAC with the provided HMAC, and continue/error as needed.load()
function.If mode
is just "b"
or just "t"
you can skip the type checks (remember to pass the mode on to the original load()
function!), but if mode
is "bt"
you need to do the checks.
Why would you need it to be signed though? To prevent code injection?
I investigated this feature in my emulator and found that using string.dump for memory swap would actually be an enormous undertaking and we'd have to parse the byte ourselves in some cases (for example serializing upvalues) So I don't find this worth it to support string.dump
swap? nah. this is just for stripping debug symbols and optionally precompiling each .lua file in OpenOS during install (so it can be installed on a machine with very little RAM and disk space).
y'know what would work for runtime RAM management? shrinking buffers/disk cache (buffer.lua) if the RAM is low.
Why not make it just check against a list of SHA hashes? The list could be provided by OC and plugin mods as they are already trusted to run code. While it'd be okay to allow dumping the string and adding that to a list of hashes in the save file, as it is kinda already loading right into memory from there with the whole persistence system, it's pointless because any modifications you'd want to make would fail the hash.
The point is not to make modifications. The point is to eliminate the "Lua parser" step (saves CPU time) and strip debug information (saves RAM and disk space). The former is done by simply loading bytecode. The latter is done with string.dump(f, true)
- this is built-in, at least in Lua 5.3.
Alright, in that case, then it could work and if implemented correctly should no worse in security than the current system of saving state.
string.dump()
should be replaced with a function that signs the resulting bytecode.load
should verify bytecode signatures.The signature should be generated server-side. There's no need to have more than one signature per server. The whole signature process should be done in Java/Scala so as to not leak the key. The key should be loaded into a
byte[]
every time it is to be used, and thebyte[]
should be cleared (set to 0) every time after use, so as to not leak the key. Thisbyte[]
should be global and synchronized, to reduce the risk of leaking the key.This lets you get all the benefits of bytecode (smaller size, faster loading, etc) without any of the drawbacks (because only bytecode produced by the server can be loaded).