Author Topic: Cryptography Implementation Discussion  (Read 18474 times)

unless the method will definitely forget up the entire thing, there is no reason to not include both and require them to do X walking/dancing/jumping/looking and 30 characters of random stuff via servercmd. we now have random position numbers, and random text-data.

can someone explain how also reading the other player's position/rotation IN ADDITION TO THE HOST would be bad?
It potentially leaves the RNG open to an injection attack, where the attacker knows the input to the seed generator and therefore predicts the output, and therefore the private key.

we also should think about some kind of "antivirus" or anti-tampering mechanism or something, if possible. Could we export the mod to main.cs upon first install, then whenever the game launches, the mod will be in ram. when the game shuts down, disable all other packages... maybe verify the integrity of the export function, somehow? and then write to the main.cs again? basically, by being the alpha mod loaded in and the omega mod shut down, we can circumvent other add-ons tampering

that's the theory anyway, it needs work. i've been putting thought into an "antivirus" mod for blockland, you see.
really not possible to make it tamper proof as you can just fetch an infected/normal main.cs.dso from a web server anywhere and put it in, and also the launcher will overwrite it. this isn't a client mod, it's a support mod.

Why dont you use the chat history?
That is something that only the host knows 100% of.

It potentially leaves the RNG open to an injection attack, where the attacker knows the input to the seed generator and therefore predicts the output, and therefore the private key.
no because they don't know the full data they only know theirs and any cohorts

I'd like to point out that all of the methods discussed seem to be vulnerable to a man-in-the-middle attack - Torque server commands aren't encrypted at all, so chat and a random seed command would both be visible to a determined attacker.

I'm not trying to provide problems with no solutions, it's just that I see the problems and can't find solutions. :(

Question, how would it be vulnerable to a man in the middle attack? Even though torque commands aren't encrypted they're only sent directly to the server. (Which could theoretically be spied on with a packet sniffer, but really nothing other than that)

If someone is impersonating the host from the beginning, then all is lost tbh.

It WOULD however be vulnerable to someone who say, has access to your server through the rtb control panel or one of the many remote control admin mods out there. Though that's really unavoidable.

no because they don't know the full data they only know theirs and any cohorts
Unless we decide to use twice the data, that would mean they have to guess half of the plaintext that would have had to guess in order to get the keys.

Or less. Depends.
« Last Edit: January 21, 2014, 03:52:14 PM by Ipquarx »

Could we use the complete chat history in addition to the CRC's of all the host's files?

Calculating the CRC's wouldn't be a problem because we could do that ahead of time.

So I got a working version of ECC in C# and tested out how long it takes to work.

Which is... around .01ms. Compared to 20000ms for torque. :V

We should just badger Badspot into writing ECC directly into the engine, kinda like how sha1 already is.

Personally, I think it would be more reasonable to have him write 64 bit integers and doubles into TS. That would give a MAJOR speedup and in general make lots of things much easier in TS.

Well, that too obviously. There are plenty of things that the engine desperately needs.

We should just badger Badspot into writing ECC directly into the engine, kinda like how sha1 already is.
nonono, not open source. crypto must be open source for it to be worth a damn. yes, the rest of the engine is closed source, so i guess that nullifies my point.
Personally, I think it would be more reasonable to have him write 64 bit integers and doubles into TS. That would give a MAJOR speedup and in general make lots of things much easier in TS.
i think this might be acceptable

nonono, not open source. crypto must be open source for it to be worth a damn.

He could just use an open-source crypto library.

At least 20 seconds for ECC is better than RSA, which would take 10 minutes+...

EDIT: I updated the math library in the GIT to the one I currently have. Things have been vastly improved so feel free to take a look at things!
« Last Edit: January 27, 2014, 03:18:52 PM by Ipquarx »

You should really change your rand.cs to:



You seem to still be using one using tiny values, unlike a proper BSD LCG.

i'm pretty sure we're not using that lcg, we need  one that's cryptographically strong. been a while since i've actually read the code, so it might've changed

yeah, to the best of my knowledge that hasn't been touched for months