Tag Info

Hot answers tagged

24

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


23

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


16

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


11

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


10

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


7

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


7

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


7

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


5

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


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

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


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

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

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


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

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


2

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


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


1

There is a straightforward brute force method. For example, take the lowest $8$ bits of everything and check for valid values of $K_1$ and $K_2$, mod $2^8$. You will need about $2^{16}$ checks to get the lower $8$ bits of $K_1$ and $K_2$. Proceed then to values mod $2^{16}$, as you know the lower $8$ bits of $K_1$ and $K_2$, only bits $8\dots15$ of these ...


1

The scheme you describe is perfectly secure, so long as you are only sending a message as long as the pre-shared key. So basically it's an inefficient way to do a One Time Pad. Let's see what happens when you try to send 768 bits of message when you only have 512 bits of pre-shared key: Let $A$ and $B$ be the two blocks of pre-shared key material (each ...


1

Let me get this straight; if you are sending a 256 bit message, and get a 256 bit reply, the obvious way using OTP would be the message to use up 256 bits of pad, and the reply to use up a separate 256 bits of pad, using a total of 512 bits. Instead, you propose to use a total of 512 bits to send the message (and a temporary pad), the reply will then be ...


1

Your scheme lacks any authenticated. I recommend you use authenticated encryption. Yes, this will require additional storage. It's necessary. ECB mode is not recommended. To expire a key and introduce a new one, why don't you just decrypt all of the current stuff under the previous key and re-encrypt under the new key? Applying bit-flipping to IVs is a ...


1

Search for passwords on IT Security and you will find tons of advice on how to store passwords, and how not to. Your scheme is not a good method for hashing passwords: it is a fast hash, it lacks any salt, and it unnecessarily limits the password length. People have studied this at great length: before trying to re-invent the wheel, I suggest you read up ...


1

Since a good block encryption algorithm, e.g. AES, running in counter mode, i.e. encrypting some more or less arbitrary chosen (unknown to the opponent) input values, is generally considered to be sufficiently secure, IMHO that could provide a rather simple and convenient way of deriving a large number of keys from a given master key. One could that way even ...


1

can we assume that b breached number of keys, no matter what the quantity would not help an attacker discover the previous nor next key in the set without the original seed data? No, you cannot assume it. Whether that holds depends upon what key generation algorithm you use. For good key derivation algorithms it will be true; but if you choose an ...



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