06-11-2003, 07:49 PM
Quote:um... Mango??? You there???? ;*)
So...here's a compiled program I wrote in QB that encrypts/unencrypts.
http://www.tcdn.teiher.gr/upload/downloa...fileid=682
I'm posting the compiled version and not the source because it is so much easier to use. Just unzip then drop the file to be encrypted onto the EXE file...you will be prompted for a password and the encrypted file "filein.jkc" will be placed in the same directory with the original file. To unencrypt, just drop the encrypted file on the EXE and same deal...the unencrypted file will be "filein.ckj". You will have to change the extension back to its original value.
I've been learning about encryption on sci.crypt newsgroup. There's basically no easy way to break my scheme...however, I've learned of several potential weaknesses. I'm in the process of addressing these. I've actually written the code to address all the issues...but I haven't put it all together because the new version will, by necessity, produce an encrypted file that's slightly longer than the original...this means I need to come up with a uniform file-structure and file reader...If I'm going to make the effort, I want the program to be attractive enough that someone might actually use it. I bought a book on c++ yesterday, and plan to port my code as a way to learn c.
Anyway, the version I posted here works well and is very easy to use if you use the drag-n-drop method. If you simply launch the exe instead, you will find the file navigation very awkward (although it does work, once you understand it).
The main weaknesses in my scheme is the following:
if an attacker knows the contents of an encrypted file, he can steal the key...this is a major proplem...I addressed it by making the key dependent on both a checksum value and the password...this means that even if an attacker knows the contents of an encrypted file, the key he can recover will only unencrypt a file that happens to have the same 32-bit checksum and was encrypted with the same password...not likely to be of value to an attacker, since he *already* had the file he's attacking.
In addressing this issue, it is required to attach an encrypted version of the checksum to the original encrypted file. Then, to unencrypt the file, the user first unencrypts the checksum value (with a key derived from the encryptd file checksum and the password). This key is used to recover the original checksum which is then used (along with the password) to generate the file encryption key...and the file is unencrypted.
There are several subtilties to this...such as...with the newer scheme, the encrypted file is by necessity longer by the checksum...which means that the symmetry of encrypting and decrypting is lost...which means a file reader is needed to unencrypt. This has some advantages...such as the log file is no longer needed...rather it's easy to have the program output the original filename. It also gives the opportunity to carry additional info with the file such as a "request confirmation" flag, or a "USE XXXXXXXXX as password in reply" flag (encrypted, of course). All of this is going into V4.0...
Also...v4 uses shift registers so that I can generate the key 32-bits in parrallel, instead of 1-bit at a time. This has given me an approx 25x speed increase for key generation, which allows me to use much larger keys...anyway...even though I have my checksum code finalized, my key-update code secured, and the parallel key generation code working, I don't plan to create the unencrypter in BASIC.
The code that I compiled into this exe is 16 kb (with comments) and has 16 subs.
Cheers...