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.
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
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.
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.
Related links:
- http://imperceptiblethoughts.com/2013/12/20/reproducible-multi-project-gradle-builds-part-2.html
- https://wiki.debian.org/ReproducibleBuilds/TimestampsInJarFiles
- http://code.briarproject.org/akwizgran/sortjar
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: Analysis of non-deterministic parts in the build process, gradle plugin for deterministic builds
Priority: low
Knowledge Prerequisite: Java programming
Skill level: medium
Mentor: Vincent Breitmoser
Contact: Mailinglist or on IRC (Valodim in #openkeychain at irc.freenode.net)
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)