(In reply to James Alexander from comment #0)

(and private key displayed or saved, personally I think it should be saved
to server)

As far as saving it to the server: the point of the encryption (AFAIK) is to prevent people from looking at the poll results until the poll is closed. If we have the key sitting right there next to the encrypted poll results, why bother encrypting it at all instead of relying on system and db access restrictions to keep people out?

(In reply to Brad Jorsch from comment #1)

(In reply to James Alexander from comment #0)

(and private key displayed or saved, personally I think it should be saved
to server)

As far as saving it to the server: the point of the encryption (AFAIK) is to
prevent people from looking at the poll results until the poll is closed. If
we have the key sitting right there next to the encrypted poll results, why
bother encrypting it at all instead of relying on system and db access
restrictions to keep people out?

I'm open to debate and PB is on the bug as well I think. I completely agree that it should not remain on the server. Traditionally it had been placed in the hands of a trusted third party (for board elections outside counsel for example or for arbcom elections LCA) and so the person actually creating the poll (who is more likely to be the person checking votes etc) is not necessarily someone who should have access to the key. The idea was that saving it as a file on the server (perhaps as an SQL file with the insert command for later or just as a txt file) would allow us to pull it off the server, delete it from the server and give it to the trusted person.

Apologies in advance: I'm actually responding from vacation and from the seat of a plane about to take off so I may not be able to respond for a little while. I will be back working remotely Thursday and in the office late Monday afternoon.

So, if the keys are not supposed to be stored on the server, and also the user who inputs the poll also isn't supposed to deal with the keys, what should the solution be?

Storing the keys server-side means that anyone with root access on that server can eavesdrop the communications. Given the level of protection needed in this case, the best "user-friendly" solution would be using a browser extension for managing and handling the private key and its encryption work. A good example of this approach is what mailvelope (https://www.mailvelope.com/) is doing.

Having credible End-to-end encryption cannot happen on a vanilla browser, and has been debated over and over in the security community.

Storing the private key on the server does seem to defeat the purpose of encrypting the results, unless that key is itself encrypted, or stored somewhere that has extra controls.

From what I can understand of the flow, if you want to keep it how you have it, you could probably encrypt the private key with a new random password, and then email the password to the users who are supposed to use it.

A safer option is to have the private-key users actually do the key generation, and then add only the public key to the poll before it starts. That prevents attacks on getting the private key, and attacks on the key generation process.

(In reply to Chris Steipp from comment #5)

Storing the private key on the server does seem to defeat the purpose of
encrypting the results, unless that key is itself encrypted, or stored
somewhere that has extra controls.

From what I can understand of the flow, if you want to keep it how you have
it, you could probably encrypt the private key with a new random password,
and then email the password to the users who are supposed to use it.

A safer option is to have the private-key users actually do the key
generation, and then add only the public key to the poll before it starts.
That prevents attacks on getting the private key, and attacks on the key
generation process.

Sorry for the delay in responding to this.

First off we have two keys that need to be created here. One never needs to be sent too anyone but should definitely be automatically created and inserted into the database (this is the signing key which should be created with a comment something along the lines of "{{election name}} signing key" and the private key has to be inserted into the database.

The second key is the 'encryption' key and the one we're mostly talking about here. This is the one where the public key needs to be inserted into the database but the private key should not be (until after the election).

I don't think we need to get too deep in the guts here since time is more important and, in the end, this is still a highly specialized tool and a bit of manual intervention in some areas is ok because of that. This was the idea about saving it on the server, not because it would stay there (it shouldn't) but just because it was a place it could be easily pulled from.

The big thing that I would like to try and avoid is the user manually creating the key themselves (using the cli tool etc) that's fine and dandy for me (and I've done it for the past couple years) but it's a strong weak point for people to screw up on or not know what to do. I want to make that as easy as possible and anything that requires them too copy and paste the key in to a form is bad for that and I think removes functionality and security from the current system rather then adding it in the end.

I could be ok with a separate form (perhaps that requires a separate right) that delivers the secure key to you as a download. The email option is intriguing but I imagine then requires us to put in a config variable for what email to use or to require that the poll creator know what email it should go too (and could easily just send it to themselves and that's actually probably the default for most people just out of what you would expect). That doesn't seem incredibly future proof... tbh I'm mostly still leaning towards saving the private key somewhere as hackish but one of the better options given everything but I can understand the desire not to do that.

What is the level of effort required for the options? The current copy and paste piece just doesn't meet the requirements sadly.

After consulting with Ops a little more, generating keys on the server isn't going to work for technical reasons: gpg --gen-key requires a lot of entropy, which tends to be in short supply on the servers. This means that generating each key is liable to take a long time and the lack of entropy might negatively affect other services.

About the only option left if you want to avoid people using gpg themselves is either a browser extension (as suggested in comment 4) or some sort of JavaScript key-generation library such as https://keybase.io/kbpgp/ (which I tried with an example from their documentation, and it didn't work right).

WONTFIXing this per discussion with Erik M, James A, Brad J, and myself on Friday.

See bug 71693 which satisfies a similar use case to this bug.