Tag Info

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

7

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

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

As fgrieu notes in the comments, the protocol might not even work reliably in the absence of adversaries: if the tag fails to receive the reader's reply of "True", the keys will get out of sync. (If that happens, the tag will just retry the next exchange with the old key, so this could be fixed by having the reader remember one more "subkey". But the ...

5

This is not a mathematical proof. A notable place it fails to be a proof is here: Pay attention to which cipher text I use, look up to match the message with the cipher-number below. $$cipher1⊕cipher3=character1⊕character3⊕IV1⊕IV2$$ (Note that the cipher BOTH use the SAME KEY, but they remain secure because of the two different IV) This line is ...

4

Is the Kurihara algorithm really what it purports to be (dramatically faster but equally secure replacement for Shamir Secret Sharing)? The algorithm being referred to is in this paper, and I believe that the speed benefits are at best marginal, if not nonexistent. As for the speed benefits being marginal, well, normally we use secret sharing as a part ...

3

There is a very simple, completely generic solution, that unlike the other solution doesn't assume anything about how the two encryption schemes work internally (e.g., that they are built from block ciphers or have pseudorandom ciphertexts): given a message $m$, choose a uniformly random $m_1$ of the same length and let $m_2 = m \oplus m_1$. Then encrypt ...

3

There is of course but because of carry bits there will be data-dependent "nonlinear" terms. If I do it for 2 bits you can get the idea. It gets unwieldy but you can easily write code to do it for longer bitlengths. The list below is an XOR table expressed as integers: $$\begin{array}{c|ccc} \oplus & 0 & 1 & 2 & 3 \\ \hline 0 & 0 & ... 3 This partial answer establishes (rather trivial) lower and upper bounds for the asymptotic hardness of the problem, assuming h behaves like an n-bit wide random function. If one hashes m messages M, then computes f(i,j,k)=h(M_i)\oplus h(M_j)\oplus h(M_k) for (i,j,k)\in\mathbb {Z_m}^3, that's m^3 results, with most values duplicated at least 6 ... 2 Well, if you construct what you described you basically create a function f: \{0,1\}^{2m} \rightarrow \{0,1\}^m. As you correctly pointed out these two strings give the same when xor'ed. So the messages 10101111 and 00000101 will result in the same xor and hence will get mapped to the same hash, resulting in a second preimage as you found two x,x' ... 2 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 ... 2 Maarten appears to make it look like it's an impossible (or, at least, an exceedingly difficult task) to recover the two plaintexts. Indeed, if you literally know nothing about the plaintexts, it can be difficult. However, you typically have a reason you are interested in the messages, and hence often have a clue as to what language they might be. If the ... 2 While you're a crypto newbie, I hope that you know something about mathematics (because you've stumbled something that needs to be described in mathematical terms). What you've described here is actually polynomial multiplication (over polynomials in GF(2) (that is, we do our computations modulo 2). That is, you can interpret the numbers as specifying a ... 2 Collisions are not much of a concern, since you have to compute them to know they happen, and assuming your values are a typical hash size (256+ bits) they will never happen randomly anyway. But yes, having identical computation that use the same data is wasteful if you don't store the intermediate values. However, the main problem your function has is that ... 2 First things first: a PRNG (Pseudo Random Number Generator) can not provide a one-time pad. As a reminder: a one-time pad… has to be truly random, must be at least as long as the plaintext, is never reused in whole or in part, and is kept completely secret. Only when all four points are met, we´re talking about OTP. Your PRNG idea fails to meet those ... 2 It's exclusive or (or XOR), corresponds to x \oplus y := x+y \pmod 2 for single bits, i.e., scalars. It is sometimes used for binary vectors as well, whereby two bitvectors of length n$$ \mathbf{x}=(x_1,\ldots,x_n)$$and$$ \mathbf{y}=(y_1,\ldots,y_n)$$result in$$ \mathbf{x}\oplus \mathbf{y}=(x_1\oplus y_1,\ldots,x_n \oplus y_n)  i.e., a bitwise ...

1

