Tag Info

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

There are two points to consider here: How likely is it that two different strings give the same MD5 hash? This is known as a hash collision. A good hash function makes this probability as small as possible (this would be about $1/2^{128}$ for MD5). If you have a larger number of strings to hash, the probability of any collision between any of them grows ...

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

If $K$ is random and you only know $A$ or $B$ (but not both) then, no, there is no way to infer anything about the key - this is the (in)famous one-time-pad. If you know $A$ and $B$, then you can recover $K$ very easily. Exclusive-or has those properties: $\forall n$, $~~~~ n \oplus n = 0$ $\forall n$, $~~~~ n \oplus 0 = n$ (identity element) $\forall a, ...

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

If you have known plaintext, namely one input file that is known in its entirety, this is trivial to break. So I'll explore methods that might lead to a break, if you don't know what's in the input file that was compressed. I suggest that you start by analyzing the DEFLATE stream format carefully (see also these handy notes). This will probably help you ...

For most purposes, you probably don't need to provide confidentiality protection for the version field. There may be some settings where the version field allow traffic analysis, and to analyze that, we'd need to know so much detailed information about your particular protocol that the question would probably become too localized to be a good fit for this ...

Once you've XORed two messages with the same secret value, the net result is the same as if you had XORed them with each other without using the secret at all. Given $plaintext_1$ ⊕ $key$ = $cyphertext_1$ and $plaintext_2$ ⊕ $key$ = $cyphertext_2$, then $cyphertext_1$ ⊕ $cyphertext_2$ == $plaintext_1$ ⊕ $plaintext_2$. Because ...

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