On Wed, 25 Jan 2012 18:19:56 -0500 Daniel Kahn Gillmor <[email protected]> wrote:
>i'm confused by your proposal. some clarifying questions follow: sorry, upon re-reading it, noticed that I left out mentioning some steps that I thought through, but didn't post ;-( ----- >> [1] The person who wants to create a new key, first generates a >> symmetrically encrypted gnupg message, and decrypts it and gets >the >> session key. And leaves the encrypted message on his own website, so that whoever he decides to give the passphrase to, can easily recover the session key. ----- >This seems like it might just be an elaborate way to ask for a >random >number, but i'm not sure what the intent is. Is it just trying to >get a >decent-sized chunk of randomness? or is there another purpose? >if it's >just about randomness, rephrasing more simply might make this >clearer. It's about randomness that can't be brute forced by today's attack resources, but easily communicatable. ----- >> [2] Hash the [(preferred key name)+(seesion key)+(e-mail >address)] > >What is the "preferred key name" ? are you expecting users to >name >their keys? whatever their preferred e-mail name is, i.e, [email protected] ----- >> [3] Generate the key with the uid of >> [(preferred key name)+(session key)+(e-mail address)] > >What happened to the hash here? are you suggesting that the User >ID is >the digested form or the non-digested form? the actual hash of the [[email protected]] i.e. SHA256 of [email protected] ----- > >> [4] Identify the key to the server by the hash. > >OpenPGP certificates are handed to the keyserver as is; the >keyserver >chooses how to index them. What do you mean by "identify the key >to the >server by the hash" ? Here there are 2 ways to go (a) create the key with the uid of [email protected] and send it to the keyserver, with instructions to index it by its hash as the only search criteria (major headache for backward compatibility, as you rightly pointed out) or (b) create the key with uid as the hash itself i.e. SHA256 of [email protected] This poses no backward compatibility problems, and is easily computable by someone who knows Alice's name, e-mail address and passphrase to the symmetrically encrypted message she posted on her site. ----- >> Personally, I agree with David Shaw, that the problem can be >> avoided by just generating a random UID (maybe a truncated >session >> key) and giving the fingerprint and UID to anyone who wants to >look >> it up on the keyserver, as well as the e-mail address separately >to >> whomever the user wants to correspond with.) > >how does your proposal above compare to David Shaw's (seemingly >simpler) >proposal, or to the proposal i outlined elsewhere in this thread? ----- it makes the 'anonymous' key id less likely to be duplicated, i.e. BE452FD9 but is basically the same idea as your's and David's anyway, it seems easier to just give the fingerprint ;-) than to go through all the above, but it's a possible doable approach ... vedaal _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
