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

9

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

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

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

4

A stream cipher, by definition, acts on individual bits at a time. This effectively means that bits later in the plaintext cannot affect bits around the beginning of the ciphertext. It can, however, feed the ciphertext back into the state of the PRNG to affect all future bits. This can be seen in the CFB (Cipher Feedback) block cipher mode. It acts similarly ...

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

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

3

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

3

At the present time only exists xnor, which is the complement of xor. 0 0 = 1 0 1 = 0 1 0 = 0 1 1 = 1 = xnor The others truth tables ignores entirely one of the inputs and are not suitable for accumulation of entropy.

3

While the other answer is correct, there are multiple ways to disprove a theorem. In your case you want to disprove $$\Pr[\mathcal M=m|\mathcal C=c]=\Pr[\mathcal M=m]$$ holds for $$c=m\oplus k \oplus \operatorname{rev}(k)$$. The first one is to argue using the probabilities and show that the above equation doesn't hold for this scheme. The second (formally ...

3

You know that the definition of perfect secrecy is $P(M = m \mid C = c) = P(M = m)$ for all $m$ and $c$ and that each key is only used once. This mean that know about $c$ not affect $P(M=m)$ and if you know $c$ you can't access any information about $m$. But as yyyyyyy mentioned,since $k\oplus \operatorname{rev}(k)$ is symmetric, if $\operatorname{Enc}(k,m)$ ...

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

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

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

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

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

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

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

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