Add possibility for generating the PGP key clientside

[evilaliv3]

An interesting feature to be developed in the short term and that would be useful for a lot of adopters and users (i'm thinking for example to big multi stackolder AfriLeaks, PubLeaks but in general to receivers workflow semplification or to other training reasons) would be to add the possibility to generate the PGP key clientside both from the Receiver interface that from the Admin interface.

It would be interesting infact to add the possibility for the user to generate the key directly from the web interface and to perform the following actions:

1. save the public key on the node (automatically performed)
2. download the password armored secret key on its computer.

this would be an interesting first step of integration of openpgp.js and the features implemented won't result to be trashed also in the long term solution that will be implemented in the OTF roadmap obtaining e2e. in fact this feature will simply pass to be performed manually by receivers to be automatically performed by the glclient but the low level routines implemented would probably remain the same.

among the requirements for the implementation:

• the pgp key key for the user need to be automatically generated with secure settings without the need for the user to choose them (e.g. 4096 bits, 2years validity)
• the input by the user should be reduced to the minimum: (e.g. no need to type the name or the user, that is the receiver name nor the email of the user that is the receiver email.)

[evilaliv3]

@fpietrosanti / @hellais : i was thinking this thing with @vecna while thinking for exampel to our training (afrileaks or the possible future session at IJF) where we want to simplify the steps needed in order to create the PGP key without the need for a special software for the user in the first steps of the setup, and minimizing the know how needed to perform the action that will result simply in a click.

what do you think?

[evilaliv3]

@hellais i'm assigning this task to you and this would be probably an interesting thing to be probably implemented in your next development cycle.

[fpietrosanti]

I think it's needed for the overall OpenPGP client-side encryption functionalities, btw imho it's not necessarily going to significantly improve that much the usability (ie: A user already having it's key). If we want to start from this process, rather than from the file encryption approach, that's fine.

[vecna]

Currently one of the limit of GPG/PGP is:

• generating a key require a unique procedure, and this unique procedure has to be show during the training. This lead to confusion because is something that has never done anymore.
• different OS had different softwares to do that
• we support only "PGP key armor", and this mean open a .asc file in text mode, copy paste. This is quite uncommon for some users.

Therefore "generate PGP key" solve an entrance barrier, that's why matter. we can keep as secondary the key backup functionality.

[evilaliv3]

yep @fpietrosanti by the way this ticket is nothing so long to be implement and won't require more than a single day long activity.

my view of simplification is exactly the one said by @vecna. this way when the Admin or the receiver want to setup the key it does not require the user to download a specialized software nor to type specialized commands. to this aim i'm thinking of the training i followed in joburg where i passed along every tails platform an i has to open a terminal, type gpg --antani writing the length and bla bla with a procudere prone to a lot of errors and waste of time.

[fpietrosanti]

@evilaliv3 i think that integrating openpgp.js, managing the async key generation, exporting the keys in gnupg digestable formats, etc would require 5-10 working days minum. Btw there's no major usability improvement on receiver-side because it still need to use specialized software, but instead of having to learn the graphical gpg tool to generate the key, need to learn the same tool to do the import. Not big improvement there.

[evilaliv3]

yep i agree that probably on the gnupg digestable formats, but we will see. anyhow all are things to be addressed in the OFT roadmap.

and okay the semplification is more on the admin side during a training but trust me that on that side it will speed a lot the things saving ~3-5 minutes for receiver and minimizing the errors. i'm thinking in fact that during a training if you stay so much on singular computer you are loosing the attention of other people and and in addition generally if the single receiver procedure is long to not loose the single receiver one ends in telling what he is doing and that ends in more loosed time.

[fpietrosanti]

Ok, the key generation has to be done anyway for the roadmap, but a set of other issues to be done before arise to my mind such as:

• verifying the availability of entropy in the browser
• checking the browser version/capabilities
• provide the ability to repeat the procedure in presence of errors (ie: what if the user does not save the generated keyring?)
• doing the key generation job "asynchronously" in order not to freeze the browser
• providing all the UX/graphical feedback during such sort of "receiver activation process" (that shall be integrated within a forced-globaleaks-password-change i expect)
• testing the procedure to import the keys (analyze the format required to minimize user interactions, data-format and HTTP mime/type required to fire the Tails graphical Key management tool).
• document the procedure in the wiki "Encryption" section

[evilaliv3]

right points. i've already thinked to some; here are the answers

• verifying the availability of entropy in the browser: for this one we need to enquire the community.
• checking the browser version/capabilities: this would be somehow straingtforward by asking the openpgp js community and then writinga a requirement test and eventually not offering the clientside feature
• provide the ability to repeat the procedure in presence of errors (ie: what if the user does not save the generated keyring?): no real problem exists as right now. simply the user will continue to have the possibility to generate a new key (the same apply rightnow where the user can load a new key)
• doing the key generation job "asynchronously" in order not to freeze the browser: i'm hoping that also related to this the openpgp js community has already solved the issue.

[evilaliv3]

this ticket should be reformulated in relation to the specs writtend on https://docs.google.com/document/d/1ShdxubexlFPKedhO28i0RvnjHSiQU4lma5B0DSs2xsQ/edit?usp=sharing . its best to switch using that document to keep track of the various changes and then cleanup this ticket with the exact things to be implemented.

[evilaliv3]

i'm going to add the support for this ticket in the devel branch and to integrate the code in a new branch called feature/end-2-end-encryption.

[evilaliv3]

components for this have been already tested but such such a feature for the receiver is still not present even in end2end branch. let's move this ticket to next milestone.

[evilaliv3]

Closing a deprecated.