Re: hashed user IDs redux [was: Re: Creating a key bearing no user ID]
On 26/01/12 12:07, Peter Lebbing wrote: I like it. Maybe I should clarify that this is in no way a feature request; I just like the pragmatic solution in itself. I personally don't see a use case where one would be satisfied with an e-mail address of the form mailinglisten--noenum-zttgfznhu3rnkfyaxjuym...@hauke-laging.de but dissatisfied with just handing the fingerprint for a key to someone. I wouldn't want to spell out that e-mail address to someone. If I'm not going to give it verbally, why not just give the key fingerprint? You could print the fingerprint on your business card, and not enter your e-mail address in the UID of the key. And in e-mails, you have the header OpenPGP: id=8FA94E79AD6AB56EE38CE5CBAC46EFE6DE500B3E Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs redux [was: Re: Creating a key bearing no user ID]
On 1/26/12 11:22 AM, Peter Lebbing wrote: If I'm not going to give it verbally, why not just give the key fingerprint? Yes. I've not hidden my opinion that I think this is an exercise in quixotry, but still, never let it be said I wasn't willing to make some contribution to an idea. Let's not talk about implementation details: right now we don't have a good enough handle on the problem to talk about how to solve it. So let's see if we can't use a 'Problem', 'Goal', 'Requirements' and 'Constraints' model to focus the conversation a little bit. PROBLEM: * Some people want to make it possible to opt out of their email addresses being harvestable on the keyservers. GOAL: * Give users an optional way to make their user IDs resistant to harvesting. REQUIREMENTS: * The solution must work within the OpenPGP framework without requiring any extensions. * The solution must work with SKS without requiring any extensions. * The User ID must be searchable (otherwise the solution is trivial, create a User ID with a name but no email address). If a user searches the keyserver for exactly a given email address, matching certificates must be returned. CONSTRAINTS: * Key enumeration. There are only roughly 10 million login names five characters or less. Searching those 10 million login names over the top 100 email domains amounts to about a billion queries. Split over a botnet of 100,000 elements, each bot would have to make 10,000 queries. Even if each query took one second (an unreasonable number: it would substantially impact OpenPGP adoption because people would be furious over the slow speed of lookups), that means a spammer network could break any such blinded hashing scheme in about three hours. * Utility. One way to make a blinded hashing scheme enumeration- resistant is to put a large amount of random data in there. However, searching for 'zz78gH1Y==@hotmail.com' is of comparable complexity to searching for a certificate ID. The system must work for all reasonable User IDs, rather than requiring User IDs to be unreasonable. ... Looking over this, I don't think that what MFPA wants is possible. I just don't. The key enumeration issue and the ease of getting past it, *even if we require each search to take one second to execute*, is the gorilla in the center of the room that's threatening to pound to a pulp anyone who seriously tries to take on this problem. If we discard the must conform to OpenPGP and must be compatible with SKS requirements, then maybe we could make it work. But as is, if I was asked to evaluate this research project, I would call it extreme risk for minimal reward. Risk, in an engineering management context, usually means risk of failure and wasting all the resources invested. The risk level seems extreme. Even if you succeed, how many people will join up? How many people will revoke their old User IDs and create new ones? Few, I think, which makes this minimal-reward. Even if you succeed, you'll impact only a very small fraction of OpenPGP users. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: RSA padding scheme
MFPA wrote: On Monday 23 January 2012 at 12:47:03 AM, in mid:20120123004703.GB10912 at crustytoothpaste.ath.cx, brian m. carlson wrote: This is not a problem with OpenPGP because the attacker never gets to see the value encrypted with RSA because it's the symmetric key. Isn't that the same thing as the session key, which can be viewed using --show-session-key? Yes, it is. However, decrypting a message does not automatically provide the session key to the user (outside of the internal functionality of the OpenPGP implementation). So what I'm saying is that even if you have an oracle that will decrypt messages on demand and provide them to the attacker, that doesn't mean that the oracle is going to provide the session key used to decrypt that message, which you need to conduct the attack. Also, please, please, please don't ever CC me. This resulted in a major delay as I deleted the message which I am now replying to and had to cobble it together based on the archive. Please respect my Mail-Followup-To and post replies only to the list. -- 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: hashed user IDs redux [was: Re: Creating a key bearing no user ID]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Thursday 26 January 2012 at 5:03:14 PM, in mid:4f218752.90...@sixdemonbag.org, Robert J. Hansen wrote: So let's see if we can't use a 'Problem', 'Goal', 'Requirements' and 'Constraints' model to focus the conversation a little bit. PROBLEM: * Some people want to make it possible to opt out of their email addresses being harvestable on the keyservers. GOAL: * Give users an optional way to make their user IDs resistant to harvesting. The use of the word harvesting in this context suggests to me a concern about spamming rather than about privacy. And I would like the ability to protect my name as well as (or instead of) my email address. REQUIREMENTS: * The solution must work within the OpenPGP framework without requiring any extensions. * The solution must work with SKS without requiring any extensions. * The User ID must be searchable (otherwise the solution is trivial, create a User ID with a name but no email address). If a user searches the keyserver for exactly a given email address, matching certificates must be returned. Is without requiring any extensions a necessary requirement? If a solution were feasible that required an extension or a local proxy to handle the keyserver queries, why should it be discarded? CONSTRAINTS: * Key enumeration. There are only roughly 10 million login names five characters or less. Searching those 10 million login names over the top 100 email domains amounts to about a billion queries. Split over a botnet of 100,000 elements, each bot would have to make 10,000 queries. Even if each query took one second (an unreasonable number: it would substantially impact OpenPGP adoption because people would be furious over the slow speed of lookups), that means a spammer network could break any such blinded hashing scheme in about three hours. Why would a spammer network bother to generate email addresses and submit them as keyserver queries, rather than just sending spam out to them all? I guess the day *could* arrive when we start receiving spam that is encrypted to the right key(s) for the email address(es) it goes to, but I currently see that more as a possibility than a probability. ... Looking over this, I don't think that what MFPA wants is possible. I just don't. The key enumeration issue and the ease of getting past it, *even if we require each search to take one second to execute*, is the gorilla in the center of the room that's threatening to pound to a pulp anyone who seriously tries to take on this problem. I think that what you say is impossible, is more than I am looking for from this scheme. That strength of protection would be brilliant but rather pointless in the context. Lets assume for a moment the goal you have stated above has been reached, including an airtight solution to the key enumeration issue. What do we really have? I have names and email addresses in blinded User IDs on my key and they are believed to be safe for a long time given the current technology. For want of a better analogy, the names and email addresses readable from User IDs on the keyservers are akin to listings in the phone book. The names and email addresses that cannot be read because they are obscured in blinded User IDs are akin to unlisted phone numbers. There is a certain level of protection afforded by choosing not to have your number listed, but you can still tell anybody the number yourself and they might accidentally or deliberately pass it on. Even if you succeed, how many people will join up? I don't know. For telephone numbers, as I posted in a thread here in July 2010, the owners of 78% of the non-business landline numbers in my address book at the time had made the effort to not have their numbers listed in the phone books. Mobile phone numbers are unlisted by default; not a single person had arranged a listing for their non-business mobile. Not scientific. Not representative. Just the contents of my address book. - -- Best regards MFPAmailto:expires2...@rocketmail.com Pain is inevitable, but misery is optional. -BEGIN PGP SIGNATURE- iQCVAwUBTyHkqaipC46tDG5pAQpIFAP+Pk6XUci+VVZaGeN7D3nLM3sZuCRhL03O iIAwQR0TnTYIUC8uD07TfrQDsXmEOVa3a4yDSX7AGIFgbqG0oKUioEecpDwbZinm 6LKorTNkxbp2J2WiVdaLW+4/fQ5ytjn0jxDKvmoRb3Bf8hgSjCUy/zxkYCQ2KHxT xoU7IlSeC9g= =a9JS -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs redux [was: Re: Creating a key bearing no user ID]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/26/2012 15:41, MFPA wrote: The use of the word harvesting in this context suggests to me a concern about spamming rather than about privacy. And I would like the ability to protect my name as well as (or instead of) my email address. As I said the last time you brought this up put whatever you like in the name and e-mail fields, and notify the people you communicate with of what's there, and the fingerprint of the key. They can then set up rules in their e-mail client that when they communicate with you via e-mail address foo that they should use key bar. You're done. There is no software modification needed to accomplish what you want to do. Doug - -- It's always a long day; 86400 doesn't fit into a short. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJPIfReAAoJEFzGhvEaGryEZ+sH/0ePlo1pAS4Y/NLpNfPseN5f lnQM7Fpt8QUsUG7zyxKsk4zG8RNy1YQTqjY38HjUP0u9ykgp2v0kT2UxfyLCMXte iZtoxTqZW0Fa8GAurPrSH7GD7RtCYmtKOOP5q5+Ep2UfIu/Uh+rcGbkpXVszSKnF 9yLQvSKUDvzC/P10YKbuP0p96UuYsStv+bmN8rNGt4BoOgEDeBPlflVUhIco6WKI sylguccRvnvKjMFk6FA9AhsEP/bBKzf0LoaXEczhJOkZ9sUpZXCnAmQZKyzKNvWp Ir0pRyfYcyZsPIBDISAv4egz6eOPNEOgr42WkeqQu8ywg4rv4w97fJl0CJTIUnc= =bPyh -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs redux [was: Re: Creating a key bearing no user ID]
Doug Barton wrote: On 01/26/2012 15:41, MFPA wrote: The use of the word harvesting in this context suggests to me a concern about spamming rather than about privacy. And I would like the ability to protect my name as well as (or instead of) my email address. As I said the last time you brought this up put whatever you like in the name and e-mail fields, and notify the people you communicate with of what's there, and the fingerprint of the key. They can then set up rules in their e-mail client that when they communicate with you via e-mail address foo that they should use key bar. You're done. There is no software modification needed to accomplish what you want to do. DING! DING! DING! DING! We have a winner! You do not wish your name or email address in a certificate's UID, THEN DON'T PUT IT IN. Feed whatever text you wish through the hashing algorithm of your choice and use that. Bang! You're done. Just do it. OpenPGP and the software involved do not need any changes. And as Rob pointed out, any changes would have a difficult time getting accepted. -- 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: hashed user IDs redux [was: Re: Creating a key bearing no user ID]
On 1/26/2012 6:41 PM, MFPA wrote: The use of the word harvesting in this context suggests to me a concern about spamming rather than about privacy. The use is correct. Spamming is what someone does once they have your private information: harvesting is the act of collecting. And I would like the ability to protect my name as well as (or instead of) my email address. One windmill at a time, my ingenious gentleman of La Mancha. Is without requiring any extensions a necessary requirement? Necessary is a strong word. The consequence of extending it is you get to be the one to write the extensions (both in RFC and source-code form) and maintain them across a whole raft of other operating systems and hardware configurations. If a solution were feasible that required an extension or a local proxy to handle the keyserver queries, why should it be discarded? A local proxy is not an extension. An extension means we're going to break conformance with the OpenPGP spec or we're going to break compatibility with the SKS keyserver network. If you break conformance with the OpenPGP spec, then you get to build the new spec. If you break compatibility with the SKS network, then you get to build a new network to replace it. Why would a spammer network bother to generate email addresses and submit them as keyserver queries, rather than just sending spam out to them all? I have been waiting for you to realize this. *Even if you solve the key enumeration problem, you solve nothing.* It doesn't get you anything, because the email enumeration problem is just as bad. For want of a better analogy, the names and email addresses readable from User IDs on the keyservers are akin to listings in the phone book. The names and email addresses that cannot be read because they are obscured in blinded User IDs are akin to unlisted phone numbers. And yet, my two unlisted cell phones both routinely get robocalls and telemarketers. They, too, work by enumeration. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
