Tag Info

Hot answers tagged

37

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


28

There is a great graphical representation of the possible problems that arise from reusing a one-time pad. Reusing the same key multiple times is called giving the encryption 'depth' - and it is intuitive that the more depth given, the more likely it is that information about the plaintext is contained within the encrypted text. The process of 'peeling ...


20

Collisions of RSA keys should never happen for realistic key sizes and good random number generators. Assume a 1024 bit RSA key; the primes from which it has been derived are about 512 bit. If we assume every 500ths 512 bit number is a prime, and we assume the most significant bit of the 512 bit number is set, we still get about $2^{500}$ or $10^{150}$ ...


18

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


16

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


16

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


11

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


10

Yes, the attacker would have a realistic chance of recovering plaintext, and preventing him from knowing the IV values does not reduce this risk. The problem is that CTR mode encryption is effectively: $C = P \oplus F(Key, IV)$ where $P$ is the plaintext, $C$ is the ciphertext, and $F$ is a complex function of its two inputs. The problem with this is if ...


9

Here since the key is used more than one time, an attack called Crib-Dragging can be used to attack the cipher text. A blog post which could give you a greater understanding on the implementation part is located at travisdazell.blogspot.in/2012/11/many-time-pad-attack-crib-drag.html: Many Time Pad Attack - Crib Drag The one time pad (OTP) is a ...


8

Yes, this is a fine approach. This sort of technique is known as "key separation". Since your master key is a cryptographically secure key, you do not need to use a large iteration count. Also, you could use any PRF, in place of PBKDF2. (The iteration count is normally used if you are applying PBKDF2 to a passphrase, instead of a cryptographically secure ...


8

Well, reusing a key isn't a problem; after all, RSA keys are generally used many times. However, if you fix the padding, there does exist one other potential problem; message malleability. To example, suppose Alice sends two messages to Bob, $X_1, X_2$ and $Y_1, Y_2$. To send these, Alice actually sends: $E(X_1), E(X_2)$ $E(Y_1), E(Y_2)$ Now, Eve can't ...


8

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


6

CBC mode encrypts as follows: $$ C_0 = E_K(IV\oplus P_0);\\ C_i = E_K(C_{i-1}\oplus P_i), $$ where $P_i$ are plaintext blocks and $C_i$ are ciphertext blocks. Traditionally, IV must be random and is published alongside the ciphertext to enable decryption. If it is also published in your case, then this reveals the key and is trivially insecure. If the ...


5

If you encrypt the messages $m_1$ and $m_2$ with the pad $p$ as $$\begin{aligned} c_1 &= m_1 \oplus p, \\ c_2 &= m_2 \oplus p, \end{aligned}$$ where $\oplus$ denotes the binary operation of a finite group (e.g. addition on integers modulo $n$, or XOR on bitstrings, etc.) and $p$ is a random element of the group, then, indeed, an attacker who ...


5

You would retain perfect security in the situation you described. Consider your question in reverse. Use the ciphertext as a OTP and use the n-time-pad as the ciphertext. Since your ciphertexts are random their concatenated result is also random and would qualify as an OTP. At this point is doesn't matter what the OTP was, the conditions for perfect ...


5

Hint: Are you familiar with frequency analysis (for breaking classical ciphers)? Hint: If you have a guess/hypothesis that there is a space at a particular position in one of the ciphertexts, can you think of any way to test whether your guess/hypothesis seems likely to be correct or not?


5

Yes, there are secure alternatives to support random-access based encryption. I did not come up with a way to break the proposed combination. Still, instead of inventing a new mode, I would recommend to take consider existing modes for this kind of operation, such as XTS mode. The existing modes are more studied, and (in some ways) more efficient. XTS mode ...


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


3

Some remarks: a 16 byte IV is required by CBC, but you may not require a 128 bit unique value for your protocol CBC relies on an IV that is indistinguishable from random to an attacker, fixing bits in the IV is not a good idea CBC requires a padding mechanism, unless you can use ciphertext stealing Now a few calculations reveal that if you rely on the ...


3

Each zero in m1⊕m2 indicates a matching character. These are known as coincidences. The number of coincidences can possibly indicate what language they are communicating in since different languages have a different character frequency distribution. (Random data should have coincidences 1/26 of the time if using only lowercase letters, whereas English should ...


3

I think what you are looking for is a Password-Based Key Derivation Function (PBKDF). You can take a moderately strong password, like 12-14 random letters and numbers (no dictionary words though!), and throw it into the PBKDF function together with some other parameters, e.g. salt, number of iterations and the desired key length. After that you have a ...


3

The thing here is: When you just XOR the cyphertexts with each other, what you get is in fact the XOR result of both cleartexts. f(a) ⊕ f(b) = a ⊕ b And after that point, all that's left is to use statistical analysis, as ir01 has mentioned. In fact, the early cell phones used to implement a somewhat similar encryption scheme. They had a one byte (if ...


2

What you want is a key derivation function (KDF). Here's a fairly thorough list of some standardized ones. Ps. The suggestion given by user1852723 to use HMAC, with your "seed" as the key and a counter (or other non-repeating sequence) as the input, more or less corresponds to the "Counter mode KDF" construction described in NIST SP 800-108, with HMAC as ...


2

What you are looking for is a Pseudo Random Function that should be indistinguishable from uniform, even if the key material that is passed to it is not. One potential problem with your scheme is that the AES key schedule is not particularly good at extracting the entropy from keys that are not selected (pseudo-)randomly, such as passwords and pass-phrases. ...


2

You should consider using an authenticated encryption (AEAD) mode. As @d-w says, and as the name implies, it will detect malicious manipulations of the cipher text stored in the DB with high probability. On top of that: you will also detect all cases where you are using the wrong key by mistake. you can authenticate any metadata associated to the credit ...


2

Generate key-pair Generate random salt, hash password with proper password hash (scrypt or PBKDF2) to derive a master key. Use HKDF to derive one login key and one encryption key from master key Encrypt private key with encryption key from previous step Upload it to server, download only possible by proving possession of login key (either send over SSL, or ...


2

Would you say: the probability of mass life extinction on earth caused by asteroid impact is like $2^{-28}$/year; but the risk is so big that I think it's worth taking some countermeasure? The applied cryptographer's position is that below a certain probability, like $2^{-40}$ lower than mass life extinction on earth, there's no need to mitigate the risk. ...


2

Your combined mode of operation is not as easy to attack as a two-times-pad (i.e. stream-cipher with fixed IV used twice), but it still has some weaknesses. For example, an attacker which did read your file before and after the change can easily find out which 128-bit-blocks of the file did change and which ones stayed the same. Depending on the file format ...


2

If they are not generating a new key for every encryption, then the other answers apply. If they are generating a new random key for every encryption, then there are no glaring security holes (since they are using a poor random number generator, even if they think they are generating new keys for every encryption, they might not be). That said, if they ...


2

Yes, the same keypairs can be used to derive shared secrets between multiple pairs of parties. If knowing the shared secret between Alice and Bob would help Eve find out the shared secret between Alice and Carol, Eve could just create her own random private key and calculate a "shared" secret between that key and Alice's public key to get the same ...



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