3
$\begingroup$

Is it possible to find out which public key was used to generate the message?

Scenario is like this :

I got data which is encrypted with a public key. Now a "bad guy" hast the encrypted data, and knows the decrypted content and wants to know who was the receiver of the data. The "bad guy" has all possible public keys which could have been used to encrypt the data.

Is it possible for the "bad guy" to find out who was the receiver(or witch public key was used).

Thanks a lot.

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ Yes, you can try all keys to find the one that matches the ciphertext but that would be impractical depending on how many keys exist. For example you may have recovered 10-20 keys somehow (practical), or you might try to brute-force all possible key combinations (impractical). And no, you cannot find the recepient without extra data such as an email address, message content that gives away personal info etc. $\endgroup$
    – rath
    Apr 24 '13 at 17:24
  • $\begingroup$ I seem to remember having read (either here or at security.SE) that PGP $\hspace{1.8 in}$ intentionally makes it easy to do that. $\:$ $\endgroup$
    – user991
    Apr 24 '13 at 17:48
  • $\begingroup$ The decrypted content is of no help accomplishing this task. But he can trivially do it because the PGP file contains the ID of the key needed to decrypt it. $\endgroup$
    – David Schwartz
    Apr 27 '13 at 8:28
1
$\begingroup$

From this answer:

The key ID of the recipient is included in plain-text in the encrypted file. Other possibly interesting information "hidden in plain sight" is just the size of the file, or the name of the encrypted file (if someone just sends it without alteration of course.)

What you might not realise is that the recipient Key ID is effectively an optional field. ...

and

You can encrypt using the -R (or --hidden-recipient) flag with gpg to avoid revealing the recipient's public key in an encrypted message.

and

... However, also see this answer for ways to differentiate between recipients if the attacker has access to a large number of messages.

A practical aside -- secondary clues may be in various logs. For instance, an attacker who obtains such a message might also be able to access (say) a .bash_history file with the recipient's address, or a web-server log with IP addresses that provide clues to who POST'ed or GETs the file, etc.

Improve this answer
$\endgroup$
2
  • 3
    $\begingroup$ While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. (Maybe you can replace that ${\color{red}{white\ text\ workaround}}$ with some excerpts of the Security.SE Q&A you’ve linked to? That would surely make more sense…) $\endgroup$
    – e-sushi
    Sep 2 '14 at 18:50
  • $\begingroup$ @Ricky I have to concur to e-sushi's comment ... could you write at least some excerpt of that answer here, maybe with some emphasis on the crypto-related stuff? $\endgroup$
    – Paŭlo Ebermann
    Nov 18 '14 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.