Re: Restarting gnupg-agent inside X session
On Tue, 1 Mar 2011 02:41, da...@systemoverlord.com said:
Other than on systems where $HOME is on a filesystem that does not
support sockets (e.g., NFS/CIFS/etc.), is anyone aware of an issue with
the use of --use-standard-socket? Seems like it would make restarting
GnuPG 2.1 will use --use-standard-socket by default. The windows port
does this for years. If you want to run a second gpg-agent, you need to
use a different homedir, though. I use
unset GPG_AGENT_INFO
unset SSH_AGENT_PID
export SSH_AUTH_SOCK=${HOME}/.gnupg/S.gpg-agent.ssh
in the startup script for interactive shells. The only software which
does not work correctly is Easypg because it uses GPG_AGENT_INFO to
decide whether it shall ask for a passphrase; given that this is Emacs,
I can easily fix it.
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Restarting gnupg-agent inside X session
Daniel Kahn Gillmor wrote: On 02/28/2011 06:49 PM, David Tomaschik wrote: Each process has its own copy of the environment inherited from its parent, so it's not possible to change the GPG_AGENT_INFO variable for all processes. You could start gpg-agent with --use-standard-socket, and programs should fall back to that. Alternately, since you probably already know the current setting of GPG_AGENT_INFO, you could just start the agent and link its new socket to the place where the old one used to be. Something like (untested): old_socket=$(printf %s $GPG_AGENT_INFO | sed 's/:.*$//') mkdir -m 0700 -p $(dirname $old_socket) eval $(gpg-agent --daemon) new_socket=$(printf $s $GPG_AGENT_INFO | sed 's/:.*$//') ln $new_socket $old_socket David and Daniel, many thanks for your suggestions! I was not aware of the --use-standard-socket option. I think this will do it for me. Linking the new socket to the old one is also a nice way I didn't think of and maybe it will be useful someday. Marco -- OpenPGP Key ID: 0x62937F7F signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GnuPG Card with ssh authentication problems
On Sun, 27 Feb 2011 20:16, k...@grant-olson.net said: If you want someone to cleanup and update the howto, I volunteer. I just need to know the name of the cvs project. 'card-howto' didn't seem to work. It is the module card-howto in the gpgweb repository. However, I recently started to convert it from Docbook to org-mode. This is not finished, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Default hash
I believe that within the next five years someone will discover an academic attack against Rijndael. I do not believe that anyone will ever discover an attack that will allow someone to read Rijndael traffic. So while I have serious academic reservations about Rijndael, I do not have any engineering reservations about Rijndael. -- Bruce Schneier, Cryptogram Newsletter, October, 2000. From Schneier/Ferguson's 2003 book, Practical Cryptography: We don't quite trust the security...No other block cipher we know of has such a simple algebraic representation. We have no idea whether this leads to an attack or not, but not knowing is reason enough to be skeptical about the use of AES. However, even though he has reservations about Rijndael, he has said publicly numerous times that he prefers everyone to use AES instead of the other finalists, no doubt because it has had undeniably more analysis thrown its way. -- View this message in context: http://old.nabble.com/Default-hash-tp31002378p31033879.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
CA Certificate on GPF Cryptostick
Hi, I´m trying to move a private Key (RSA, PEM format) made by a Microsoft CA to the GPF Crypto Stick. gpgsm tells me while importing: pgsm: no issuer found in certificate gpgsm: basic certificate checks failed - not imported ERROR: object length field 1 octects too large ERROR: object length field 1 octects too large gpgsm: total number processed: 1 gpgsm: not imported: 1 Any idea? Is it possible to do the import? Thanks, Mario ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Why do we use a different key to sign than to encrypt
Not GPG specific, but I was wondering if someone could point me in the direction of some resources that explain why we use different keys to sign and encrypt (for cases where the same key _could_ do both e.g. RSA). I cant seem to pick anything up on google. Thanks -- Guy Halford-Thompson - http://www.cach.me/blog ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: PGP/MIME considered harmful for mobile
Op 28-2-2011 23:23, Robert J. Hansen schreef: He then learned that his users thought the banner across the top was just another one of those annoying Flash ads, and they tuned it out. Their senses were dulled by overadvertising. He had better also distributed Adblock Plus to try to counter the sensory overload. -- Met vriendelijke groet, Johan Wevers ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Smart Card Physical Best Practices?
On Sat, Feb 26, 2011 at 09:40:07PM -0500 Also sprach David Tomaschik: I've recently received my smart card, but was wondering what the best practices are, mainly from a physical standpoint. When I use it in my laptop reader, it sticks about 2 out of the side, and I have some concern about this (i.e., getting damaged by being pushed into something, etc.). I am using the Authentication key on it for SSH, and the normal signing encryption operations, so I suppose I need it when sending signed email and signing into a system. Do most people leave it in the computer most of the time, or just insert it as needed? This brings to mind: how many insertion cycles can these cards handle? Looking online, various smart cards are rated anywhere from 10,000 to 250,000 insertions. (At 10,000, as few as 10 insertions per day would net a 3 year lifetime.) If you are concerned with the insertion-limited lifetime, and with other possible kinds of damage to the smart card itself, perhaps you should consider getting one of the versions with the SIM removal option. Pop the chip out of the card and put it inside one of those USB tokens that take them. Then the SIM itself is always (at least partially) protected inside a casing, and the insertion problem is offloaded onto the USB mechanism (which is more expendable). If the USB token fails eventually, take the SIM out and put it in a new one; you may have been using it for years by then, but your effective insertion count is 2. As an added bonus, you may use your OpenPGP card on any computer with a USB port, without needing a separate card reader available. -- Le hasard favorise l'esprit préparé. --Louis Pasteur pgpOJgEYqnxrY.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[Announce] Libksba 1.2.0 released
Hello! We are pleased to announce version 1.2.0 of Libksba. Libksba is an X.509 and CMS (PKCS#7) library. It is for example required to build the S/MIME part of GnuPG-2 (gpgsm). The only build requirement for Libksba itself is the libgpg-error package. There are no other dependencies; actual cryptographic operations need to be done by the user. Libksba is distributed under the GPLv3+. There are no user tools accompanying this software, thus it is mostly relevant to developers. This release adds features required by the GnuPG 2.1 development version. You may download the library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.2.0.tar.bz2 (575k) ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.2.0.tar.bz2.sig Noteworthy changes in version 1.2.0 (2011-03-01) * New functions to allow the creation of X.509 certificates. * Interface changes relative to the 1.1.0 release: ~~ ksba_certreq_set_serial NEW. ksba_certreq_set_issuer NEW. ksba_certreq_set_validityNEW. ksba_certreq_set_siginfo NEW. Commercial support contracts for Libksba are available, and they help finance continued maintenance. g10 Code, a Duesseldorf based company owned and headed by Libksba's principal author, is currently funding its development. We are always looking for interesting development projects. See also http://www.gnupg.org/service.html . Happy hacking, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-announce mailing list gnupg-annou...@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
need help on non-interactive gnuPG binary
Hi, I am planning to use gnuPG (v1.4.10) binary in netbsd 5 for encryption. The key generation is supported as interactive session, but I want to use non interactive session. I could not find any binary with non interactive session. Does anyone know where to get such a binary?? Regards, Ravi ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why do we use a different key to sign than to encrypt
On Mar 1, 2011, at 8:13 AM, Guy Halford-Thompson wrote: Not GPG specific, but I was wondering if someone could point me in the direction of some resources that explain why we use different keys to sign and encrypt (for cases where the same key _could_ do both e.g. RSA). I cant seem to pick anything up on google. There is no one reason, but a few reasons that, taken together, makes this useful. One reason is that it enables the use of sign-only or encryption-only algorithms, which if one key had to do it all, would not be usable. Another reason is that it helps prevent a complete compromise - if only a subkey is compromised, the whole key is not compromised. It allows for the best-algorithm-for-the-job decision to be made (for example, many people like signing with DSA because the signatures are physically smaller and thus not so obvious in email). It allows easier key changes without changing the main identity key by expiring or revoking just a subkey and making a new one. And so on. Some of these reasons overlap as well. OpenPGP supports both the single-key and multiple-key models, so you're not forced to do it one way or the other. The default in GnuPG is multiple key. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why do we use a different key to sign than to encrypt
On Tue, Mar 01, 2011 at 01:13:16PM + Also sprach Guy Halford-Thompson: Not GPG specific, but I was wondering if someone could point me in the direction of some resources that explain why we use different keys to sign and encrypt (for cases where the same key _could_ do both e.g. RSA). This may not be the whole story, but I did manage to find this: http://www.di-mgt.com.au/rsa_alg.html#weaknesses -- Le hasard favorise l'esprit préparé. --Louis Pasteur pgpbqg3nFtKvE.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: need help on non-interactive gnuPG binary
On Mar 1, 2011, at 7:39 AM, ravi shankar wrote: Hi, I am planning to use gnuPG (v1.4.10) binary in netbsd 5 for encryption. The key generation is supported as interactive session, but I want to use non interactive session. I could not find any binary with non interactive session. Does anyone know where to get such a binary?? The regular 1.4.10 binary supports non-interactive key generation. See the file 'doc/DETAILS' in the GnuPG distribution, and specifically the section Unattended key generation. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why do we use a different key to sign than to encrypt
Thanks for the list of resources G On 1 March 2011 14:41, Jeffrey Walton noloa...@gmail.com wrote: On Tue, Mar 1, 2011 at 8:13 AM, Guy Halford-Thompson g...@cach.me wrote: Not GPG specific, but I was wondering if someone could point me in the direction of some resources that explain why we use different keys to sign and encrypt (for cases where the same key _could_ do both e.g. RSA). I cant seem to pick anything up on google. Key separation and management. See Handbook of Applied Cryptography, Chapter 13 (http://www.cacr.math.uwaterloo.ca/hac/). Jeff -- Guy Halford-Thompson - http://www.cach.me/blog ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Why do we use a different key to sign than to encrypt
On Tue, Mar 1, 2011 at 9:34 AM, lists.gn...@mephisto.fastmail.net wrote: On Tue, Mar 01, 2011 at 01:13:16PM + Also sprach Guy Halford-Thompson: Not GPG specific, but I was wondering if someone could point me in the direction of some resources that explain why we use different keys to sign and encrypt (for cases where the same key _could_ do both e.g. RSA). This may not be the whole story, but I did manage to find this: http://www.di-mgt.com.au/rsa_alg.html#weaknesses The weaknesses documented there do not seem to apply to OpenPGP (and hence GnuPG). One, messages are not actually encrypted with RSA; a symmetric algorithm is used to encrypt messages and the key to that encryption is encrypted with RSA. I believe that GnuPG uses a larger encryption exponent, reducing the threat posed by the Chinese Remainder Theorem. The threat of the same key on that page only applies where the RSA encryption was done to the plain text directly. Likewise, OpenPGP signing is done on a hash of the plain text. (Again, not on the plain text directly.) David -- David Tomaschik, RHCE, LPIC-1 System Administrator/Open Source Advocate OpenPGP: 0x5DEA789B http://systemoverlord.com da...@systemoverlord.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Security of the gpg private keyring?
On Tuesday 01 March 2011, David Shaw wrote: On Feb 28, 2011, at 7:09 PM, David Tomaschik wrote: I think key UIDs generally reveal more information than I am comfortable with. For example, why does your UID need to contain your email address in plain text rather than as a hash? Searching for that email address would need to return any keys that matched on the hashed version in addition to any keys that matched on the plaintext version. Somebody knowing the email address (or name or hostname) could find the key but mere inspection of the key UIDs would not reveal all its owner's names, email addresses, etc. I'm usually told such an option does not exist because it would serve no purpose and/or there would be no demand for it. While I understand your concerns, I think it would just be nice if the owner of a key could set a flag on it indicating that they did not want their key published to keyservers. Then privacy could be preserved with MUCH smaller changes to infrastructure. (Though, admittedly, it might require a change in the OpenPGP spec, which would actually be much larger.) This flag actually exists in OpenPGP already (and what's more, GnuPG even sets it by default). The catch is that none of the other infrastructure (keyservers, mainly) checks it, and given the current design of the keyservers and how they sync key data between them, they can't easily check it. It would be a very large (I'd say even larger than the hashed user ID example above) task to make this flag truly useful. Hmm. Why do the keyservers need to support it at all? IMO the clients that want to upload a key should check for this flag and warn the user if a key has this flag. Of course, this won't stop people from uploading keys with clients that do not support this flag, but at least those people that use a flag-enabled client will be made aware of the key owner's wish not to upload the key. Regards, Ingo 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: PGP/MIME considered harmful for mobile
On Sunday 27 February 2011, Doug Barton wrote: On 02/27/2011 02:04, Ingo Klöcker wrote: On Saturday, February 26, 2011, MFPA wrote: Hi On Friday 25 February 2011 at 1:45:03 AM, in mid:87lj14x4yo@servo.finestructure.net, Jameson Rollins wrote: Yikes! I thought we were almost done killing inline signatures! Don't revive it now! If PGP/MIME is broken on android, we need to get them to fix it, not go backwards to inline pgp. Using inline PGP signatures means using the simpler and more reliable of the two solutions. The fact that its specification was defined earlier does not mean using inline signatures is a step backwards; PGP/MIME is a complement to pgp inline, not a replacement. The major problem I see with using cleartext signatures in email is the lack for support of non-ASCII text (or, more precisely, character encoding). Can you provide examples that do not work when both the mail client(s) and gnupg are properly configured to use UTF-8? No, sorry. I haven't been using inline PGP signatures for ages and neither do most of the people I exchange emails with. Therefore I cannot provide real world examples. Back when I was still using inline PGP signatures I regularly got replies with a full quote of my inline-signed message where the signature on the quoted message was broken. You might say that it's not relevant because it's just a quote. But I say it is very relevant if such a reply is forwarded to a third party. And also if it isn't forwarded a bad signature is still highly irritating (at least to me). Of course, my experience is from a time when UTF-8 wasn't used in email. But do the standard mail clients (Outlook, GMail, Thunderbird) really default to UTF-8 nowadays? Expecting people to properly configure their mail clients is an unrealistic dream. Regards, Ingo 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
key generation problems
Hi, I have CentOS 5.5 with gnupg 1.4.5. I am using the following command to generate the keys: echo LinuxMasters | /usr/bin/gpg --homedir /home/USER/.gnupg -e -a -r em...@domain.com /somefile The problem I am facing is that until today all the keys generated using this command had the same size of 1261 bytes and were working properly. Now when I do it the keys have the size of 912 bytes and no longer work. Absolutely nothing changed config related on the server. If I need to send you more info regarding my configs please tell me what and I will send. So my question is, why is this happening? Please help Thanks ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Security of the gpg private keyring?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 1 March 2011 at 8:56:56 PM, in mid:201103012156.57...@thufir.ingo-kloecker.de, Ingo Klöcker wrote: Hmm. Why do the keyservers need to support it at all? IMO the clients that want to upload a key should check for this flag and warn the user if a key has this flag. I think the warning would be a good idea because it should serve to reduce accidental uploading of keys (except by those who view such warnings as noise and just click through without really reading them). Since the keyserver-no-modify flag is set by default in GnuPG and this warning would be triggered for a large percentage of keys, why bother checking for the flag? Do you really want to publish this key to a keyserver? could be asked every time the user told the client to upload any key, perhaps also displaying some info about the key and the server. - -- Best regards MFPAmailto:expires2...@ymail.com If it aint broke, fix it till it is broke! -BEGIN PGP SIGNATURE- iQE7BAEBCgClBQJNbYFUnhSAAEAAVXNpZ25pbmdfa2V5X0lEIHNpZ25pbmdf a2V5X0ZpbmdlcnByaW50IEAgIE1hc3Rlcl9rZXlfRmluZ2VycHJpbnQgQThBOTBC OEVBRDBDNkU2OSBCQTIzOUI0NjgxRjFFRjk1MThFNkJENDY0NDdFQ0EwMyBAIEJB MjM5QjQ2ODFGMUVGOTUxOEU2QkQ0NjQ0N0VDQTAzAAoJEKipC46tDG5pFKAEAIXA JlNpZtG1aUk4j+t25EVUMh/Wwx02fSLwsRfmjgb8W46B6ZWUJz3qkU0oum+HdKQn U/ADiI1jQsS33jcKtqHQd6okI72r5w4dEWfFc7E8Y0c42g4x/1n1kJd5ofSjivZV DxQf3NC4rwtYNebSThraOasVkTmr2V+CQHnfw04v =/QiR -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Security of the gpg private keyring?
On Mar 1, 2011, at 6:29 PM, MFPA wrote: On Tuesday 1 March 2011 at 8:56:56 PM, in mid:201103012156.57...@thufir.ingo-kloecker.de, Ingo Klöcker wrote: Hmm. Why do the keyservers need to support it at all? IMO the clients that want to upload a key should check for this flag and warn the user if a key has this flag. I think the warning would be a good idea because it should serve to reduce accidental uploading of keys (except by those who view such warnings as noise and just click through without really reading them). Since the keyserver-no-modify flag is set by default in GnuPG and this warning would be triggered for a large percentage of keys, why bother checking for the flag? Do you really want to publish this key to a keyserver? could be asked every time the user told the client to upload any key, perhaps also displaying some info about the key and the server. For that matter, you could just emit the warning for any key that you don't also have the secret part for. That is, keys that have a higher chance of not being yours. I would worry about the warning being invisible after a while though. 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?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi On Tuesday 1 March 2011 at 1:54:25 AM, in mid:4d6c51d1.6030...@fifthhorseman.net, 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 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 Wednesday 2 March 2011 at 1:43:45 AM, in mid:4d6da0d1.20...@fifthhorseman.net, 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?]
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
