Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 20 March 2011 at 6:31:49 PM, in , Ben McGinnes wrote: > On 20/03/11 1:52 PM, MFPA wrote: >> Whether on a keyserver or on your local keyring, I see >> little difference. > Which just shows how your use differs with that of > others. 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. All fair enough but the reason I see little difference between personal information being on other people's local keyrings or on keyservers is covered in the next sentence, which you agreed with. >> Keys that exist on local keyrings sooner or later tend >> to end up on keyservers. > True. >> The first two or three times I looked at PGP and >> GnuPG, I found the apparent requirement to include >> personal information in user IDs repulsive and >> therefore moved on without any further study. A >> feature such as this might have attracted me to study >> further and maybe adopt sooner. > No offence, but I think this is more a lack of > imagination. I think my second key ever used a > pseudonym with no email address or comment and it was > made the same day as my first one. No offence taken. When I eventually looked into it I realised the requirement for including the email address, although strongly suggested by most descriptions and how-to articles I found, was not real. One of the first keys I created was the one use to I sign these messages; the is because whatever PGP version I was using wouldn't create a key without an "email address" of string@string.string and I was unaware of example.net at the time. - -- Best regards MFPAmailto:expires2...@ymail.com Is it bad luck to be superstitious? -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNhpBfnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pILYD/iCq cplQC5D1+3RVeOO/w08C3haZyEOcCP7f8nQwZ8+qKczsWzpES6vUIKmy6NavawQZ GFWAJv2paLAtoH8rNencYVx1w0pOooimGMZ7bLL7ShgiljkeUz1ESOvXO+V2iE2Y wj8Re258FTkIVhvhWjjqQAF9UH8AQmXOEbyAip19 =meYo -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 20/03/11 1:52 PM, MFPA wrote: > On Sunday 13 March 2011 at 4:39:49 PM, in > , Ben McGinnes wrote: >> >> That too is an understandable argument. Especially when it comes >> to searching the keyservers, but less easy to maintain in relation >> to searches of a local keyring > > Whether on a keyserver or on your local keyring, I see little > difference. Which just shows how your use differs with that of others. 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. > Keys that exist on local keyrings sooner or later tend to end up on > keyservers. True. > The first two or three times I looked at PGP and GnuPG, I found the > apparent requirement to include personal information in user IDs > repulsive and therefore moved on without any further study. A > feature such as this might have attracted me to study further and > maybe adopt sooner. No offence, but I think this is more a lack of imagination. I think my second key ever used a pseudonym with no email address or comment and it was made the same day as my first one. > Burying it in expert mode, and thereby branding it as nonsensical or > silly and for experts only, would have effectively rendered it > invisible to me. Perhaps. As long as it is not a default option and it is well and truly clear what limited privacy options it provides. It would be too easy for people just discovering it to believe that it provides greater security than it really does. > A scheme such as this would allow the user, without publishing their > personal information, to publish a key that others could locate and > use. That is not the same thing as preventing their personal > information being revealed. True, but if the aim is not publishing personal information in the clear, then other means of revealing that same information make this "protection" little more than an annoyance to others. >> After all, a relationship could be determined by their identity and >> if there were enough such signatures from people you know in real >> life, it may be possible to determine your identity that way. > > Maybe inferred rather than determined. Perhaps inferred is better, at least at first. > You could have gone to a keysigning party and met a group of people > who knew each other in real life but you'd never seen any of them > before. True. > And working out who you are in real life wouldn't necessarily reveal > your email addresses or any other identities you had in hashed user > IDs. Okay. > (You might have your name unhashed and only be hashing your email > addresses.) Alright, I can see how some might find that useful. >> It seems that the only real strength the hashed UID has is if it is >> adopted by every user, regardless of whether they want it or not. > > Why? If all the UIDs were hashed then it would be considerably more difficult to determine the identity of one of them, even if they had signed each others' keys than if only one person had their name and addresses hashed. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 13 March 2011 at 4:39:49 PM, in , Ben McGinnes wrote: > On 14/03/11 12:32 AM, MFPA wrote: >> Fair enough but I believe a person's desire to >> withhold their own personal information outranks >> another person's desire to make use of that personal >> information. > That too is an understandable argument. Especially > when it comes to searching the keyservers, but less > easy to maintain in relation to searches of a local > keyring Whether on a keyserver or on your local keyring, I see little difference. Keys that exist on local keyrings sooner or later tend to end up on keyservers. >> I would like hashing to be offered for the name and >> then again for the email address, along with a >> one-liner that obscuring the information in the UIDS >> offered minimal protection as described in gpg.man and >> made it harder for other users to locate and use the >> key; if there's a default answer it should be "No". >> Maybe others would feel it should be only in expert >> mode, or perhaps enabled by a "hash-uid" option to the >> "gen-key" command. > I'd definitely say the default should be off and > enabling it only via expert mode would probably be > wise. The first two or three times I looked at PGP and GnuPG, I found the apparent requirement to include personal information in user IDs repulsive and therefore moved on without any further study. A feature such as this might have attracted me to study further and maybe adopt sooner. Burying it in expert mode, and thereby branding it as nonsensical or silly and for experts only, would have effectively rendered it invisible to me. > if you have a key that only has > hashed UIDs of your real name and email address(es), > would you wish to prevent signatures of your key from > contacts who did not use the hashing function? No I would not wish to prevent them. Anyway, I'm not convinced that a mechanism to enforce the keyserver-no-modify flag is possible. In the absence of such a mechanism, wishing is about all you could do to prevent such signatures. > If the > concern is preventing your personal information being > revealed and someone who knows you, but is less > concerned about this is willing to sign your key, would > you attempt to stop them? I would not seek to stop them, and if I did they might not listen. A scheme such as this would allow the user, without publishing their personal information, to publish a key that others could locate and use. That is not the same thing as preventing their personal information being revealed. > After all, a relationship > could be determined by their identity and if there were > enough such signatures from people you know in real > life, it may be possible to determine your identity > that way. Maybe inferred rather than determined. You could have gone to a keysigning party and met a group of people who knew each other in real life but you'd never seen any of them before. And working out who you are in real life wouldn't necessarily reveal your email addresses or any other identities you had in hashed user IDs. (You might have your name unhashed and only be hashing your email addresses.) > It seems that the only real strength the hashed UID has > is if it is adopted by every user, regardless of > whether they want it or not. Why? - -- Best regards MFPAmailto:expires2...@ymail.com Look, it's a hat! It's not going to hurt you. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNhWwFnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pnW4D/1Va N7ry2e6L236i6UTq5PS0mYx/5Abvlz7NtinXwAMAmaTvhm+X7mibRj1hAKdK+XMY sqAM3/ThV4DNFaie5Y4SPI9XXiomq3phnZQQoGNMa9GV+dleUbrJHd8b4d6z6+wd HquiMCw26FstnWvvBLMf5fgqUYS5DnWblcJGm9dF =Dp1h -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 16/03/11 2:04 PM, Doug Barton wrote: > > I do, occasionally, get spam directed to addresses that I am sure > were harvested from they keyservers. How long ago would those addresses have been harvested from the keyservers? > However at the far outside of the range it's no more than 10/month, > whereas my usual run rate for all other types of spam is around > 100/day. That's actually not that much. Most stuff directed at my server is for this address and one or two others and it's usually at least 200/day. Although that doesn't count anything stopped by the grey-listing (which stops a *lot*). Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 03/15/2011 16:15, Ben McGinnes wrote: I think that if spammers were harvesting addresses from the keyservers then you would have received some by now. I do, occasionally, get spam directed to addresses that I am sure were harvested from they keyservers. However at the far outside of the range it's no more than 10/month, whereas my usual run rate for all other types of spam is around 100/day. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 16/03/11 9:54 AM, MFPA wrote: > On Monday 14 March 2011 at 1:06:26 AM, in > , Ben McGinnes wrote: > >> Anyway, out of curiosity, did you ever receive spam by that address >> and prove it had been harvested from the keyservers? I still think >> harvesting addresses from the keyservers is too much effort for >> spammers, who mostly generate the target addresses, but it would be >> nice to finally answer that question. > > No mail received at all on that address so far. That key has only > been up just over a year. I think that if spammers were harvesting addresses from the keyservers then you would have received some by now. I don't think they bother because: a) The effort required to harvest the addresses would be better spent elsewhere and most, if not all, spammers are lazy. b) It would be easier to just generate usernames at a target domain name than to work from a large list (these days). c) It is more likely that OpenPGP users are going to include people who will hunt down spammers and get their upstream providers to disconnect them. > Up until now, if I received any mail on that address, the address > could only have been harvested from a keyserver (or randomly > matched). Going forward, if I receive any mail on that address it > was probably harvested from the mailing list archive. That would be likely. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Monday 14 March 2011 at 1:06:26 AM, in , Ben McGinnes wrote: > Anyway, out of curiosity, did you ever receive spam by > that address and prove it had been harvested from the > keyservers? I still think harvesting addresses from > the keyservers is too much effort for spammers, who > mostly generate the target addresses, but it would be > nice to finally answer that question. No mail received at all on that address so far. That key has only been up just over a year. Up until now, if I received any mail on that address, the address could only have been harvested from a keyserver (or randomly matched). Going forward, if I receive any mail on that address it was probably harvested from the mailing list archive. - -- Best regards MFPAmailto:expires2...@ymail.com Oven mitt: A partially charred grease stain that fits over the hand. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNf+4wnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p0lEEALDU +aAzxVfu0TtDPZV2WJ784Tz0OBltiIAz2gqofF7hRH2ZzMAufJNdUTRMEI+spSB/ zhPn0je+Yk7PjVoHwRXyb+P7cPSmWxtJ7p5Af+u3/mF83hQcpEi4EgWxGXVHOSUu qz2nhTXpneH3eBtqeC8KXvToHzAGcnFR979XFU7h =y9Kx -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
MFPA: >> Trust is not transitive. If A trusts B and B trusts C, >> there is no requirement that A trusts C. > > In real life, true. But what about the GnuPG default of trusting a key > that carries certifications from 1 fully trusted or 3 marginally > trusted keys. Unless you manually inspect each trust path, how would > you spot unknown keys from past real-life associates you distrusted? You're mixing concepts. Trusting someone to vouch for others' keys validity in *not* the same as believing someone else's key is valid. I think, what Robert meant (and feel free to correct if I'm off here) is he wouldn't trust certifications from that "ex-CEO Ben", but there's nothing wrong really if one or several persons whom Robert trusts certify "Ben's" key. In GnuPG, you assign trust levels manually. In turn, GnuPG computes validity automatically. Trust doesn't gets transferred from one key to another. Validity does (in a sense). -- Vlad "SATtva" Miller 3d viz | security & privacy consulting www.vladmiller.info | www.pgpru.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 14/03/11 11:44 AM, MFPA wrote: > On Sunday 13 March 2011 at 5:02:52 PM, in > , Ben McGinnes wrote: > >> I'd hardly call it "flashing lights" just to be listed on the >> keyserver, especially when the same data source also contains a >> large amount of effectively useless data in which any key on the >> servers is buried amongst. > > Ok, you know what I mean. When you have found the key, all user IDs > are readable and the information is clearly visible. Compared to a > key showing only hashes in the user IDs, this is like having the > information up in lights for all to see. (-: I can't speak for everyone else, but I've always taken the term of saying something is in "flashing lights" to mean that something is drawing attention to that thing. The existence of a UID being in a human readable format on a keyserver doesn't really fit that category. >> Speaking of which, I presume key ID 0x992F6351 is one of your >> tests? > > Without looking at it I couldn't comment; I have a handful out there. > (-; Well, the name kind of gives it away: N.O. Hashing 2048 bit RSA key 992F6351, created: 2010-03-03 > Last I heard, dfgh.net was one of the domains whose owner allows its > use as an alternative to spamgourmet.com. If it has changed hands, the > new owner could be in for a shock... The whois data says it's been registered for a few years, so it probably hasn't changed hands. Anyway, out of curiosity, did you ever receive spam by that address and prove it had been harvested from the keyservers? I still think harvesting addresses from the keyservers is too much effort for spammers, who mostly generate the target addresses, but it would be nice to finally answer that question. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 13 March 2011 at 5:02:52 PM, in , Ben McGinnes wrote: > Ah, I'm still using the 1.4.x branch, so I haven't seen > any of that. Nor have I; it is just my understanding from descriptions and answers to questions that I have read. > I'd hardly call it "flashing lights" just to be listed > on the keyserver, especially when the same data source > also contains a large amount of effectively useless > data in which any key on the servers is buried amongst. Ok, you know what I mean. When you have found the key, all user IDs are readable and the information is clearly visible. Compared to a key showing only hashes in the user IDs, this is like having the information up in lights for all to see. (-: > Speaking of which, I presume key ID 0x992F6351 is one > of your tests? Without looking at it I couldn't comment; I have a handful out there. (-; > If so, you probably should've used > example.net as the domain name. Depends. What was being tested may have required a working email address. > It's possible that the > registrant of dfgh.net in Turkey might object to this > reference to his domain. Last I heard, dfgh.net was one of the domains whose owner allows its use as an alternative to spamgourmet.com. If it has changed hands, the new owner could be in for a shock... >> Yes, different people you communicate with using >> different names/email addresses could share >> information. If this were uploaded to a database that >> became widely used instead of keyservers it would >> circumvent the whole idea... > As, indeed, would traffic analysis. And neither of these are within the scope of the limited protection intended by this scheme. - -- Best regards MFPAmailto:expires2...@ymail.com Wisdom is a companion to age; yet age may travel alone. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNfWTknhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p3yMD/1IJ vAVZxk3WTNL9Hlzy3b5raJcvfW3dA1SxL8079IhoxWPh9Pu7RrmuE6hSzenwmY+2 BeNOAIFTfWwc5n5nUALFZtosgRI/y18VxtQVDSs4/S4QYwxzfrzUpJrlCwdeM5nQ +Zx4PoqeTexjsxhX+YdjJahc1Y51JiW3JTwur/TK =qb68 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 14/03/11 1:12 AM, MFPA wrote: > On Sunday 13 March 2011 at 7:58:36 AM, in > , Ben McGinnes wrote: > >> So, my question, how would you enable a user to display those keys >> with known names or identities without searching for a specific key >> belonging to a particular person? > > My understanding is that the new keybox format for storing keys will > allow storing of metadata such as when the key was last > refreshed/updated/matched a search, usage statistics, and local > notes which might include the known names and/or email addresses. Ah, I'm still using the 1.4.x branch, so I haven't seen any of that. Maybe when 2.1 actually reaches the next stable release (2.2) I'll have to have another look. > There is a balance to be achieved. A user taking advantage of the > new feature have to accept the key would be less efficiently > searched and located than one which announced all their details in > flashing lights; I'd hardly call it "flashing lights" just to be listed on the keyserver, especially when the same data source also contains a large amount of effectively useless data in which any key on the servers is buried amongst. Speaking of which, I presume key ID 0x992F6351 is one of your tests? If so, you probably should've used example.net as the domain name. It's possible that the registrant of dfgh.net in Turkey might object to this reference to his domain. > Yes, different people you communicate with using different names/email > addresses could share information. If this were uploaded to a database > that became widely used instead of keyservers it would circumvent the > whole idea... As, indeed, would traffic analysis. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 13 March 2011 at 2:47:23 PM, in , Robert J. Hansen wrote: > On 3/13/2011 8:37 AM, MFPA wrote: >> of information unless it is known that somebody is >> actively looking for the information. In my world... > So at this point you're saying, "I want to convince > somebody else to volunteer their time and energy > implementing a bogus solution to a problem that doesn't > even exist." I am saying no such thing in that short snippet nor in the rest of my posting. - -- Best regards MFPAmailto:expires2...@ymail.com Roses smell better than onions but don't make such good soup -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNfPuOnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p4qAD/2hA jHgGFfJ1xUnv5dpFuqwjvAxKgkVXyf/ZLkOOr72JyFOkx2m3lrEN9qpE6KZnKjjB X4MyHo0TGPojZAWrIW7XGfrtfIPKaD/oCpIWPMJfYXlx32K03e8AAHG50BX/q8MS a+L06W4l8b6sqdVHo6HYFSorZZ6aOP/tlUpqq512 =JCAI -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 14/03/11 12:32 AM, MFPA wrote: > On Sunday 13 March 2011 at 5:48:55 AM, in > , Ben McGinnes wrote: > > I'm assuming a short descriptive paragraph in the gpg.man file plus > some good info becoming available over time in various "start up > guides" etc. by searching the web or mailing list archives or asking > on mailing lists, as with other GnuPG features. It doesn't matter if > people learn after the key is created because additional UIDs > containing extra hashes can be added later. Don't depend on the mailing lists, we're a very small subset of GPG users. All relevant documentation will need to be included for those users where connectivity to the Internet is sporadic at best. >> As much as I find your idea interesting, I think I'd rather have >> the ability to search on sections of a UID. > > Fair enough but I believe a person's desire to withhold their own > personal information outranks another person's desire to make use of > that personal information. That too is an understandable argument. Especially when it comes to searching the keyservers, but less easy to maintain in relation to searches of a local keyring (as I discussed in my other message). >> If your hashed UID were an optional feature that were not enabled >> by default, I doubt I would object, > > I would like hashing to be offered for the name and then again for > the email address, along with a one-liner that obscuring the > information in the UIDS offered minimal protection as described in > gpg.man and made it harder for other users to locate and use the > key; if there's a default answer it should be "No". Maybe others > would feel it should be only in expert mode, or perhaps enabled by a > "hash-uid" option to the "gen-key" command. I'd definitely say the default should be off and enabling it only via expert mode would probably be wise. > The main disadvantage I see in hashing the information is slightly > increased complexity in locating keys. That assumes the individual > would otherwise have a key containing his information unhashed. For > individuals whose UIDs would otherwise contain spurious or no > information, locating their key should become easier. That appears to be the case. Certainly for individuals like yourself I can see the appeal. > The search/research capability that you outlined would be reduced if > significant numbers of keys with only hashed UIDs came about, Yes. Although to be honest, even if this feature were added, I don't see it becoming very popular. > if the organisations you are searching allow their people to use > such UIDs. That would require an OpenPGP policy being adopted which is not exactly common with most organisations. > The impact on the WoT is unclear. One scenario is no change from the > current situation, where an individual who chooses not to reveal > their name and email address(es) in their UID has little chance of > success in finding people willing to provide certifications. I doubt there would be much change, although it does raise another question: if you have a key that only has hashed UIDs of your real name and email address(es), would you wish to prevent signatures of your key from contacts who did not use the hashing function? If the concern is preventing your personal information being revealed and someone who knows you, but is less concerned about this is willing to sign your key, would you attempt to stop them? After all, a relationship could be determined by their identity and if there were enough such signatures from people you know in real life, it may be possible to determine your identity that way. It seems that the only real strength the hashed UID has is if it is adopted by every user, regardless of whether they want it or not. Anyway, the more we discuss this, the less likely it appears that it will be added to either GnuPG or any of the commercial PGP products, let alone the RFCs. Still, the advantage of GnuPG is that it is released under the GPL (version 3, last time I checked), so there's nothing stopping you from creating your own fork to add the feature. If it became popular through practical example then the chances of the feature being incorporated in the main release would be vastly increased. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/13/2011 8:37 AM, MFPA wrote: >> If nobody's looking for people's email addresses, then >> there's no need to not publish email addresses. > > That assumes that there is no need to obscure a piece of information > unless it is known that somebody is actively looking for the > information. In my world... So at this point you're saying, "I want to convince somebody else to volunteer their time and energy implementing a bogus solution to a problem that doesn't even exist." I'm done with this thread. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 13 March 2011 at 7:58:36 AM, in , Ben McGinnes wrote: > So, my question, how would you enable a user to display > those keys with known names or identities without > searching for a specific key belonging to a particular > person? My understanding is that the new keybox format for storing keys will allow storing of metadata such as when the key was last refreshed/updated/matched a search, usage statistics, and local notes which might include the known names and/or email addresses. > It could be done with a local db or address book which > maps previous key searches to the hashes and keys they > match, but this seems to be an additional level of > complexity just to achieve a current feature Don't forget the additional feature of being able to publish a key that, by direct examination, will not reveal your name(s) and/or email address(es) but can still be located by a user who already has that information about you. There is a balance to be achieved. A user taking advantage of the new feature have to accept the key would be less efficiently searched and located than one which announced all their details in flashing lights; a user encountering that key can at least locate it from the name or email address, unlike if the key owner had used spurious or no information in the UIDs. > and could > also be used to circumvent the entire idea if performed > on a large enough scale. Yes, different people you communicate with using different names/email addresses could share information. If this were uploaded to a database that became widely used instead of keyservers it would circumvent the whole idea... - -- Best regards MFPAmailto:expires2...@ymail.com My mind works like lightning... one brilliant flash and it's gone -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNfNDLnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pUosD/19j MG6l6l1aaS9Ou/g8alGi3zwLUZbnpqcp5PDhUGn2F4CW5JB06TK29FDxrh+Ij/9B 39rOb4nd3d84/cIa/SMcyvgOqJB9GAjORCIE/JuQbp8+JplkGQQ+y5/8GZ60jWqq AVh22ZiJzIjh9jV2MEIU3jiSJMR1dii74TmCHVqf =x//r -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Sunday 13 March 2011 at 5:48:55 AM, in , Ben McGinnes wrote: > I think you're assuming a level of innate understanding > of what can be done with every part of a UID by every > user when they create a key. This is most definitely > not the case. I'm assuming a short descriptive paragraph in the gpg.man file plus some good info becoming available over time in various "start up guides" etc. by searching the web or mailing list archives or asking on mailing lists, as with other GnuPG features. It doesn't matter if people learn after the key is created because additional UIDs containing extra hashes can be added later. > As much as I find your idea interesting, I think I'd > rather have the ability to search on sections of a UID. Fair enough but I believe a person's desire to withhold their own personal information outranks another person's desire to make use of that personal information. > If your hashed UID were an optional feature that were > not enabled by default, I doubt I would object, I would like hashing to be offered for the name and then again for the email address, along with a one-liner that obscuring the information in the UIDS offered minimal protection as described in gpg.man and made it harder for other users to locate and use the key; if there's a default answer it should be "No". Maybe others would feel it should be only in expert mode, or perhaps enabled by a "hash-uid" option to the "gen-key" command. > but I > think the current use of UIDs has value that I would > not want to see superceded by the hashed version. The main disadvantage I see in hashing the information is slightly increased complexity in locating keys. That assumes the individual would otherwise have a key containing his information unhashed. For individuals whose UIDs would otherwise contain spurious or no information, locating their key should become easier. The search/research capability that you outlined would be reduced if significant numbers of keys with only hashed UIDs came about, if the organisations you are searching allow their people to use such UIDs. The impact on the WoT is unclear. One scenario is no change from the current situation, where an individual who chooses not to reveal their name and email address(es) in their UID has little chance of success in finding people willing to provide certifications. - -- Best regards MFPAmailto:expires2...@ymail.com Yellow snow is not lemon flavoured -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNfMdZnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pjkwD/1Zu TjY54C6MwgqVJ6hN5VcmaeEhSNwZsLXZbL4F5RtWvLRIqzneHYr3gFLug7YKTTWb qXtSgUwrMjYEL4KbP+Ah34EerpQ7/PMq/PaY99bxNWpSfLBD7LOkR/65spR0etU1 Qhf6gMLrFzHvJUeGBfxgovYdKo8Zecnmj3DAFmkN =KpW4 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 12 March 2011 at 11:06:14 PM, in , Robert J. Hansen wrote: > If nobody's looking for people's email addresses, then > there's no need to not publish email addresses. That assumes that there is no need to obscure a piece of information unless it is known that somebody is actively looking for the information. In my world you obscure certain information simply because it is nobody else's business. Just like you move stuff to the drawer or filing cupboard because there is an offchance that somebody walking through the office might read it if left on the desk, not because you think they are specifically looking for it. > And if > there's a need to not publish email addresses, that's > because somebody's looking for them. That suggests that all information should be published unless it can be demonstrated there is a compelling reason to not publish. Whilst this is true for some categories of information, it is not universally true for all information. Much information relating to corporations or individuals would not be published unless there were a compelling reason to publish. My email addresses are personal contact information relating to me as an individual. I know of no reason to publish any of my email addresses to anybody other than those with whom I use that email address to communicate; they are quite simply nobody else's business. In the absence of a reason to publish, there is no requirement for a reason to not publish. > It is not good enough right now to prevent an even > moderately skilled attacker from recovering email > addresses. Just like a moderately skilled attacker could look in the desk drawer or filing cabinet, or could open the envelope that obscures a bank statement or telephone bill. Those schemes are good enough for the minimal level of protection they seek to provide. > This scheme offers the illusion of security instead of > actual security: It offers no such thing. In order to be an illusion it would need to be fooling somebody. The scheme was never claimed to offer security against any form of attack more severe than casual snooping, and never could because anybody could add signatures to the key that stated the unhashed version of any of the hashed strings. The scenario of a spammer brute-forcing and then spamming was interesting, if a little esoteric. Usually, spamming subsides after a few weeks and (aside from a certain amount of irritation and wasted time) is of little consequence. If the spammer published a list enumerating the email accounts that went with the particular key ID then it might be a significant attack against this scheme. Even then, it would have little relevance unless the list (or maybe a link to it) were in a signature appended to the key. > and I feel selling people an illusion > is a deeply corrupt act. Insurance companies, amongst others, earn billions by doing just that. But this scheme is no illusion; I am aware of no pretence that it offers anything it does not. > I mean, really, is that what you want to sell? Or > should this be taken as a, "the idea of blinded UIDs is > a good one, but this idea is inadequate and should be > taken back to the drawing board"? It depends on the reason for wishing to use blinded UIDs. You have demonstrated limitations to this idea; I still believe it to be adequate for my purposes. More thought is needed, followed by further discussion at some point. - -- Best regards MFPAmailto:expires2...@ymail.com Wise men learn many things from their enemies. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNfLqUnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pJlgD/1yR ITx5g87K8gc7EXsMD+fI+r/avMP9ih8iHfJL7ih4Ibyk3sl3lCP7eIeZ1TC4ZET5 Q3uP/mWX+y/XwwAy2uB3c5otBr3ariVbjK1G3dKnVGeL2fh6oQoGXEgmfp+MOih/ G+V5k/OMNC6UIaOU6uZcI6+1BRV8edTGvAm0ERDx =KnPv -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 13/03/11 5:32 PM, John Clizbe wrote: > Ben McGinnes wrote: >> >> Thanks. I think I might have to play around with installing a local >> server. I don't have a big enough link to run a public server, but >> running a local one would probably serve as an interesting exercise. > > I think that's my problem with sks.keyservers.net, getting too many > timeouts. Have to beat on AT&T *again* Even though my poor little ADSL connection is fairly small, at least I do have a very competent and responsive ISP. >> Is the source on the sks-servers.net site or should I be looking >> elsewhere? > > Originally @ https://savannah.nongnu.org/projects/sks/ > > Currently at Google™ Code: http://code.google.com/p/sks-keyserver/ Thanks. > my branch: hg clone https://johnclizbe-sks-keyserver.googlecode.com/hg/ > johnclizbe-sks-keyserver What does your branch have that the main one doesn't? > You need Berkeley DB >= 4.6 and ocaml >= 3.11.0 Cool. > I've built on Linux, Mac OS (MacPorts), and Solaris (Blastwave) I'd be building on Linux and there will be plenty of examples of that floating around. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 13/03/11 6:37 AM, MFPA wrote: > > Whatever you do with user IDs is optional, since they are just a > free-text field. And of course a user wanting to make their key > match more searches could include extra UIDs with additional > hashes. For example John Smith could > include hashes of example.com and of john.smith. In any event, > including the information in hashed form should make the key more > likely to be found than if the info were not there at all. There's something else about this which has been nagging me, how would you address this: Currently a user's public keyring contains easily readable UIDs and can be examined in any way they see fit. If hashed UIDs were adopted it would be possible to have hundreds of keys in the keyring which only display hashed UIDs when listing the keyring. Some of these may belong to people the user corresponds with, some may have been picked up in order to try to verify the WoT and some may have been picked up to verify signatures on correspondence (e.g. in mailing lists). So, my question, how would you enable a user to display those keys with known names or identities without searching for a specific key belonging to a particular person? Say I ended up with a couple of hundred keys using only hashed UIDs and I know that around 40 of them are people I correspond with, the rest are from signatures on mailing lists or whatever. If I wish to split those keys off from the others into a smaller keyring, instead of leaving everything in the default keyring, how do I determine that without wading through large email archives to find the key IDs of those people I have corresponded with? Also, when I am viewing the signatures on keys and I see signatures containing hashed UIDs of other people I do know and also have keys for, how do I know which one is which in order to differentiate them from the hashed UIDs of keys I may have, but don't know the identities of? It could be done with a local db or address book which maps previous key searches to the hashes and keys they match, but this seems to be an additional level of complexity just to achieve a current feature and could also be used to circumvent the entire idea if performed on a large enough scale. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 13/03/11 7:22 AM, Robert J. Hansen wrote: > On 3/12/2011 1:05 PM, MFPA wrote: >> How does the WoT idea require me to know the names or email addresses >> associated with the keys in the trust path? The text strings in User >> IDs do not feature in the trust calculation. > > Yes, in fact, they do. > > In my past, there's an ex-CEO whom I'll just call "Ben." I wish you hadn't. ;) > Ben made some really astonishingly bad decisions that put him in > prison for eighteen months, and left me with a permanent distrust > for him. If I see Frank has signed Ben's certificate, and I trust > Frank, am I going to trust Ben? > > Of course not. I wouldn't trust him either. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Ben McGinnes wrote: > On 12/03/11 6:26 PM, John Clizbe wrote: >> >> That's the SKS implementation of the key database. On top of the >> keys, there are several other tables. Within each table there is >> also empty space, most commonly space left at the end of a page. >> >> The present size of just the raw keys -- like you would pull in a >> keydump to bootstrap a server -- is 4.38 GB > > Thanks. I think I might have to play around with installing a local > server. I don't have a big enough link to run a public server, but > running a local one would probably serve as an interesting exercise. I think that's my problem with sks.keyservers.net, getting too many timeouts. Have to beat on AT&T *again* > > Is the source on the sks-servers.net site or should I be looking > elsewhere? Originally @ https://savannah.nongnu.org/projects/sks/ Currently at Google™ Code: http://code.google.com/p/sks-keyserver/ Current release: http://code.google.com/p/sks-keyserver/downloads/detail?name=sks-1.1.1.tgz&can=2&q= trunk: hg clone https://sks-keyserver.googlecode.com/hg/ sks-keyserver my branch: hg clone https://johnclizbe-sks-keyserver.googlecode.com/hg/ johnclizbe-sks-keyserver You need Berkeley DB >= 4.6 and ocaml >= 3.11.0 I've built on Linux, Mac OS (MacPorts), and Solaris (Blastwave) -- John P. Clizbe Inet: John (a) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 12/03/11 6:26 PM, John Clizbe wrote: > > That's the SKS implementation of the key database. On top of the > keys, there are several other tables. Within each table there is > also empty space, most commonly space left at the end of a page. > > The present size of just the raw keys -- like you would pull in a > keydump to bootstrap a server -- is 4.38 GB Thanks. I think I might have to play around with installing a local server. I don't have a big enough link to run a public server, but running a local one would probably serve as an interesting exercise. Is the source on the sks-servers.net site or should I be looking elsewhere? Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 13/03/11 6:37 AM, MFPA wrote: > > Whatever you do with user IDs is optional, since they are just a > free-text field. And of course a user wanting to make their key > match more searches could include extra UIDs with additional > hashes. For example John Smith could > include hashes of example.com and of john.smith. In any event, > including the information in hashed form should make the key more > likely to be found than if the info were not there at all. I think you're assuming a level of innate understanding of what can be done with every part of a UID by every user when they create a key. This is most definitely not the case. > If there was a point there other than curiosity value, it went way > over my head. (-: That was an example. The point was being able to determine, to some extent, the degree of OpenPGP use in Australian politics and the civil service. In the case of that minister, I knew the rest of his party used it because I know they were using a corporate version of PGP in 2000 or 2001. The two major parties over here have always had some interesting interactions online (ever since a scandal involving a staffer of one providing information to "hack" the website of the other in 1998). Currently I can run "gpg --search-keys aph.gov.au" and get the keys for everyone who has one in Parliament House (most of them are civil servants, only two or three are politicians). With hashed UIDs, unless the person generating the hash specifies additional hashes to be included then that will cease to work. As much as I find your idea interesting, I think I'd rather have the ability to search on sections of a UID. If I ever want to be contacted in a way that is separate from my name, then I'll just go to the effort of creating a new key with a pseudonym and relevant mail drop. If your hashed UID were an optional feature that were not enabled by default, I doubt I would object, but I think the current use of UIDs has value that I would not want to see superceded by the hashed version. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/12/2011 7:41 PM, Hauke Laging wrote: > No. You just control who can make the next step: Mapping keys to UIDs. Yes. Like I said, you want an ORCON system. If you control how people can use data, then you've entered ORCON. As soon as you invent an ORCON system, I would love to revisit this conversation. I am not being in the slightest bit facetious: I think ORCON systems are difficult theoretical and practical challenges and I'd love to see a successful system fielded. It's just that, as currently drafted, this isn't it. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Am Freitag 11 März 2011 14:54:57 schrieb Robert J. Hansen: > On 3/10/2011 3:09 PM, Hauke Laging wrote: > > That's the technical situation today. But it is no use to announce > > that to the whole world. > > (Did you mean "not necessary" instead of "no use"?) I meant "not useful". > It is useful to quite a lot of people. Look at how many people map out > webs of trust for entirely innocent purposes. As MFPA mentioned: This would not prevent mapping. It would (if noone fails) help limiting the access to the identities in the map to those who are supposed to be able to do that by the decision of the respective identity owner. > How do you propose determining who really needs those signatures for > validation purposes and who doesn't? And once you've made that > determination, how do you enforce it? The access to signatures is not limited. Everyone decides himself which ones he needs. But the owner of the identity decides whom it is revealed to. > "I'll make the certification, but I get to > control who gets to learn about the certification." No. You just control who can make the next step: Mapping keys to UIDs. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 03/12/2011 15:06, Robert J. Hansen wrote: This scheme offers the illusion of security instead of actual security: and I feel selling people an illusion is a deeply corrupt act. +1 I'm hoping that this discussion is going to draw to a close soon, having already lived through it and drawn roughly the same conclusions on PGPNET. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Am Sonntag 13 März 2011 00:06:14 schrieb Robert J. Hansen: > I mean, really, is that what you want to sell? Or should this be taken > as a, "the idea of blinded UIDs is a good one, but this idea is > inadequate and should be taken back to the drawing board"? Your arguing pretends that somebody is to be fooled. That is not the case. Nothing prevents gnupg (and I even suggested to do that) from warning that this feature seems to just be used for an email address which is does not make sense to be used with (for the reason you explained very convincingly). When offering this feature it should be clearly said that it not worth much for most existing addresses. It isn't, too, for new addresses which are simple. As a user you should decide to take both or none: a safe email address and a safe UID or a normal address and a normal UID. This would not be snake oil. But a tool that requires certain knowledge and awareness. Just as today's gnupg itself. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/12/2011 5:25 PM, MFPA wrote: > A desire to not publish my email addresses (but still have somebody > who knows any of my addresses find my key on a server) does not equate > to an assumption that somebody wants to harvest email addresses from > servers. Yes, it does. If nobody's looking for people's email addresses, then there's no need to not publish email addresses. And if there's a need to not publish email addresses, that's because somebody's looking for them. > Is not about providing complete confidentiality, anonymity or > security. Instead of leaving a document open on the desk, this scheme > is more akin to putting it in the drawer or cupboard than it is to > putting it in the safe. Not secure but good enough in many > circumstances. It is not good enough right now to prevent an even moderately skilled attacker from recovering email addresses. A work factor of 10 billion means I write a Perl script, let my iMac work for a week, and fill up a $100 hard drive. This scheme offers the illusion of security instead of actual security: and I feel selling people an illusion is a deeply corrupt act. "If we use this blinding scheme it will look like it works but in reality anyone who wants to map out the Web of Trust will probably just be delayed for a week and the majority of users will think they're secure." I mean, really, is that what you want to sell? Or should this be taken as a, "the idea of blinded UIDs is a good one, but this idea is inadequate and should be taken back to the drawing board"? ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 12 March 2011 at 8:24:34 PM, in , Robert J. Hansen wrote: > On 3/12/2011 3:10 PM, MFPA wrote: >> After generating the list of possible email addresses, why would a >> spammer generate the hashes and search for keys instead of simply >> blasting out messages to the whole lot? > Beats me. You're the one who's assuming someone wants > to harvest email addresses. A desire to not publish my email addresses (but still have somebody who knows any of my addresses find my key on a server) does not equate to an assumption that somebody wants to harvest email addresses from servers. If such an assumption was stated it wasn't by me. (-: > Imagining a spammer behind > it is just part of a thought exercise. Fair enough. It just seemed difficult to imagine what would be the return on their effort. > Focus on the > real issue -- that this scheme you're proposing is not > secure against an even mildly motivated attacker -- not > who the prospective attacker is. Fair enough, I underestimated quite how easy a brute force attack could be. Longer email addresses at less-obvious domain names makes it just that little bit harder but that is not really the point, IMHO. Since anybody can add a certification to the key saying whatever they choose, somebody else could make public one or more of the hashed email addresses or identities. No major problem, just add a new one. Is not about providing complete confidentiality, anonymity or security. Instead of leaving a document open on the desk, this scheme is more akin to putting it in the drawer or cupboard than it is to putting it in the safe. Not secure but good enough in many circumstances. - -- Best regards MFPAmailto:expires2...@ymail.com You can't build a reputation on what you are going to do -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNe/L5nhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pYCwD/3iq j/lM7ACgiteMKjkncvhLTnrNv2yJg+ybKd1fqz+K9oTkT/UG/aoiNGLQZOmHDs1y HtjfrqcdUQVael3uhj5zl1KrYpXWmDjTBFpQHEspxpqmXY2529WqOrvDqyHdvUMg qFeWHDI8hbCXGi4+gY/md9JzOfymLo0LNcPBV8eB =m7VY -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 12 March 2011 at 8:22:06 PM, in , Robert J. Hansen wrote: > On 3/12/2011 1:05 PM, MFPA wrote: >> How does the WoT idea require me to know the names or email addresses >> associated with the keys in the trust path? The text strings in User >> IDs do not feature in the trust calculation. > Yes, in fact, they do. > In my past, there's an ex-CEO whom I'll just call > "Ben." Ben made some really astonishingly bad > decisions that put him in prison for eighteen months, > and left me with a permanent distrust for him. If I > see Frank has signed Ben's certificate, and I trust > Frank, am I going to trust Ben? > Of course not. Presumably GnuPG factors this into the trust calculations by virtue of the trust level you have assigned to Ben's key, not by parsing his User IDs. > Trust is not transitive. If A trusts B and B trusts C, > there is no requirement that A trusts C. In real life, true. But what about the GnuPG default of trusting a key that carries certifications from 1 fully trusted or 3 marginally trusted keys. Unless you manually inspect each trust path, how would you spot unknown keys from past real-life associates you distrusted? > In fact, if > it turns out A knows C, transitivity can break > completely. Indeed, if you know that a certificate belongs to somebody you actually know, trust *calculations* are irrelevant. Of course you might trust somebody's security procedures and keysigning policy but wish to keep your valuables or your wife well away from him. - -- Best regards MFPAmailto:expires2...@ymail.com A picture is a poem without words -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNe+REnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5piV8EAKTN tjx4dkO4XZWWjW/IW+rt39i3YKVsrXcEhpyiH/Gc9RdOMxXaKd+SUkSCDRSAqd0d wl4WFhGQpbR42kAYbMliDAnbKZpxuydlZMbL/MAx2ncZYBMAjQd6RP5FOx/W4NPh 8zeALI92omNd4QGtMLql6bZjKi9waDyV/sjReiCV =slFP -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Saturday 12 March 2011 at 8:14:34 PM, in , Robert J. Hansen wrote: > Product liability is civil, not criminal. OK, balance of probabilities rather than beyond reasonable doubt. > Regardless, > it doesn't matter: for all that judges tell juries > "your job is to determine the truth of the accusation," > a jury's natural instinct is going to be to find a > responsible party. Fair enough, you know more about this than I do. I would expect their natural instinct to be doing the job they were charged with, as quickly as possible so that they could get back to their own lives. - -- Best regards MFPAmailto:expires2...@ymail.com There is no job so simple that it cannot be done wrong -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNe9nqnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p2C8EAIrM de47xF1hdJU7EzxaUeZVibVy06f9mNRiaXs/8vw5wIhgGSHOsxvEgU5qMyGoPOQq YOeKUcbFYTlxfYa7OCbLtIl1mKV007Hdyn9FaLXF6tdXKiyRLK6kx+e2NudB+64z Pyd+1Md/AllA4SeAVTXNs4vhuns3vnIsOtX5zTYP =CDp/ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/12/2011 3:10 PM, MFPA wrote: > After generating the list of possible email addresses, why would a > spammer generate the hashes and search for keys instead of simply > blasting out messages to the whole lot? Beats me. You're the one who's assuming someone wants to harvest email addresses. Imagining a spammer behind it is just part of a thought exercise. Focus on the real issue -- that this scheme you're proposing is not secure against an even mildly motivated attacker -- not who the prospective attacker is. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/12/2011 1:05 PM, MFPA wrote: > How does the WoT idea require me to know the names or email addresses > associated with the keys in the trust path? The text strings in User > IDs do not feature in the trust calculation. Yes, in fact, they do. In my past, there's an ex-CEO whom I'll just call "Ben." Ben made some really astonishingly bad decisions that put him in prison for eighteen months, and left me with a permanent distrust for him. If I see Frank has signed Ben's certificate, and I trust Frank, am I going to trust Ben? Of course not. Trust is not transitive. If A trusts B and B trusts C, there is no requirement that A trusts C. In fact, if it turns out A knows C, transitivity can break completely. > What would not be visible (at least to people who didn't already know > it) is the identity and email address of the certifying key's owner. So far, you haven't produced a mechanism that will do this. We're still at the "it would be nice if..." stage of your idea. Thus, I really can't respond to statements of what this mechanism would or wouldn't do, since we don't have a mechanism to analyze. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/12/2011 11:55 AM, MFPA wrote: > Determining whether it has been proven beyond reasonable doubt that > the defendant is guilty as charged has nothing to do with the > apportionment of blame. Product liability is civil, not criminal. Regardless, it doesn't matter: for all that judges tell juries "your job is to determine the truth of the accusation," a jury's natural instinct is going to be to find a responsible party. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Wednesday 9 March 2011 at 1:39:35 PM, in
, Robert J. Hansen wrote:
> 3. Deploying this scheme means:
> (a) people can no longer do fuzzy searches for
> email addresses ("show me all user IDs that
> look like this pattern")
> (b) finding
> people's certificates may be made more
> difficult due to (a)
Certificates with only hashed user IDs would be harder to find than
those that contain the actual name and email address. But easier to
find than those that show spurious information or contain no email
address or name at all.
> 4. My suspicion is the number of users covered by (2)
> is pretty small. My suspicion is the number of users
> impacted by (3) is pretty large. My suspicion is we do
> not have a very good handle on just how difficult we
> need to make things, given the resources available to
> spammers in (1a).
After generating the list of possible email addresses, why would a
spammer generate the hashes and search for keys instead of simply
blasting out messages to the whole lot?
- --
Best regards
MFPAmailto:expires2...@ymail.com
Wisdom is a companion to age; yet age may travel alone.
-BEGIN PGP SIGNATURE-
iQE7BAEBCgClBQJNe9McnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf
a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC
OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB
MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pEYMD/3Q/
Qt8LnJvVjv4Bb88jeiMBFxETBKcfkeJsY5u+dICB9lS7JmKzGoR6gzTod/mZdTMV
9+NuLrlDXcOxQfRZTdd38z6YIf6nBgmRSvAxzG7DH/WCxGVoQkChNV13+pY/rf6c
BBFW2gf/DruOyWHh6jN3IV8YDjdM1p1+0NUAgu71
=3R5z
-END PGP SIGNATURE-
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 10 March 2011 at 2:58:32 AM, in , Ben McGinnes wrote: > I have. Many, many times. There's no point doing it > for a free email service provider's domain (e.g. > gmail.com), but sometimes there are advantages in > checking for keys belonging to people at particular > organisations (e.g. government departments). This is > one of the reasons why I'd prefer MFPA's suggestion, > were it ever implemented, to be optional rather than > the default. Whatever you do with user IDs is optional, since they are just a free-text field. And of course a user wanting to make their key match more searches could include extra UIDs with additional hashes. For example John Smith could include hashes of example.com and of john.smith. In any event, including the information in hashed form should make the key more likely to be found than if the info were not there at all. > If that feature weren't available, I doubt I would've > found this: > pub 1024D/B3F77236 2000-09-21 uid > Stephen Smith sub > 2048g/0E0EEE5F 2000-09-21 > Stephen Smith was in Opposition when he made that key, > but now he's Minister of Defence. If there was a point there other than curiosity value, it went way over my head. (-: - -- Best regards MFPAmailto:expires2...@ymail.com COMMITTEE: A body that keeps minutes and wastes hours. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNe8uEnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pbxAEAIAh 17OwkWRD6Y72jkJY3RQxub8ycj2buFKS6F7uTrRKad3yaLbPv7Pmh8NKWs42YZa+ jOflm3L53gAD7slSvSWwE2pzeorIZU/Gz0MWdxXSyJUTTykwZHPzvKMwtPL0nQcJ u76y9Q821KbUfiA2gGVTZQjt7wusRF7NEZK29Bot =QdF0 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 9 March 2011 at 1:46:53 PM, in , Hauke Laging wrote: >If you want to validate a key by its signatures > and see a signature of an unknown key then there is > (IMHO) no reason why you should know who has certified > this key. This information can easily be abused. Information that has no use to you in the task in hand is just "noise." If it is information about me for which you have no legitimate use, I would rather it were not at your disposal in case of possible nefarious use. - -- Best regards MFPAmailto:expires2...@ymail.com Keep them dry and don't feed them after midnight -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNe8LqnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pOl4D/jx2 3yMqLREYequSYhS5lOMyF+i7ItZADI2k74Cj6IzOowSQqrEk2G6wX8xmwI8vBVTP 3VK41B/haudCg9L7B0pQI1YYT2Fjlyb8by1DiN8UOPpq4KJJEt+wvs+oMtq1DmYW w6gJIphvNKu1ZTifXfBZmBsNc4CvCVTe4jLcH4XU =P5Kp -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 10 March 2011 at 1:34:13 PM, in , Robert J. Hansen wrote: > A public certification is intended as an > announcement to the world: "Hey, world! I am [name] > and I vouch for this certificate!" Which most people will hear as "Hey, world! I am somebody you don't know and I vouch for this certificate!" > If people want to make public pronouncements of social > relationship, why in the world would you want to deploy > a technology that makes it difficult to discover this > social relationship? I don't think anything has been suggested here that would make it difficult to discover the social relationship. Just a means to make the public pronouncement without publicly stating your identity. And to do so in such a way that people who already know your identity can tell it is you that made the pronouncement. - -- Best regards MFPAmailto:expires2...@ymail.com Only dead fish go with the flow -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNe73lnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pWrED/jE7 3QaDWRXhk5W5X8/cPvJ0bR8BqceuEND5Cpy+SqrtWO2TxnSH2KxYRiqRm8lr5yuk CMPEvmugRdacynVzg7Smr33H01oSfl/Zi+tPjpMzDsYiKMnMKHwt3WkncqKNvgdW kvbPqU5IJgUVBH5HRad+4YeDUwN1gLa2YVZkfj0Q =gKTd -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Friday 11 March 2011 at 1:54:57 PM, in , Robert J. Hansen wrote: > It is useful to quite a lot of people. Look at how > many people map out webs of trust for entirely innocent > purposes. In fact, mapping out webs of trust is > necessary for the WoT idea to even work. "Well, I've > signed Frank's key and I see that Frank's signed > Gianna's key, and I trust Frank so..." The WoT can be mapped with or without names. In your example, how is your trust enhanced by knowing Gianna's name? "I signed Frank's key and I see that Frank's signed a key that has user ID '7b7581fe6670a6a4a29b2fd46eaf5ac34a6a86d134fe8931729e66970b707349 <466ffe71badce782db1808ee80bd01dabf0d95e4a3b8ccbbe5fcdc68b86c2bb9>', and I trust Frank so..." How does the WoT idea require me to know the names or email addresses associated with the keys in the trust path? The text strings in User IDs do not feature in the trust calculation. >> It's perfectly OK for me that you can see that I have >> signed Ben's key but why should others know that? > Because this is not an ORCON system. The system is > built around public certifications and private > certifications. You're talking about introducing an > entirely new method, something which seems basically > like an ORCON certification: "I'll make the > certification, but I get to control who gets to learn > about the certification." That one sentence quoted in isolation from Hauke could be construed in that way. But take into account the context and it becomes clear that he was saying no such thing. A certification made by a key that had hashed user IDs would be just as visible as any other certification. What would not be visible (at least to people who didn't already know it) is the identity and email address of the certifying key's owner. - -- Best regards MFPAmailto:expires2...@ymail.com A nod is as good as a wink to a blind bat! -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNe7X4nhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pGoQD/jR0 q47WKypv3KVj2prv09mYxLKbYakIPSR4wF57LoEMOg0J3WpD6ceGURsWJX8lovDv ii4VHB3jcGWgupYa0EzsOYGxZviHVWi+TNgblNHEcsUH4+ucIHqoh6nRoyWrOUGD 2C/ojDYkipYM+ISTWq9cSgHv+hiV1EgY8HlOPKf2 =aYPX -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 10 March 2011 at 1:18:36 PM, in , Robert J. Hansen wrote: > Remember that a jury trial is often not so much about > the law as it is about blame: if something bad happens > the jury wants to be able to point at someone and say, > "that person is responsible." Determining whether it has been proven beyond reasonable doubt that the defendant is guilty as charged has nothing to do with the apportionment of blame. - -- Best regards MFPAmailto:expires2...@ymail.com The best way to destroy your enemy is to make him your friend. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNe6WenhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pRfMD/iw2 OXYwUxfEbX1kBJanilJCHCJywTXapANwqeM3IoToOS2vq5Z/n9YRlGLjMjmUS7W4 rrQsG1wlGKpTIOTLtb9B9CsheVirEE+kX5b2zEG0ZdVkQG536t0nvUpCo+3pfOvo f2bUAzLr+p+XNCIW66ev/B8iITGV2l6/4Xxf1HmL =GJI3 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Ben McGinnes wrote: > On 12/03/11 12:33 AM, Robert J. Hansen wrote: >> On 3/11/2011 1:07 AM, Ben McGinnes wrote: >>> Out of curiosity, how big is that now? >> >> My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large. > > That's smaller than I would have thought, but a *lot* larger than the > last time I checked (sometime in the '90s). Ben, That's the SKS implementation of the key database. On top of the keys, there are several other tables. Within each table there is also empty space, most commonly space left at the end of a page. The present size of just the raw keys -- like you would pull in a keydump to bootstrap a server -- is 4.38 GB -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Ben McGinnes wrote: > On 11/03/11 12:10 AM, Robert J. Hansen wrote: >> >> Not at all. Every few days the keyserver network posts complete dumps >> of all the certificates in the system. (Or, more accurately, various >> people within the network do.) This exists so that new volunteers who >> want to contribute their services to the community can get their own >> servers bootstrapped. > > Out of curiosity, how big is that now? Checking both of my keyservers: Total number of keys: 2922831 http://sks.keyservers.net:11371/pks/lookup?op=stats @ 2011-03-12 00:00:46 CST http://keyserver.gingerbear.net:11371/pks/lookup?op=stats @ 2011-03-12 00:00:06 CST 103 servers (from http://www.sks-keyservers.net/status/) 64 active in the pool, 39 excluded from the pool (for various reasons) -- John P. Clizbe Inet: John (a) Enigmail DAWT net FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-k...@gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/11/11 2:48 PM, Johan Wevers wrote: > How much of that is repeated automated signatures from the pgp > keyserver? Don't know, but it would be an interesting thing to test. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On Mar 11, 2011, at 8:33 AM, Robert J. Hansen wrote: > On 3/11/2011 1:07 AM, Ben McGinnes wrote: >> Out of curiosity, how big is that now? > > My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large. That's the on-disk SKS database format, and so contains a good bit of non-key data and other inefficiencies. A dump of just key data is around 3.5G nowadays. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 11-03-2011 14:33, Robert J. Hansen wrote: > My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large. How much of that is repeated automated signatures from the pgp keyserver? -- Met vriendelijke groet, Johan Wevers ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 12/03/11 12:33 AM, Robert J. Hansen wrote: > On 3/11/2011 1:07 AM, Ben McGinnes wrote: >> Out of curiosity, how big is that now? > > My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large. That's smaller than I would have thought, but a *lot* larger than the last time I checked (sometime in the '90s). Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/10/2011 3:09 PM, Hauke Laging wrote: > That's the technical situation today. But it is no use to announce > that to the whole world. (Did you mean "not necessary" instead of "no use"?) It is useful to quite a lot of people. Look at how many people map out webs of trust for entirely innocent purposes. In fact, mapping out webs of trust is necessary for the WoT idea to even work. "Well, I've signed Frank's key and I see that Frank's signed Gianna's key, and I trust Frank so..." > It is required only for those people who use your signature in a > validation chain. How do you propose determining who really needs those signatures for validation purposes and who doesn't? And once you've made that determination, how do you enforce it? Those are the two major, outstanding questions, and so far I've not seen any serious attempts at answering them. It seems this discussion is stuck at the stage of "it would be nice if we all had ponies," without any real answers to questions of "so where will we get the real estate to house the ponies?" and "who among us is an equine veterinarian?" > b) nobody who really wants to inform the whole world is in any way > affected in doing that. I don't know how to respond to this: since we don't have a workable proposal for how to accomplish your objectives, we also can't discuss how your proposal will affect existing users. > It's perfectly OK for me that you can see that I have signed Ben's > key but why should others know that? Because this is not an ORCON system. The system is built around public certifications and private certifications. You're talking about introducing an entirely new method, something which seems basically like an ORCON certification: "I'll make the certification, but I get to control who gets to learn about the certification." ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/11/2011 1:07 AM, Ben McGinnes wrote: > Out of curiosity, how big is that now? My complete /var/lib/sks/DB directory comes in at 7.8G. Not too large. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 11/03/11 7:44 AM, Daniel Kahn Gillmor wrote: > > If you want to keep the fact that one keyholder has verified another > keyholder's identity secret, you cannot solve that by obscuring the > User IDs. > > The right way to solve that is with non-exportable OpenPGP > certifications, which must be passed between users explicitly. Ah, this is what I've been looking around for! For the sake of the archives, how does one provide a non-exportable certification? Obviously the export flag won't cut it. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10/03/11 9:23 PM, Hauke Laging wrote:
> Am Donnerstag 10 März 2011 06:17:25 schrieb Robert J. Hansen:
>
>> while you could conceivably come up with an email address with high
>> enough entropy, it's easier to just use anonymous services and
>> dead-drop emails.
>
> Of course, you can create a key with UIDs without name and email
> only but such keys are not very comfortable to have in your keyring
> ("What's that?").
There's nothing stopping you from creating an alternate gpg.conf file
(invoked via the --options flag) which points to different default
keys and even alternate keyrings. Put the entire lot in a TrueCrypt
volume and when it's not in use, people won't be able to decrypt
enough to know about the alternate identities.
> Of course, you can add a UID annotation feature without having the
> hashing feature. But not having the hashing feature makes it more
> difficult to get the key (and key updates).
Not necessarily. You can put anything you like in the UID and people
can search on that. Just running "gpg --search-keys
alt.anonymous.messages" should show a good list of keys where people
have done exactly that over the years.
> Keyserver access is pretty anonymous. If you put keys on a website
> (the address of which the one can have given you who gave you the
> non- public email address) then that is another way to try to reveal
> the identity of the communication partner.
There are plenty of ways to reveal the identity of of correspondents
unless a certain amount of effort has been put into anonymising the
transmission. Anyone wanting to do this (including just to play
around and see how it works) would be well served by looking into Tor
and remailers.
> I appreciate your effort to consider the problem as a whole. It
> would be a pity to create something that turns out to be useless in
> the end.
Yes and it would be dangerous to create something which instills a
false sense of security. This hashing idea is an interesting method
of preventing the revelation of a given identity (real or
pseudonymous) from a casual observer, but it does not prevent a number
of things which enable that information to be determined, including
traffic analysis.
> But that is not a problem here any longer: Those people who just
> want to protect their social connections by signing other keys
> without revealing their identity to those who don't know it already
> have no need to cover their target addresses because the marketing
> people and "just curious" normal ones are not capable of reading
> their email traffic. So there already is a use case. Your objections
> for the high security cases are very good to raise awareness but
> point outside the gnupg sphere.
The thing is, the hashed UID idea isn't attempting to address an issue
with GPG per se. It's attempting to address an issue with privacy of
identity in a larger context; to whit, by attempting to conceal names
and social connections as they are displayed as UIDs and signatures or
certificates. There are other ways to obtain this information, even
without utilising GPG or examining the body of a message. Traffic
analysis alone reveals far more than who may have signed someone's key
at some point in time.
> You made a brute force calculation. Why should keyservers allow
> brute force searches for hash IDs? If you use millions of remotely
> controlled idiot PCs simultaneously for that then it may be hard to
> track them but then we are close to a DoS, aren't we?
Robert's already covered this pretty well.
Regards,
Ben
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 11/03/11 12:10 AM, Robert J. Hansen wrote: > > Not at all. Every few days the keyserver network posts complete dumps > of all the certificates in the system. (Or, more accurately, various > people within the network do.) This exists so that new volunteers who > want to contribute their services to the community can get their own > servers bootstrapped. Out of curiosity, how big is that now? Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
If one really wanted to overthrow the "People's Republic of Berkeley," using obfuscated e-mail addresses with the proposed methods outlined in this thread would be akin to inventing a solution for a problem that doesn't exist. There are already numerous methods for off-the-record encrypted communications. Indeed, OTR was to devised as a protocol that allows encrypted and authenticated communications without having to be a slave to an interminable digital signature that might come back to haunt you. As for remaining anonymous, one can merely connect to the IM server via Tor or some other similar method. Or one could even run their own P2P IM software like XMPP thus cutting out the middle man. Another option is a hidden .onion IRC service or a SILC chat conference. If one is really bent on using e-mail, one can merely create a throw-away address using Tor and then create a throw-away GPG key. There are numerous ways to do this already. OpenPGP's goal is not anonymity or deniability. If you want that, there's better protocols and methods as Robert Hansen has hinted at already. -- View this message in context: http://old.nabble.com/Security-of-the-gpg-private-keyring--tp31031263p31114600.html Sent from the GnuPG - User mailing list archive at Nabble.com. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 03/10/2011 03:09 PM, Hauke Laging wrote: > You have validated my key (among others) and I (among others) have validated > Ben's. Now you want to validate Ben's key indirectly. Ben's key has ten > signatures, the one by my key is the only one usable for you. The next person > who tries to validate find another signature useful. It's perfectly OK for me > that you can see that I have signed Ben's key but why should others know > that? > Why should you be able to find out who are the other ones who have made > signatures for Ben's key? > > I would make a local signature if I would not want to let anyone know that I > have verified the key. But in that case you could not verify Ben's key what I > am willing to enable. The motto is: Don't reveal more than necessary. You > have > to reveal something in order to make the whole thing work but you don't have > to reveal all. How does hashed user IDs address this particular question? You don't need to care about the User IDs on keys if you just want to map relationships. If i'm mapping relationships, and i decide from that mapping that a particular keyholder is "interesting", *then* the hashed User IDs might become a minor stumbling block in my figuring out who the keyholder is in the "real world". But the point of User IDs is to bind human-intelligible (and therefore likely low-entropy) "real world" information to keys. So if i have reasonable computer resources at my disposal, reversing the digest of low-entropy material seems like a possibility. If you want to keep the fact that one keyholder has verified another keyholder's identity secret, you cannot solve that by obscuring the User IDs. The right way to solve that is with non-exportable OpenPGP certifications, which must be passed between users explicitly. For example: "Hi Bob, I'm Alice. Charles vouches for my identity as you can see from this non-exportable cert." In this example, Charles does not want the world to know that he has certified Alice's key. But he's willing to let Alice decide who knows this information, so he gives her a copy of his non-exportable cert. After Alice has introduced herself to Bob this way, both B and A know about the C->A certification, but the rest of the world is still at a loss. either B or A could share this certificate with anyone else, of course. It's out of C's hands as soon as he gave a copy of the non-exportable cert to A. --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Am Donnerstag 10 März 2011 14:34:13 schrieb Robert J. Hansen: > On 3/10/2011 5:23 AM, Hauke Laging wrote: > > ]Those people who just want to protect their > > social connections by signing other keys without revealing their identity > > to those who don't know it already have no need to cover their target > > addresses because the marketing people and "just curious" normal ones are > > not capable of reading their email traffic. So there already is a use > > case. > Certifications come in two basic varieties: public and private. A > public certification is intended as an announcement to the world: "Hey, > world! I am [name] and I vouch for this certificate!" That's the technical situation today. But it is no use to announce that to the whole world. It is required only for those people who use your signature in a validation chain. Everyone else does not need (and probably not use) the signature so there is no benefit for exposing the connection (though unclear) between the key owner and the certifier. > If people want to make public pronouncements of social relationship, why > in the world would you want to deploy a technology that makes it > difficult to discover this social relationship? I want to deploy this technology because a) this is in my strong opinion not what people WANT (it's just what they DO because there is neither much awareness for the problem nor a usable alternative) b) nobody who really wants to inform the whole world is in any way affected in doing that. > This doesn't make any sense to me. Quite possibly I have completely > misunderstood what you're arguing. May be a language problem, sorry. I'll try with an example: You have validated my key (among others) and I (among others) have validated Ben's. Now you want to validate Ben's key indirectly. Ben's key has ten signatures, the one by my key is the only one usable for you. The next person who tries to validate find another signature useful. It's perfectly OK for me that you can see that I have signed Ben's key but why should others know that? Why should you be able to find out who are the other ones who have made signatures for Ben's key? I would make a local signature if I would not want to let anyone know that I have verified the key. But in that case you could not verify Ben's key what I am willing to enable. The motto is: Don't reveal more than necessary. You have to reveal something in order to make the whole thing work but you don't have to reveal all. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10-03-2011 2:12, Jeffrey Walton wrote: > Imagine you are Tunisian or Libyan or some other nationality where > disagreeing with the regime might get you killed. Would you want your > name and email associated with another's keyring? I would not sign any key in that case. Even more, I would not sign any email so the regime could prove I wrote it. I would only encrypt them. > Or would you prefer anonymity? Of course. -- Met vriendelijke groet, Johan Wevers ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/10/2011 5:23 AM, Hauke Laging wrote: > ]Those people who just want to protect their > social connections by signing other keys without revealing their identity to > those who don't know it already have no need to cover their target addresses > because the marketing people and "just curious" normal ones are not capable > of > reading their email traffic. So there already is a use case. You've just described the use case for a local certification. Certifications come in two basic varieties: public and private. A public certification is intended as an announcement to the world: "Hey, world! I am [name] and I vouch for this certificate!" If people want to make public pronouncements of social relationship, why in the world would you want to deploy a technology that makes it difficult to discover this social relationship? This doesn't make any sense to me. Quite possibly I have completely misunderstood what you're arguing. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/10/2011 4:57 AM, Hauke Laging wrote: > A little practical advantage: If gpg had such a feature then the > documentation may mention everything that is needed additionally > (depending on the targetet opponent: spammers, facebook-alikes, > secret police) or useful. Someone would have to be crazy to write this. The product liability lawsuits alone would be daunting. Remember that a jury trial is often not so much about the law as it is about blame: if something bad happens the jury wants to be able to point at someone and say, "that person is responsible." If I were to write this, it wouldn't matter how big of a disclaimer I put on the cover page: I would live in fear of someone hauling me into court to say, "Ladies and gentlemen of the jury, I followed his instructions and I got to spend six weeks discovering what my own liver tasted like. I blame him for the fact I was captured and tortured by the secret police." This also doesn't get into the problem of there being so astonishingly few people on the list -- quite possibly *zero* people on the list -- who are competent to write such a thing. A good rule of thumb in crypto is to never trust ciphers designed by people who haven't first earned their bones by breaking them. The same applies to countersurveillance and tradecraft: don't take advice from people who haven't first proven their abilities at finding people who really, really don't want to be found. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/10/2011 5:23 AM, Hauke Laging wrote: > You made a brute force calculation. Why should keyservers allow brute force > searches for hash IDs? If you use millions of remotely controlled idiot PCs > simultaneously for that then it may be hard to track them but then we are > close to a DoS, aren't we? Not at all. Every few days the keyserver network posts complete dumps of all the certificates in the system. (Or, more accurately, various people within the network do.) This exists so that new volunteers who want to contribute their services to the community can get their own servers bootstrapped. If I want to brute-force the certificates, I'd just say, "hey, I'm interested in standing up a new keyserver," get a dump of all the certs, and then do the brute forcing on my own system without ever needing to hit the network. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10/03/11 12:46 AM, Hauke Laging wrote: > > There are several advantages: > > 1) You don't reveal the social connections by signing keys. If you > want to validate a key by its signatures and see a signature of an > unknown key then there is (IMHO) no reason why you should know who > has certified this key. This information can easily be abused. The > perfect web of trust would be the perfect source of information > which should be considered private (who knows whom). This problem is > hardly reduced by the fact that there are signatures (from key > signing parties) from people without real social or commercial > contact. I can certainly see where a number of people would be interested in this aspect, while those people wishing to publicly announce that they've signed particular keys can do so by not utilising the hashing. > 2) For people in countries where authorities' rights and actions are > not as easily ruled unconstitutional like in Germany (or not at all) > it is useful if not only the content of their communication is > hidden but also the identity of the communication partners (even of > those in free countries). This is, of course, more complex than > hashing a key ID, thus I am not sure how important this feature > would be (as you have to hide the partner's email address or the > connection to the identity and these email addresses have both to be > kept secret (because you can easily hash all "publicly available" > addresses) and to be complex enough not to be guessed; this may > result in greatnesses like sqq8ctpmbf81yucw8nzwb...@hauke-laging.de). This, can only really work for the identities associated with a given key. At the end of the day, Alice still has to send an email to Bob and a truly determined adversary who can intercept that email can at least derive the key IDs the message is encrypted to. Unless that (incredibly annoying) feature of checking all secret keys is enabled, of course. I've forgotten what the option is called. > In general it is useful for a web of trust to have long living > keys. Email addresses are more easily changed than keys. Yeah, well, I got so sick of changing my email address that I got my own domain name (no, that wasn't the only reason). > 3) You prevent spammers from using keyservers as a source. Yes, I am > aware that certain people on this list don't accept this as an > argument (for different reasons). The most important point for this > question is probably that the infrastructure has to be safe BEFORE > it gets so big that it becomes interesting for spammers. With the way most spammers operate, I think this is of little effect until such a time as the majority of global email users have keys on the keyservers. Most spammers just generate usernames at a target domain name. At least that's what my Postfix logs indicate. >> Another reason why we all love Germany now. ;) > > According to a new study it has the best worldwide image of all > relevant countries worldwide. However. :-) There's nothing quite like an unnamed report to back up a nebulous claim. It's probably right, though, albeit only because Iceland is so bloody cold. ;) Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Am Donnerstag 10 März 2011 06:17:25 schrieb Robert J. Hansen:
> while you could conceivably come up with an
> email address with high enough entropy, it's easier to just use
> anonymous services and dead-drop emails.
Of course, you can create a key with UIDs without name and email only but such
keys are not very comfortable to have in your keyring ("What's that?"). Of
course, you can add a UID annotation feature without having the hashing
feature.
But not having the hashing feature makes it more difficult to get the key (and
key updates). Keyserver access is pretty anonymous. If you put keys on a
website (the address of which the one can have given you who gave you the non-
public email address) then that is another way to try to reveal the identity
of the communication partner.
I appreciate your effort to consider the problem as a whole. It would be a
pity to create something that turns out to be useless in the end. But that is
not a problem here any longer: Those people who just want to protect their
social connections by signing other keys without revealing their identity to
those who don't know it already have no need to cover their target addresses
because the marketing people and "just curious" normal ones are not capable of
reading their email traffic. So there already is a use case. Your objections
for the high security cases are very good to raise awareness but point outside
the gnupg sphere.
You made a brute force calculation. Why should keyservers allow brute force
searches for hash IDs? If you use millions of remotely controlled idiot PCs
simultaneously for that then it may be hard to track them but then we are
close to a DoS, aren't we?
Hauke
--
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Am Donnerstag 10 März 2011 04:42:25 schrieb Ben McGinnes: > Which brings us back to creating a pseudonym, using Tor (or other > anonymising services), getting a disposable mail drop (or using > alt.anonymous.messages) and going from there. At the bare minimum. A little practical advantage: If gpg had such a feature then the documentation may mention everything that is needed additionally (depending on the targetet opponent: spammers, facebook-alikes, secret police) or useful. Then people in a bad situation (which are probably no security experts) had a trustworthy source of information for planning their communication strategy. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10/03/11 4:17 PM, Robert J. Hansen wrote: > On 3/9/2011 10:42 PM, Ben McGinnes wrote: >> Which brings us back to creating a pseudonym, using Tor (or other >> anonymising services), getting a disposable mail drop (or using >> alt.anonymous.messages) and going from there. At the bare minimum. > > Which brings us back to the elephant in the middle of the room: as > far as I can see there's no consensus on a use case for this > feature. Certainly not that I've seen, I just like exploring ideas that seem interesting or which may lead to other ideas. I have, however, discussed this one at length with MFPA on another list (which one or two other readers here can attest to). > Some people have a knee-jerk reaction to their email addresses being > in any searchable database and want their emails obfuscated. Meh. I'm not in that camp, that horse has well and truly bolted. Besides, anyone who just knows my name and domain can easily guess which addresses will work for me. > Against this threat, the proposed feature doesn't work: email > addresses don't offer enough entropy and the mechanism could be > brute-forced. > Some people think they're going to take over the People's Republic > of Berkeley in a military coup and need to be able to deny their > connections to each other. Against this threat, the proposed > feature doesn't work very well: while you could conceivably come up > with an email address with high enough entropy, it's easier to just > use anonymous services and dead-drop emails. Which, for those people who need to attain a certain degree of deniability, this already works very well. > Has a use case been articulated for this feature, along with how > this feature would substantially advance the use case? Because if > not, one really needs to be. I'd like to cede the floor to MFPA for this one. If he doesn't, I suppose I can trawl through my PGPNET folder and find our discussion. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10/03/11 4:20 PM, Robert J. Hansen wrote: >> Some people think they're going to take over the People's Republic of >> Berkeley in a military coup > > Idiom note for non-Americans: the University of California at Berkeley > is often called, tongue-in-cheek, "the People's Republic of Berkeley." > This is a (hopefully humorous) reference to having a military coup > taking over a college campus. There hasn't been one of those since Kent State. ;) Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
> Some people think they're going to take over the People's Republic of > Berkeley in a military coup Idiom note for non-Americans: the University of California at Berkeley is often called, tongue-in-cheek, "the People's Republic of Berkeley." This is a (hopefully humorous) reference to having a military coup taking over a college campus. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/9/2011 10:42 PM, Ben McGinnes wrote: > Which brings us back to creating a pseudonym, using Tor (or other > anonymising services), getting a disposable mail drop (or using > alt.anonymous.messages) and going from there. At the bare minimum. Which brings us back to the elephant in the middle of the room: as far as I can see there's no consensus on a use case for this feature. Some people have a knee-jerk reaction to their email addresses being in any searchable database and want their emails obfuscated. Against this threat, the proposed feature doesn't work: email addresses don't offer enough entropy and the mechanism could be brute-forced. Some people think they're going to take over the People's Republic of Berkeley in a military coup and need to be able to deny their connections to each other. Against this threat, the proposed feature doesn't work very well: while you could conceivably come up with an email address with high enough entropy, it's easier to just use anonymous services and dead-drop emails. Has a use case been articulated for this feature, along with how this feature would substantially advance the use case? Because if not, one really needs to be. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10/03/11 2:10 PM, Robert J. Hansen wrote: > > I think it should also be noted that if I was serious about trying to > overthrow a government, I'd create a bare certificate without a name or > an email address on it. I'd also use it as infrequently as possible and > try to avoid any technology more complicated than, say, a wheel, lever, > or inclined plane. Heh. Trying to topple any government is definitely on the hazardous side of things. In general they're either large enough to have enormous resources to track you down or small and dodgy enough to just send a hit team. Or both. > GnuPG will not keep your communications secure against major adversaries > who are willing to torture you for so long you think you've made an > unfortunate lateral career move. It's just a tool in the toolbox. > You're going to need the rest of the toolbox, too. Which brings us back to creating a pseudonym, using Tor (or other anonymising services), getting a disposable mail drop (or using alt.anonymous.messages) and going from there. At the bare minimum. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/9/2011 10:01 PM, Ben McGinnes wrote: >> Imagine you are Tunisian or Libyan or some other nationality where >> disagreeing with the regime might get you killed. Would you want >> your name and email associated with another's keyring? Or would you >> prefer anonymity? > > Another perfectly good reason for wanting to conceal identifying > information. There are, no doubt, plenty. I think it should also be noted that if I was serious about trying to overthrow a government, I'd create a bare certificate without a name or an email address on it. I'd also use it as infrequently as possible and try to avoid any technology more complicated than, say, a wheel, lever, or inclined plane. GnuPG will not keep your communications secure against major adversaries who are willing to torture you for so long you think you've made an unfortunate lateral career move. It's just a tool in the toolbox. You're going to need the rest of the toolbox, too. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10/03/11 12:12 PM, Jeffrey Walton wrote: > > Imagine you are Tunisian or Libyan or some other nationality where > disagreeing with the regime might get you killed. Would you want > your name and email associated with another's keyring? Or would you > prefer anonymity? Another perfectly good reason for wanting to conceal identifying information. There are, no doubt, plenty. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10/03/11 11:03 AM, Hauke Laging wrote: > Am Mittwoch 09 März 2011 14:39:35 schrieb Robert J. Hansen: > > As we all know you love anecdotal evidence, here's mine: You are > probably right but consider two points: > > 1) Today there is no use in obeying the (2) rules. If such a feature > is implemented then those who are interested in using it will > consider creating new email addresses according to (2). Nonetheless > the number of interested users may be small (but increasing with > increasing public attention to privacy problems besides reading mail > contents). I'd agree with this. There are enough increases in prying eyes from governments and corporations for more and more people to consider such obfuscation warranted or warranted under some circumstances. >> My suspicion is the number of users impacted by (3) is pretty large. > > I have never done that. I cannot iamagine why this should be > important to anyone. You know which email address you are going to > write to, don't you? OpenPGP should not prevent new features > because somebody abuses the infrastructure as a kind of address > book. I have. Many, many times. There's no point doing it for a free email service provider's domain (e.g. gmail.com), but sometimes there are advantages in checking for keys belonging to people at particular organisations (e.g. government departments). This is one of the reasons why I'd prefer MFPA's suggestion, were it ever implemented, to be optional rather than the default. If that feature weren't available, I doubt I would've found this: pub 1024D/B3F77236 2000-09-21 uid Stephen Smith sub 2048g/0E0EEE5F 2000-09-21 Stephen Smith was in Opposition when he made that key, but now he's Minister of Defence. > More important: Not everyone is going to do this. Those people who > regard it important to protect their addresses and names really > don't care about convenience (if the alternative is omitting the > feature). In the mean time, those who would be more likely to do this end up creating pseudonymous accounts and separate keys for each case they wish to deal with. > It might make sense to print a warning if a user activates this > hashing feature for a UID with an email address which is obviously > not brute force safe. Good idea. > And in contrast to Werner I do believe that signatures are going to > kill the spam problem one day. :-) Ah, but will that be in our lifetimes? I don't know how much effect that will really have on spam, but I can see signatures helping to prevent things like this: https://secure.wikimedia.org/wikipedia/en/wiki/Utegate Following the revelation that the email at the centre of the scandal had been faked by Godwin Grech, I did email my MP suggesting they start using OpenPGP signatures. Apparently the DSD had cleared OpenPGP compliant software for use by government departments years ago, but it was up to each department to decide whether or not to use them. Presumably Treasury and the Department of the Prime Minister and Cabinet chose not to. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10/03/11 12:39 AM, Robert J. Hansen wrote: > > 4. My suspicion is the number of users covered by (2) is pretty > small. Very probably, at least at the moment (for the reasons Hauke mentioned). > My suspicion is the number of users impacted by (3) is pretty large. Almost certainly. > My suspicion is we do not have a very good handle on just how > difficult we need to make things, given the resources available to > spammers in (1a). I don't really think the spamming scenario is of great concern. Spammers get email addresses from plenty of other methods and there are better ways to stop spam than preventing your email address from being posted somewhere, including a keyserver. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 10/03/11 12:24 AM, Robert J. Hansen wrote: > > It seems like this is really close to asking for private stream > searching, which would be the next logical step -- some way for the > client to query the database for a record in such a way there is no > way for the database to know what was queried. That seems unnecessary. The conversion of a search string to a hash can be performed locally and the hash can then be passed to the keyserver. If there is a match, the key can be retrieved or updated and since a specific key will be requested there is no need to conceal the search parameters further. > This may sound alluring, but it's an ephemera. The current > best-known PSS algorithm requires about one zebibyte of traffic to > do a ten-character ASCII search. Wow, that would certainly kill my pissant little DSL connection. > These sorts of blinded searches are really tempting, but there are > enormous theoretical hurdles to be cleared. I would respectfully > suggest that if any discussion moves to PSS-type functionality, that > discussion be headed off at the pass. :) Yep, fair enough. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On Wed, Mar 9, 2011 at 8:11 AM, Ben McGinnes wrote: > On 9/03/11 2:44 AM, Johan Wevers wrote: >> MFPA schreef: >> > Something that would not be necessary if the > underlying openPGP implementations could handle hashed > user IDs. >>> Isn't it much easier to use the key ID / signature for that? You already have that. >>> >>> I don't understand. >> >> Use the keyID / signature as the hashed user ID, since it (should) >> uniquely identify the key. Since a hash is one way you can't derive >> the email address from it anyway, from the keyID you also can't >> (directly) deduce the email address. > > Ah, but the keyID can already be used to locate a key, that's not what > MFPA is getting at. What he wants is a function built into GPG and > the keyservers, possibly via some kind of proxy tool, to do this: > > * User generates a key, when prompted for a name enters "Joe Citizen" > and when prompted for an email address enters "j...@example.net" > > * GPG or interface for it takes those strings and generates a hash > (let's use SHA256 for this example) so the UID for the key appears > to be: > "7b7581fe6670a6a4a29b2fd46eaf5ac34a6a86d134fe8931729e66970b707349 > <466ffe71badce782db1808ee80bd01dabf0d95e4a3b8ccbbe5fcdc68b86c2bb9>" > > * Anyone trawling through keys on a public server or downloading > random keys cannot see who owns that key or what their email address > is, but anyone who knows Joe or his email address can search the > keyservers for that data because the hash can be calculated from the > data they do have (e.g. j...@example.net) and search for the key with > the matching hash. > > This would allow someone to use a single key for multiple identities > or pseudonyms, without the information about those identities being > learned by different groups. Well, probably not. > > Personally, I think it's an interesting idea and I can see the value > in it, but I'm not sure there are enough people really pushing for it > (yet). With things like the data retention legislation being pushed > in Europe, Australia and other countries, that may change. > Imagine you are Tunisian or Libyan or some other nationality where disagreeing with the regime might get you killed. Would you want your name and email associated with another's keyring? Or would you prefer anonymity? Jeff ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Am Mittwoch 09 März 2011 14:39:35 schrieb Robert J. Hansen:
> 2. To really gain benefit from this scheme, you must:
>
> (a) have a non-trivially-brute-forceable email address
> (b) want to be able to hide your email address
> 3. Deploying this scheme means:
>
> (a) people can no longer do fuzzy searches for email
> addresses ("show me all user IDs that look like this
> pattern")
> (b) finding people's certificates may be made more
> difficult due to (a)
>
> 4. My suspicion is the number of users covered by (2) is pretty small.
As we all know you love anecdotal evidence, here's mine: You are probably
right but consider two points:
1) Today there is no use in obeying the (2) rules. If such a feature is
implemented then those who are interested in using it will consider creating
new email addresses according to (2). Nonetheless the number of interested
users may be small (but increasing with increasing public attention to privacy
problems besides reading mail contents).
2) gpg offers a lot of features which I guess are used (and even known) by a
small share of its users. Nonetheless they got implemented. Obviously the main
argument is not the number of users but the quality of the software. There is
a whole section "Doing things one usually doesn't want to do." in the man
page. I guess it contains more than 80 options.
> My suspicion is the number of users impacted by (3) is pretty large.
I have never done that. I cannot iamagine why this should be important to
anyone. You know which email address you are going to write to, don't you?
OpenPGP should not prevent new features because somebody abuses the
infrastructure as a kind of address book.
More important: Not everyone is going to do this. Those people who regard it
important to protect their addresses and names really don't care about
convenience (if the alternative is omitting the feature).
It might make sense to print a warning if a user activates this hashing
feature for a UID with an email address which is obviously not brute force
safe.
And in contrast to Werner I do believe that signatures are going to kill the
spam problem one day. :-)
Hauke
--
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Am Mittwoch 09 März 2011 14:11:16 schrieb Ben McGinnes: This discussion has been there before (initiated once by me). > This would allow someone to use a single key for multiple identities > or pseudonyms, without the information about those identities being > learned by different groups. Well, probably not. There are several advantages: 1) You don't reveal the social connections by signing keys. If you want to validate a key by its signatures and see a signature of an unknown key then there is (IMHO) no reason why you should know who has certified this key. This information can easily be abused. The perfect web of trust would be the perfect source of information which should be considered private (who knows whom). This problem is hardly reduced by the fact that there are signatures (from key signing parties) from people without real social or commercial contact. 2) For people in countries where authorities' rights and actions are not as easily ruled unconstitutional like in Germany (or not at all) it is useful if not only the content of their communication is hidden but also the identity of the communication partners (even of those in free countries). This is, of course, more complex than hashing a key ID, thus I am not sure how important this feature would be (as you have to hide the partner's email address or the connection to the identity and these email addresses have both to be kept secret (because you can easily hash all "publicly available" addresses) and to be complex enough not to be guessed; this may result in greatnesses like sqq8ctpmbf81yucw8nzwb...@hauke-laging.de). In general it is useful for a web of trust to have long living keys. Email addresses are more easily changed than keys. 3) You prevent spammers from using keyservers as a source. Yes, I am aware that certain people on this list don't accept this as an argument (for different reasons). The most important point for this question is probably that the infrastructure has to be safe BEFORE it gets so big that it becomes interesting for spammers. > Another reason why we all love Germany now. ;) According to a new study it has the best worldwide image of all relevant countries worldwide. However. :-) Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/9/2011 8:11 AM, Ben McGinnes wrote:
> * Anyone trawling through keys on a public server or downloading
> random keys cannot see who owns that key or what their email address
> is, but anyone who knows Joe or his email address can search the
> keyservers for that data because the hash can be calculated from the
> data they do have (e.g. j...@example.net) and search for the key with
> the matching hash.
There are a couple of major problems here:
1. There's not all that much entropy in an email address. Let's say
that I want to harvest email addresses. I create a list of, say, the
top thousand email providers in the world, and then every five-character
lowercase username. For each five-character lowercase username, compute
the hash for that user name at each of the top thousand email providers.
For each hash, look it up in the database. Total work factor: about 11
billion hashes have to be made, probably under a terabyte of data --
very practical.
(a) And don't forget that with services like Amazon's cloud,
massive data crunching distributed across hundreds of
machines costs a few pennies per processor-hour. This
has the potential to ruin your entire day: cloud computing
shifts the fulcrum of computational leverage *immensely*.
2. To really gain benefit from this scheme, you must:
(a) have a non-trivially-brute-forceable email address
(b) want to be able to hide your email address
If you don't care ("b" fails), then this scheme is just an
inconvenience. If you have a brute-forceable email address ("a" fails),
then this scheme offers no benefit.
3. Deploying this scheme means:
(a) people can no longer do fuzzy searches for email
addresses ("show me all user IDs that look like this
pattern")
(b) finding people's certificates may be made more
difficult due to (a)
4. My suspicion is the number of users covered by (2) is pretty small.
My suspicion is the number of users impacted by (3) is pretty large.
My suspicion is we do not have a very good handle on just how difficult
we need to make things, given the resources available to spammers in (1a).
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/9/2011 8:11 AM, Ben McGinnes wrote:
> Personally, I think it's an interesting idea and I can see the value
> in it, but I'm not sure there are enough people really pushing for it
> (yet). With things like the data retention legislation being pushed
> in Europe, Australia and other countries, that may change.
It seems like this is really close to asking for private stream
searching, which would be the next logical step -- some way for the
client to query the database for a record in such a way there is no way
for the database to know what was queried. This may sound alluring, but
it's an ephemera. The current best-known PSS algorithm requires about
one zebibyte of traffic to do a ten-character ASCII search.
These sorts of blinded searches are really tempting, but there are
enormous theoretical hurdles to be cleared. I would respectfully
suggest that if any discussion moves to PSS-type functionality, that
discussion be headed off at the pass. :)
("Private searching on streaming data" by R. Ostrovsky: PDF available at
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.78.631&rep=rep1&type=pdf
).
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 9/03/11 2:44 AM, Johan Wevers wrote: > MFPA schreef: > Something that would not be necessary if the underlying openPGP implementations could handle hashed user IDs. >> >>> Isn't it much easier to use the key ID / signature for >>> that? You already have that. >> >> I don't understand. > > Use the keyID / signature as the hashed user ID, since it (should) > uniquely identify the key. Since a hash is one way you can't derive > the email address from it anyway, from the keyID you also can't > (directly) deduce the email address. Ah, but the keyID can already be used to locate a key, that's not what MFPA is getting at. What he wants is a function built into GPG and the keyservers, possibly via some kind of proxy tool, to do this: * User generates a key, when prompted for a name enters "Joe Citizen" and when prompted for an email address enters "j...@example.net" * GPG or interface for it takes those strings and generates a hash (let's use SHA256 for this example) so the UID for the key appears to be: "7b7581fe6670a6a4a29b2fd46eaf5ac34a6a86d134fe8931729e66970b707349 <466ffe71badce782db1808ee80bd01dabf0d95e4a3b8ccbbe5fcdc68b86c2bb9>" * Anyone trawling through keys on a public server or downloading random keys cannot see who owns that key or what their email address is, but anyone who knows Joe or his email address can search the keyservers for that data because the hash can be calculated from the data they do have (e.g. j...@example.net) and search for the key with the matching hash. This would allow someone to use a single key for multiple identities or pseudonyms, without the information about those identities being learned by different groups. Well, probably not. Personally, I think it's an interesting idea and I can see the value in it, but I'm not sure there are enough people really pushing for it (yet). With things like the data retention legislation being pushed in Europe, Australia and other countries, that may change. Not that Werner has to worry since he's in Germany and they ruled that the data retention legislation was unconstitutional. Another reason why we all love Germany now. ;) Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
MFPA schreef: >>> Something that would not be necessary if the >>> underlying openPGP implementations could handle hashed >>> user IDs. > >> Isn't it much easier to use the key ID / signature for >> that? You already have that. > > I don't understand. Use the keyID / signature as the hashed user ID, since it (should) uniquely identify the key. Since a hash is one way you can't derive the email address from it anyway, from the keyID you also can't (directly) deduce the email address. -- ir. J.C.A. Wevers // Physics and science fiction site: joh...@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html Public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 3 March 2011 at 12:33:27 AM, in , Robert J. Hansen wrote: > It's not a tangent at all, and for almost the exact > reason you cite. You would say "it can easily be done." > I would say, "it can easily be enforced." I'm not > seeing an effective enforcement mechanism here. Without > that, I don't see how it can easily be done. What would need to be enforced? If a user chose to use hashes when creating their user-IDs, then all by themself without the need for any enforcement mechanism they have obscured the data; somebody already in possession of the data can compare hashes but somebody inspecting the user-IDs cannot extract the information that is obscured. > Basically what you're saying is, "I don't want other > people to be able to publicly share data that I feel > personally identifies me." That's a perfectly > understandable want, but you can't make data > uncopyable. Digital information may be easily and near > costlessly copied and shared: that's just its essential > nature. Precisely the point of using hashes in user-IDs: all that would be available to copy and share is a hash of the data. >> 3. I have email addresses that you don't know. >> These email addresses are readable from my key's user >> IDs. It is trivial for you to obtain these >> email addresses. >> 4. I have email addresses that you don't know. >> These email addresses are not readable from my key's >> user IDs. It is harder for you to obtain these >> email addresses. > I don't believe 4 is the case at all. In this era of > Facebook, Twitter, social media and people profligately > sharing information, well... this seems a lot like > locking up the barn after the cattle have run off. Even if you consider the search to be trivial, it is still harder than not needing to search. I deliberately used the comparative. Now I'm just being a pedant. (-: > You're begging the question: how does it get made > ex-directory? In the case of a telephone, it's because > you have a single point of authority who will enforce > your wishes. In the case of the certificate servers, > how does it get done? > I'm not saying it shouldn't get done or that I wouldn't > like it if it were done. I'm only saying that, at > present, it doesn't appear it *can* be done. The user already has complete control over what string to use as their user-ID. There is nothing stopping anybody from publishing a key with user-IDs such as "b735ed0655b5a9017bc102f6b1799aa9959a3251 (55fbb2c0169d568bbd2ced25e1f47737e7ef3a34) <529ed52d3ec1186584ec75109e732f9b9da3f12d>" but there is no point without a mechanism for other users to select that key from an email address (or a name). - -- Best regards MFPAmailto:expires2...@ymail.com Lotto: A tax on people who are bad at statistics! -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNc4gwnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pgdgEALob 6wWg/GGyae8cHa9nl4eExBGTONpi+r+BITD735NZLm2FREVHvFisc7An7Ti9jLbU lurAycbCQ5BXeR+V+b5UgxBVK5AOLa69nwAxL7eoESyZ+Lnzq4fuMNUnFd2vmEth iI1QBknRG3qiiY3vnucpCgTI+Dy7VILR0ceREbgb =Jimz -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 3 March 2011 at 8:30:13 AM, in , Johan Wevers wrote: > Op 2-3-2011 20:25, MFPA schreef: >> It is also much easier to create new email addresses >> than it is to change phone numbers. And more practical >> to have multiple or short-life email addresses than is >> the case with phone numbers. > Not really, here I can get a new (mobile) phone number > by buying a prepaid simcard Certainly that is true of mobile numbers, and thank you for pointing it out. I should have specified I was referring to landline numbers but since mobile numbers (in the UK) are not usually listed in the telephone directory, it didn't occur to me. - -- Best regards MFPAmailto:expires2...@ymail.com If you are afraid to speak against tyranny, then you are already a slave. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNc3bHnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5p2HMEAJWZ kTOluPqlFsDbClyRPV7U2gnCzKzvBXd3wpLkMSn88Guz3R/6nqcN3VGRs6/VsWAE LnefHIny48V4C9Dt1ltE736xoNCJERbimyRHzI2h1Pzdgt+RQ/8fQAKgsSbS6eXt /LG0pmn6Pa5tTUp0Vdb32lzP8zwqant6WmmIVgiJ =2tJq -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 3 March 2011 at 8:36:36 AM, in , Johan Wevers wrote: > Op 3-3-2011 1:21, MFPA schreef: >> Something that would not be necessary if the >> underlying openPGP implementations could handle hashed >> user IDs. > Isn't it much easier to use the key ID / signature for > that? You already have that. I don't understand. - -- Best regards MFPAmailto:expires2...@ymail.com Success isn't how far you got, but the distance you travelled from where you started -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNcrYBnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pr3ED/RQb yNmn7SVKQojUvWRFZoKvI0Jt6AJC6MFovc3vNPMJKqsCfF+mYgGxsHL2t8oPaKkb O8asryh2EmUlFpJfHnqQD1bYQCgIdXWmTjSk5C5Sk7nwt6xZr7W2UW+ex8sHTsN3 +aidIIku/4dlwar8XB6GUMiOvQ9JGDJJCFQmniDK =rNlT -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 3 March 2011 at 8:32:00 AM, in , Johan Wevers wrote: > Op 2-3-2011 21:14, Daniel Kahn Gillmor schreef: >> You'd still need to do the work of changing, say, MUAs >> to re-think their key-selection criteria to include >> keys without e-mail addresses (maybe just based on the >> human-readable part of the To: header?) > That can be done much easier: upload a version without > the email address to the keyservers, and store locally > a version with your (current) email. Then don't sync > that with the keyservers of course. I do that already. But what about anybody else whose MUA requires an email address in the key UID to locate my key? - -- Best regards MFPAmailto:expires2...@ymail.com No man ever listened himself out of a job -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNcrUUnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pk9UEALzv z2PBP2uLAd2ZPky6REU2Lcj6d5D3EpKZR+Dsqxa2rEO32RhUGvl2kczfWVs8rHWE F5l8OzVkoKrZfeVP+ud6ayH7hlQmGA1Zvpds5h9T/+kMCXfriJGDBkelwojwxJ5z tPlRLJJgJdDBOZg+RMwV42bW197QH6LyDpA0NDYg =c3uY -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Op 3-3-2011 1:21, MFPA schreef: > Something that would not be necessary if the underlying openPGP > implementations could handle hashed user IDs. Isn't it much easier to use the key ID / signature for that? You already have that. -- Met vriendelijke groet, Johan Wevers -- Met vriendelijke groet, Johan Wevers ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Op 2-3-2011 21:14, Daniel Kahn Gillmor schreef: > You'd still need to do the work of changing, say, MUAs to re-think their > key-selection criteria to include keys without e-mail addresses (maybe > just based on the human-readable part of the To: header?) That can be done much easier: upload a version without the email address to the keyservers, and store locally a version with your (current) email. Then don't sync that with the keyservers of course. -- Met vriendelijke groet, Johan Wevers ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
Op 2-3-2011 20:25, MFPA schreef: > It is also much easier to create new email addresses than it is to > change phone numbers. And more practical to have multiple or > short-life email addresses than is the case with phone numbers. Not really, here I can get a new (mobile) phone number by buying a prepaid simcard for about 10 Euro (including 10 Euro credit). The cheapest prepaid packages with phone are about 15 Euro (old model phone that is being dumped). For some contacts that is precisely what I do: give them a second number, if I get too many calls on it I don't want I replace the simcard. -- ir. J.C.A. Wevers // Physics and science fiction site: joh...@vulcan.xs4all.nl // http://www.xs4all.nl/~johanw/index.html PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 2 March 2011 at 8:14:08 PM, in , Daniel Kahn Gillmor wrote: > it sounds to me like you've simply made it difficult > for people to correspond with you over long periods of > time because your e-mail address isn't likely to > continue working. Not especially so. The ones I use for mailing lists etc. change periodically. This makes no difference to people contacting me, since they should be doing it via the list. Ones I use with specific individuals or groups of people, some are quite fleeting while others persist for years. > If your only concern is that you don't want your e-mail > address publicly visible on the keyservers, just make a > User ID with no e-mail address at all, and leave it at > that. > You'd still need to do the work of changing, say, MUAs > to re-think their key-selection criteria to include > keys without e-mail addresses Something that would not be necessary if the underlying openPGP implementations could handle hashed user IDs. > But you wouldn't have to do any of the following: > * specify and try to reach consensus on the syntax of > a "standard" Hashed User ID Isn't that best handled *after* a proof-of-concept? > * modify underlying OpenPGP implementations to try > digested searches Could these be handled by a local proxy? The openPGP implementation (which is configured to use the local proxy as keyserver, and not to check the local keyring) queries the proxy using the plaintext search string. The proxy checks the local keyring for both the plaintext search string and the hash, and returns the combined results to the openPGP implementation. The proxy (simultaneously?) queries a keyserver for both the plaintext search string and the hash. If there were matches in the local keyring, the keyserver results are discarded (or cached?). If there were no matches in the local keyring, the combined results from the keyserver are returned to the openPGP implementation and keys may be imported as normal. > * convince third-parties that it is worth their while > to certify digested user IDs That is not necessarily harder than convincing them to sign user IDs wit no email address. - -- Best regards MFPAmailto:expires2...@ymail.com Zorba the Greek - before he zorbas you -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNbt7/nhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pYmsEAL9V ZcywGGE/10DWc2Lqv8G/r+ugt0Wju9dObr+Ll3BNjkANu+bTWRJpFMVsTF4Y/PHZ VEuYZh2dRFPF8FCK7MjwSy0lQ6EsR6yxGlMWjrx5ECvfV8V/r/1pC+GWyBl+aSD8 myYbz+uMd1d7YOsebNn7Z3SohyZhu3cwUuCKidTT =LmYB -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/2/11 7:37 PM, Ben McGinnes wrote: > More seriously, I've been through this discussion with MFPA before and > I can see some circumstances where his idea might have merit, so I'd > be willing to help test too. Same here. I am deeply skeptical, but not unwilling to be proven wrong. IMPOSSIBLE: means (1) I wouldn't like it and when it happens I won't approve; (2) I can't be bothered; (3) God can't be bothered. Meaning #3 may perhaps be valid but the others are 101% whaledreck. -- John Brunner, _Stand on Zanzibar_ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 1/03/11 1:20 PM, Grant Olson wrote: > > I wouldn't mind testing to help out, but I'm not throwing away my > current key anytime soon. Ah ha! Another hint about the scav hunt. ;) More seriously, I've been through this discussion with MFPA before and I can see some circumstances where his idea might have merit, so I'd be willing to help test too. Regards, Ben signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/2/11 6:34 PM, MFPA wrote: > You are going off at a tangent. The mechanism for preventing the phone > number being obtainable from a query of the phone book or directory > enquiry services is not relevant; just the fact that it can easily be > done. It's not a tangent at all, and for almost the exact reason you cite. You would say "it can easily be done." I would say, "it can easily be enforced." I'm not seeing an effective enforcement mechanism here. Without that, I don't see how it can easily be done. Basically what you're saying is, "I don't want other people to be able to publicly share data that I feel personally identifies me." That's a perfectly understandable want, but you can't make data uncopyable. Digital information may be easily and near costlessly copied and shared: that's just its essential nature. > 3. I have email addresses that you don't know. > These email addresses are readable from my key's user IDs. > It is trivial for you to obtain these email addresses. > > 4. I have email addresses that you don't know. > These email addresses are not readable from my key's user IDs. > It is harder for you to obtain these email addresses. I don't believe 4 is the case at all. In this era of Facebook, Twitter, social media and people profligately sharing information, well... this seems a lot like locking up the barn after the cattle have run off. > "This phone number is not listed in the phone book or at directory > enquiries" is easily achieved by being ex-directory; this does not > affect the usefulness of my telephone service. You're begging the question: how does it get made ex-directory? In the case of a telephone, it's because you have a single point of authority who will enforce your wishes. In the case of the certificate servers, how does it get done? I'm not saying it shouldn't get done or that I wouldn't like it if it were done. I'm only saying that, at present, it doesn't appear it *can* be done. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 2 March 2011 at 8:27:50 PM, in , Robert J. Hansen wrote: > The analogy continues to break down. "Binding," in the > context of the analogy, means "if someone breaks this > instruction, they will be hurt." Maybe the government > will start a criminal prosecution, maybe you have > recourse in a civil lawsuit, but ... ultimately, "if > someone breaks this instruction, they will be hurt." > Okay, fine: who are you electing to be the > hurt-inflicter for the OpenPGP community? And in the > absence of a designated hurt-inflicter, how can there > be a "binding instruction"? You are going off at a tangent. The mechanism for preventing the phone number being obtainable from a query of the phone book or directory enquiry services is not relevant; just the fact that it can easily be done. Consider these scenarios:- 1. I have a phone number that you don't know. This phone number is listed in the phone book and at directory enquiries. It is trivial for you to obtain the number. 2. I have a phone number that you don't know. This phone number is not listed in the phone book or at directory enquiries. It is harder for you to obtain the number. A parallel exists with:- 3. I have email addresses that you don't know. These email addresses are readable from my key's user IDs. It is trivial for you to obtain these email addresses. 4. I have email addresses that you don't know. These email addresses are not readable from my key's user IDs. It is harder for you to obtain these email addresses. "This phone number is not listed in the phone book or at directory enquiries" is easily achieved by being ex-directory; this does not affect the usefulness of my telephone service. It is only easy because the appropriate mechanism has been put in place to achieve it. "These email addresses are not readable from my key's user IDs" is easily achieved by simply not including them in the user IDs. This is easy because the user ID field is free-text and doesn't have to be Name (Comment) . This adversely affects the usefulness of my key, since MUAs commonly rely on the email address in the user ID for key selection. Hashed user IDs are a possible alternative mechanism to achieve "these email addresses are not readable from my key's user IDs" that could have less of an adverse affect on key usefulness. > The analogy you're drawing is appealing at first > glance, but the more I look at it the more it breaks > down. I said "in this respect the two are similar." You appear to be saying "they are not similar because in these other respects they are different." >> It is also much easier to create new email addresses >> than it is to change phone numbers. > I would *far* rather change my phone number than change > my email address. Probably a total of 50 people have > my phone number: if I change it, big deal. If I change > my email address, I'd probably need to inform upwards > of a thousand people of the change. A good point well made. I was comparing the effort involved in actually creating a new email address (a few seconds to a couple of minutes at the keyboard) to the effort involved in actually getting the phone company to change a phone number (ringing the phone company, navigating their stupid menu system, eventually getting through to a customer service agent in foreign parts who barely speaks English, trying to make them understand, discussing the reasons why they should provide the number change - such as nuisance phone calls you have been receiving, wait for the change to happen, chase up the billing errors, etc.). - -- Best regards MFPAmailto:expires2...@ymail.com Never lean forward to push an invisible object. -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNbtQRnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pARsD/1iG sr2ROg6NOqTJDhasftiQwXYZ9YiEFK4TacuT1TIl8MRYynMJU35EgqioWvh3B3LJ Mfqaqvff9OlK8wyrmbQ585USxmXYf7aDtsfI3tqzrvgoYIMpl/iLRxpN4JGwSpv1 D2r2jlIHUq1LehNUYjbl0DGR+1kishfWhAHkxiSO =euzF -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 3/2/11 2:25 PM, MFPA wrote: > Once, maybe. But for quite a few years (in the UK at least) there have > been many competing directory enquiries services, and more recently > the online versions as well. Choosing to be ex-directory is a > binding instruction to your telephone company not to release your > number to any such services. The analogy continues to break down. "Binding," in the context of the analogy, means "if someone breaks this instruction, they will be hurt." Maybe the government will start a criminal prosecution, maybe you have recourse in a civil lawsuit, but ... ultimately, "if someone breaks this instruction, they will be hurt." Okay, fine: who are you electing to be the hurt-inflicter for the OpenPGP community? And in the absence of a designated hurt-inflicter, how can there be a "binding instruction"? The analogy you're drawing is appealing at first glance, but the more I look at it the more it breaks down. > It is also much easier to create new email addresses than it is to > change phone numbers. I would *far* rather change my phone number than change my email address. Probably a total of 50 people have my phone number: if I change it, big deal. If I change my email address, I'd probably need to inform upwards of a thousand people of the change. It may be true that *for you* it is easier to create new email addresses than to change phone numbers. It does not hold true for everyone, and just how broadly it holds true is unknown. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 03/02/2011 02:25 PM, MFPA wrote: > For somebody who uses the same email address to communicate with many > contacts and keeps the same email address for a long time, that is > true. For somebody like me who uses various different email addresses > and replaces some of them on a regular basis it is plenty practical > enough. it sounds to me like you've simply made it difficult for people to correspond with you over long periods of time because your e-mail address isn't likely to continue working. If your only concern is that you don't want your e-mail address publicly visible on the keyservers, just make a User ID with no e-mail address at all, and leave it at that. You'd still need to do the work of changing, say, MUAs to re-think their key-selection criteria to include keys without e-mail addresses (maybe just based on the human-readable part of the To: header?) But you wouldn't have to do any of the following: * specify and try to reach consensus on the syntax of a "standard" Hashed User ID * modify underlying OpenPGP implementations to try digested searches * convince third-parties that it is worth their while to certify digested user IDs --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 2 March 2011 at 4:07:19 AM, in , Robert J. Hansen wrote: >> The benefits of your phone number being ex-directory >> are the benefits that derive from it being harder for >> people to obtain your phone number without your >> permission, harder to link the number to your >> name/address, and impossible to find your address or >> phone number by looking in the phone book. > Here the analogy breaks down. Generally speaking there > is only one telephone directory for a given geographic > area, which makes it possible for you to keep your > phone number private by keeping it out of that one > directory. Once, maybe. But for quite a few years (in the UK at least) there have been many competing directory enquiries services, and more recently the online versions as well. Choosing to be ex-directory is a binding instruction to your telephone company not to release your number to any such services. > Email doesn't work the same way. There is no > centralized directory. It is also much easier to create new email addresses than it is to change phone numbers. And more practical to have multiple or short-life email addresses than is the case with phone numbers. > To keep your email private > requires that you fastidiously keep it out of > thousands, tens of thousands of directories. This > doesn't strike me as very practical. For somebody who uses the same email address to communicate with many contacts and keeps the same email address for a long time, that is true. For somebody like me who uses various different email addresses and replaces some of them on a regular basis it is plenty practical enough. > The benefits of keeping a telephone number out of the > directory do not seem analogous to keeping an email > address off the certificate servers. Not exactly analogous (hence my "admittedly not a direct comparison" when I introduced it) but I have drawn enough parallels for it to be a relevant comparison. Of course there are differences. - -- Best regards MFPAmailto:expires2...@ymail.com Vegetarian: Indian word for lousy hunter!!! -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNbpmnnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pOmsD/1/V 0tg8BJz1uLyfHWfcQq3l/1eaIxBfa3+z3d68LYQ5ZcsoBNlJxAd/80FKmBb0a83r 8h7EuQsJZcHTLfPTUjB6dS1D8ffqp/e3K/lCQSzy4yccgiw1QwTPzf3C1L3THePa LDAqa2PSctUip578m/yRehrcR2E2CYt1NOlpfWEM =1E41 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
> The benefits of your phone number being ex-directory are the benefits > that derive from it being harder for people to obtain your phone > number without your permission, harder to link the number to your > name/address, and impossible to find your address or phone number by > looking in the phone book. Here the analogy breaks down. Generally speaking there is only one telephone directory for a given geographic area, which makes it possible for you to keep your phone number private by keeping it out of that one directory. Email doesn't work the same way. There is no centralized directory. To keep your email private requires that you fastidiously keep it out of thousands, tens of thousands of directories. This doesn't strike me as very practical. The benefits of keeping a telephone number out of the directory do not seem analogous to keeping an email address off the certificate servers. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Wednesday 2 March 2011 at 1:43:45 AM, in , Daniel Kahn Gillmor wrote: > On 03/01/2011 08:05 PM, MFPA wrote: >> My analogy, admittedly not a direct comparison, would be having a >> phone number that is ex-directory. It is no defence against random >> dialling, nor against your number being recorded from outgoing calls >> if you don't take steps such as withholding the CLI, nor against >> somebody who has your number passing it on without your permission. >> Despite these failings there is still benefit in being ex-directory. > What are those benefits? The benefits of your phone number being ex-directory are the benefits that derive from it being harder for people to obtain your phone number without your permission, harder to link the number to your name/address, and impossible to find your address or phone number by looking in the phone book. A key that had only hashed UIDs would have analogous benefits relating to email address instead of phone number and to keyserver instead of phone book. A key with some hashed and some human-readable UIDs would perhaps be like having two phone numbers, one listed and the other ex-directory. > Are they worth the tradeoff > of having a large number of non-human-readable User > IDs? Depends who evaluates the worth, how they evaluate it, and if you accept that is really the trade-off. I use different email addresses with different contacts and change some email addresses regularly. Hashed UIDs would allow hiding my email addresses from the people they are not used with, as well as preventing a human-readable set of defunct email addresses. If I included my email addresses in hashed UIDs, they are not human-readable but could still be used to find/identify my key and maybe even facilitate opportunistic encryption. At the moment I cannot usefully include them hashed, so I don't include them at all. For my own key, to me the trade-off is if hashed but still useful I will include, if human-readable I will not. For somebody else encountering my key, the trade-off is the email address they want to match is either in a hashed user ID or it's in no user ID at all. What is the disadvantage of a large number of non-human-readable User IDs on a key? The User ID that I am using at the time (eg to select a key) is useful, all others are irrelevant noise and may as well not be human-readable. - -- Best regards MFPAmailto:expires2...@ymail.com Lotto: A tax on people who are bad at statistics! -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNbbfVnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pxM8D/0mi vUZEjULh30eTkuM26YhxdwuxC27qeRUtMWcDP/gYiiEgittoLvq2IVLfrZac1sj7 0vsaaR27PFMSErYjBMJfk6T54Fg2Jel5GfodbRfbxaDpzrTZG0iNqee/m1ea3+cA z4yXpu/o0vZkdmxA9sJx0XXwOK3h5WVu9YhVNady =4umI -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 03/01/2011 08:05 PM, MFPA wrote: > My analogy, admittedly not a direct comparison, would be having a > phone number that is ex-directory. It is no defence against random > dialling, nor against your number being recorded from outgoing calls > if you don't take steps such as withholding the CLI, nor against > somebody who has your number passing it on without your permission. > Despite these failings there is still benefit in being ex-directory. What are those benefits? Are they worth the tradeoff of having a large number of non-human-readable User IDs? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 1 March 2011 at 1:54:25 AM, in , Daniel Kahn Gillmor wrote: > However, i'm quite serious about the flaws paralleling > the failures of NSEC3 to prevent DNS zone enumeration. > the problem space is slightly different, but i think > the math comes out about the same in terms of the cost > of trying to brute force these things. > Ultimately, i think Hashed User IDs provide only weak > benefit against the equivalent of zone enumeration > through the keyservers (which is presumably the goal), > so understanding these arguments and providing a > convincing refutation of them (or outlining an entirely > different benefit) is probably the first task someone > would need to take on. My analogy, admittedly not a direct comparison, would be having a phone number that is ex-directory. It is no defence against random dialling, nor against your number being recorded from outgoing calls if you don't take steps such as withholding the CLI, nor against somebody who has your number passing it on without your permission. Despite these failings there is still benefit in being ex-directory. > Having a hashed User ID alongside your non-hashed User > ID provides no benefit at all Those of us who use different email addresses with different contacts (and/or periodically change email addresses) might generate a hashed user ID for each email address, maybe with a non-hashed user-id for our name. Similarly with role-based user IDs, a user might have their name in a non-hashed UID but use hashed UIDs for their roles. - -- Best regards MFPAmailto:expires2...@ymail.com Is it possible to be a closet claustrophobic? -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNbZfYnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pw4wD/1R0 qopVlkQLWTmidAyoAZeFOqgVmGTh40Ppu2nN49qq19+VZUFllAf/QcZw8+x3sWjh TRdvLlMbvHRCtw6pqbWayW4aRN3NnMpWtUZnqnyEaErtGic8XgrD9O963dIcMvHd kmNIf28PN774kNydUgF1hKyhBq6m/JAJ4BbCdQKV =l3Bc -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs [was: Re: Security of the gpg private keyring?]
On 02/28/2011 08:54 PM, Daniel Kahn Gillmor wrote: > On 02/28/2011 07:44 PM, Grant Olson wrote: > > You can pull a copy of a stalled/never-submitted Internet-Draft from here: > > git://lair.fifthhorseman.net/~dkg/openpgp-hashed-userids > > If anyone wants to push this further, please let me know. > I'll take a look when I get some more time. To be honest though, I'm not particularly interested in the feature either. I was just trying to illustrate that MFPA could get something going without needing a new OpenPGP RFC, or without spending years of effort until he got tangible results. And if the (non)standard got got popular enough, tools, whether they be keyservers or mail clients or gnupg, would start to handle hashed userid lookups. Even just two simple script that wrap around gnupg, 'generate-hashed-userid' and 'retrieve-hashed-userid', would be a huge start. > >> If that could be agreed on, you could probably get a few mailing list >> regulars to add that ID in addition to their normal UIDs. > > Having a hashed User ID alongside your non-hashed User ID provides no > benefit at all (unless you consider confusing people trying to > understand and/or certify your OpenPGP certificate a benefit). > Yes, of course. I was just thinking of the initial implementation and testing phase. It'd be nice if MFPA could see that the tools work correctly, by seeing the 'before' and 'after' versions of UIDs, and without people having to maintain a separate secret key. I wouldn't mind testing to help out, but I'm not throwing away my current key anytime soon. -- -Grant "Look around! Can you construct some sort of rudimentary lathe?" signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
hashed user IDs [was: Re: Security of the gpg private keyring?]
On 02/28/2011 07:44 PM, Grant Olson wrote: > I think something similar could be done with hashed emails. Just some > (non)standard like: > > hashed_uid://$SHA1_OF_EMAIL/$RIPEMD_OF_EMAIL > > But using something better than my obviously naive hash-collision > prevention algorithm. this is (very roughly) what we came up with too (our approach to avoiding hash collisions was to use a stronger hash instead of 2 weak hashes). You can pull a copy of a stalled/never-submitted Internet-Draft from here: git://lair.fifthhorseman.net/~dkg/openpgp-hashed-userids If anyone wants to push this further, please let me know. However, i'm quite serious about the flaws paralleling the failures of NSEC3 to prevent DNS zone enumeration. the problem space is slightly different, but i think the math comes out about the same in terms of the cost of trying to brute force these things. Ultimately, i think Hashed User IDs provide only weak benefit against the equivalent of zone enumeration through the keyservers (which is presumably the goal), so understanding these arguments and providing a convincing refutation of them (or outlining an entirely different benefit) is probably the first task someone would need to take on. I'm not convinced that the tradeoff is worth it myself, but if someone wanted to make the argument, i'd be happy to listen. > If that could be agreed on, you could probably get a few mailing list > regulars to add that ID in addition to their normal UIDs. Having a hashed User ID alongside your non-hashed User ID provides no benefit at all (unless you consider confusing people trying to understand and/or certify your OpenPGP certificate a benefit). This would only be helpful to people who use nothing but hashed user IDs on their keys. > From there > start with a shell script that writes out a correct 'gpg --search-keys' > request. Then on to more advanced things, like adding hashed_uid search > to the default sks-keyserver pages, enigmail integration, etc. yes, this is the implementation work that would need to be done. Whoever wants to pick it up needs to also pay particular attention to the user experience. OpenPGP tools are pretty confusing already, so thinking through how to hide the gibberish (hashed userids) in the background and present the user with something intelligible would be a critical step toward making this something anyone might want to adopt. I wish i had a better solution to offer to this concern. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
