Tag Info

Hot answers tagged

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 ...


15

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 ...


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, 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, ...


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 ...


11

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. ...


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 ...


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

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 ...


8

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 ...


7

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 ...


7

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 ...


7

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 ...


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

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 ...


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

What do you mean 'a one time pad with a password'? One time pads don't take passwords, they take samples of truly random data as long as the message. If what you're doing is taking the password, repeating it N times, and using that as if it were a random one-time pad, well, that can usually be broken even if you don't send a second message. If what you're ...


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

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 ...


5

The most known example of just XOR would be the One-time pad (or at least, one of its implementations). It just takes a random key stream and XORs it with the plaintext stream to create the cipherstream. The one-time pad is also the only provably perfect cipher, where knowing any amount of ciphertext and plaintext does not help to know any single additional ...


5

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 ...


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

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 ...


5

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 ...


4

This looks totally weak. If you know 128 bits of known plaintext, you can infer the corresponding 128 bits of keystream. The keystream being the multiplication of the random matrix by the key (in the vector space $\mathbb{F}_2^{128}$), the key is then revealed through a basic matrix inversion.


4

We typically refer to a homomorphic cipher if we can take two ciphertexts and combine them in a way that has a predictible result on the plaintexts. In your example you have taken one ciphertext and one plaintext. Using a stream cipher correctly you should never have 2 ciphertexts encrypted with the same portion of a keystream. So, combining two ciphertexts ...


4

For simple XOR-based encryption algorithms such as OTP, the key size must be the same as the message size. If you choose a smaller key and try to divide the message into chunks, you would not have a perfectly secure scheme anymore. Now, since you tagged java, I'm assuming that this increase in time for smaller key sizes is due to the code trying to divide ...



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