# Is there any vulnerability in this scheme?

We want to design a symmetric encryption scheme. Note that the following things are true for our system:

1. The plaintext P will change every time for a given user.
2. A user will choose a password which may remain same for their lifetime
3. A 256-bit key K is derived by hashing the user's password(using SHA256).
4. We will need to encrypt plaintexts multiple times. However, it is guaranteed that each time, the plaintext will be different
5. Plaintext is guaranteed to be 256-bit.
6. Plaintext will be generated internally in the system and no one can access it.
7. Ciphertext will be in public domain. So a user in possession of password can derive plaintext.

If we use XOR-Cipher (C = P ^ K and P = C ^ K), is this system secure. Our alternative is to use AES or chacha20-poly1305. Will any of those offer any advantage over the XOR-Cipher scheme?

PS. We'll be using checksum(SHA of plaintext) in the xor-based system for integrity (as chacha-poly has MAC).

• Surely this is a multi pad cipher then, because the key is always the same, which is insecure. Theres more about this in the use and security tab of your wiki link – SamG101 Jan 4 at 14:22
• Could you elaborate on what way is this insecure? The use and security section raises three concerns. 1. Frequency analysis: since we are not repeating the key, this is not possible. 2. Known plaintext attack: it is practically impossible to know plaintext. Similarly, malleability isn't a concern I think because integrity is preserved using hash of the plaintext. – Orwell Jan 4 at 14:42
• Instead of your design, why don't you tell your actual problem that may have a simpler solution than yours? For example, using SHA256 for key derivation is a bad idea. You need something like PBKDF2 and get multiple keys. If there are multiple users that recieve the same data, then they can access others key if you use the simple x-or. – kelalaka Jan 4 at 17:14

This appears to be a one time pad cipher, turned into a multi time pad cipher, as the key remains the same for every different plaintext that is entered. This is a broken construction then - look at the "Use and Security" tab of your wiki link.

If AES for example is used, say CTR mode, using a counter, then it is secure, as long as the counter never repeats - basically becomes multi pad again.

For integrity checking, use a HMAC or similar with the key being the hash of the AES key, or with some HKDF extract and expand system. The problem with using just a hash is if someone changes the ciphertext, then they can recompute the hash and change it, so the integrity is broken.

• The use and security section raises three concerns. 1. Frequency analysis: since we are not repeating the key, this is not possible. 2. Known plaintext attack: it is practically impossible to know plaintext. Similarly, malleability isn't a concern I think because integrity is preserved. Also, I'm not using hash of ciphertext but of the plaintext. Do I still need HMAC? – Orwell Jan 4 at 14:40
• crypto.stackexchange.com/questions/2249/… @poncho explains it really well – SamG101 Jan 4 at 16:50
• and how are you not repeating the key, when the key is always the hash of the same password per user? – SamG101 Jan 4 at 16:51

The system is either insecure or horribly insecure.

When using Xor, an attacker with two ciphertexts can xor them, eliminating the key and getting the Xor of two plaintexts.

You said plaintexts are all distinct and 256 bits, if they are chosen uniformly at random, getting the XOR of two of them is obviously not desireable but doesn't immidiately reveal the plaintexts.

If even one plaintext is revealed, it reveals all others for same key, if part of one plaintext is revealed it reveals matching part in all others.

If the plaintexts are low entropy, guessable, have some structure. E.g are at partly in human language. Xor of pairs of plaintext trivially reveal the plain texts and key.

Even if you use, a strong cipher, e.g AES CTR. your key derivation is weak and allows for efficient brute forcing of passwords. A general purpose hashing function makes for poor password based key derivation. Use something suitable, e.g: PBKDF2, bcrypt, scrypt or argon2 These slow down brute forcing. Remember user chosen passwords are not high entropy.