• Forum
  • Lounge
  • I invite you to my little open-source pr

 
I invite you to my little open-source project!

Pages: 12
Hello forum,

A few days ago I started a little project with my friend.
The goal is to make an encryption utility which can encrypt and decrypt files using various algorithms. So far we have XOR, Vigenère and Caesar cipher, with RC4 and TEA on the way! We'll try not to use an encryption library and instead write the implementations ourselves (after all, we do this to learn!).
Feel free to give feedback or even contribute :)

http://code.google.com/p/encryptor/

The program is in alpha stage, this means it WORKS, but is far from the final product (especially GUI-wise).

Cheers,

Xander

PS: I also finally learned to use source control (using svn). A must-have for all my future projects!
Last edited on
I see you're using Qt... I approve :)

I also haven't looked at your encrypt() and decrypt() functions, but I'm curious as to how you're implementing them. Personally I would have them take a pointer to a function (whatever the actual encryption you want to perform is), so that you only have to deal with one encrypt() function that encrypts in whatever manner you tell it too :)

Good luck with the project.
Last edited on
¿why GUI? I would prefer read from stdin, write to stdout and command line options
Try to separate the interface from the 'actual program'
By instance, there shouldn't be a QMessageBox or a QElapsedTimer in the Xor::encrypt method.

1
2
3
4
5
6
7
8
9
        //start encryption
        unsigned i = 0; 
        for(long long j = 0; j < blocksize; j++)
        {
            i++;
            if(i > key.size())
                i = 0;
            buffer[j] = key[i] ^ buffer[j];
        }
I found more clear
1
2
for(size_t K=0; K<blocksize; ++K) //blocksize is not too big to need long long
  buffer[K] ^= key[ (K+1)%key.size() ]; //¿why are you using K+1?  


Edit: you are using key[ key.size() ] in the encryption
Last edited on
closed account (3hM2Nwbp)
One addition that I'd recommend is support for encrypting byte arrays as well as files. That support is inherently available through file encryption, sure, but an interface for byte-array-specific encryption would in my opinion be a huge plus.

* I've recently had to encrypt data for transport over the wire, and I actually had a hard enough time figuring out how to do that with the multitudes of libraries available. They all seemed so cryptic in how they operate.

** Another little tidbit that would be attractive would be to provide current stable binary builds for multiple platforms. Building from source is, to some, an annoyance, and to others, an impossibility due to inexperience.
Last edited on
It seems like most of you checked the source r4 package out, it is completely outdated.
I'll upload the most recent snapshot as a .rar tonight :)
i would like to join I can do grunt work if you will have me
Sure man, but please explain "grunt work" :p
** Another little tidbit that would be attractive would be to provide current stable binary builds for multiple platforms. Building from source is, to some, an annoyance, and to others, an impossibility due to inexperience.


Fair point, but building from source isn't that hard :/ It takes around two minutes to cd to the right directory and type "make." And how many people that are using an encryption program don't know how to "open up that little black box" and type a few things.
When I followed instructions (even copypasted a bat file) the "little black box" told me that 'make' is not supported on the version of Windows I have ;p
Last edited on
xD, well who builds from Windows anyways? Linux <3
When I use my windows laptop (with MinGW) my make command is mingw32-make.
Might try that :)
grunt work would be doing coding that no one would want to do, or that needs doing because someone else is working on something important
You can work on whatever you want, we can ALWAYS roll back to a previous revision if something goes wrong!
PM me your email and I'll add you!

EDIT: As suggested by ne555, we seperated the functionality from the interface :)
Last edited on
Remember that if you've got any virtual method, you ought to make the destructor virtual.

It seems that your dialogs are leaking, wonder if there is a good way to get rid of that pointer and use an object.
What do you mean, my dialogs are leaking?
And i dont need to write a destructor because Qt automatically handles it :)
I'm talking about EncryptDialog::EncryptionAlgorithm* algorithm;
You aren't deleting it.

There is one in update(), but you reconstruct it afterwards. ¿why don't just use the assignment operator? As the dialog is coupled with the algorithm, there is no danger of 'base slice'.
That sounds familliar...
I would love to join, this would actually be my first Open source project, i have been looking around for a while to join a project and this one seems interesting.

can you elaborate on the current community and support
Haha there is no real "community" yet. You can only expect somewhat of a community from really big projects like jmonkeyengine. Currently were 3 developers who contribute in their spare time.
Suggestion: add key file option for XOR encryption, because:

1) The 0 is a neutral operand for XOR, so by encrypting binary files with lots of 0's, part of the (or even the whole!) password may be visible when opening the encrypted file in a hex editor.

2) The password could also be deduced if your adversary knows what kind of data you encrypted, by extracting it from the file format.

Also this:
1
2
3
4
5
6
7
8
9
10
11
12
13
void Vigenere::encrypt(std::ifstream &in, std::ofstream &out)
{
    std::string::const_iterator keyChr = key.begin();

    // Start the encryption
    char chr;
    while(in.get(chr) && out)
    {
        out<<char(chr ^ (*keyChr)); // shouldn't this be a `+'?
        if(++keyChr == key.end())
            keyChr = key.begin();
    }
}


Edit: grammar, typos and gone testing.
Last edited on
Damn right that should be a +!
And what can we do about the first point? It won't change when we have a key file, or will it?
Pages: 12