Updated OpenPGP Security (markdown)
parent
47f3397fc4
commit
e0a28cc5f4
|
@ -26,7 +26,7 @@ Show warning on...
|
|||
* This allows to strip the master key from the OpenPGP key and use the subkeys alone
|
||||
* No expiry (see below)
|
||||
|
||||
## No expiry?
|
||||
## 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 any attack scenario (if set to e.g. 2 years in the future):
|
||||
|
@ -36,7 +36,7 @@ Anyone can upload keys with User IDs containing the email and names of other per
|
|||
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 for expiry
|
||||
#### Arguments for expiry
|
||||
from http://blog.josefsson.org/2014/08/26/the-case-for-short-openpgp-key-validity-periods/ (detailed arguments in the blog)
|
||||
> 1. I don’t trust myself to keep track of a private key (or revocation cert) for 50 years.
|
||||
> 2. I want people to notice my revocation certificate as quickly as possible.
|
||||
|
@ -51,13 +51,13 @@ from https://help.riseup.net/en/security/message-security/openpgp/best-practices
|
|||
|
||||
No real argument here. Just shows that OpenPGP is complex.
|
||||
|
||||
#### Revocation certificate
|
||||
## Revocation certificate
|
||||
TODO: Yes we must do this. Important TODO
|
||||
|
||||
#### Support for Image Attribute Subpacket?
|
||||
No, in about 99% of all use cases there are better photos to be found in Android's contact database. Photos are displayed only if a key has been confirmed.
|
||||
## 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 are displayed only if a key has been confirmed, otherwise this could lead the user into a false sense of security.
|
||||
|
||||
## Why key IDs aren't displayed
|
||||
## Key IDs aren't displayed
|
||||
* Short key IDs (last 32 bits of the key's fingerprint) are trivially to replicate via a [preimage attack](https://en.wikipedia.org/wiki/Preimage_attack).
|
||||
* Two equal long key IDs can be generated using a [collision attack](https://en.wikipedia.org/wiki/Collision_resistance)
|
||||
* Examples can be found at See https://github.com/coruus/cooperpair
|
||||
|
@ -84,9 +84,7 @@ If two keys exist in OpenKeychain's database with the same main user id, the cre
|
|||
|
||||
Answer based on [dkg's blog post: "OpenPGP Key IDs are not useful"](https://www.debian-administration.org/users/dkg/weblog/105) (CC-BY 4.0)
|
||||
|
||||
# Key creation
|
||||
|
||||
## Why we don't show a comment field on key creation
|
||||
## No comment field on key creation
|
||||
Most OpenPGP User IDs look like this:
|
||||
```
|
||||
Jane Q. Public <jane@example.org>
|
||||
|
|
Loading…
Reference in New Issue