Updated OpenPGP Security (markdown)
parent
96e8d321fb
commit
b4c670d44c
|
@ -112,6 +112,45 @@ Studies have shown that password meters can indeed encourage the selection of be
|
||||||
* "Does my password go up to eleven?: the impact of password meters on password selection"
|
* "Does my password go up to eleven?: the impact of password meters on password selection"
|
||||||
* https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/
|
* https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/
|
||||||
|
|
||||||
|
### Decrypt/Verify Cases
|
||||||
|
|
||||||
|
| v/d | Case | What/Where | Color | Explanation |
|
||||||
|
|--- |----- |---- |------ |------ |
|
||||||
|
| verify | No signature | in Toolbar | red | Not a real error, TODO: maybe overlay? |
|
||||||
|
| | master key expired | in Toolbar | red | In most cases: Passphrase or secret key lost, key expired after some time, no real attack in 99% of the cases|
|
||||||
|
| | master key revoked | overlay error | red | Secret key stolen, used on a compromised device |
|
||||||
|
| | Unknown master key | in Toolbar with Name and Lookup button | red | Maybe change to automatic download in most cases? Currently red, because without a key it says nothing and can be at worst revoked/wrong sig, etc. |
|
||||||
|
| | subkey expired | - | red | see master key expired |
|
||||||
|
| | subkey revoked | - | red | see master key revoked |
|
||||||
|
| | Insecure signature key crypto | - | - | TODO: implement! |
|
||||||
|
| | Invalid signature | overlay error | red | attack |
|
||||||
|
| | Unconfirmed key | - | orange | not confirmed yet |
|
||||||
|
| | Confirmed key | in Toolbar with name | green | awesome |
|
||||||
|
| dec | No encryption | in Toolbar | red | Not a real error, TODO: maybe overlay? |
|
||||||
|
| | master key expired | - | - | TODO: implement? |
|
||||||
|
| | master key revoked | - | - | TODO: implement? |
|
||||||
|
| | subkey key expired | - | - | TODO: implement? |
|
||||||
|
| | subkey key revoked | - | - | TODO: implement? |
|
||||||
|
| | Insecure dec key crypto | - | - | TODO: implement? |
|
||||||
|
| | encrypted | - | green | awesome |
|
||||||
|
|
||||||
|
### Key Confirmations
|
||||||
|
|
||||||
|
see https://github.com/open-keychain/open-keychain/blob/development/OpenKeychain/src/main/res/raw/help_certification.html
|
||||||
|
|
||||||
|
### 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
|
### Relevant links
|
||||||
* https://gist.github.com/coruus/68a8c65571e2b4225a69
|
* https://gist.github.com/coruus/68a8c65571e2b4225a69
|
||||||
* https://github.com/coruus/cooperpair
|
* https://github.com/coruus/cooperpair
|
||||||
|
|
Loading…
Reference in New Issue