# Tag Info

23

It's important to make the distinction between ciphers which use XOR internally as a component operation (which is nearly all of them), and 'ciphers' which just XOR the plaintext with a secret. If the key is the same length as the plaintext, then it's a one time pad, so in some sense, yes, with "sufficient randomness" you can safely encrypt with XOR. The ...

18

They are both linear, but in different algebraic Groups. Which is to say, xor is linear in any finite field of characteristic 2, while 'ordinary' addition is linear in the infinite field of the Real numbers. Addition modulo $n$ (which is more cryptologically significant than addition over the Reals) is also a linear operation, but in the ring of integers ...

17

Yes, you are remembering correctly. Yes, this is a reasonable method to find the key length. The reason why this works is because, typically, the plaintext is not uniformly random. For instance, rather than a random bit-string, the plaintext might be some English text, encoded in ASCII. If $X,Y$ represent two random English letters, encoded in ASCII, ...

15

The notation $c=\oplus~c_i$ is (terrible) shorthand for $$c=\bigoplus_{i \in I(c)} c_i$$ where the sum sign should be replaced by the big xor sign which could also be written as $$c=\sum_{i \in I(c)} c_i,$$where $\sum$ denotes vector addition modulo 2. An example of this decomposition (for length 8 vectors) is $$c=(1,0,1,0,0,0,1,0)=$$ which is nonzero in ...

13

On software platforms, bytewise adding will not be faster than bitwise XORing. It may be a bit slower, though, also this will be negligible with regards to the process which generated the stream (and, for that matter, will probably also be negligible with regards to the memory bandwidth). On hardware platforms (FPGA, dedicated ASIC), addition is slower than ...

13

Yes, it's the same XOR. It gets used inside most of the algorithms, or just to merge a stream cipher and the plaintext. Everything is just bits, even text. The word "hello" is in ASCII 01101000 01100101 01101100 01101100 01101111. Just normal bits, grouped in 5 bytes. Now you can encrypt this string with a random string of 5 bytes, like an One-time pad. ...

11

If the key used to XOR your plaintext is any shorter than your plaintext, then the repeats will give it away. If the key is truely random, and never reused, it is effectively a one-time-pad. The historical name for XOR encryption is Vernam cipher. is there something inherently wrong with XOR based ciphers The amount of effort you need to put into ...

10

The combination between addition modulo $2^{32}$ (not modulo $32 = 2^5$) - indicated by $\boxplus$ in the diagram - and XOR (i.e. bitwise addition modulo $2$) - indicated by $\oplus$ - makes the algorithm more non-linear. Each of them for itself is a linear operation, but over different groups (addition in $GF(2^{32})$ vs. addition in $Z/2^{32})$, and the ...

10

No, you can reuse a message as often as you want with the OTP. (But never reuse the key!) What happens if you reuse a key? The attacker can xor the two encrypted messages (ciphertexts) and gets the xor of the two plaintexts. The xor of two messages is highly insecure and can be easily turned into two plaintexts with some know patterns. What happens if you ...

10

The usual method to do this is to turn the block cipher into a stream cipher. In that way the ciphertext is generated by XOR'ing the plaintext with a generated key stream. This key stream in turn is generated by the mode of operation that turns the block cipher into a key stream. There are several of these modes, but CTR mode of operation is most often used ...

10

XORing a master key (presumably a long term key) with data is a very dangerous idea. If any data key is leaked, then the master key may be easily calculated, thus leaking all keys. ($m$ for the master key, $d_x$ for all data keys) $$c_x = d_x \oplus m$$ then somehow $d_4$ is leaked $$m = d_4 \oplus c_4$$ $$d_x = c_x \oplus m$$ You'd be better off applying a ...

9

The name I would use for this protocol is "broken". It is insecure. An eavesdropper gets to observe $Q_0 = P \oplus CM$, $Q_1 = Q_0 \oplus SM = P \oplus CM \oplus SM$, and $Q_2 = Q_1 \oplus CM = P \oplus SM$. Notice that we have the relation $$Q_0 \oplus Q_1 \oplus Q_2 = (P \oplus CM) \oplus (P \oplus CM \oplus SM) \oplus (P \oplus SM) = P.$$ Therefore, ...

9

Not at all secure; generating preimages would be trivial. Here's a demonstration with a three-block message: Here is your suggested method (limited to three block messages): $E_0 = Encrypt( IV \oplus P_0 )$ $E_1 = Encrypt( E_0 \oplus P_1 )$ $E_2 = Encrypt( E_1 \oplus P_2 )$ $E_3 = Encrypt( E_2 \oplus 0 )$ $Hash = E_0 \oplus E_1 \oplus E_2 \oplus E_3$ ...

9

Within the DES block cipher itself, the XOR operation is used at two different places: On the input of S-boxes, XOR-ing 48 bits per round: 48 bits from a subkey (extracted from the 56-bit key), and 48 bits that are the output of expansion E. The 48-bit result forms the eight 6-bit inputs of the S-boxes. On the output of S-boxes, XOR-ing 32 bits per round: ...

9

