This is a page showing all proposed ideas for our application for the Google Summer of Code 2015.
About OpenKeychain
OpenKeychain is an OpenPGP implementation for Android. <img src="http://www.openkeychain.org/public/images/screen1.png" alt="Screenshot" height="512" "width="306" align="right" /> 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 Yubikey devices.
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. We are actively working together with K-9 Mail to bring secure email based on the OpenPGP standard to Android.
OpenKeychain can be installed from Google Play and F-Droid.
Prerequisites
- Be a student enrolled at a university
- Solid understanding of Java
Contribution Guidelines
- Join the development mailinglist at http://groups.google.com/d/forum/openpgp-keychain-dev
- Read the README, especially the notes about coding style
- 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.
We are happy about every code contribution and appreciate your effort to help us developing OpenKeychain!
"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.
I sorted out some probably easy issues and tagged them: https://github.com/openpgp-keychain/openpgp-keychain/issues?labels=simple-one-patch&page=1&state=open
Google Summer of Code Registration Procedure
- Have one patch accepted in OpenKeychain (see "one patch" rule)
- Lookout for interesting ideas on this page and choose multiple according to the time you expect to work on them. You can also propose your own ideas
- Tell us about your plans on the mailinglist
- Apply officially on the Google Summer of Code page (Registration opens on March 16, 2015, 7 p.m. UTC.)
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.
To help you meet your goals and so that your mentor can better evaluate your progress you need to:
- Track your progress and milestones on our issue tracker.
- Participate in discussions on our mailinglist
- 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.
- 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
Improve keyserver support
Brief explanation: OpenKeychain contains basic support for HKP keyservers and keybase.io. Keys can be found by searching for names, emails, etc. easily in-app. Also existing keys can be updated using the key view. Still, keyserver support could be improved vastly. An "update all keys" option should be integrated. However, we recently decided against the "swipte to refresh" pattern and consider "update all manually" an advanced feature. Implementing a SyncAdapter is much more important (see below). More backend work is required to make the keyserver implementation threaded, allowing faster updates of long key lists. It needs to be considered how errors or single unavailable keys are handled properly. A snackbar could be used to display update results. The UI inside the key view needs to be considered seperatly. Swipe to refresh should only be used for lists and is not the right pattern here. The UI inside the preferences also needs an overhaul using a RecyclerView. A connected task is the periodic sync of keys which should be available as an opt-in preference. In the backend this can be implemented using Android's SyncAdapters (see available SyncAdapter in OpenKeychain that connects keys to Android's contacts). While working on keyservers, the DNS key discovery should be verified (unit test?). Because updating all your keys exposeds your social contacts, privacy problemds needs to be investigated. A possible option is to include proxy support and Tor support using appropriate libraries. We can adopt design choices of https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/
Expected results: Awesome keyserver integration
Priority: Very high
Knowledge Prerequisite: Java programming
Skill level: medium
Mentor: Dominik Schürmann
Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
Ed25519 / EdDSA support
OpenKeychain supports elliptic curve cryptography, but only the ECDSA and ECDH algorithms as specified in RFC 6637, which only support the NIST curves. To support the Ed25519 curve requires support for EdDSA as specified in this Internet Draft by Werner Koch. This is also a requirement for compatibilty with OpenPGP keys generated by Google End to End. This task includes implementing EdDSA in the BouncyCastle library, which OpenKeychain uses for its low-level crypto operations, and adding support for it in OpenKeychain's UI itself.
Expected results: Working implementation of Ed25519 EC crypto in OpenKeychain
Priority: Very high
Knowledge Prerequisite: Java programming, Elliptic Curve cryptography
Skill level: hard
Mentor: Vincent Breitmoser
Contact: Mailinglist or #openkeychain on irc.freenode.net
Passphrase alternatives
Brief explanation: The private key material in secret keys is usually encrypted with a string-to-key algorithm, that is, a passphrase. This passphrase has to be entered before each crypto operation can be performed. Even though caching is possible, typing passphrases on a smartphone can be quite the nuisance especially for common operations like sending a signed email or reading an encrypted one. Mobile devices have touch screens, nfc readers, and several other methods of input not available on desktop computers, which allow for alternative methods of passphrase input like lock patterns or NFC tags. Those concepts have advantages in convenience over passphrases, but also implications on security and require some careful thought to provide good UX with minimal loss of security.
Expected results: Planning and implementation of alternative methods for passphrase input
Priority: High
Knowledge Prerequisite: Java programming
Skill level: medium
Mentor: Vincent Breitmoser
Contact: Mailinglist or #openkeychain on irc.freenode.net
Key Deletion UX/Revocation
Brief explanation: When deleting a key the user should be asked to revoke the key if it is a secret one instead of just deleting it. Deleting a secret key should be considered an expert option the average user should not do. Furthermore, generation of revocation certificates should be supported both as part of the key generation process and for manually revoking a key at a later point in time.
Expected results: Better UX when deleting keys/Support for revocation certificates
Priority: High
Knowledge Prerequisite: Java programming
Skill level: easy
Mentor: Dominik Schürmann
Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
Improve unit tests
Brief explanation: Unit tests are important, especially for a security-related application like OpenKeychain. We have a reasonable amount of unit tests which covers critical parts of our crypto code for a total of 25% coverage. Testing on Android has come a long way since last year though, so this task is about exploring those new possibilities and seriously improving that coverage, including UI and API test cases. Related: https://github.com/open-keychain/open-keychain/issues/689
Expected results: Test coverage, possible use of more test frameworks
Priority: High
Knowledge Prerequisite: Java programming
Skill level: medium
Mentor: Vincent Breitmoser
Contact: Mailinglist or #openkeychain on irc.freenode.net
Backup/Restore
Brief explanation: While OpenKeychain contains an "export all keys" functionality, there is no easy way to backup/restore all keys, especially the secret keys. Implementing such backup functionality requires a careful evaluation of existing approaches, such as Whiteout.io's key sync and scenarios proposed on the ModernCrypto Messaging mailinglist. Also solutions integrated into TextSecure and Threema should be looked at. We could imagine a backup via IMAP (see SMS Backup Plus) with periodic reminders. But that is only one option. Google's cloud or proprietary solutions should be avoided. A related issue is the transfer of an initial GnuPG key to OpenKeychain. Could this also be done using IMAP or other exchange protocols protected by a Password Authenticated Key Exchange (PAKE, see Firefox Sync)?
Expected results: Backup/Restore functionality.
Priority: medium
Knowledge Prerequisite: Java programming
Skill level: hard
Mentor: Dominik Schürmann
Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
File Decryption Screen
Brief explanation: Currently the file decryption screen in OpenKeychain only allows to decrypt one file at a time and only allows saving of decrypted files into the filesystem. While this is okay for simple scenarios. The decryption process could result in many files being decrypted. Either when multiple files are shared together using Android's ACTION_SEND_MULTIPLE or when the OpenPGP data structure contains many parts. Thus, the screen should be extended for multiple files. A list of files should be displayed like done in the encryption screen that with the options save/open per file item. To get the right content type and decrypt the filename the new internal DECRYPT_METADATA functionality of OpenKeychain should be used. The real payload should be decrypted when save/open is clicked. Furthermore the recipient's key user id should be displayed inside the item. A related problem are hidden recipients: The OpenPGP standard allows to prevent the disclosure for whom a file/message is encrypted for. This feature should be implemented in the encrypt screens as well as displayed per file item in the new decryption screen. The "delete after decryption" functionality needs to be re-designed for this task. Also "detached signatures" should be supported by the new decryption screens. An internal method has already been done during the work on PGP/MIME. This can be used, but needs a carefully designed UI. Also related: https://github.com/open-keychain/open-keychain/issues/950
Expected results: Nice decryption screen
Priority: Medium
Knowledge Prerequisite: Java programming
Skill level: medium
Mentor: Dominik Schürmann
Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
Keys in DNSSEC/DANE
Brief explanation: Together with the XMPP Standards Foundation (XSF), see their GSoC idea, we would like to extend the MiniDNS library with DNSSEC support to allow the retrieval of OpenPGP keys from DNS entries.
MiniDNS is a DNS client library, which allows Android Apps and Java programs to resolve DNS resource records (RR). On Android, some resource records could not be resolved using only the Android API, for example DNS SRV RRs. Which was one of the main reasons MiniDNS was invented. Adding support for DNSSEC would be the logical next step to improve the security of the software using MiniDNS. See also https://github.com/rtreffer/minidns/issues/7.
How OpenPGP keys should be published in DNS records is explained in "Internet Draft:
Using DANE to Associate OpenPGP public keys with email addresses" and "Internet Draft: Best Common Practise for using OPENPGPKEY records". OpenKeychain should be extended to allow importing keys from these records.
Expected results: DNSSEC implementation for MiniDNS and simple import of keys from DANE.
Priority: Low
Knowledge Prerequisite: Java programming, understanding of DNS
Skill level: hard
Mentor: Dominik Schürmann
Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
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. While we could also use faketime to produce identical binary APKs, it would be much nicer to develop a Gradle Plugin that achieves the same. 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 eventually 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
A minor ToDo related to this idea is the usage of the Gradle Witness Plugin for pinning plugins from Maven.
Expected results: Gradle plugin for deterministic builds
Priority: Low
Knowledge Prerequisite: Java programming
Skill level: easy
Mentor: Dominik Schürmann
Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
Protection against "Activityjack Attack"
Brief explanation: Lets think of an attacker that prepares an app without special permissions that has one activity that looks exactly like OpenKeychain's passphrase dialog. The attacker can prepare the activity to a point it can not be differentiated from OpenKeychain's. This is especially easy because OpenKeychain is open source (copy paste the passphrase dialog, remove actual functionality and you are done). This concept can be used to easily fool the user into entering his passphrase, which is a big security problem. One proposed solution from CommonsWare's Blog is that the user chooses a picture that is displayed every time the passphrase dialog pops up. This picture can not be known by the attacker (we are not talking about apps with root access!). The core idea here is that the user must be able to reliably distinguish genuine OpenKeychain dialogues from malicious activities.
Expected results: Protection against "Activityjack Attack"
Priority: Very low
Knowledge Prerequisite: Java programming
Skill level: easy
Mentor: Dominik Schürmann
Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
Tasker Plugin
Brief explanation: Tasker is an app for automating tasks on Android, e.g., 'automatically send a message to someone when I am at home'. Having OpenPGP support in Tasker would allow for much better transport security for tasks related to end-to-end communication. Thus, a Tasker plugin should be developed that uses our OpenPGP API to allow automatic encryption/signing/decryption/verification. A good integration into Tasker and an easy UI is required.
Expected results: Tasker plugin for encryption/signing/decryption/verification
Priority: Very low
Knowledge Prerequisite: Java programming, understanding of DNS
Skill level: medium
Mentor: Dominik Schürmann
Contact: Mailinglist or over XMPP (Jabber-ID: dominik@dominikschuermann.de)