hashed user IDs

[Hauke Laging]

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 
unsafe environment.


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110322/f0a03a51/attachment.pgp>