What is the definition of linearity? Linearity is defined for maps between vector spaces. If you have a field $F$ and two vector spaces $U$ and $V$ over the field $F$, a map $$T:U\rightarrow V$$ is said to be linear if $$T(\gamma_1\odot u_1\oplus\gamma_2\odot u_2)=\gamma_1 \odot T(u_1)\oplus\gamma_2\odot T(u_2)$$ whenever $\gamma_1,\gamma_2\in F$ and ...

8

XOR operations, fixed bit movements (as in taking the 2 topmost bits or concatenating bits etc.) and data dependent rotations form a functional complete set of operations. This means that you can realize any function between fixed length binary strings, including all possible blockciphers, using them. To show that these operations form a functional complete ...

8

You can use any invertible operation to apply the key stream to the plaintext for encryption (and use the inverse to apply the key stream to the ciphertext for decryption). Addition/subtraction are such a pair, but you have to take care for the carry - either use it $\bmod 256$ (i.e. byte-wise), or use it $\bmod 2^n$ with $n$ some block size in bits. Make ...

8

Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...

8

It is possible to turn a hash function into a stream cipher; there are several methods for that, and the simplest is to compute $h(K||IV||x)$ for hash function $h$, initialization vector $IV$, and successive values of a counter $x$. This yields an arbitrarily long sequence of pseudo-random blocks (32 bytes per invocation if $h$ is SHA-256). Then XOR that ...

8

The symbol of the circle with the + in it is one of many symbols for exclusive-or. XOR, EOR, EXOR, ⊻, ⊕, ↮, and ≢. Binary OR is true when either input is true; binary XOR is true when exactly one input is true. If both inputs are true, the XOR result is false. One property of this is that if either input bit flips, the output bit will also flip. That's sort ...

6

The short answer is no. The scheme gives poor protection against collisions, that is inputs detected as having the same content (within order) when they have not. As noted in the question, this can occur when entries in an input are duplicated; e.g. ("O","X","O") and ("X") collide. This can also occur for maliciously crafted entries. For a start, MD5 is ...

6

If I understand right, your operation effectively is $$\forall i: c_i = p_i \oplus k_0 \oplus k_1 \oplus k_2 \oplus \dots \oplus k_n,$$ whith $c_i$ the ciphertext bits, $p_i$ the plaintext bits, and $k_j$ the key bits. As $\oplus$ (this is XOR) is associative, this is equivalent to $$k^* := k_0 \oplus k_1 \oplus k_2 \oplus \dots \oplus k_n,$$ \forall ...

6

The encryption scheme seems to be: re-use an existing 128-bit secret, originally used to unlock a read-prevention mechanism, as the 128-bit key; split the plaintext (data to protect from prying eyes) into 128-bit blocks; XOR each block with that 128-bit key. That approach is flawed. Two cardinal mistakes are made: Use XOR with a keystream that repeats. ...

6

To answer your question: no this is not homomorphic encryption because one of the plaintexts is used unencrypted. There may be times when it is a useful property, but the only uses I know of it are to demonstrate the malleability of xor ciphers. To be a homomorphic encryption function, it should be possible to calculate the encryption of some function of ...

6

Yes, the XOR used in cryptography means the same bitwise XOR operator you're familiar with. And yes, to securely encrypt a message with XOR (alone), you do need a key that is as long as the message. In fact, if you have such a key (and it's completely random, and you never reuse it), then the resulting encryption scheme (known as the one-time pad) is ...

6

Well, if we have plaintext^shiftedPlaintext, what we have is the values $P_i \oplus P_{i+k}$, where $k$ is the length of the shift. What does this imply? Well, if we consider the values $P_i \oplus P_{i+k}$, $P_{i+k} \oplus P_{i+2k}$, $P_{i+2k} \oplus P_{i+3k}$, ... we get a chain where, if we guess one of the values $P_{i+nk}$ for some $n$, we can ...

5

Unless you are badly (and I mean truly badly) misrepresenting the idea, it is one of the worse ideas I've seen in crypto in quite some time. The first bit is effectively exclusive or'ed with the parity of the key; the ciphertext bit will be either the plaintext bit (if the key has an even number of '1' bits) or the complement of the first plaintext bit (if ...

5

The inequality is obtained by a distance argument. Consider two points $X,Y$ on the real line. Taking another point $Z$, you have $|X-Z| + |Y-Z| \geq |X-Z+Z-Y| = |X-Y|$. Applying this "triangle" inequality to your equality 1, we have for any $z \in \mathbb{R}$, \$\begin{array}{l} \bigl\lvert\Pr[A(x\oplus g(U_n))=1] - z\bigr\rvert + \bigl\lvert ...

5

What you are proposing in effect means that you use a not-really-random one-time-pad, which is used twice (i.e. a two-times-pad). This is not secure. Using a single hash to generate a key from a password is a bad idea - especially if the password is short, it is easy to brute-force it (i.e. try lots of passwords). Using the simple XOR cipher to encrypt a ...

5

I've got a feeling that I'm going to write this a lot on here: define "sufficient". The question you must answer is "what do you want to protect and how much is it worth to you"? In general, a plain XOR cypher with a key shorter than the total plaintext encrypted is pretty weak, and methods for decrypting are more or less trivial. So if there's a lot of ...

Only top voted, non community-wiki answers of a minimum length are eligible