Concept of EasyGpg

This page tries to summarize the ideas of the EasyGPG Concept and its relation to the existing technology, namely Kleopatra. Wherever needed, the different sections individually address both aspects.

Vision

easyGPG

With easyGPG communication partners will typically exchange their emails and files confidentially. To achieve this, the effort needed for the user will be minimal and numerous security levels and compatible applications will be supported.

Comments:

• communication partners: all people even without any previous knowledge on crypto. See section archetypes for more details.
• typically: We are aware that we will not be able to reach 100% of the communication events and security demand varies between different users.
• confidentially: Means end-to-end encryption.
• minimal effort: We are aware that there will always be a small additional hurdle. We try to make it as small as possible to foster frequent use.
• compatible applications: A variety of applications can only be reached by providing open standards and free software.
• To make this vision become reality, we want to introduce a standard to define a handshake of the client about to send an email with the mail-provider that will return the public key of the recipient.

Kleopatra

Kleopatra will be a crypto manager providing all the power features advanced users need to manage their confidential communication. Users with lower demands will not need to enter to the full application, instead Kleopatra will provide contextual dialogues for the main applications (Mail, File Manager) to either allow to encrypt files or emails and to gather the information needed to configure private communication.

Users

Trying to formalize the users of a project is always a difficult task. We have decided to go with what we call archetypes for now:

Tasks of the Users

Following some typical tasks of the users are described and how the interaction with easyGPG resp. Kleopatra will look like:

T1: Sending Mail to one reciepient

Description: Annika wants to tell her University that she is sick.

User:

• This task does apply to all users

Comments:

• University provides a look-up service for public keys
• Communicating about Sickness is a sensible topic and hence the communication about it needs to be encrypted.

Workflow:

1. Annika starts email client on her desktop
2. Annika selects her university identity to send mail with
3. Annika put her professors email address into the TO: field.
   1. Automatically the public key for that address is being retrieved. A little indicator represents the security estimation of that communication process (smart integration of Tofu, WoT, individual certificate verifications,...). She could click here in order to gain more information about this state and what to do in order to improve the secrity estimation.
4. She writes and sends her mail as usual.

Remarks:

• This process in its ideal form does not require any more steps than sending usual, not-encrypted email.
• Users should be able to configure the behaviour if it is not possible to send an encrypted mail (e.g. send anyway, ask, wait for some time before being able to send)

T2: Communicating with a non-crypto user

Description: John wants to communicate safely with a potential whisle blower.

User:

• This task does also apply to all other users.

Comments:

• We assume the new contact has no key-pair yet.

Workflow:

1. John starts his email client on his desktop
2. John chooses the right identity to send with
3. John enters the email-address in the TO: field
   1. The system now searches for a public key, finds non and indicates this directly on the TO. field
4. John now enters the rest of the mail and presses "Send"
5. The system feedbacks to him, that it is not able to send encrypted (because John has defined this in the settings), why this is so and offers the following:
   1. Inform the communication partner how to set-up encryption:
      1. Send a mail with instructions
      2. Webpage with instruction to communicate via some other form (Telefon, Jabber, ...)
      3. White list this recipient as someone to not communicate ecrypted to
   2. Define what to do with this mail:
      1. Send not encrypted
      2. Save
      3. Send as soon as a key is discovered
      4. Discard the current mail

Remarks:

• The standard behaviour when trying to send to someone without key has to be defined. For Erna e.g. it will be sufficient to send anyway, without asking
• The white list of non-encryption partners needs to be configured. Ideally, the system searches for keys to the partners anyhow and asks to remove them from the white list, when a public key is being found.

T3: Create a new mail account after having recieved crypto instructions:

Description: Ernst want to leak and discuss a memo with John.

User:

• This task does also apply to all other users.

Comments:

• Ernst got an URL from John about how to setup crypto.
• To be secure nothing gets back to him, Ernst has bought a new computer.
• He has access to the internet and just applied for a free email account.

Workflow:

1. Following the instructions he now installs Thunderbird and Enigmail.
2. He starts and follows the normal setup to access his new mail account
3. After the "normal" mail setup, the dialogue asks him whether he wants to import his keys or create a new key.
4. He chooses new key, as he has none. The keys get generated and he gets asked to choose a password to protect his key.
5. He get instructions how to backup his key and gets asked to upload his key so others can communicate safely with him.
6. He is now ready to communicate with John.

Remarks:

• It seems to be reasonable to make the set-up process even slicker. Neither passwords nor uploading or backuping the key has to be done in this step. It might be a good idea to simply prompt the user with these tasks after having used crypto a couple of times. This advantage would be to even lower the barrier to start with crypto.

T4: Installation of GPG4Win / Kleopatra

Description: Annika wants to install software to encrypt her communication.

User:

• This task does also apply to all other users.

Comments:

• She has found some manuals, pointing her to install GPG4Win

Workflow:

1. She download GPG4Win and start the normal installation
2. During the installation the system shows her the new actions she can do with GPG4Win installed, namely file-actions and email actions.
3. After successful installation of GPG4Win she can
   1. Quit the application
   2. Watch a video (?) that explains the main terms of encryption to her
      1. After watching the video she is asked to create or import her own keys (see T3)
   3. Import her keys.
   4. Last option would be to start Kleopatra.

Remarks:

• When she stops the configuration before key creation, the corresponding dialouges will be prompted once she initiates an action that requires some input from her (e.g. she wants to sign something)
• There should not be any need to start Kleopatra itsself. All configuration should be done via external dialogues (compare T3)

Some corner cases

• What should happen if not all recipients possess keys / the same kind of keys?
  • Don't send
  • Only send the encrypted mails
  • Send all unencrypted
  • Send different mails encrypted and unencrypted
• How to solve when more than one certificate is being found?