3
$\begingroup$

Client and server have given generator 3 and modulus which is 256 bit prime same all the time for all clients and server (simply hardcoded).

They both generate a private exponent and send result to each other and generate secure key. This all is done over insecure channel. That's all simple Diffie-Hellman exchange.

After this step every sent packet is encrypted over simple XOR block cipher by secure key's bytes, in this case 256bit long block.

Is this way of encryption any secure and if yes, how much, if no, what are ways to reverse it, as it is so simple and doesn't use much resources?

Improve this question
$\endgroup$
1
  • $\begingroup$ Apart from the XOR weaknesses already noted, you should also be aware that "simple Diffie-Hellman" is trivially vulnerable to a man-in-the-middle attack unless you extend it with some way of verifying that you're in fact talking to who you think you're talking to during the key exchange. You need either a shared secret and a MAC or some kind of public-key signing of the $g^x$ values. $\endgroup$ Commented Sep 10, 2015 at 0:32

3 Answers 3

Reset to default
1
$\begingroup$

After this step every sent packet is encrypted over simple XOR block cipher by secure key's bytes, in this case 256bit long block.

Does this mean "divide the message into 256-bit blocks, and XOR each block with the key"? If so, this is very insecure. If any part of the message is predictable, the attacker can recover part or all of the key, and potentially decrypt the rest of the message and any future messages under that key.

Another problem: if the attacker has some knowledge of the structure of the plaintext (e.g. it's a JSON object), they can tamper with the message to change what it says.

The usual solution to these problems is to use the key with an authenticated encryption mode like AES-GCM.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Data are binary, serialized hash-map. How does AES-GCM performance compare to simple XOR in number of operations to be done and what would be maximal key length? $\endgroup$ Commented Sep 9, 2015 at 19:22
  • 1
    $\begingroup$ AES-GCM is way slower, but it's not really a useful comparison. This XOR scheme provides approximately zero protection in any real-world situation. (and if security isn't important, then why encrypt it all?) $\endgroup$ Commented Sep 9, 2015 at 19:26
  • $\begingroup$ As I look over AES-GCM now, how should be AAD and Nonce generated then when only secret key is known on both sides? Or can it be hardcoded as well? $\endgroup$ Commented Sep 9, 2015 at 19:48
  • 1
    $\begingroup$ AAD is optional, you can leave it out. Nonce can be randomly generated each time you encrypt, and transmitted unencrypted (it just has to be different each time). $\endgroup$ Commented Sep 9, 2015 at 19:54
2
$\begingroup$

In addition to the problems that user595228 has mentioned, well, an attacker can easily solve a discrete log modulo a 256 bit prime; from that, he can recompute the shared secret, and that would give him the entire message. To be secure, you really need at least a 1024 bit prime; with a 2048 bit prime being greatly preferred.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Well, even 8192 bits long prime is not problem, so are you saying that XOR cipher with big enough prime could be secure as well? $\endgroup$ Commented Sep 9, 2015 at 19:46
  • $\begingroup$ @jakubinf: no, you still have to worry about the attacks that uer595228 pointed out. $\endgroup$ Commented Sep 9, 2015 at 19:48
0
$\begingroup$

If you want this scheme to be any kind of practically secure, each XOR block cipher will need a dedicated one-time-use key. This can be done if you use the private/public key exchange in a way the public key is randomly generated per block. This way, each block will use a different key.

However, this comes with drawbacks. Increased compute time, increased difficulty in managing keys, longer messages make key management much more difficult, and any out-of-order key will break decrypting the message(s).

You could get around this by keeping the public key the same and generating a number of random private keys, since they are kept in storage on each host machine anyways, per each 256bit block and storing the private keys in sequence of the XOR order which will be message-dependent. In this way, you basically get a one-time-pad per 256 bits which exponentially increases, mathematically, the decryption attack difficulty.

For the end of the message, if the last block is less than 256 bits, you will need to pad with random bits somehow so all 256 bit blocks are the same size but also be able to remove those random bits when the intended receiver of the message decrypts. If you want to increase the difficulty, you can set the number of XOR rounds to the number of 256 bit blocks. The more blocks, the more rounds.

I am not suggesting this as a fool-proof, mathematically unbreakable, method for using XOR encryption, but it is a cool concept to play with. Especially if it is just to keep casual users from seeing contents of a message or file.

Improve this answer
$\endgroup$