0

If i have a string with 1024 chars and a simple xor algorithm would it be still easily crackable ?

const unsigned char Key[1024] = {0x.........};

void EncodeBuffer(unsigned char Buffer[],unsigned int Size) {
    unsigned int i = 0,c = 0;
    while (i < Size) {
         while(c < 1024)
              Buffer[i] ^= Key[c++];
         i++;
         c = 0;
    }
}
Hasturkun
  • 35,395
  • 6
  • 71
  • 104
HMVC
  • 99
  • 1
  • 11
  • 1
    If someone can trick you it encrypting an already encrypted text that would be bad. – Thilo Sep 11 '13 at 11:44
  • 1
    Of course it is. Its _strength_ (if you want to call it in this way) is that crackers don't know the algorithm (but of course this is a pretty weak point, especially if they can see both plain and encrypted text). More or less it's just **little bit** better than no encryption at all. – Adriano Repetti Sep 11 '13 at 11:44
  • 3
    This question appears to be off-topic because it is about encryption, rather than programming. It might be on topic on [crypto.se]. – Hasturkun Sep 11 '13 at 11:47
  • 4
    @Adriano: Obscurity gives little to no security. XORing data with a unique random key might be secure (so long as the key is never reused and is at least as long as the message) – Hasturkun Sep 11 '13 at 11:50
  • What if i strengthen the algorithm and added 10 different operations and didn't reuse the key,would that be enough ? – HMVC Sep 11 '13 at 11:50
  • Looks to me like that will work pretty well, since buffer will be zero when you're done. Pretty hard to decode that. – Hot Licks Sep 11 '13 at 11:50
  • 1
    If it would implement a proper XOR encoding with a key that is a long as the message and never reused, then that is all the security that is needed and not possible to decrypt. If those conditions don't hold, obfuscating doesn't usually give you more security. Especially, when logical operations are involved, one might end up doing 10 things that amount to 1. – dornhege Sep 11 '13 at 11:53
  • A simple but pretty unbreakable code is to use some random object (eg, the bytes of an image, or an mp3 file) as your XOR key. However, such objects tend to have repeated bytes, so you'd want to run the key thorough some sort of randomizer first. Then the key can be any length and can be, eg, a file on a 3rd party web page, known to sender and receiver. – Hot Licks Sep 11 '13 at 11:54
  • @HotLicks XORing is not **secure** at all because a key can't be random unless you save it somewhere. Moreover if they can access both plain and encrypted data then it can be broken in few minutes (of course by someone who knows what he is doing). The point is to define **what is secure in this context**. If he's encrypting game's data then it _may_ be enough, if he's saving my password to access sensible informations then...I hope I won't ever use that program. – Adriano Repetti Sep 11 '13 at 12:01
  • Look, if somebody feeds several similar strings to your algorithm and investigates the output, it'll be very easy to figure out the algorithm, because you didn't even try to change bit order or something. Get a cryptography library and use it instead of homebrew solutions. That is - if you want security. – SigTerm Sep 11 '13 at 12:23
  • @Adriano - The point is, the object supplying the key (the "shared secret") can easily be known to sender and receiver and no one else. There are millions of images and sound files on the web, so the would-be code breaker has an impossible task to find the one file. And it can vary daily -- on Tuesdays the second image on some CNN web page, eg, and on Wednesdays a podcast from the Fox News site. – Hot Licks Sep 11 '13 at 12:50
  • @HotLicks the point is that...even if the key is secret (like any password or cypher phrase) then it can be easy broken. **The only _secret_ here is the algorithm itself** (because they have first to investigate it). If it's known then they can break the encryption in less than 1 second...that's why this is not used for secure communication, it doesn't matter how often you change the key! If someone want to break it **even 64 bits DES is NOT secure, do you really think a simple XOR can be? Seriously???** Perfect to encrypt personal notes stored on your (desktop!) computer but else... – Adriano Repetti Sep 11 '13 at 12:59
  • 3
    @Adriano - Do you even understand what a one-time pad is?? – Hot Licks Sep 11 '13 at 13:02
  • @SigTerm I agree, I can't explain that any variation of a XOR algorithm is NOT secure at all. It'll just obfuscate data little bit (of course this can be perfectly valid in some circumstances but the main point is WHERE it is used). Even a _stupid_ "NOT" of each bit can be enough for obfuscation purposes... – Adriano Repetti Sep 11 '13 at 13:04
  • @HotLicks Do you even can show me one real world application where it can be used? Moreover would you feel to **suggest someone to use it** if we don't even know in **which context**? – Adriano Repetti Sep 11 '13 at 13:07
  • @HotLicks: When algorithm uses "obscurity for security", it'll be cracked/compromised for good at the moment somebody gets physical(or administrative) access to the machine that uses this algorithm - because nothing is safe from cracking on a machine that can be physically accessed by somebody. It'll be better to use well-known non-secret algorithm that can't be cracked unless you get private key. Even if key is compromised (which will be your fault), it can be replaced, which will be easier than replacing entire encryption algorithm. – SigTerm Sep 11 '13 at 13:21
  • 3
    I agree the OP's original scheme use "security by obscurity", but there's no "security by obscurity" issue with a one-time pad. There is a "shared secret", but that's true of any bidirectional cipher, and of course securing that "secret" is critical. – Hot Licks Sep 11 '13 at 13:50
  • @HotLicks one-time pad can be used in so few corner cases that I wouldn't even consider it in any application that uses encryption. That's why I wouldn't mention it when everything we know about the domain is...10 lines of code. – Adriano Repetti Sep 11 '13 at 14:10
  • 4
    @Adriano: XORing your data with, say, a keystream generated by encrypting a counter with AES ([CTR mode](http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29)) is fairly safe and known. XOR isn't the problem. – Hasturkun Sep 11 '13 at 14:24
  • @Hasturkun I'm not talking about XOR itself but this encryption technique. That generator will just make the key random _enough_ but I assumed it is (otherwise no sense to talk about it). The problem is that if attacker can send a known sequence then he can do analysis on results. Doing that it'll make the sequence (used as key) predictable and that will break encryption (by definition). – Adriano Repetti Sep 11 '13 at 14:38
  • @Adriano: Of course, assuming a fixed repeating key, convincing your victim to encode a large array of zeros should reveal the key. – Hasturkun Sep 11 '13 at 16:09
  • 1
    @Adriano you can talk until the end of the world, but if you have a big enough random *key stream* then a one time pad is certainly an option. Knowing anything about the plain text won't help you one bit. Any mistakes during the generation the key stream - including reuse - is obviously fatal. But if that would be an issue, then CTR mode encryption would not be safe either. I agree that if the key is stored as bytes in class that is doing encryption that reuse is likely and probably fatal. – Maarten Bodewes Sep 11 '13 at 16:09
  • @owlstead as I replied in the comment to one answer and I tried to explain in other comments: we don't know the context. Is this used to send secured data through Internet? Cracker can only sniff or he can even send data? – Adriano Repetti Sep 11 '13 at 18:18
  • @Hasturkun as I said the problem is when he can send data to do his analysis. Of course if he can only sniff then (assuming the best possible quality for the key) there is not any problem with this. – Adriano Repetti Sep 11 '13 at 18:20

