Updated Google Summer of Code 2016 (markdown)
Vincent
parent
aacec28fec
commit
fd1a945b09
|
|
@ -1,7 +1,7 @@
|
|||
This is a page showing all proposed ideas for our application for the [Google Summer of Code 2016](https://summerofcode.withgoogle.com/).
|
||||
|
||||
# About OpenKeychain
|
||||
[OpenKeychain](http://www.openkeychain.org/) is an OpenPGP implementation for Android.
|
||||
[OpenKeychain](https://www.openkeychain.org/) 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.
|
||||
|
||||
|
|
@ -12,6 +12,7 @@ OpenKeychain can be installed from [Google Play](https://play.google.com/store/a
|
|||
# Prerequisites
|
||||
* Be a student enrolled at a university
|
||||
* Solid understanding of Java
|
||||
* Knowledge of OpenPGP ([RFC 4880](https://tools.ietf.org/html/rfc4880)) is recommended
|
||||
|
||||
# Contribution Guidelines
|
||||
1. Join the development mailinglist at http://groups.google.com/d/forum/openpgp-keychain-dev
|
||||
|
|
@ -27,7 +28,7 @@ We require one accepted patch (pull request) from each potential GSoC student, b
|
|||
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
|
||||
To make it easier for you to get started, we picked some (hopefully) easy issues for this purpose: https://github.com/openpgp-keychain/openpgp-keychain/issues?labels=simple-one-patch&page=1&state=open
|
||||
|
||||
# Google Summer of Code Registration Procedure
|
||||
1. Have one patch accepted in OpenKeychain (see "one patch" rule)
|
||||
|
|
@ -36,225 +37,139 @@ I sorted out some probably easy issues and tagged them: https://github.com/openp
|
|||
4. [Apply officially on the Google Summer of Code page](https://summerofcode.withgoogle.com/org-signup/) (**Registration opens on March 14th 2016**)
|
||||
|
||||
# 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.
|
||||
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:
|
||||
|
||||
To help you meet your goals and so that your mentor can better evaluate your progress you need to:
|
||||
|
||||
* We have a weekly developer meeting on IRC, where all students talk about their last week's progress, challenges and milestones.
|
||||
* Track your progress and milestones on our [issue tracker](https://github.com/open-keychain/open-keychain/issues).
|
||||
* 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.
|
||||
* 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](https://github.com/open-keychain/open-keychain/issues).
|
||||
* You are encouraged to write blog posts for [our website](http://www.openkeychain.org).
|
||||
|
||||
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](https://github.com/open-keychain/open-keychain/issues/1025) using appropriate libraries. We can adopt design choices of https://gaffer.ptitcanardnoir.org/intrigeri/code/parcimonie/
|
||||
## Move to App Lock Mechanism
|
||||
**Brief explanation:**
|
||||
|
||||
**Expected results:** Awesome keyserver integration
|
||||
**Expected results:**
|
||||
|
||||
**Priority:** Very high
|
||||
**Priority:**
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium
|
||||
|
||||
**Mentor:** Dominik Schürmann
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
|
||||
## Detached Signatures
|
||||
**Brief explanation:**
|
||||
|
||||
## Ed25519 / EdDSA support
|
||||
OpenKeychain supports elliptic curve cryptography, but only the ECDSA and ECDH algorithms as specified in [RFC 6637](https://tools.ietf.org/html/rfc6637), which only support the NIST curves. To support the Ed25519 curve requires support for EdDSA as specified in [this Internet Draft](http://www.ietf.org/id/draft-koch-eddsa-for-openpgp-01.txt) by Werner Koch. This is also a requirement for compatibilty with OpenPGP keys generated by [Google End to End](https://github.com/google/end-to-end). This task includes implementing EdDSA in the [BouncyCastle](https://www.bouncycastle.org/) library, which OpenKeychain uses for its low-level crypto operations, and adding support for it in OpenKeychain's UI itself.
|
||||
**Expected results:**
|
||||
|
||||
**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](http://groups.google.com/d/forum/openpgp-keychain-dev) 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
|
||||
**Priority:**
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium
|
||||
|
||||
**Mentor:** Vincent Breitmoser
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) 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
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) 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
|
||||
## Improved Key Discovery
|
||||
**Brief explanation:** (mail address -> key, e.g. via dns)
|
||||
|
||||
**Expected results:** Test coverage, possible use of more test frameworks
|
||||
**Expected results:**
|
||||
|
||||
**Priority:** High
|
||||
**Priority:**
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium
|
||||
|
||||
**Mentor:** Vincent Breitmoser
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) 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](https://blog.whiteout.io/2014/07/07/secure-pgp-key-sync-a-proposal/) and scenarios proposed on the [ModernCrypto Messaging mailinglist](https://moderncrypto.org/mail-archive/messaging). Also solutions integrated into TextSecure and Threema should be looked at. We could imagine a backup via IMAP (see [SMS Backup Plus](https://github.com/jberkel/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
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) 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](http://developer.android.com/training/sharing/receive.html#handling-content) 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](https://github.com/open-keychain/open-keychain/issues/626): 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
|
||||
## Manage sync status of user's keys
|
||||
**Brief explanation:**
|
||||
|
||||
**Expected results:** Nice decryption screen
|
||||
**Expected results:**
|
||||
|
||||
**Priority:** Medium
|
||||
**Priority:**
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium
|
||||
|
||||
**Mentor:** Dominik Schürmann
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) 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,](http://wiki.xmpp.org/web/Summer_of_Code_2015#Add_support_for_DNSSEC_to_Smack_via_MiniDNS) we would like to extend the [MiniDNS library](https://github.com/rtreffer/minidns) 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](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"](http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-01) and ["Internet Draft: Best Common Practise for using OPENPGPKEY records"](http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-01). 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
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) 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](https://guardianproject.info/2015/02/11/complete-reproducible-app-distribution-achieved/). 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.
|
||||
## TOFU Trust Model
|
||||
**Brief explanation:**
|
||||
|
||||
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
|
||||
**Expected results:**
|
||||
|
||||
A minor ToDo related to this idea is the usage of the [Gradle Witness Plugin](https://github.com/WhisperSystems/gradle-witness) for pinning plugins from Maven.
|
||||
|
||||
**Expected results:** Gradle plugin for deterministic builds
|
||||
|
||||
**Priority:** Low
|
||||
**Priority:**
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** easy
|
||||
|
||||
**Mentor:** Dominik Schürmann
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) 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](http://commonsware.com/blog/2014/08/25/defending-against-activityjack-attacks.html) 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](http://groups.google.com/d/forum/openpgp-keychain-dev) 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](http://tasker.dinglisch.net/plugins.html) should be developed that uses our [OpenPGP API](https://github.com/open-keychain/open-keychain/wiki/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
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
|
||||
|
||||
## UI test suite
|
||||
**Brief explanation:**
|
||||
|
||||
just some notes for tasks for now:
|
||||
**Expected results:**
|
||||
|
||||
- App lock instead of passphrases
|
||||
- Improved key search UI
|
||||
- Manage sync status of user's keys
|
||||
- Key discovery (mail address -> key, e.g. via dns)
|
||||
- TOFU trust model?
|
||||
- Detached Signatures?
|
||||
- UI test suite (would really love this)
|
||||
- EDDSA?
|
||||
**Priority:**
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium
|
||||
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
|
||||
|
||||
## Improved Key Search UI
|
||||
**Brief explanation:**
|
||||
|
||||
**Expected results:**
|
||||
|
||||
**Priority:**
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium
|
||||
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
|
||||
|
||||
## Improved Yubikey Import
|
||||
**Brief explanation:**
|
||||
|
||||
**Expected results:**
|
||||
|
||||
**Priority:**
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium
|
||||
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
Loading…
Reference in New Issue