Mirrors
/
open-keychain
mirror of https://github.com/open-keychain/open-keychain.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated OpenPGP Security (markdown)

Dominik Schürmann 2015-03-16 15:30:48 +01:00
parent 2e3f5d8424
commit b791424548
1 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
OpenPGP-Security.md

@ -57,7 +57,7 @@ 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.
## Why aren't key IDs displayed?
## Why 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
@ -69,11 +69,17 @@ We want two things from a key management framework: unforgability, and human-int
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 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 "](https://www.debian-administration.org/users/dkg/weblog/105) (CC-BY 4.0)
# Key creation