Mirrors
/
open-keychain
mirror of https://github.com/open-keychain/open-keychain.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Google Summer of Code 2015 (markdown)

Vincent 2016-02-18 14:24:23 +00:00
parent 4e317f1ba9
commit 9b63ef1724
1 changed files with 186 additions and 162 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

348
Google-Summer-of-Code-2015.md

@ -1,17 +1,18 @@
This is a page showing all proposed ideas for our application for the [Google Summer of Code 2015](http://www.google-melange.com/gsoc/homepage/google/gsoc2015).
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.
<img src="http://www.openkeychain.org/public/images/screen1.png" alt="Screenshot" height="512" "width="306" align="right" />
[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.
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.
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](https://openkeychain.org/k-9) to bring secure email based on the OpenPGP standard to Android.
OpenKeychain can be installed from [Google Play](https://play.google.com/store/apps/details?id=org.sufficientlysecure.keychain) and [F-Droid](https://f-droid.org/app/org.sufficientlysecure.keychain).
# 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,220 +28,243 @@ 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)
2. 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
3. Tell us about your plans on the mailinglist
4. [Apply officially on the Google Summer of Code page](https://www.google-melange.com/gsoc/homepage/google/gsoc2015) (**Registration opens on March 16, 2015, 7 p.m. UTC.**)
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:
* 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/
This is a list of larger tasks which we have on our roadmap, and which we feel are well suited for GSoC projects.
**Expected results:** Awesome keyserver integration
**Priority:** Very high
## 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:** Vincent Breitmoser / Adithya Philip
**Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## 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:** 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)
**Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## 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.
## 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:** 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
**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
**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
**Expected results:** Test coverage, possible use of more test frameworks
**Priority:** High
**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.
**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:** hard
**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)
**Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## 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
## 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](https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030150.html)
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.
**Expected results:** Nice decryption screen
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](https://github.com/open-keychain/openpgp-api)
we expose for client apps.
**Priority:** Medium
**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](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## 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](https://github.com/open-keychain/open-keychain/issues/1587) 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](https://github.com/fidesmo/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:** Dominik Schürmann
**Mentor:** Vincent Breitmoser
**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
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
**Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## 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.
**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/).
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
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.
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:** Gradle plugin for deterministic builds
**Expected results:** Analysis of non-deterministic parts in the build process,
gradle plugin for deterministic builds
**Priority:** Low
**Priority:** 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)
## 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
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
**Contact:** [Mailinglist](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))
## 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](https://lists.riseup.net/www/subscribe/openkeychain)
or on IRC (Valodim in [#openkeychain at
irc.freenode.net](https://kiwiirc.com/client/irc.freenode.net/openkeychain))