hashed user IDs
mailinglisten at hauke-laging.de
Tue Mar 22 01:44:10 CET 2011
Am Sonntag 20 März 2011 19:31:49 schrieb Ben McGinnes:
> I have a
> number of keys on my keyring and when I list them I like to see which
> key belongs to which identity/account (I don't care if it's a real
> name or not, just as long as I can see something that makes sense to
> me). Hashed IDs, depending on how common they became, would make this
> and key management difficult.
They would probably not.
1) A good implementation of such a feature would allow the storage of
additional data (like in trustdb.gpg). In listings this info would be shown
(probably with a hint) instead of the hash.
2) If you search for a key on a keyserver then gpg would know what you have
searched for. You want the key for hashid at hauke-laging.de. Then gpg first
seaches for this string but without success. The it seaches for
3dcfba2bd001d14b56b8341965cdaa85 which results in a match. So gpg would
download this key and automatically write "hashid at hauke-laging.de" as
additional UID information info hashiddb.gpg or whatever.
3) If a key file with haded UIDs is imported as a file (not from a keyserver)
then the user should be asked to add some comment. He need not do that, of
course, but in that case he should not complain later about that.
> It would be too
> easy for people just discovering it to believe that it provides
> greater security than it really does.
That is true for gnupg as a whole. Or does anyone really claim that a relevant
amount of new gnupg users has a clue about the need of protection the secret
keys which are usually stored in rather unsafe environments? I assume that
most new users believe: "Great technology. Now my data is really safe."
Being consequent gpg without --expert should ask during each key generation:
1) Are you REALLY sure you don't want to create this key on a smartcard?
2) You are running Windows / X / have network access / a kernel older than
four days. Are you REALLY sure you want to create a key in THIS environment?
Think about appropriate warnings for entering a passphrase in an obviously
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 555 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users