Table of Contents

This is a page showing all proposed ideas for our application for the Google Summer of Code 2016.

About OpenKeychain

OpenKeychain is an OpenPGP implementation for Android. Screenshot Similar to what the well-known GnuPG software does on desktop systems, OpenKeychain primarily serves as a key management tool, but with a stronger focus on usability. Modern mobile devices allow new features like key exchange via QR or NFC, and support for secret keys stored on NFC security tokens, such as YubiKey NEO.

On its own, OpenKeychain supports encryption, decryption, signature generation, and signature verification of files and text. In addition to stand-alone use, it comes with an API which makes crypto operations available for other apps. At the moment, we are also actively working on K-9 Mail to bring secure email based on the OpenPGP standard to Android.

OpenKeychain can be installed from Google Play and F-Droid.

Formal Prerequisites

Be a student enrolled at a university
Solid understanding of Java
Knowledge of OpenPGP (RFC 4880) is recommended

Keep in mind that mentoring is about providing guidance to help you solve your task, but we don't want to keep holding your hand all the way. It's important for us to know that you can code and solve technical challenges on your own, while also maintaining a constructive dialogue of relevant design decisions with us.

Contribution Guidelines

Join the development mailinglist at https://lists.riseup.net/www/subscribe/openkeychain
Read the README, especially the notes about coding styles
Fork OpenKeychain and contribute code (the best part ;) )
If you have questions ask on the mailinglist, or in #openkeychain on irc.freenode.net!
Open a pull request on Github. We will help with occurring problems and merge your changes back into the main project.

"One patch" rule

We require one accepted patch (pull request) from each potential GSoC student, before accepting the student for GSoC participation.
The reason for this requirement is that you can show us that you have succeeded in building OpenKeychain, and that you have understood a little piece of OpenKeychain's code and are able to improve it. This requirement is based on the "two patches" rule applied by projects such as Inkscape and Subsurface.

To make it easier for you to get started, we picked some (hopefully) easy issues for this purpose: https://github.com/open-keychain/open-keychain/labels/help-wanted

Google Summer of Code Registration Procedure

Have one patch accepted in OpenKeychain (see "one patch" rule)
Lookout for interesting tasks on the Ideas page in our wiki, then choose one you would like to work on. If you have an interesting task of your own in mind, you can also propose your own ideas - if you do, make sure to leave enough time to discuss it with us!
Apply officially on the Google Summer of Code page (Registration opens on March 14th 2016). In your proposal, outline your understanding of the task you picked. This should include a description of the task from your perspective, challenges and design decisions you expect to encounter along the way, and a rough timeline for your implementation ideally based around four milestones (i.e., one every three weeks). Make sure to allocate some time for writing tests and code review!

Evaluation

GSoC has two formal evaluation points, at the mid-term and at the end. These evaluations determine if you receive the stipend from Google. In order to receive a pass for the evaluations you will need to show adequate progress toward your project's goals. We have a number of mechanisms to help you meet your goals and get in touch with us and other developers:

We have a weekly developer meeting on IRC, where all students talk about their last week's progress, challenges and milestones. We will also inform you about our own progress and current plans during this meeting.
You need to have a public OpenKeychain branch for your code to which you commit regularly. To this end, you will be granted write access to our repository after we accept your first larger pull request.
Students are encouraged to track their progress and milestones on our issue tracker.
You are encouraged to write blog posts for our website.

Remember: we want you to succeed and we'd like you to stick around.

Ideas

This is a list of larger tasks which we have on our roadmap, and which we feel are well suited for GSoC projects. This is not an exhaustive list, if you have a great feature in mind feel free to suggest your own! We are always up for discussion.

Improved Key Search UI

Brief explanation: The current dialog for search and import of keys is, compared to most of our other activities, quite outdated. Besides weaknesses in UI design, it is lacking a number of features. However, these use cases are quite different from what the relevant code was originally designed for, so it should be rewritten in a more flexible way, to work with these new requirements. The new UI should incorporate display of information from already known keys in addition to the data obtained from keyservers, and add an option to download and view keys prior to actual import.

A secondary goal to this task is support for new key discovery options, notably by lookup of OPENPGP records via DANE.

Expected results: Rewritten key search user interface and backend, key discovery via DANE.

Priority: high

Knowledge Prerequisite: Java programming

Skill level: medium-high

Mentor: Adithya Abraham Philip

Contact: Mailinglist or over XMPP (Jabber-ID: aaphilip@jappix.com)

Move from Passwords to App Lock Mechanism

Brief explanation: At the moment, keys are encrypted individually with their passphrases, prompting the user for the password before each use (with possible caching). This is mostly a historical design decision since it's what GnuPG does. At this point however, we believe that most users are better served with a simple and easily understandable "app lock" mechanism.

Technically, this task involves moving the mechanism which deals with encryption of keys from the crypto operation classes into the DataAccessObject which is used to access the database. This makes it necessary to re-encrypt secret keys during import, which is not quite trivial to implement because it requires user interaction during import.

Expected results: Individual passphrase mechanism is replaced by an "App Lock" one, keys are re-encrypted during import

Priority: high

Knowledge Prerequisite: Java programming

Skill level: medium

Mentor: Vincent Breitmoser

