Expiration date on PGP key leaks date of source's first contact

[heartsucker]

Description

When we autogen PGP keys, the expiration is set to 1 year. This can be used to infer the date a source first used SD. We may want to remove this expiration field altogether to get around this issue.

[garrettr]

Mind if I take this one? :)

[garrettr]

Note that GPG keys also embed a Creation Date, which defaults to the current system time at the moment the key is generated; however, like the expiration date, it is also customizable.

[garrettr]

Additional thought: should we be specifying an expiration date on SecureDrop's internal reply GPG keys at all? The keys are managed by the server and never made accessible to anybody else. Allowing them to expire seems like it would create problems (e.g. a long-term user returns and can no longer receive replies because their reply key has expired) without any benefit (keys are managed by the server anyway). What do you think, @heartsucker, @redshiftzero?

[garrettr]

One more thought: should we add some code to randomize the creation and expiration dates for reply keys that have already been created on existing deployments?

[redshiftzero]

Additional thought: should we be specifying an expiration date on SecureDrop's internal reply GPG keys at all?

Good point, we should just have keys not expire

should we add some code to randomize the creation and expiration dates for reply keys that have already been created on existing deployments?

Hmm so I think one needs the passphrase of the private key to modify the expiration date / created on fields (worth double checking). If that's true, then we could add a method to crypto_util.py to check and update the expiration date / created on fields and run it after login (when g.codename is available). This won't handle the case if a user doesn't log in for a year, but there's not much we can do about that. What do you think @garrettr? Let me know if you think of a better place for this logic.

The nice thing about this migration being in the app code (otherwise I would wonder whether it's worth the trouble) is that writing unit tests to cover this scenario is pretty straightforward.

[garrettr]

This won't handle the case if a user doesn't log in for a year, but there's not much we can do about that.

Yup, I think that's the best/only option available to us given the other design constraints. Would you prefer I implement in the PR I'm about to submit for this issue, or would it be better to do it in a follow-up?

[redshiftzero]

I think it's worth getting the fix to remove the expiration date / created on fields in first (since it can cause a bug) and then we can tackle the removal of those fields after login for existing sources in a followup

Smaller PRs are best PRs :)

[garrettr]

@redshiftzero How would you feel about the following:

1. Land a PR that randomizes creation and expiration times (I have one nearly ready to go)
2. Create a follow-up issue that sets reply keys to never expire
3. Create a follow-up issue to manage updating existing keys

[redshiftzero]

Hmm, I suspect the diff between 1 and 2 is pretty small? Along those lines, I slightly worry about randomizing the times, e.g. for creation time it seems safest to just set the creation time to a certain date in the past (e.g. Jan 1 2010 or something equally arbitrary before the creation of SecureDrop).

Agreed on a separate PR/issue for 3