Hacker News new | past | comments | ask | show | jobs | submit login

Using XOR is terrible. The fact that they only apply it to the first 128 bytes of the file is even worse.



I think the author is overreact / grandstand, it's not fair to say this app encrypted nothing - I decompiled the code and found it at least does encrypted the SMS/Call logs data, using AES. Secondly,maybe only XOR the front 128bit for video/image files is not secure enough, but anyone who has a brain knows that, considering the computing power of most Android phone, using strong algorithm to encrypt a whole media(e.g. video) file is hardly realistic, even unwise -- unless you can tolerate a long decrypting decrypting process before playing a video. BTW, I read through the description of Vault Google Play page, there is nothing says it sales the ability of encrypt data, it just claims to "Hide some xxx on your phone" -- for that purpose XOR is enough


Don't most popular video formats essentially store certain frames as complete images, and then store frame to frame differences to cover the video between frames?

If so, I wonder how effective it would be to encrypt just the complete frames, leaving the frame differences for the in between frames unencrypted?


That would not be very semantically secure; while you could not see exactly what the original image was, you could still make out the movement. That would sort of be the analog of the ECB penguin on moving pictures.


I think actually there is nothing worse than using XOR, full stop.


XOR is not, by itself, a problem. Heck, the most secure encryption method on the entire planet, the one time pad[1], is just an XOR of some secret bytes with a plaintext. XOR is also one of two fundamental building blocks of the current state-of-the-art AES-256 encryption algorithm[2] (the other being a series of bit shifts).

The problem here is deriving something so simple from the key, and only applying it to the first 128 bytes. This is unforgivably dumb, when there are perfectly serviceable encryption services available as part of open source libraries, such as the aforementioned AES-256 algorithm.

[1]: http://en.wikipedia.org/wiki/One-time_pad [2]: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Th...


XOR is only one implementation of one time pad, it is also commonly used with modular addition. If you do it with letters then it effectively becomes a Vigenère cipher with a long key.

The one-time-pad is a special case of any number of poly-alphabetic substitution ciphers, XOR just being one that happens to be implemented on lots of silicon. Considering this is all about an app that has very short keys (a few numeric digits) it's perfectly legitimate to criticise the use of a substitution cipher as they are especially poor when used with short keys compared to real crypto libraries that will use that short key as the passphrase for a real key.


Well it's not the XOR that's special, it's the secret part that is. Without the value being secret, it might as well not be encrypted.


When I said XOR I meant XOR with a one-byte key on every character of input. e.g.

    char* xor_encrypt(char* input, char key) {
        int i;
        int m = sizeof(input);
        output = (char*)malloc((int) m + 1);
        
        for (i = 0; i < m; i++) {
            output[i] = input[i] ^ key;
        }
        output[m] = 0;
        
        return output;
    }



you could put a couple of NULLs in front of the file so its unreadable and claim its encrypted :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: