Talk:Why not make better password protection for RPG files?

Mike C. Zelda Classic Compresses and encrypts the quests (in that order). That makes them both small and reasonably secure. There's no reason why we can't do that.

Sure, they could grab a copy of the lumps from Playing.tmp, but Custom still won't edit it without a password. They'd have to circumvent that, or even write their own editor!

Or, in other words, seat belts are not 100% effective, but they do save lives.

Bob the Hamster I stand by my no-encryption stance. Encryption isn't a seat-belt, and people-editing-your-game isn't loss of life. However, I think compressing RPG files in the future would be fantastic.

FyreWulff Plus you have the people that forget the password to their games. With one-way encryption, once their game is encrypted, it's gone. With the current system, you can still 'unlock' their game for them. Yes, I did do the hard route and had TMC help come up with a way to keep people from editing Sword of Jade (which is working less and less with each update, which is part of the reason the patch for Jade will remove the password), but I think the honor system works very well. Just as long as all third party programs (like OHRgfx, etc) respect it. The only time it's really been violated was when someone released a program to remove the password from a game. Perhaps there should be some sort of a guideline article, like "I want to develop a program that edits/works with OHRRPGCE games, what should my program respect/do?"

Mike C. Well, clearly it couldn't be one way, or Game would have a hard time reading it.

Anyway, James, you can't claim that all encryption is useless. Sure, it may not keep out the most determined hackers who have nothing better to do for the X amount of time it takes to figure out the encryption, or who dump the memory or whatever.

I think it would be reasonable for Game to load up the RPG right into memory. Sword of Jade is what, 30 Megs (don't have access to it right now...)? Firefox is using 60 Megs, + whatever Task Manager doesn't show. 30 Megs is nothing, and it would eliminate the archaic unlumping method that few other games have used since... ever?

I know that everything I'm saying I'd have to do myself, but that doesn't make it invalid, or bad, or wrong.

Heck, I just thought... a brute force decryption attack would try different keys until it worked (i.e. you get valid data). But, if the RPG is then compressed, then valid data doesn't look like valid data, except for perhaps the signature at the beginning. Just food for thought...

Inferior Minion Also, OHR is opensouce, so anyone who wanted to extract the data just needs to come to this wiki where the encryption/decryption process will be documented. I don't see it accomplishing much at all. As it stands, the password protection is as effective as a locked door with the key sitting on the floor. If someone really wanted in, there's not much stopping them. It's keeping the honest people honest.

The Mad Cacti: I see no point in encryption either. On the other hand, it's actually easier to steal stuff out of PLAYING.TMP than out of an unpassworded RPG file :P But, there's not a really large need to specifically load an RPG file into memory, if you don't like PLAYING.TMP the next easiest alternative is probably to read data straight out of the RPG file. But... I don't have any arguments against it or anything, I suppose...

Compressed RPG files would be cool, but they would make it a pain for 3rd party utilities to support. I could never finish my 1024 byte assembly graphics extractor if I had to decompress the file! :( Still, RPG sizes can be pretty crazy.

Bob the Hamster If we compress the RPG, we would use a standard compression library like zlib or similar, which would not be difficult to use with other languages.

Oh, and I wasn't claiming that encryption is useless, just that perfect encryption is impossible when Alice=Eve.

As for playing.tmp, keeping certain data in-memory would be good. Keeping all lumps in memory would be very bad. Loading lumps directly from the RPG file rather than having an intermediate temporary file in playing.tmp could be good, depending on performance, but some lumps would probably still be best cached to disk. Descisions like this should be based on feature requirements, quality requirements, and actual perfomance testing and efficency testing. Security requirements are not the deciding factor.