Expose journalist public key to sd-app

[legoktm]

Currently sd-client uses qubes-split-gpg to encrypt journalist replies, in the new app we are shifting to doing the encryption in the app itself; this is because we don't actually need access to the private key to encrypt a message, we just need the public key.

In dom0/sd-gpg we have access to the private key, we would need to extract the public key out of it.

Some potential options:

1. During provisioning, export the public key and set it in QubesDB for sd-app
2. In sd-app, export the public key from sd-gpg using qubes-split-gpg (as a persistent thing? on boot?)

[deeplow]

I don't fully understand the rationale for deviating from the previous implementation in this specific case. But regardless, here's my take:

During provisioning, export the public key and set it in QubesDB for sd-app.

I'm guessing this is no longer being considered due to the QubesDB limit. I think we could make it fit, but it would be brittle and doesn't sound like a good approach because of that risk.

In sd-app, export the public key from sd-gpg using qubes-split-gpg (as a persistent thing? on boot?)

This would be my preferred option if the use of another encryption library (as opposed to split-gpg) is set in stone. We already have the necessary RPC policies and there's no need to change provisioning and manage yet another key reference.

Regarding persistent vs on boot, I'd suggest doing it on need. Here's a breakdown:

• persistent - if I understand correctly, we'd want to avoid "persistent", given that it would mean going back to salt-configured sd-app.
• on boot: the usual pattern we've implemented is placed before other necessary systemd services start (which would depend on it) and whose development is outside of our control (e.g. Tor);
• on need: the client is different because we fully control when this information is needed, so the client can request the public key from sd-gpg when it needs it, somewhat similar to how sources' keys were imported into sd-gpg in the old client. This avoids the often necessary complexity of on-boot configuration. In practice, on every run, the client will ask for the public key once per session.

[legoktm]

I don't fully understand the rationale for deviating from the previous implementation in this specific case.

Primarily so that we don't need to import all the source keys into the sd-gpg keyring, which ends up being separate state and just slows things down, and secondarily, it's both simpler and faster to handle it all in the same VM since no private keys are even needed.

[legoktm]

Regarding persistent vs on boot, I'd suggest doing it on need. Here's a breakdown:

This makes total sense and I agree with your analysis + conclusion. Let me move this issue to the client repo then, since all the development work will happen there.

[legoktm]

@zenmonkeykstop wrote:

Could export at application start from sd-gpg, getting the pubkey for all private keys stored. It might be a bit more future-proofed. (Also means no securedrop-workstation changes needed.)

Yes to the general plan, but I think we would just export the primary submission key that is configured in QubesDB. Any extra private keys in sd-gpg should be just for decryption, not encryption. This matches the server behavior in that there's only one submission key that journalists encrypt replies to.

[cfm]

Just in the interest of explicitly ruling out simple things: Have we considered writing the first 3072 bytes of the public key to QubesDB key SD_PK_1 and the remaining 1024 bytes to SD_PK_2 and then concatenating them (SD_PK = SD_PK_1 || SD_PK_2) within the app? (Is that what we're worried would be brittle? :-)

[legoktm]

I didn't consider that tbh, it does feel a little brittle to me though... 🤔

[deeplow]

I thought about that possibility as well. If on the fate of sd-gpg regarding its persistance (to be discussed today in freedomofpress/securedrop-workstation#1325) we conclude that we'd want to expose the private key via a very simple RPC policy (sd-gpg -> dom0), then we could also consider doing the same thing for exposing the public key in the same manner. That's another option as well.