3 ms·

Documents are public key encrypted and you view them on an airgapped laptop. Submission server is on TOR to provide obfuscation of the transmission source. IMH

by crb002 13y ago

Documents are public key encrypted and you view them on an airgapped laptop. Submission server is on TOR to provide obfuscation of the transmission source. IMHO the system is over complicated. There should just be a client side HTML5 drag and drop that encrypts files pre-transmission. Should be symmetric so both source and journalist are reading messages on an airgapped laptop.

jarrett 13y ago
> There should just be a client side HTML5 drag and drop that encrypts files pre-transmission. The problem is that you'd be doing crypto in JavaScript. We're not currently at a point where that's viable: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ Currently, if you want to securely transmit a document, you're pretty much stuck with learning and using something like PGP/GPG. Which is a pain for a lot of people, because there are new concepts to learn, software to install, and keyrings to manage. But it's the best we have right now.
- arca_vorago 13y ago
  I'm curious why more people aren't setting up dmz'd ssh servers on something like raspberry pi's for communication/document transfer with others. I wonder how viable a torrent like ssh p2p system would function... mumbles thoughts to self All I know is that PGP/GPG use can be a pita, and I've noticed fewer people who used to using it these days, which seems strange. (I thought the NSA revelations would have upped adoption...)
  - conradev 13y ago
    It's certainly viable: http://labs.bittorrent.com/experiments/sync.html http://labs.bittorrent.com/experiments/sync.html
  - jarrett 13y ago
    I'm not sure a P2P SSH system would be any better. With SSH, you still need to manage and verify keys. This is where the PITA is with PGP. People don't like generating keys, fiddling with key rings, etc. So I don't see significant usability gains there. Conceivably, you could do something with ephemeral keys, but then you're moving away from an SSH model. And ephemeral keys have their own problems. Namely, you have to verify the other person's key every time. (Often people use voice verification for this.) So while managing keyrings in PGP is annoying, so are ephemeral keys. I think crypto inherently imposes annoying burdens on end users. Also, a big advantage with PGP is that it works asynchronously. I can send you a PGP-encrypted email, and your computer doesn't even have to be turned on at the time. With P2P, both parties have to be present and have their clients running at the same time.
solutionyogi 13y ago
What's your credential to claim that system is over complicated? Are you a security professional? Have you performed a full blown security audit of the system? Have you designed an alternate system which is less complicated and equally secure?
JshWright 13y ago
I'm not sure you understand what 'airgapped' means... (Hint: WiFi doesn't count)
not_rhodey 13y ago
I'm inclined to agree with you, generally speaking simplicity is security. Also, I believe that the "secure JS in-browser crypto is impossible" argument is entirely bunk in this context-- people need to stop reciting this compulsively and take the time to think each situation through. Realize that the SecureDrop document submission client is a web application. The browser of the document submitter will run whatever the SecureDrop Source Server provides it barring the edge case of the submitter verifying the source page source with GitHub before allowing JS in NoScript. The security of the document submitter is already prone to compromise by way of a malicious web app provided by malicious Source Server or MITM. Moving the project to something more JS heavy on the client side would in no way worsen the threat model.
- jarrett 13y ago
  > people need to stop reciting this compulsively and take the time to think each situation through. I believe that thinking has already been done, and the reasoning published. If you can refute the well-publicized arguments against JS crypto, then of course that would be productive and appreciated. Given the discussions that have already taken place, I believe the burden of proof now rests with those who support JS crypto, not those who oppose it. To make an analogy: We "compulsively" assert that the earth orbits the sun. But that's not a cargo cult. It's a conclusion which we've confidently accepted based on the weight of the evidence. > Realize that the SecureDrop document submission client is a web application. The browser of the document submitter will run whatever the SecureDrop Source Server provides it barring the edge case of the submitter verifying the source page source with GitHub before allowing JS in NoScript. If that's true, then SecureDrop might not be so secure. I'm not pointing to SecureDrop as a gold standard. There are very few cryptosystems I trust. > The security of the document submitter is already prone to compromise by way of a malicious web app provided by malicious Source Server or MITM. Moving the project to something more JS heavy on the client side would in no way worsen the threat model. That might be true, but then again it might not. We don't know much about JS crypto. We don't know what attacks are possible. (We know about compromising the JS source, but that's only one threat model. There could be others that are unstudied.) Thus, it's quite possible that there are attacks which depend on the application using a specific browser feature, such as drag-and-drop. Is this likely? Not terribly so. But is it possible? Absolutely. But I'm sort of nitpicking. Like you said, JS can be MITMed, so there's not much point in debating whether a given JS crypto app is secure or not. The best strategy is to just not use JS crypto.

