User talk:RavynousHunter/GEP

Errmmmm.... decryption ftw? And is the source code available for review, or must I reverse engineer the 20kB .exe? --◄mendel► 11:47, 10 December 2008 (UTC)
 * It decrypts it's own files, it'd be kind of pointless to make an encrypter that wasn't capable of decrypting it's own files. I just figured that one would assume that would be the case, apparently I was wrong, ammending...  [[Image:RHSig.jpg]] talk 10:05, 11 December 2008 (UTC)
 * Hmm, I wouldn't call XOR 128 "encryption", but maybe that's just me... --◄mendel► 16:20, 11 December 2008 (UTC)
 * Would "obfuscation" be better? This isn't for those who want some omgwtfbbq encryption so the guvment can't get their seekrit docs.  This is more geared toward people who have things on their computers they don't want others to see; maybe homework, papers, code, porn, the point isn't to provide some super-secure encryption, it's to fool and/or confound those who are otherwise incapable of figuring something like this out.  You'd be surprised how well something as simple as this can work...  [[Image:RHSig.jpg]] talk 03:50, 13 December 2008 (UTC)
 * On most parents it would work well. Obfucating computer game text files this way doesn't work all that well, though. To provide excellent encryption without much more effort, require the name of another big file (a compressed file or image works best) to be given. Skip the first 1% of the big file (to avoid identifying header information that contains constant parts across different files of the same type). Use key=0xAA as a starting value. Then XOR each byte in the plaintext with key and a byte in the cyphertext; store the result as ciphertext and use it as the new value for key. As long as your key file is longer than the text you want to encrypt, and if it is truly random (do not use a random number generator!), this encryption is impossible to break without the key (which could be stored on an USB stick or burned to a CDR). If your key file is shorter than your plaintext, you have to re-use it from the start, which removes some security, but would still be fairly hard to crack. Of course the encryption is completely reversed by using the same operation (with the same key file) on the encrypted file. If you put it into a function, you don't have to write it twice into your program (like you did with the XOR 128 part). --◄mendel► 09:54, 13 December 2008 (UTC)
 * The reversal needs to take into account that it is the cyphertext byte that is used for encrypting the next byte, and as such in the decryption phase the next key byte is not the result of the previous decryption step, but rather its input (and XOR the next key file byte, of course). --◄mendel► 09:59, 13 December 2008 (UTC)
 * Might be in v1.1 or v1.2, but I think I'd like to get multi-file support in first. Haven't seen how well VC++ 2008 Express handles GUI apps, I know in VS.Net 2003 Acad, it can be a bitch.  Just too bad I don't know much about filestreams in C#.  If ya happen to have any other suggestions, tho, keep 'em coming.  [[Image:RHSig.jpg]] talk 12:05, 13 December 2008 (UTC)

v1.1
Well, I've started work on v1.1, this one will have a GUI instead of a CLI (considering VC++ was giving me problems with command-line arguments). So... In lieu of using multiple forms, I decided to use a tab control which is, imo, more reliable overall. Sooo... Yeah...  I'll keep those interested parties informed as I go on. talk 13:35, 13 December 2008 (UTC)
 * Ugh, it seems to be much the same as before, IntelliSense, the nice little thing MS made to give you the names of all applicable functions and whatnot, does not want to cooperate at all with a CLR C++ app. So I'm looking at VC# 2008 Express, and learning how FileStreams work there.  ::sigh:: [[Image:RHSig.jpg]] talk 14:12, 13 December 2008 (UTC)