Why hashed User IDs is not the solution to User ID enumeration (was: Re: Creating a key bearing no user ID)
On 01/23/2012 06:23 PM, MFPA wrote: It sounds like you value the flavour of privacy that could be afforded by a scheme involving the use of hashes in UIDs to protect names and email addresses. Such a scheme would (for example) allow somebody with one of your email addresses to locate your key, but would not allow somebody to devine your names or email addresses by inspecting your key. An extension would be required to allow GnuPG to locate keys using both the hash and the plaintext string simultaneously. What you're looking to do with this proposed hashed-user-id scheme is to find a way to avoid allowing people to enumerate e-mail addresses or User IDs from the data contained on the keyservers. Right? I'd also like to be able to do that, but i don't think hashed-user-ids is an effective way. Here's why: I worked for a while with a group of people (several of the other monkeysphere devs) to spec something like this out, to try to address this very issue. However, after thinking about the various possible solutions, and reading more, i started to think this all smelled very similar to another problem: DNSSEC zone enumeration. DNSSEC zone enumeration is a byproduct of the way that NXDOMAIN responses must be signed in order to be provable; the original proposal required the signed NXDOMAIN response to indicate the range of names which were excluded. this makes it easy for an attacker to jump from name to name via NXDOMAIN records, and enumerate all records in the zone. So far, this looks very much like the current keyservers, which allow for trivial enumeration of IDs. DNSSEC tried to fix this with NSEC3 records, which work differently; instead of listing the boundaries of the requested NXDOMAIN range, they listed the boundaries in a hashed space. that is, instead of saying there are no records of any type between bar.example.com and foo.example.com, they say there are no records of any type whose labels hash to somethng between 8a367d741d7a9a904ef6f92fd99de3d57ded1203 and cb17eb75226ca198afec4ea1170f02fade354e3e. So now, the attacker who wants to enumerate the zone has to reverse the hash to uncover the endpoints. The trouble is that domain names (and e-mail addresses, and human names) are very low-entropy things, and actually are pretty easy to enumerate and test. Dan Bernstein wrote a tool called NSEC3walker that can practically enumerate a DNSSEC-signed zone that uses NSEC3 records, using pretty low-end hardware, and doing few network queries: http://dnscurve.org/nsec3walker.html A comparable tool could be made to attack any sort of hashed-user-ids scheme, which means that anyone who wants to harvest or enumerate addresses this way could probably do it. Certainly, the bar is raised for User ID enumeration, but only slightly. So, as someone who was similarly eager for such a scheme, i have to ask myself: does the marginal gain in address-enumeration-protection outweigh the costs in complexity and confusion that the scheme adds? Certainly, the keyservers will continue to support non-digested User IDs, so now tools will need to be able to handle both of them; we'll also need a policy for end-user agents to answer questions like when looking up this e-mail address, do i send it only in digested form to the keyservers for lookup? or do i send it in cleartext form as well, thereby leaking the e-mail address to the keyserver operators (and to anyone on the network path)? How do we explain or expose policy questions like that to users who already struggle with the concepts behind OpenPGP? or do we modify the keyservers themselves to index digested forms of cleartext User IDs, and respond to digest lookups with cleartext responses, thereby turning the keyservers into a digest-reversing oracle for those non-hashed User IDs which exist? Ultimately, i don't think the tradeoffs for this scheme are worthwhile for the marginal and limited gain that the proposal provides. I'd love to find a solution to the User ID enumeration problem, but i don't think hashed-user-ids is it. Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using root CAs as a trusted 3rd party
Hi Mike, gnupg users, * gn...@lists.grepular.com gn...@lists.grepular.com [22. Jan. 2012]: [...] I sometimes wonder if the traditional public web of trust is even a good idea. Are you happy to be associated with everybody you've signed the key of and those who have signed yours? Are you sure that none of these people will do anything in the future which might cause these public associations to become a problem for you? When I sign a key a make a statement that I checked somehow that the key belongs to a specific person P. I might make further claims via a notation or a policy url but I don't have to. Merely stating that I proved someones identity of P should not mean anything else. But you are right, perhaps in the future P will be known to be a christ|communist|murderer|free software user|... and some government|churches|militia|... may come after me because I had dealings with such a person. But this might also happen because I am neighbour to P1 or was in school with P2 or even more problematic, because this christ|communist|devil|free software user|... might be me. And especially in the later case I would be happy if at least freedom loving free software users stand against inhuman and morally wrong accusations. Signing a key means signing a key. And we should fight for that if anyone gets in trouble because of it. Ciao, Gregor -- -... --- .-. . -.. ..--.. ...-.- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using root CAs as a trusted 3rd party
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 21-01-2012 18:50, Gregor Zattler escribió: Hi Aaron, gnupg users, * Aaron Toponce aaron.topo...@gmail.com [21. Jan. 2012]: I just signed an OpenPGP key with cert level 0x12 (casual checking) given the following scenario: * A PGP key was signed by an SSL certificate that was signed by a root CA * I verified that the signature was indeed from that root CA. * I striped the signature, and imported the PGP key. * I then signed the key, exported, and sent back. What are your thoughts on using root CAs as a trusted 3rd party for trusting that a key is owned by whom it claims? Of course, this is merely for casual checking, but it seems to be good enough. IMHO by signing a key you make a statement about the connection between a person or owner and the user id you sign, saying I somehow convinced myself that user owns this key. This only makes sense if you have some insight into the matter that a person which is confronted with the key only cannot have. Your signature should add some information. Merely saying I'm convinced that the user is the owner/originator of the key because someone else already signed this key, does not make much sense to me. I think you should have added a notation explaining you reasoning. Well, if Trent signs Alice key, Bob, who trust Trent, might sign her key too. Charly doesn't know Trent, but he trusts Bob's judgement, so he might accept Alice's key as valid, not because of Trent's signature, but because of Bob's signature. Also, maybe Trent only signs keys if 2 persons have checked it, but he just sign it once, that signature doesn't reflect the amount of people having checked it. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPHvTaAAoJEMV4f6PvczxAAjQIAIPfzIApPoR+FWibTqvp6Ijl 7i3YB5lvP7HpsLdpcA9To4XlmBXVuaPH4u+eJr/d8dOIJ/qCEgJnkaPamG/bXOU3 AobiXY0B0/mpF809vpF3+cNY+8PVTPVeWz66BrBzfVg9CVOUo+fhygChfyPTrEDw BL+fjowHmdliUhF8jDvw3Em2Oa+wcugImNnmTKncr3Qj1Kmp3UtVOSLQD5tbia3c SzHQ8nAHFgEbjpE3To+UjcXaBfd3kQnZ2WKKdcJdjxFscd0lvSj0dkj5jAnpWZZH xKoLE8ljvfSZOk73v5vxLENj4xWBOUJopi+bzaN4ZjTEMmUV0DOnh93C0QBTceQ= =gy8V -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using root CAs as a trusted 3rd party
On Tue, Jan 24, 2012 at 03:13:46PM -0300, Faramir wrote: Well, if Trent signs Alice key, Bob, who trust Trent, might sign her key too. Charly doesn't know Trent, but he trusts Bob's judgement, so he might accept Alice's key as valid, not because of Trent's signature, but because of Bob's signature. Also, maybe Trent only signs keys if 2 persons have checked it, but he just sign it once, that signature doesn't reflect the amount of people having checked it. This is why OpenPGP implementations have trust settings. If Bob trusts Trent's assertions, then he can give Trent full trust and Bob's implementation will believe that Alice's key belongs to Alice. There's no need to sign the key. If I truly believe that a key belongs to someone that I have seen use it for several years and that is trusted by numerous other people, but I have not verified the connection between that person's identity and key myself, I use a local signature. That way I don't have other people rely on my assertion if I haven't done the amount of checking that I would like to before making a public statement. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Using root CAs as a trusted 3rd party
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 24-01-2012 16:26, brian m. carlson escribió: On Tue, Jan 24, 2012 at 03:13:46PM -0300, Faramir wrote: Well, if Trent signs Alice key, Bob, who trust Trent, might sign her key too. Charly doesn't know Trent, but he trusts Bob's judgement, so he might accept Alice's key as valid, not because of Trent's ... This is why OpenPGP implementations have trust settings. If Bob trusts Trent's assertions, then he can give Trent full trust and Bob's implementation will believe that Alice's key belongs to Alice. There's no need to sign the key. But Charly doesn't have Trent's key in his keyring, he doesn't even know about Trent. So if Bob doesn't sign Alice's key, Charly won't consider it valid. He will see the signature issued by an unknown key (Trent's), and that is all. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJPHx5LAAoJEMV4f6PvczxAFh8H/0AQVJ8hDV63a6DTukz/wymT sARdhUsGEufW1VbyNx5nR6luHkXv/omYckM6JzV+om4MYnGS0ZChV9bTyfWWvJAo SAxhuht8Ees4ocK/0U4/gcEJAIzwGJd/RpjPMbyENbvtOofwjzIqU92GixSIu6iT pruCU3y1JhIE5q6LZ7d0jWs6ycdkbj+o0OVcrfHD0aTsoSEFkQkAtsvzVqIxnKy3 y/BY6+yz6BcaYWvE0WnB/fOZb9fobHwTrl1aSMn0WuewU3HlJN3dvtNueB3JYlOM DN9sx5G+h1yY0mJoLRYAZj85RCL7KZ0kLDrcHEby/4ueOKitfN0H4xRVLZbHdYA= =osi/ -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Forcing use of software pinentry instead of hardware pinpad
I've got myself an SPR-532 smart card reader. It's working fine on my Ubuntu laptop with my OpenPGP card. It makes very noisy beeping sound effects when using the pinpad though. I was planning on using it in an office environment, but the noise would draw unwanted attention and annoy people... I haven't been able to find any information on disabling the sound effects it produces. Maybe that's simply not possible. Would it be possible to use this reader and enter the pin in software, using pinentry, instead of the hardware pinpad? The pinpad part of the reader was a bonus, but it's not essential for my purposes... -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4 signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Forcing use of software pinentry instead of hardware pinpad
Am Dienstag, 24. Januar 2012, 22:45:10 schrieb gn...@lists.grepular.com: Would it be possible to use this reader and enter the pin in software, using pinentry, instead of the hardware pinpad? scdaemon knows the option --disable-keypad 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: Using root CAs as a trusted 3rd party
Am Dienstag, 24. Januar 2012, 22:10:35 schrieb Faramir: This is why OpenPGP implementations have trust settings. If Bob trusts Trent's assertions, then he can give Trent full trust and Bob's implementation will believe that Alice's key belongs to Alice. There's no need to sign the key. But Charly doesn't have Trent's key in his keyring, he doesn't even know about Trent. So if Bob doesn't sign Alice's key, Charly won't consider it valid. He will see the signature issued by an unknown key (Trent's), and that is all. You completely change the semantics and use of the web of trust. IMHO that cannot be good. Charly can check all keys of the unknown signatures. After downloading Trent's key he finds Bob's signature and can make a decision about the trust path. Network systems like the web of trust can only work of all (or: most) people act in the same way. Do you suggest that every key gets 90 instead of (I guess) today's 10 because everyone signs his (trustedly) indirect contacts? Without any chance to tell direct and indirect signatures apart? What about revocations? Let's assume that Trent revokes his signature for Alice. Is Bob going to check that regularly? Probably not. Then Charly would trust the key due to Bob's signature though Bob himself does not trust it any more! At least not when thinking about it. And as Bob's signature does not even tell a third party which direct(?) signature made him certify the key, the third party cannot check whether the respective certification has been revoked. This behaviour would kill both trust depth and signature counting. A configuration like Trust the key if it has five maginally trusted certifications does not make any sense any more if one signature can become five that easily by everyone making indirect certifications. How can Bob know whether Trent has really verified the key or just certified it because he found a signature by Peter? This is neverending. In the end probably every key in the wild would be certified by ALL active keys. Why? Because most OpenPGP users should be connected somehow (no matter how many levels in between) and the result of such behaviour would be a flat signature space. Terrible. The value of a signature would drop to nearly zero (without checking for a policy URL and the policy description there). Is that what you want? This would not be a problem at all if the meaning of a certain signature would be clear. As I mentioned several times in earlier threads I would love to have a standard set of detailed signature notations for explaining the meaning of a certification (because applications could be configured to treat standardized notations differently). One of the notations could be direct vs. indirect. 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: Creating a key bearing no user ID
MFPA wrote: On Monday 23 January 2012 at 3:04:45 PM, Holger wrote: Please simply accept that it's an issue for me as well as many others. Harvesting is supereasy: full keydumps are readily available. Yep, Full keydumps are readily available. http://www.keysigning.org/sks/ Yep, harvesting is is easy. Anyone with a journeyman knowledge of perl and can Google a regexp to match mail email addresses can do it. While a case can be made that harvesting does occur. Several friends believe it occurs as do I. However, testing I did a few years ago found the amount of SPAM attributable to a key on a keyserver was not significantly different from that received as just random SPAM noise from an unused ISP account. I've seen no volume of SPAM since then to challenge that conclusion. Sending a message to an email list such as this will likely result in at least an order of magnitude more SPAM than that attributable to the, IMO apocryphal, bogeyman of keyserver harvesting. It sounds like you value the flavour of privacy that could be afforded by a scheme involving the use of hashes in UIDs to protect names and email addresses. Such a scheme would (for example) allow somebody with one of your email addresses to locate your key, but would not allow somebody to devine your names or email addresses by inspecting your key. An extension would be required to allow GnuPG to locate keys using both the hash and the plaintext string simultaneously. I wondered when this regular exercise in sadoequinecrophilia would appear. :-( The same issues remain untouched just like the countless other times you've brought up this idea. What are it specifications? Is there any support from the IETF OpenPGP working group? Is there an implementation of your idea? Endlessly and tirelessly repeating the same Wouldn't it be nice if..., without addressing the issues posed and the questions asked only marks one as a crank or a bore. While we're at it, I'd like low-priced dark beer, a smart good-looking gingerbear boyfriend, and, of course, whirled peas. Suggestions like this tend to get lambasted because they do not enhance security, and privacy appears to be seen as unimportant. The ceaseless implication that those who do not agree with your ideas believe that privacy is unimportant is insulting to those who actively work producing code to enhance individual and corporate privacy. Just stop it. Changes to security software that do not increase security are to be examined under heightened scrutiny -- complicating the codebase allows errors to hide. I don't presently support this idea because the questions I've asked about it have yet to be answered. I'm skeptical that I'm ever going to get the details. The idea may have merit -- but most of us have yet to see that merit. I as others are unconvinced that this idea will work, the interoperability and user impact questions remain unanswered. -John (Replies _ONLY_ to the list, please.) -- 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Creating a key bearing no user ID
On 1/24/2012 11:10 PM, John Clizbe wrote: However, testing I did a few years ago found the amount of SPAM attributable to a key on a keyserver was not significantly different from that received as just random SPAM noise from an unused ISP account. My own experience may be worth mentioning. I had (have) an email account that's only ever mentioned in one place, on a certificate of mine. For several weeks it received no spam, and then in the space of a couple of days the spam volume was indistinguishable from any other account. My conclusion from this is once the spammers know they have a hit, they share your email address quickly. The deluge goes from a trickle to a firehose in the space of a day or two. The same issues remain untouched just like the countless other times you've brought up this idea. What are it specifications? Is there any support from the IETF OpenPGP working group? Is there an implementation of your idea? While these questions are certainly apt, I'd like to see a firm theoretical foundation for the idea. We don't have a solid theory for how to achieve MFPA's desired end. Until we do, I think all discussion about implementation is premature. Without a strong theoretical foundation, talk about blinded hashes of email addresses is sort of like talk about perpetual motion machines: yes, it would be lovely to have them, but we don't have the first clue how to do it. The burden is not on the critics of these ideas to prove they are impossible: the burden is on the advocates of these ideas to show they are possible. Casting aspersions as to the motives of critics puts one in the same ranks as cancer cure quacks who defend themselves against their critics in mainstream oncology by saying, well, of course they want you to stay sick. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