by crb002 13y ago

jarrett 13y ago

> There should just be a client side HTML5 drag and drop that encrypts files pre-transmission. The problem is that you'd be doing crypto in JavaScript. We're not currently at a point where that's viable: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/ Currently, if you want to securely transmit a document, you're pretty much stuck with learning and using something like PGP/GPG. Which is a pain for a lot of people, because there are new concepts to learn, software to install, and keyrings to manage. But it's the best we have right now.

arca_vorago 13y ago
I'm curious why more people aren't setting up dmz'd ssh servers on something like raspberry pi's for communication/document transfer with others. I wonder how viable a torrent like ssh p2p system would function... mumbles thoughts to self All I know is that PGP/GPG use can be a pita, and I've noticed fewer people who used to using it these days, which seems strange. (I thought the NSA revelations would have upped adoption...)
- conradev 13y ago
  It's certainly viable: http://labs.bittorrent.com/experiments/sync.html http://labs.bittorrent.com/experiments/sync.html
- jarrett 13y ago
  I'm not sure a P2P SSH system would be any better. With SSH, you still need to manage and verify keys. This is where the PITA is with PGP. People don't like generating keys, fiddling with key rings, etc. So I don't see significant usability gains there. Conceivably, you could do something with ephemeral keys, but then you're moving away from an SSH model. And ephemeral keys have their own problems. Namely, you have to verify the other person's key every time. (Often people use voice verification for this.) So while managing keyrings in PGP is annoying, so are ephemeral keys. I think crypto inherently imposes annoying burdens on end users. Also, a big advantage with PGP is that it works asynchronously. I can send you a PGP-encrypted email, and your computer doesn't even have to be turned on at the time. With P2P, both parties have to be present and have their clients running at the same time.

solutionyogi 13y ago

What's your credential to claim that system is over complicated? Are you a security professional? Have you performed a full blown security audit of the system? Have you designed an alternate system which is less complicated and equally secure?

JshWright 13y ago

I'm not sure you understand what 'airgapped' means... (Hint: WiFi doesn't count)

not_rhodey 13y ago

I'm inclined to agree with you, generally speaking simplicity is security. Also, I believe that the "secure JS in-browser crypto is impossible" argument is entirely bunk in this context-- people need to stop reciting this compulsively and take the time to think each situation through. Realize that the SecureDrop document submission client is a web application. The browser of the document submitter will run whatever the SecureDrop Source Server provides it barring the edge case of the submitter verifying the source page source with GitHub before allowing JS in NoScript. The security of the document submitter is already prone to compromise by way of a malicious web app provided by malicious Source Server or MITM. Moving the project to something more JS heavy on the client side would in no way worsen the threat model.

jarrett 13y ago
> people need to stop reciting this compulsively and take the time to think each situation through. I believe that thinking has already been done, and the reasoning published. If you can refute the well-publicized arguments against JS crypto, then of course that would be productive and appreciated. Given the discussions that have already taken place, I believe the burden of proof now rests with those who support JS crypto, not those who oppose it. To make an analogy: We "compulsively" assert that the earth orbits the sun. But that's not a cargo cult. It's a conclusion which we've confidently accepted based on the weight of the evidence. > Realize that the SecureDrop document submission client is a web application. The browser of the document submitter will run whatever the SecureDrop Source Server provides it barring the edge case of the submitter verifying the source page source with GitHub before allowing JS in NoScript. If that's true, then SecureDrop might not be so secure. I'm not pointing to SecureDrop as a gold standard. There are very few cryptosystems I trust. > The security of the document submitter is already prone to compromise by way of a malicious web app provided by malicious Source Server or MITM. Moving the project to something more JS heavy on the client side would in no way worsen the threat model. That might be true, but then again it might not. We don't know much about JS crypto. We don't know what attacks are possible. (We know about compromising the JS source, but that's only one threat model. There could be others that are unstudied.) Thus, it's quite possible that there are attacks which depend on the application using a specific browser feature, such as drag-and-drop. Is this likely? Not terribly so. But is it possible? Absolutely. But I'm sort of nitpicking. Like you said, JS can be MITMed, so there's not much point in debating whether a given JS crypto app is secure or not. The best strategy is to just not use JS crypto.