1 Answers1

5

First of all, your algorithm doesn't do what you probably think it does. You end up xoring every byte of Buffer with every byte of Key, which really means that you're xoring every byte of Buffer with the same byte. What you probably meant was something like this:

const unsigned char Key[1024] = {0x.........};

void EncodeBuffer(unsigned char Buffer[],unsigned int Size) {
    unsigned int i = 0;
    while (i < Size) {
        //Each byte of the buffer is xor'd with a byte of the key
        //Each byte of the key may be used for more than one byte in the buffer (insecure)
        Buffer[i] ^= Key[i % 1024];
        i++;
    }
}

Now, this is a bit more secure, but not secure enough for the real world. The more you encrypt with this, the easier it will be for attackers to guess the key. Additionally, if the attacker can see the source code (or even the compiled binary), they will have the key.

What you're likely looking for is a one-time pad, which requires a key at least the length of the input.

By the way, if you're trying to write this to use in any sort of real-world situation, I suggest you don't and just use an existing encryption library. This stuff is hard to get right, and there are enough people working on this that it's better to save yourself (not to mention your customers) the headaches of dealing with buggy encryption.

Eric Finn
  • 8,629
  • 3
  • 33
  • 42
  • 1
    Probably should remove the second i++.. – Mats Petersson Sep 11 '13 at 11:51
  • 3
    And instead of the nested loops a Key[i % 1024]. – dornhege Sep 11 '13 at 11:55
  • Even encrypting each character with next one can work pretty well (and given it may be little bit more tricky to decode because same character will be encoded in different ways in different texts (for example "THIS" and "THAT", with a fixed key both H will be encoded to the same value but with his "trick" they won't). That said should it be secure encrypting? **Would you like to store your home banking sensible data in a program with this encryption?**. He should first say WHERE he needs encryption and why. Moreover modern almost every OS has easy to use function for safer encrypting... – Adriano Repetti Sep 11 '13 at 12:06
  • 1
    +1 Great answer. Pointing out the OP's error highlights the fact that its easy to get event the simplest encryption wrong. The link for one time pad is helpful. – Caleb Sep 11 '13 at 12:37
  • +/-1 I agree with last sentence: "_...if you're trying to write this to use in any sort of real-world situation, I suggest you don't and just use an existing encryption library..._". If he needs security then he has to do it right, if he needs obfuscation then even something simpler can work for him. – Adriano Repetti Sep 11 '13 at 13:18