Hot answers tagged

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


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


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


4

As long as the keys $K_i$ are only used once, this is semantically secure. To see it, observe that if $K_i$ is a uniformly random value in $\{0,1\}^{|M|}$ then so is $C_i = M \oplus K_i$.


4

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


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

First of all, there is nothing really special about spaces. It is a fact of how the ascii encoding is put together that e.g. chr(ord('a') ^ ord(' ')) = 'A' and vice versa. Your code should just xor things together and not try to do anything special if the key character is a space. 4 important properties of xor are: 1) a xor 0 = a 2) a xor b = b xor a 3) a ...


3

You don't have to use XOR, but rather, it tends to be convenient. One of its convenient properties is that it is its own inverse. Also, XOR implements addition in $\mathbb F_{2^n}$, making XOR a key component of working in finite fields of characteristic $2$, if you want to use them in an algorithm. The "one-time pad" is usually defined as taking a random ...


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

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


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

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

The first thing you should do is estimate the key length. While you may be able to do this using Kasiski examination, in this modern era of computers I very much recommend instead using the index of coindicence, which you can compute very easily, e.g. with this Python program: import sys msg = sys.stdin.read() # read ciphertext from standard input for ...


1

First things first: Don't roll your own crypto. As for your current approach: This is basically a vigenere cipher which is inherently broken, provides not integrity protection and wouldn't even encrypt known / predictable bit positions (where the ASCII code is constant zero or one). As for an improved version: Use a well-known encryption algorithm (e.g. ...


1

The "XOR cipher" described does not encrypt more than the first block, even if you do not reuse keys. The subsequent blocks can be "decrypted" by the attacker simply by undoing the XOR – there is no secret involved. Decrypting the first block and finding the key does require more than one message. It is a case of the many-time pad and can be solved either ...


1

Assuming your authenticated message is public (which is reasonable), this scheme seems insecure for the following reason: Your authentication tag $t$ over message $m$ is computes as $$t=sha256(salt||key) \oplus sha256(m)$$ This means that any adversary knowing $m$ can compute a new authentication tag $t'$ for a message $m'$ in the following way: $$t' = t ...


1

From "Claude Elwood Shannon - Collected Papers" edited by N. J. A. Sloane and Aaron D. Wyner, I understand that Claude Shannon proved that any encryption algorithm possessing these characteristics is absolutely secure: The encryption keys must be random numbers of uniform distribution. The keys must be shared in absolute secrecy by the sender and receiver. ...


1

First of all, the write() function does nothing but decode a single hexadecimal digit into a number from 0 to 15. You could replace it with: function write(x) { return parseInt(x, 16); } Thus, the code: var diff = write(input[i]); var firstNum = write(input[i + 1]); takes two consecutive hex digits from the input string and decodes them. The ...


1

$ Pr(H(a) \oplus H(b) = V)$ is independent of $V$ For a good hash, as pointed out in the comments. Pick your input space to be the output space of SHA-224 so with probability $1/2$ (1) holds. The range of $H$ is a group under $\oplus$. So (2) holds. 3 won't hold by the same group property. Another $2^{112}$ trials will likely yield $a',b'$ satisfying (3) ...


1

asymmetric cryptosystems like RSA and ElGamal don't use XOR and they are based on number theory but XOR is very powerful,if you have planintext$\oplus$Key and your key is random number,but your plaintext is not random then the result of planintext$\oplus$Key is random,in other words XOR operation prevents from statistical properties attacks like frequency ...


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.


1

This cipher system is the original Vernam cipher. (In the original Vernam cipher, the key was stored on a loop of paper tape that repeated over and over). Like all practical encryption systems, the Vernam cipher has a secret key that it uses over and over. ciphertext[i] = plaintext[i] bit_xor key[ i % keylength ] This cipher can be seen as a variant 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 ...



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