There's a lot of ways to attack this. The first thing to notice is that if you know the value of plaintext at index $i$, you can then deduce the value of all the plaintext bytes at index $i+8k$; for all integers $i$ (!). That's because the relation between plaintext and ciphertext bytes is $P_{i} = C_{i} \oplus P_{i-8}$; if you know $P_{i-8}$ (and, of ...

1

Without more context the answer isn't quite precise. In the following answer $\oplus$ always denotes bit-wise XOR. First let's quickly revisit "plain" cascade encryption. You encrypt arbitrary messages using the keys $K_1,K_2,K_3$ and the encryption algorithm $E$ as follows: $C=E_{K_1}(D_{K_2}(E_{K_3}(P)))$ Now the first possible XOR-cascading construction ...

1

First: Analyzing code is off-topic on this site, don't expect much. To the question: "Never write your own crypto" is a statement, that is all too often disregarded. Without digging deep, it looks like some self-made (and totally insecure) algorithm: The key is not used at all, therefore it is basically a streamcipher (one symbol at a time) with a ...

1

For example, let say that you have a message: "100 dollars should be moved." and you encrypt it with OTP. Then everybody can just take the first character "1" and change it to a 9 by XOR the 1 from the cipher-text and then XOR a "9" with the key you got. What you are describing is what happens if an attacker introduces changes in the ciphertext by a ...

1

Is CBC mode in OTP more secure? No. If your one time pad satisfies the required properties (it's truly random, the attacker has no information about it, and it's only used once), then OTP already has perfect secrecy; playing around with how it works can't make things better. If your one time pad doesn't satisfy the required properties, then all bets ...

1

XORing a key and message is called a one time pad. It is perfectly secure, providing confidentiality, when used correctly. That last part is the hard part, along with finding a situation in which you only need confidentiality.

1

Unless you know more about the plaintexts two ciphertexts may not convey all the information to reconstruct the two messages. For instance if you have a bit 0 then both messages may contain a 0 at that location or they may both contain a 1. If you have a 1 message 1 may contain a 0 and message 2 may contain a 1, but it could also be the other way around. ...

1

The keystream is as long as the message, so you don't want to send that to the receiver. The keystream is generated by a much shorter key (e.g., 128-bit private key). That is what the receiver needs in order to decrypt the message. So, how do you get that to the receiver? Well, clearly you can't just send it in the clear or anyone watching the channel would ...

1

Anyone who has the keystream and the ciphertext can trivially calculate the plaintext — it's a xor operation bit by bit. Sending the keystream alongside the ciphertext would completely defeat the purpose of encryption. The principle of stream ciphers is that the sender and the receiver agree on an algorithm, a secret key and some parameters, and both ...

1

Use AES-128, the instruction set in most CPU's (AES-NI) speeds up the encryption and does not put to much load on your CPU. I would use CBC but there might be better mode operations for encrypting files. Also don't forget to use a MAC. Using a one time pad (OTP) is nice but what you're doing is not an OTP it's more a Vigenère cipher. If you were to use OTP ...

1

You're using bytewise xor, and three plaintexts $x,y,z$ with a small alphabet (A-Z, which I assume means ASCII values 0x41-0x5a). Then knowing $a \oplus x$, at a certain index, we know all possible values of $a$, at that same index, namely $\{0x41 \oplus (a \oplus x),\ldots, 0x5a \oplus (a \oplus x)\}$. But we have 2 more constraints from $a \oplus y$ and $a ... 1 The exact details depend on the logic family but basically The difference is that the charge representing those "1" bits need to be discarded somehow. This is done by switching the output to ground, 1^0 is 1 so no charge need to go away but 1^1 is zero meaning at least two gates get discharged to ground slightly raising its voltage due to the non zero ... 1 Basically, to (naïvely) implement modular reduction by M = (1 << 128) + 0x87, you need to: take the upper 128 bits$x_H$of the 256-bit (actually, 255-bit, since the high bit can never be set) PCLMULQDQ result$x = x_H \| x_L$, shift them down by 128 bits, XOR-multiply them by 0x87, XOR the result with the lower 128 bits$x_L\$ of the 256-bit result, ...

1

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.

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