open-keychain

Table of Contents

OpenPGP Security Choices
Keyserver Security
Version Header in ASCII Armor
Key creation defaults
No expiry for keys created by OpenKeychain

Arguments in favor of expiry

No support for Image Attribute Subpackets
Key IDs aren't displayed

In OpenKeychain

No comment field on key creation
Password meters

Key Confirmations
Trust
Certification screen
Reasons
Relevant links
RFCs
Relevant Drafts
Drafts
Whiteout
Other

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

OpenPGP Security Choices

We never generate v3 signatures, always v4
We do not import v3 keys (https://github.com/coruus/cooperpair/tree/master/keysteak)
If a v4 key is imported with a long key id that already exists in the database, the import is canceled. (see https://github.com/coruus/cooperpair/tree/master/pgpv4 for test keys)
Whitelist of ciphers, whitelist of hash algorithms, minimum key requirements, and cipher/hash/key defaults can be found in PgpSecurityConstants.
We explicitly don't honor the preferred algorithms indicated by imported public keys to prevent downgrade attacks (see coruus comments).

Keyserver Security

All pre-configured keyservers use HKPS
The default keyserver is hkps://hkps.pool.sks-keyservers.net
List of trusted keyservers is: hkps://hkps.pool.sks-keyservers.net, hkps://pgp.mit.edu
"Trusted keyserver" means that we ship with a pinned certificate
When updating a key from a keyserver, the fingerprint of the downloaded key is checked to match the fingerprint of the existing key

Version Header in ASCII Armor

We don't include a version header in ASCII Armored OpenPGP packets as defined in RFC4880. This is a privacy feature and prevents incidents like

Key creation defaults

Autocrypt defaults:
2 RSA 3072 bit keys:
- master key: certify flag + sign flag
- subkey 2: encrypt flag
No expiry (see below)

No expiry for keys created by OpenKeychain

We don't see any advantages in setting an expiry date for OpenPGP keys.

If set, the user is required to extend the key before it reaches the expiry date (-> more interaction needed, less usable).
It does not prevent attack scenarios: If someone steals your secret key, he can extend the expiry date.
Some argue that expiry dates help keeping the keyservers clean from valid but unused keys: If a secret key is lost with an expiry date of 2 years in the future, the public key is still valid for 1 year in average and might be used by others to encrypt stuff. Furthermore, anyone can upload keys with User IDs containing the email and names of other persons, thus it is easy to flood keyservers with valid keys without the consent of the entity who controls the email address. Thus, expiry dates are no valid fix for a much bigger problem that lies in the way OpenPGP keyservers operate currently.
In general, OpenPGP keys need to be validated through other channels than keyservers to rely on them.

Arguments in favor of expiry

from http://blog.josefsson.org/2014/08/26/the-case-for-short-openpgp-key-validity-periods/ (detailed arguments in the blog)

I don’t trust myself to keep track of a private key (or revocation cert) for 50 years.

I want people to notice my revocation certificate as quickly as possible.

I want people to notice other changes to my key (e.g., cipher preferences) as quickly as possible.

The "keep keyservers clean" argument: Anyone can upload keys in your name
Updating from keyserver should be done automatically not enforced by short expiry dates.
Same as 2.

from https://help.riseup.net/en/security/message-security/openpgp/best-practices

You may think that is annoying and you don’t want to deal with it, but it is actually good to be doing this on a regular basis so you keep your OpenPGP skills fresh. It indicates to users that they key is still active, and that the keyholder is using it, and gives you an opportunity to review the current state of your tools, and best practices. Also, many people will not sign a key that has no expiration date!

This argument summed up: "OpenPGP is complex, you need to learn a lot of stuff and keep up to date. Expiration dates are a great reminder."

To remind yourself you could also use a calendar
This whole argument basically admits that many OpenPGP implementations and tutorials are overly complex.
Our goal is to not require any complex knowledge for OpenPGP usage

No support for Image Attribute Subpackets

In about 99% of all use cases there are better photos to be found in Android's contact database. Photos from Android's contact database are displayed only if a key has been confirmed, otherwise this could lead the user into a false sense of security. It is also not clear what a certification of an Image Attribute Subpacket would semantically mean. This is not specified in RFC 4880. Other applications such as Kleopatra also doesn't support this subpackets.

Key IDs aren't displayed

Short key IDs (last 32 bits of the key's fingerprint) are trivially to replicate via a preimage attack.
Two equal long key IDs can be generated using a collision attack
Examples can be found at https://github.com/coruus/cooperpair

We want two things from a key management framework: unforgability, and human-intelligible handles. Key IDs fail at both.

Fingerprints are unforgable (as much as SHA-1's preimage resistance, anyway -- that's a separate discussion), but they aren't human-intelligible.
Key IDs (both short and long) are neither human-intelligible nor unforgable (regardless of existence of a keysigning network), so they are the worst of all possible worlds.

So reasonable tools should not expose either short or long key IDs to users, or use them internally if they can avoid them. They do not have any properties we want, and in the worst case, they actively mislead people or lead them into harm. What reasonable tool should do that?

For anything human-facing, we should be using human-intelligible things like user IDs and creation dates. These are trivial to forge, but people can relate to them. This is better than offering the user something that is also trivial to forge, but that people cannot relate to. The job of any key management UI should be to interpret the cryptographic assurances provided by the certifications and present that to the user in a comprehensible way.

For anything not human-facing (e.g. key management data storage, etc), we should be using the full key itself. We'll also want to store the full fingerprint as an index, since that is used for communication and key exchange (e.g. on calling cards).

In OpenKeychain

In OpenKeychain several methods for key exchange exists:

QR Codes containing the full fingerprint
SafeSlinger: secure hash commitment based full key exchange
NFC: Full key exchange via NFC

If two keys exist in OpenKeychain's database with the same main user id, the creation date is displayed alongside the keys to differentiate them.

Answer based on dkg's blog post: "OpenPGP Key IDs are not useful" (CC-BY 4.0)

No comment field on key creation

Most OpenPGP User IDs look like this:

Jane Q. Public <jane@example.org>

This is clean, clear, and unambiguous.

However, some tools (gpg, enigmail among others) ask the user to provide a "Comment:" field when they are choosing a new User ID (e.g. when making a new key). These UI prompts are evil. The savvy user knows to avoid entering anything in this field, so that they can end up with a User ID like the one above. The user who provides something here (perhaps even something inconsequential like "I like strawberries", due to not being sure what should go in this little box) will instead end up with a User ID like:

Jane Q. Public (I like strawberries) <jane@example.org>

This is bad. This means that Jane is asking the people who certify her key+userid to certify whether she actually likes strawberries (how could they know? what if she changes her mind? should they revoke their certifications?) and anywhere that she is referred to by name will include this mention of strawberries. This is not Jane's identity, and it doesn't belong in an OpenPGP User ID packet.

Furthermore, since User IDs are atomic, if Jane wants to change the comment field (but leave her name and e-mail address the same), she will instead need to create a new User ID, publish it, get everyone who has certified her old key+userid to certify the key+newuserid, and then revoke the old one.

It is difficult already to help people understand and participate in the certification network that forms that backbone of OpenPGP's so-called "web of trust". These bogus comment fields make an already-difficult task harder. And all because of strawberries!

Tools like enigmail and gpg should not expose the "Comment:" field to users who are generating keys or choosing new User IDs. If they feel it absolutely must be present for some weird corner case that 0.1% of their users will have, they could require that the user enters some sort of "expert mode" before prompting the user to do something that is likely to be a mistake.

Bad examples can be found in dkg's blog post.

Answer based on dkg's blog post: "OpenPGP User ID Comments considered harmful" (CC-BY 4.0)

Password meters

Currently, a very simple password meter is shown in the key creation wizard to encourage users to choose better passphrases to protect their keys.

Studies have shown that password meters can indeed encourage the selection of better passwords:

"How Does Your Password Measure Up? The Effect of Strength Meters on Password Creation."
"Does my password go up to eleven?: the impact of password meters on password selection"
Carnegie-Mellon’s 2011 study concluded that length was the only thing that really influences password strength.

Key Confirmations

see https://github.com/open-keychain/open-keychain/blob/master/OpenKeychain/src/main/res/raw/help_certification.md

Trust

We do not support "trust signatures" because they are rarely used and complex to implement.
There are currently no plans to switch to a more complex model (like ownertrust).

Certification screen

Selection of names only, emails are grouped under names
Do not allow selection of keyserver, this only confuses users where to upload the key (keyservers are federated). If the user really needs a separate un-federated keyserver, she can set the keyserver using the preferences as the preferred one.
Instead of upload key, talk of "synchronize key"

Reasons

Email verification is too difficult to implement in an automatic fashion (requires certifying the user ids separately and sending these pub keys to the email addresses, then receive all those keys and import them again.)
Names as a reality anchor: By asking the user if the person you see/hear corresponds to the key you received you prevent injection of keys with names from other people.

Relevant links

RFCs

Relevant Drafts

Drafts

Whiteout

https://github.com/whiteout-io/mail-html5/wiki/Secure-OpenPGP-Key-Pair-Synchronization-via-IMAP (backup here: Secure OpenPGP Key Pair Synchronization via IMAP)