Support files and messages that sources have encrypted with the site's public key prior to uploading/submitting them

[hoyla]

HI I'm sorry if this issue is recorded somewhere else; I couldn't find it although I imagine you're well aware of it. In summary the sd-app on the SecureDrop Workstation does not handle content that has been recursively encrypted with the same key, even though that is what happens when sources follow the on-site instructions.

1. Source goes to source interface site x.onion
2. Source reads the instructions at x.onion/why-public-key
3. Source downloads the public key and encrypts a file y.pdf => y.pdf.gpg using the pubkey
4. Source composes a message and encrypts that text using the pubkey
5. Source uploads the encrypted file and submits the encrypted text.
6. Server re-encrypts the encrypted message and file so there is two layers of encryption on each, using the same public key.
7. Journalist uses the SecureDrop workstation to sync and decrypt the message and file.

Result:

• Journalist sees ciphertext in the sd-app. One layer of encryption has been stripped away, but not the next. There is no obvious way for the journalist to access the site's private key to decrypt the message a second time.
• Journalist sees encrypted file "y.pdf.gpg" in the sd-app. As above just one layer of encryption has been stripped away. If the journalist attempts to open this file it is treated as an unknown file type and the temporary VM shuts down.
• The only obvious way to view these files is to export them to a LUKS encrypted USB stick, launch an old SecureDrop Viewer workstation, and decrypt there.

Is there a way for the journalist to access the private key on the Qubes workstation?

[rocodes]

Hi @hoyla, sorry you're encountering this. Right now the workstation doesn't handle double-encrypted files and messages, as you can see. (client repo issue: https://github.com/freedomofpress/securedrop-client/issues/220)

To answer your question, the private key material is stored in the vault VM (sd-gpg), but since it's the most sensitive credential in the system, I'd be worried about any workarounds that would have users interacting manually with sd-gpg and potentially introducing human error. So I'm afraid that for now, using Tails and the SVS as a fallback is the right call.