Updated Google Summer of Code 2016 (markdown)
Vincent
parent
56ca612d94
commit
4e317f1ba9
|
|
@ -2,7 +2,7 @@ This is a page showing all proposed ideas for our application for the [Google Su
|
|||
|
||||
# About OpenKeychain
|
||||
[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" />
|
||||
<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. 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.
|
||||
|
|
@ -50,12 +50,45 @@ Remember: we want you to succeed and we'd like you to stick around.
|
|||
|
||||
This is a list of larger tasks which we have on our roadmap, and which we feel are well suited for GSoC projects.
|
||||
|
||||
## Move to App Lock Mechanism
|
||||
**Brief explanation:**
|
||||
|
||||
**Expected results:**
|
||||
## 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, most notably display of
|
||||
information from the local database in addition to the data obtained from
|
||||
keyservers, and download and viewing of keys prior to actual import. However,
|
||||
these use cases are quite different from what the relevant code was originally
|
||||
designed for, which is why implementation of those new features will involve
|
||||
some rewrites.
|
||||
|
||||
**Priority:**
|
||||
**Expected results:** Rewritten key search user interface and backend
|
||||
|
||||
**Priority:** high
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium-high
|
||||
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
|
||||
|
||||
## Move from Passwords to App Lock Mechanism
|
||||
**Brief explanation:** At the moment, keys are individually encrypted 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 encryption of keys from the
|
||||
operations which work on them into the DataAccessObject. It also makes
|
||||
re-encryption of secret keys during import necessary, making that an
|
||||
interactive process.
|
||||
|
||||
**Expected results:** Individual passphrase mechanism is replaced by an "App Lock" one
|
||||
|
||||
**Priority:** high
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
|
|
@ -66,28 +99,22 @@ This is a list of larger tasks which we have on our roadmap, and which we feel a
|
|||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
|
||||
|
||||
## Improved Key Discovery
|
||||
**Brief explanation:** (mail address -> key, e.g. via dns)
|
||||
## 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:**
|
||||
**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:**
|
||||
|
||||
**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)
|
||||
|
||||
|
||||
## Manage sync status of user's keys
|
||||
**Brief explanation:**
|
||||
|
||||
**Expected results:**
|
||||
|
||||
**Priority:**
|
||||
**Priority:** medium
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
|
|
@ -99,31 +126,26 @@ This is a list of larger tasks which we have on our roadmap, and which we feel a
|
|||
|
||||
|
||||
## TOFU Trust Model
|
||||
**Brief explanation:**
|
||||
**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. 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.
|
||||
|
||||
**Expected results:**
|
||||
**Expected results:** Support for a trust model based on the TOFU assumption
|
||||
|
||||
**Priority:**
|
||||
**Priority:** medium
|
||||
|
||||
**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
|
||||
**Skill level:** medium-high
|
||||
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
|
|
@ -134,21 +156,6 @@ This is a list of larger tasks which we have on our roadmap, and which we feel a
|
|||
|
||||
This is a list of smaller tasks, which we expect to take one or two weeks at most. We encourage students to pick one of these along with their main task in their proposal, because after several weeks of working on one task it can be refreshing to just do something different for a while.
|
||||
|
||||
## 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)
|
||||
|
||||
|
||||
## Detached Signatures
|
||||
**Brief explanation:**
|
||||
|
|
@ -195,4 +202,36 @@ This is a list of smaller tasks, which we expect to take one or two weeks at mos
|
|||
|
||||
**Mentor:** Vincent Breitmoser / Adithya Philip
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
|
||||
|
||||
## Support Yubikey PIN Change
|
||||
**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