Updated Google Summer of Code 2015 (markdown)
Vincent
parent
f812ce6f48
commit
55ebbd50c1
|
|
@ -58,6 +58,8 @@ Because updating all your keys exposeds your social contacts, privacy problemds
|
|||
|
||||
**Expected results:** Awesome keyserver integration
|
||||
|
||||
**Priority:** Very high
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium
|
||||
|
|
@ -67,24 +69,13 @@ Because updating all your keys exposeds your social contacts, privacy problemds
|
|||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**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)
|
||||
|
||||
## p-25519 / 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 p-25519 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:** Working implementation of p-25519 EC crypto in OpenKeychain
|
||||
|
||||
**Priority:** Very high
|
||||
|
||||
**Knowledge Prerequisite:** Java programming, Elliptic Curve cryptography
|
||||
|
||||
**Skill level:** hard
|
||||
|
|
@ -94,10 +85,28 @@ OpenKeychain supports elliptic curve cryptography, but only the ECDSA and ECDH a
|
|||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or #openkeychain on irc.freenode.net
|
||||
|
||||
|
||||
## 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.
|
||||
## 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:** Test coverage, possible use of more test frameworks
|
||||
**Expected results:** Backup/Restore functionality.
|
||||
|
||||
**Priority:** high
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**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)
|
||||
|
||||
|
||||
## 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
|
||||
|
||||
|
|
@ -108,12 +117,49 @@ OpenKeychain supports elliptic curve cryptography, but only the ECDSA and ECDH a
|
|||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or #openkeychain on irc.freenode.net
|
||||
|
||||
|
||||
## 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.
|
||||
## 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:** Tasker plugin for encryption/signing/decryption/verification
|
||||
**Expected results:** Better UX when deleting keys/Support for revocation certificates
|
||||
|
||||
**Knowledge Prerequisite:** Java programming, understanding of DNS
|
||||
**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.
|
||||
|
||||
**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
|
||||
|
||||
|
||||
## 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.
|
||||
|
||||
**Expected results:** Nice decryption screen
|
||||
|
||||
**Priority:** Medium
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** medium
|
||||
|
||||
|
|
@ -121,7 +167,6 @@ OpenKeychain supports elliptic curve cryptography, but only the ECDSA and ECDH a
|
|||
|
||||
**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.
|
||||
|
||||
|
|
@ -133,6 +178,8 @@ Using DANE to Associate OpenPGP public keys with email addresses"](http://tools.
|
|||
|
||||
**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
|
||||
|
|
@ -141,61 +188,6 @@ Using DANE to Associate OpenPGP public keys with email addresses"](http://tools.
|
|||
|
||||
**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"
|
||||
|
||||
**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)
|
||||
|
||||
## 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
|
||||
|
||||
**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
|
||||
|
||||
**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)
|
||||
|
||||
## 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.
|
||||
|
||||
**Expected results:** Nice decryption screen
|
||||
|
||||
**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)
|
||||
|
||||
## 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.
|
||||
|
|
@ -209,6 +201,8 @@ A minor ToDo related to this idea is the usage of the [Gradle Witness Plugin](ht
|
|||
|
||||
**Expected results:** Gradle plugin for deterministic builds
|
||||
|
||||
**Priority:** Low
|
||||
|
||||
**Knowledge Prerequisite:** Java programming
|
||||
|
||||
**Skill level:** easy
|
||||
|
|
@ -216,3 +210,34 @@ A minor ToDo related to this idea is the usage of the [Gradle Witness Plugin](ht
|
|||
**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
|
||||
|
||||
**Contact:** [Mailinglist](http://groups.google.com/d/forum/openpgp-keychain-dev) or over XMPP (Jabber-ID: dominik@dominikschuermann.de)
|
||||
|
|
|
|||
Loading…
Reference in New Issue