3 ms·
Sending big files (inherently an asynchronous thing) through a small network which is inherently connection oriented seems like a bad idea. It is a useful tool
by rdl 12y ago
Sending big files (inherently an asynchronous thing) through a small network which is inherently connection oriented seems like a bad idea. It is a useful tool based on what components are available right now, but this is the wrong way to do things overall for security.
Both of the users have to be online simultaneously; both will be sending/receiving roughly the same amounts of data at roughly the same time.
If the user is under observation already (due to suspicion, or due to being on a logged network), and the recipient is already under monitoring (a safe assumption if he's a well known journalist writing about NSA, or Wikileaks, or whatever), it's pretty easy to correlate the flows, then find/fix/finish.
The less insane way to do this is to publish an encrypted file to some pool (usenet, youtube, etc.) using whatever anonymity technology is available to you, and then at some point in the future have the recipient download it. Moving a 256bit key anonymously can be done much more safely through the control channel (the same way you tell the user where to download), and could even be done in a broadcast way.
Or, USPS. There, you get first class mail protection on the contents, an easy to understand security model, and limited user education. I'd use USPS in preference to the SecureDrop system, and I'd sure use it in preference to this.