Sending encrypted file and password by email

Question

I know that a password for an encrypted file distributed by email should be sent out of band (i.e. not via email), and that there are better options for distributing information securely.

But, let's say someone ignores this advice and uses email for both, albeit in separate emails separated by some arbitrary time delay.

Assuming that hosted email services are used i.e both source and destination email servers are in 'the cloud' and we only consider the risk of observation of the emails as they travel across the Internet (between the sender's domain and the recipient's domain).

My initial thought is that it should be assumed that the encrypted file has been compromised, but upon reflection I don't know enough about Internet routing protocols in practice to decide whether their dyanmic nature is a factor for consideration or not.

So the question is: does the way routing protocols work mean that it is possible to come up with a likelihood that the two emails will follow the same route across the Internet and thus both be susceptible to unauthorised observation at the same point?

Answer 1

Ignoring the fact that most data is stolen at the nodes rather than in transit, your thinking isn't really quite right about how networks work, and how attackers think about traffic interception. Networks aren't just random points on a grid where a different path is chosen all the time. They're organized in a fashion where there's often going to be common points where interception is possible. This is where an attacker wants to insert him/her/itself.

Consider how the NSA behaves. The NSA tries to insert itself into these key points. You can clearly see this on one of the Snowden leaked slides: The point being, you don't have to "get lucky" and choose the right path, on the right day when you've inserted yourself into a choke point on the cloud.

Also, consider that attackers make "active attacks" and try to redirect traffic rather than sitting passively and hoping traffic will come their way. Simple examples of this are ARP poisoning and DNS poisoning. More sophisticated examples are the NSAs "Quantum Insert" project.

Answer 2

In general, you are not able to calculate that likelihood with any meaningful precision, except in very delimited cases.

TL;DR *I believe that the likelihood of an intercept at either of the channel ends is quite greater than that of a random intercept, decode, and use in transit.*

To extract the username and password from your mail traffic someone would need to be specifically targeting you; unless you also send the email with some subject amenable to large scale screening, such as "HEY! USERNAME AND PASSWORD HERE!" -- which is unlikely, to say the least. So could our hypothetical attacker be reading a torrent of emails and pick out not only your credentials (across a time delay span) but even how to use them, and where?

A way more realistic scenario is that someone is actively targeting you. To quote Arkady Darell, where would such an action make the most sense? In the middle of the Internet? Or rather at one end -- such as the sending computer, or the receiving server or computer, where we know that all such mail must, sometime or other, pass?

Therefore, if you send the email in the clear, you have to assume that your traffic has been locally sniffed and the place "where the two email routes intersect" is your own computer (or network).

If you do not send the email in the clear and use SSL, then you mostly need not worry of whatever happens en route. But you still need to worry about the sending computer's security (keyloggers, janitors, security cameras picturing the screen, ...) and the receiving computer's security.

And the server (or at least recipient mailbox account) security. For example, someone able to break into the mailbox account would be able to recover username, password and your email history, from which he could glean how to use the stolen authentication -- or vice versa, he could skim the emails, learn that there's a useful authentication being sent, and search for that.