Problems that can be addressed:(posted 9537 days ago)As for getting the key from outside source, that still makes the source code of TGMAME that gets the key public. Is the source of lynx not public because it requires a website to get an upgrade? i think so. just because you need information from a program from an outside source doesn't make it not public.
As for encrypting the whole inp file and introducing problems of it not playing back as well as not being compressable, i say it's not necessary. The only thing we need to verify is the times that the program is started and the time that the program is ended. As long as an honest recording takes 60 seconds to play, and its game fps is 60, then if there are 360 frames in the inp file that file is verified as long as you can verify the file was finished 60 seconds after it was created. You only need to encrypt the timestamps, which means you can still output a file that can be playedback by everyone, but ONLY verified by the person who knows the time sensitive key generation function and the decryption algorithm.
There are three downsides in keeping the key generating function in the mame executable: (1) the user can hack the system time, (2) the user can hack the key generating function and recreate their own valid timestamps, (3) the cheating code can be inserted backinto mame if the source is released.
There are two downside of keeping the key generating function on the net. (1) Mame players have to be online for the start and the end of recording a inp file, this can suck greatly because windows sometimes just hangs up and thus you might get the start time verified, you might not get the end time verified. (2) the program can still be hacked if people can insert the code that makes mame cheat into the executable which actually can be done easily if the source is released although it becomes more difficult with the digital timestamps needing to be refreshed.
There are plenty of free encryption algorithms, for this instance it should be good to find a least popular one (i have a link of some excellent encryption source that is free and won't be found on many search engine results) so that when compiled it won't easily be recognized as "such and such" kind of encryption assembler wise.
The best part is that those who compile mame don't have to know what the key is and the key changes each time you make a recording. But someone (a non marper please) would have to come up with a key generation function, that hashes, crcs, and/or encrypts the time in a complicated maner so that you get a unique key for each time it is run.
I've got a design of how everything would work in detail, if anyone wants to listen to more propaganda... I think i've solved all problems except the reinsertion of the cheat code if the source is released.