Contact: Mailinglist or on IRC (Valodim in #openkeychain at irc.freenode.net)

Keyserver Sync Preference per Key

Brief explanation: While communication with keyservers and upload of keys is a feature of OpenKeychain which technically works, this area is quite lacking in usability. Many users have also expressed a desire to keep their keys off keyservers. A good way to deal with both of these problems is to mark the user's keys on creation whether they should be distributed via keyservers or not, and equivalently making other keys aware of whether they are already available on keyservers or have been obtained by different means. This information should then be used as a basis to decide how to deal with publication of certificates, and solve cases where a key has new certifictes locally but is not updated on keyservers.

Expected results: A per-key preference on whether the key should be kept in sync with keyservers, and relevant behavior based on that preference.

Priority: medium

Knowledge Prerequisite: Java programming

Skill level: medium

Mentor: Adithya Abraham Philip

Contact: Mailinglist or over XMPP (Jabber-ID: aaphilip@jappix.com)

TOFU Trust Model

Brief explanation: In addition to the current model of direct verifications, we would like to add support for a "Trust on First Use" trust model. This is also in the works in GnuPG, who also have a good description of the concept on their mailing list. The general idea is to optimistically assume that a key which is initially used to establish communication with any one communication partner is likely correct, and that if was no man in the middle attack happened there, all further communication with the same key will be safe as well.

To this end, a list of keys trusted in this way should be maintained, instances of its use should be counted (how many e-mails did I encrypt to this key? how many signatures did I receive from it?), and an alarm raised if the same communication partner switches to a different key. This mechanism should conceptually take interoperability with our current trust model into account and provide an opt-out option for the user, and also take into consideration how this affects the public API we expose for client apps.

Expected results: Support for a trust model based on the TOFU assumption

Priority: medium

Knowledge Prerequisite: Java programming

Skill level: medium-high

Mentor: Vincent Breitmoser / Adithya Philip

Contact: Mailinglist or on IRC (Valodim in #openkeychain at irc.freenode.net)

Security Token Improvements

Brief explanation: OpenKeychain comes with support for security tokens (YubiKey, Fidesmo Card, …), but there are some features missing in this area for fully featured support.

The most important part of this task is creation of a nicer user interface for importing the user's keys from a supplied token, improving the ui flow and adding support for downloading the public key from a URL specified in the token (see here for a mockup). A smaller missing feature is editing the token's PIN.

A secondary goal of this task would be support for security tokens via OTG USB, requiring some abstraction of the communication mechanism we use for NFC at the moment from the Nordpol library.

A student who takes up this task should make sure to acquire testing equipment (ideally a Yubikey NEO) during the community bonding period (we might be able to help get that hardware sponsored).

Expected results: Redesigned Security Token import, PIN editing, USB-OTG support

Priority: medium

Knowledge Prerequisite: Java programming

Skill level: medium

Mentor: Vincent Breitmoser

Contact: Mailinglist or on IRC (Valodim in #openkeychain at irc.freenode.net)

Deterministic Builds

Brief explanation: Having deterministic, reproducible builds allows for verifying F-Droid builds and thus using the same APK binaries on Google Play as well as on F-Droid. This allows for easier upgrades and distributed verifications that the published source code corresponds to the published APK binary. Guardian Project has made great progress towards a fully functional solution. In this task a Gradle plugin should be developed that allows us and other projects to build deterministic builds without further dependencies on OS programs or libs. Please read the related links for more information on how this could be achieved.

Detached Signatures

Brief explanation: In our current UI, we do not support verification of files which are signed with a detached signature. The reason for this is that it does not easily fit into our current user interface patterns, in addition to a slightly more limited prevalence of this use case on Android compared to other systems. For the sake of feature completeness however, this would be nice to have, and might work nicely as a "warm-up" task.

This is a smaller task which we expect to take only one or two weeks, which makes it suitable as a secondary goal and providing a change of pace for some time while working on another task.

Expected results: Support for detached signatures in the Encrypt/Decrypt dialog.

Priority: low

Knowledge Prerequisite: Java programming

Skill level: low

Mentor: Vincent Breitmoser

Contact: Mailinglist or on IRC (Valodim in #openkeychain at irc.freenode.net)

Revocation Certificates

Brief explanation: Revocation certificates are used to revoke a key if the secret key is no longer accessible (either the actual key has been lost or its password forgotten), and is usually the last recourse in such cases. This task would involve allowing OpenKeychain to both generate and use revocation certificates. This is more of a UX design and UI implementation problem than a technical challenge, since the operations in question are already supported in the backend. As such, it is well suited for getting to know the Android framework and first steps in user interface design.

The two components:

Creation: Allowing users to create a revocation certificate for a given key from within OpenKeychain (this would involve saving the revoked public key).
Application: Revocation certificates come in two forms - as a revoked public key, and much less frequently, as a detached revocation signature. In the case of the latter the certificate must first be applied to the correct public key before proceeding. In either case, the revoked key must then be uploaded to a keyserver to complete the revocation process.

This is a smaller task which we expect to take only a couple of weeks, which makes it suitable as a secondary goal and providing a change of pace for some time while working on another task.

Expected results: Support for both generating revocation certificates in OpenKeychain and importing, applying and uploading existing revocation certificates.

Priority: low

Knowledge Prerequisite: Java programming

Skill level: low

Mentor: Adithya Abraham Philip

Contact: Mailinglist or over XMPP (Jabber-ID: aaphilip@jappix.com)