If attacker has original data and encrypted data, can they determine the passphrase?

Question

If an attacker has several distinct items (for example: e-mail addresses) and knows the encrypted value of each item, can the attacker more easily determine the secret passphrase used to encrypt those items? Meaning, can they determine the passphrase without resorting to brute force?

This question may sound strange, so let me provide a use-case:

1. User signs up to a site with their e-mail address
2. Server sends that e-mail address a confirmation URL (for example: https://my.app.com/confirmEmailAddress/bill%40yahoo.com)
3. Attacker can guess the confirmation URL and therefore can sign up with someone else's e-mail address, and 'confirm' it without ever having to sign in to that person's e-mail account and see the confirmation URL. This is a problem.
4. Instead of sending the e-mail address plain text in the URL, we'll send it encrypted by a secret passphrase.
5. (I know the attacker could still intercept the e-mail sent by the server, since e-mail is plain text, but bear with me here.)
6. If an attacker then signs up with multiple free e-mail accounts and sees multiple URLs, each with the corresponding encrypted e-mail address, could the attacker more easily determine the passphrase used for encryption?

Alternative Solution

I could instead send a random number or one-way hash of their e-mail address (plus random salt). This eliminates storing the secret passphrase, but it means I need to store that random number/hash in the database. The original approach above does not require storage in the database.

I'm leaning towards the the one-way-hash-stored-in-the-db, but I still would like to know the answer: does having multiple unencrypted e-mail addresses and their encrypted counterparts make it easier to determine the passphrase used?

Answer 1

Yes, it does make it easier. In general, the more information the attacker has, the easier their job becomes. This specific example is called a known-plaintext attack.

Answer 2

What you're describing is a known-plaintext attack. Classical ciphers were very vulnerable to this sort of attack, but modern ciphers are designed to resist it.

You'll want to read up a bit on crypto.

Answer 3

Although you can probably, with some research, choose a strong enough cryptographic method to resist the known-plaintext attack, is it really worth it just to avoid storing a hash in your database?

Using a single passphrase to encrypt all registration requests seems like you're adding an unnecessary single point vulnerability: if an attacker does crack that passphrase somehow, they can register as many accounts as they want. If, on the other hand, you generate for each new account request a one-time hash (of email address+random number, for example) to authenticate the confirmation URL, even a hacker who intercepts the confirmation email for account A is no closer to getting access to B, C, or D.

You probably want to store some state information about the confirmation process in a database anyway: there should probably be a time limit on how long the confirmation URL is valid.

Answer 4

What you need is not encryption, it is authentication. In the link you send to customers, you include not only their email address, but a timestamp and what is called a MAC, which is a symmetric-key based authentication field. The MAC should authenticate both the email address and the timestamp. 64-bit HMAC-SHA1 should do you. When you receive the link, check that the timestamp is not too far in the past and the MAC verifies; then you know you generated the link.

MACs are designed to resist attacks where attackers get to choose messages and ask for the corresponding MACs, so you don't need to worry about the MAC equivalent of a "known plaintext attack".

Answer 5

There is one scenario where the answer is YES!!! And that is if you use a stream cipher, such as RC4.

RC4 is essentially a random number generator that simply XORs the plaintext with a 'key stream' derived from your key:

P0 ^ K0 = C0
P1 ^ K1 = C1
P2 ^ K2 = C2
.
.
PN ^ KN = CN

If you have both the plaintext and the ciphertext, you can do this:

C0 ^ P0 = K0
C1 ^ P1 = K1
C2 ^ P2 = K2

and so on. As you can see, you get the key stream back. Not the key, but the stream generated by the key.