Tag Info

Hot answers tagged

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

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


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


6

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


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


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


2

No. As the key should be fully random - a premise that invalidates the use of an OTP in practice - that should not matter at all.


2

The standard random number generator, in languages like Java or Python, does not generate real random numbers but pseudorandom numbers determined by an initial seed value. If an attacker can somehow guess or determine this seed value, they can reconstruct the entire sequence of pseudorandom outputs. Furthermore, the default pseudorandom number generators ...


2

This question as stated actually has a fairly interesting and unintuitive answer. Assuming an 8 byte 64 bit xor key and your test for printable ascii characters then after a megabyte of correct data your chances of having the right key are... about one in four billion. This is completely independent of how much data you have or verify, 1/2^32 is the maximum ...


2

It turns out that this is not very difficult to solve. It also looks like this is part of a public cryptography challenge, so rather than giving it all away, I'll just provide you with a couple of pointers. First take a look at this: There is a clear repeating pattern every 5 bytes. This suggests two things: (i) an XOR key with a length of 5 was used ...


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

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

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

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

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

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



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