Topic: Non-gaming related project

[iq_132]

Here's a little file encryption program I've been working on.

I've mostly been using file compression programs to check the results for
easily recognizable patterns.  7zip, winrar (rar/zip), have been unable
to find any sort of usable patterns.  This doesn't mean that the
encryption is unbreakable, but for every day use, it is pretty evil.

Files up to 4GB are supported
Passwords of any length are supported
Password files (which should increase security), of any size, are supported
Passwords are case sensitive
The same routine is used for encryption/decryption
The algorithm is fairly simple, but extremely effective
The amount of ram used is easily set in the source (BLOCK_SIZE) but must be a power of 16
The source is very short and simple

[iq_132]

Here's an update to this...

More-or-less the same, just more evil. ^^

[CaptainCPS]

Here's an update to this...

More-or-less the same, just more evil. ^^

Interesting   , ...do you think a Cracker Team could reverse the encryption easily or you think it could take them some time to figure out the way to hack them?, just curious ^^u

SeeYaa!
 

[iq_132]

Interesting   , ...do you think a Cracker Team could reverse the encryption easily or you think it could take them some time to figure out the way to hack them?, just curious ^^u

SeeYaa!
 

I honestly don't know.  But using a large key file greatly increases the security of any encryption program.
I simply went on how well the files compress (any patterns will compress using 7z/RAR/Zip), how different the files are when you change a single byte of a short key, etc.  Just so you know, I tried a dozen different compression programs and none of them managed to find any sort of pattern. ^^

[iq_132]

Quite a lot's changed:
A third (32-bit) xor based on exponents was added
Xor2 is quite a bit more devious now that the &'s are generated and not static
The tables are now generated every 64kb instead of 1mb (less ram, and tighter security)
An initial table generation helps resolve some repeated patterns in the first use if a similar key is used
All of the xor routines have tighter integration, they all rely more heavily on each other (there are pros and cons to this...)
All important variables should be cleared now (nothing that is a security risk should stay)

[iq_132]

Fixed a crash if not using a key file.

[iq_132]

Fixed another crash (if the file size >= 64kb)
Adjusted the use of the key, it should make full use of a key 8bytes to 64kb in size
It is now MUCH slower (I've removed a few speedups that reduced security)
The key size MUST be greater than 7 bytes, and less than or equal to 64kb

[iq_132]

Fixed a small mistake -- greatly increasing security.

[iq_132]

Added another light XOR to the xor2 - use of  this may be expanded later (could be nasty)
Adjusted the key usage - for a medium sized file it should use all of a 64kb key
Adjusted the long XOR - all bits from Xor1, Xor2, and Xor3 are possibly used
bit 31 of xor2 is now used rather than being dumped immediately
Now clearing more variables in subroutines (increase in security)
Quite a big speedup - now compiled using the -O3 command of GCC

[iq_132]

Too much changed to list, really.

[iq_132]

Been screwing around with this a bit. It's been completely re-written.