# Tag Info

45

Well, the classical answer to "what is the correct thing to do after you have the XOR of the two original messages" is crib-dragging. That is, you take a guess of a common phrase that may appear in one of the plaintexts (the classical example against ASCII english is the 5 letter " the "), and exclusive-or that against the XOR of the two original messages ...

42

There is a great graphical representation (which I found on cryptosmith, but they keep changing their url structures, so I've added the graphics in here) of the possible problems that arise from reusing a one-time pad. Let's say you have the image and you encrypt it by using the binary one-time-pad (xor-ing on black and white) . You get the following ...

23

There are two methods, named statistical analysis or Frequency analysis and pattern matching. Note that in statistical analysis Eve should compute frequencies for $aLetter \oplus aLetter$ using some tool like this. A real historical example using frequency analysis is the VENONA project. EDIT: Having statistical analysis of $aLetter \oplus aLetter$ like ...

21

Let's assume that the plaintexts consist only of spaces and ASCII letters. Given the hint, that seems like a reasonable assumption to start with, even if it might turn out to be only mostly correct. Now, take one of the ciphertexts and XOR it with each of the others. Of course, the XOR operation cancels out the keystream, so you end up with the plaintext ...

19

Modern security has moved beyond looking just at passive attacks (in which the attacker is just a passive eavesdropper seeking to learn what was said); attackers are generally considered to be able and willing to pull off active attacks of various types (in which the attacker can modify or forge messages to achieve some goal). One-time pads are extremely ...

17

In general, knowledge of $m_1 \oplus m_2$ is not enough to uniquely determine $m_1$ and $m_2$, even if both are known to be, say, English text. For a simple example, $$\text{"one one"} \oplus \text{"two two"} = \text{"one two"} \oplus \text{"two one"}.$$ However, in practice it may be possible to obtain fairly good guesses for $m_1$ and $m_2$; the typical ...

16

No that is not correct, here is the thing, given a ciphertext say ezcle, there exists a key such that this would decrypt to hello, another key such that this decrypts to harry, another key which will decrypt to frank, another key which will result in world. And every other 5 letter word in the dictionary, and every other 5 letter combination of letters (I'm ...

13

Here, since the key is used more than one time, an attack called “crib dragging” can be used to attack the cipher-text. The blog post Many Time Pad Attack - Crib Drag could give you a greater understanding on the implementation part: Many Time Pad Attack – Crib Drag The one time pad (OTP) is a type of stream cipher that is a perfectly secure method ...

12

Yes, encrypting two different random "plain texts" with the same "pad" is indistinguishable from using two different random one time pads for encrypting the same plain text. You get perfect secrecy in the latter case, so you will get it in the former case as well. However, usually there is a functional difference between the key and the plain text that the ...

12

Very short answer: No Quite Short answer: No, because a scheme can only be a One-Time-Pad if the entire pad is perfectly random and secret. Concise answer: It sounds like you're trying to build a stream cipher. The security of it really comes down to how much of the scheme you think can be kept secret. If I listen in to your wifi and hear you requesting a ...

12

Synchronous stream cipher, or just stream cipher. In a synchronous stream cipher a stream of pseudo-random digits is generated independently of the plaintext and ciphertext messages, and then combined with the plaintext (to encrypt) or the ciphertext (to decrypt). In the most common form, binary digits are used (bits), and the keystream is combined with ...

10

Generating a pseudo-random stream from a key, and XORing that stream with the data to encrypt, is done on a regular basis. That's how most stream ciphers work, e.g. the well-known RC4, and also applies to block ciphers in counter mode. This is not "One-Time Pad", by definition, since OTP requires the key stream to be truly random (that's the condition from ...

10

No. This is not safe. The one-time pad requires that the pad be generated by a true-random process, where each bit of the pad is chosen uniformly at random (0 or 1 with equal probability), independent of all other bits. Any deviation from that, and what you haven't is no longer the one-time pad cryptosystem -- it is some kludgy thing. In particular, once ...

10

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

9

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

9

Would it be useful for companies who need to keep their data safe? No, a one-time-pad is only useful in very rare circumstances. The main issue is key-management. You can only use each pad once, it's as large as the data you want to encrypt, and you need to get it to all parties in a secure way. The direct competition of a one-time-pad is a stream cipher. ...

9

A recent (2006) paper that describes a method is "A natural language approach to automated cryptanalysis of two-time pads". The abstract: While keystream reuse in stream ciphers and one-time pads has been a well known problem for several decades, the risk to real systems has been underappreciated. Previous techniques have relied on being able to ...

9

In few words: OTP has perfect secrecy; For a cipher to have perfect secrecy, it is required that $|K| \ge|M|$. Let $K=M=C=\{0,1\}^n$ be the set of keys, messages and ciphertexts. If you apply the "improvement", ie, if you remove $0^n$ from the keyspace, then you've created a cipher that cannot show perfect secrecy (because now $|K| = |M| - 1 < |M|$). ...

9

Only two people can communicate with each other with the chat program. No group conversations. This is fairly limited, but let's admit. The people will be communicating over the internet. So, an insecure channel. OK. The chat program will just handle basic characters, numbers and symbols that are on a standard US keyboard. This is to keep ...

9

The bits are not independent from each other, at least within an individual song, so the pad is not truly random, thus this is not a one-time-pad. Perhaps a hash-based approach would fix this, but... ... there are a limited number of songs available, a simple attack would then be to enumerate every song (in the same format you describe) and try to decrypt a ...

9

Actually, one-time pad can be implemented on the basis of any finite group operation; with these requirements: The pad must consist of random group members; that is, each element in this pad must have equal probability of being any specific group member, and there must not be any correlation between different entries within the pad. The encrypt and the ...

9

The general scheme is called Three-pass protocol and works for all commutative ciphers. It is secure for some of them, but xor (and modular addition) are insecure choices. Your scheme: A->B: $c_1 = m \oplus a$ B->A: $c_2 = c_1 \oplus b$ A->B: $c_3 = c_2 \oplus a$ B computes $m = c_3 \oplus b$ an attacker sees all of $c_1$, $c_2$ and $c_3$. So they can ...

8

The perfect security of OTP hinges on the fact, that keys must be chosen truly at random and uniformly from the domain of all possible keys, i.e. all bitstrings of a certain length. The problem with your approach is that you use a pseudorandom number generator to generate the key. It does not matter how good the generator is, because the entropy that can be ...

8

There is no universally accepted definition of the expression "stream cipher"; but the one I most often encounter is the following: a stream cipher is a symmetric encryption algorithm which accepts as inputs arbitrary sequences of bits (or bytes) such that: the length of the output is equal to the length of the input (no padding); for any $n$ (possibly any ...

8

No, OTP would not be considered a cryptographical hash function. OTP takes a key; cryptographical hash functions don't It's generally expected that the output of a hash function be of fixed length, independent of input length. The output of OTP is the same length as the input. Hash functions are deterministic (that is, if you give the same input twice, ...

7

First of all, a terminology nit: please don't say "a One-time-pad generated by a CSPRNG"; a one-time pad must, by definition, be generated randomly, and an important part of its security proof is that it was generated randomly (and so an attacker cannot disqualify any potential pad, even if that attacker had infinite computational resources). ...

7

In the "Telegraphic Code to Insure Privacy and Secrecy in the Transmission of Telegrams" from 1882, Frank Miller assigned a number to around 14,000 code words. Bankers would select an "irregular" series of such words and exchange them with a remote partner. Any messages would be lined up below the next unused words on the pad for encoding. When you lined up ...

7

It is quite simple and stems from the idea that flipping one bit in the ciphertext flips the corresponding bit in the plaintext. So, say the ciphertext is $1011$ and we know the plaintext is $0101$ (thus the key is $1110$). Say we want a plaintext of $0000$, we just have to change the ciphertext to $1110$ (notice where the bits have been flipped) and we ...

7

Let's say Alice and Bob have $c$ bits of pre-shared secret key material. Alice generates $a$ bits of new key material, concatenates it to a message $M$ that is $b$ bits long, and uses $a+b$ bits of their pre-shared key material to encrypt "message||new-key". She sends this secure message to Bob, who decrypts it with the shared key. Now they both have $a$ ...

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