For reasons of security INSIM cannot send setup data, but i've noticed a few ideas, leagues and public servers rely on fixed setups. What if instead of setup data we could send a checksum?
struct IS_SET // Setup Checksum, for checking if a player has an approved setup without being able to read setup information { byte Size; // 12 byte Type; // ISP_SET byte ReqI; // 0 unless this is a reply to an TINY_NPL request byte PLID; // player's unique id
byte brakes // checksum for brakes byte rideheight // checksum for ride height byte suspension // checksum for suspension byte steering // checksum for steering
byte diff // checksum for differential byte gears // checksum for gear ratios byte downforce // checksum for downforce byte spare // unused };
// ENUMERATIONS FOR PACKET TYPES // =============================
enum // the second byte of any packet is one of these ISP_SET, // 50 - request set
I like this idea too, but I think that with some effort it can be done even without having the support for setup checksum in InSim I also think that MD5 would work here just fine as you're not trying to hide anything.
MD5 would be needlessly large, an old fashioned 1 or maybe even 2 byte checksum is perfectly adequate for the task.
No fancy technology needed, just good old 70's-80's coding technique Just comparing the checksum of what each user has as opposed to what they should have, with the setup divided into areas for "fixed gearing" or "fixed suspension" series etc.
I was thinking more of taking the whole .set file and calculating it's MD5. It would require a bit more data, but it would be a lifetime solution, no matter what extra setup options we might get...
I guess that her point was that most people are not usually eager to share setups and sending it through the net is the best way of letting someone get his hands on it. Checksum is also a better option size-wise.
Well there are two approaches to fixed setups, one is to forceably send a setup, but what if a series defines suspension as fixed but allowes flexible gearing etc. A fixed setup would not be compatible with this.
That's why I took the approach of a checksum of parts of the car setup, but I must admit to being fond of a public server being able to deliver a fixed setup too.
Imagine we are practing for a league race, some leagues racers preffer to keep their sets to themselves until after a big race. Especially if ones fuel strategy might be summised from tyre compound/pressure choice. It would not be right for INSIM to be able to capture exact specifics of a setup, but sending a checksum instead gets around this.
A checksum is a single value derived from the multiple input values (ie: 1st gear ratio, 2nd, 3rd, ... 6th, final gear ratio all added together bitwise), from the checksum it is not possible to extropolate what the setting for each field is - but because any change in the input value would effect the resulting checksum it is possible to detect if somebody is running a setup that conforms to series rules by comparing their checksum to the checksum generated by the leagues fixed setup.
OK, gotcha.
I thought that was what you meant by security but wanted to double-check before getting into the difficulties I can foresee... (Which you may have already considered of course )
The way I see it, you're torn between two slightly conflicting goals, which I can best demonstrate by extreme examples.
If you used a very small checksum, e.g. just 2 bits long, nobody could reverse-engineer the setup from that. BUT anyone who wanted to could trivially come up with an entirely different setup which matched that checksum, provided the algorithm to generate the checksum was known. (Just keep tweaking some fairly unimportant value(s) by small amounts until the checksum matched.)
Or... use a very long checksum, e.g. 128 bits, and it gets very difficult to find a different setup which has the same checksum - wonderful, nobody can cheat. BUT if the range of legal values in the fields used to generate the checksum is modest enough, then it becomes easy to reverse-engineer that portion of the set.
Now, having had a quick look at the setup file format, and a wee bit of testing to see what LFS actually saves (and loads, and resaves) into the wider fields (floating point and integer), I suspect that if you go for more or less the whole set in a single checksum you've probably got a good chance of making it work. Right off the top of my head I'd imagine you would need at least a 32-bit checksum, to avoid cheating, but I haven't attempted the arithmetic for this yet.
You're right that it does need to be more than a byte, 256 options does allow for the possibility of recreating a similarly compatable setup. I'm not convinced 32 bytes are needed, 65536 possible combinations should be sufficiently daunting (2 bytes).
The maths to generate a sufficiently random checksum is of no real consequence, if the numbers come out too similar than all you do is use each field as a seed for a random number generation - then use those random numbers on a bitwise XOR and you've got yourself a totally random but consistent checksum.
Hi Becky
Well, 2^16 would certainly be daunting to a human. But since it's easy to write a program to construct sets by tweaking values of certain parameters within reasonable ranges, this would be no obstacle to a brute-force approach.
Yup - if you get this bit "right" (md5 nearly got it right ) then there's no way other than brute force to go from the checksum to the original "plain" text, i.e the setup the person is using, or indeed from a setup to a subtly different one with the required checksum. But it could be done, and the only thing I can see that will stop this is if it's too hard to brute-force calculate the checksums (i.e. too many of them). If you simply make the checksum contain less information by shortening it, then many credible setups will exist which have the same checksum, preventing setup theft but allowing cheating (i.e. non-compliant setups).
I did some more tinkering, and saw some slightly inconsistent things. A patched version of LFS with newly added checksum behaviour could be altered to change any/all of this behaviour, but at present, some of the "floating point" fields behave quite differently from each other.
For example: if you drag the slider on ride height, the float that gets saved into the SET file will often have 7+ significant figures (e.g. 0.2671592), while if you just click the up/down arrows you get something with 3 significant figures (e.g. 0.256).
However, if you do the same things with bump damping, then both the slider and the arrows will give you the same precision - no more than 3 significant figures (e.g. 10700, for 10.7 Ns/mm).
You can get around this limitation for (I think) ALL of the float values by tweaking the file by hand with a hex editor, for example entering 10701.23 in the bump damping setting. This will load fine, and LFS will even save that value back to the set if you change a different value in the set. That way, you'd be able to use quite a lot of the bits in the 32 bit floating point mantissa to make it harder for someone to reverse engineer your set.
The same trick applies to some integer values where not all possible settings are used by the LFS setup editor (e.g. gear ratios). It would of course be a royal pain in the arse to have to do this by hand, but it would be trivial to write a setup obfuscator to modify the less significant bits of some appropriate setup parameters. (Still a bit of a pain though! )
I made a rough estimate, assuming you could obfuscate all float and integer fields to pretty much the max (so probably a little optimistic), and got a total of just over 500 bits worth of information for a FOX setup. (That's ignoring fields like the centre diff, which you might also get away with filling with junk.) This isn't bad for a 132 byte file (1056 bits). And I reckon 2^500 (roughly 10^150) is more sets than anyone could reasonably be expected to search for the correct checksum.
But that's not the whole story, because the set needs to be driveable. So the real range of credible values for bump damping for a FOX is probably quite a lot less - another rough estimate puts it at around 350 bits. This is still way more than enough to prevent a brute force attack.
But if we then weakened it by either or both of:
* splitting up the setup into pieces
* only using the up/down arrows to change settings
then the number of bits contributing to the checksum could be massively reduced.
Looking at your proposed split of setup checksums above, I'd guess that the most complex of them wouldn't have much more than 20 bits of genuine information going into them (regardless of checksum length) if no special measures were taken. This is only 10^6 setups to check, which would be trivial.
The basic idea is still totally viable though - this (long, sorry!) posting just shows it isn't trivial to prevent cheating and at the same time prevent setup theft.
I think (I'm not a crypto expert) that to "fix" it properly, Scawen would simply need to add extra info (let's call it junk DNA) to the setup file within each sub-area to be used for setup checksumming, and combine this with a cryptographically secure checksum (to prevent cheating). The logic about when to scramble the junk DNA would need a little thought, but it's late and my central heating has been off for nearly two hours and I'm bloody freezing, not to mention sleepy so I'll stop rambling now
)