Details of signature verification status-fd lines
Just a quick question on the --status-fd output from a --verify operation: if EXPSIG, EXPKEYSIG, or REVKEYSIG are given, could VALIDSIG or GOODSIG also show up? In other words, are these just for more information on why a signature failed, or can they qualify the GOOD and VALID outputs? Thanks -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Details of signature verification status-fd lines
On Tue, Sep 22, 2009 at 11:19 AM, Werner Koch w...@gnupg.org wrote: On Tue, 22 Sep 2009 16:26, bmea...@ieee.org said: Just a quick question on the --status-fd output from a --verify operation: if EXPSIG, EXPKEYSIG, or REVKEYSIG are given, could VALIDSIG or GOODSIG also show up? In other words, are these just for It depends. EXPKEYSIG for example may come in addition to VALIDSIG. VALIDSIG is the modern version of GOODSIG. Except for the description in doc/DETAILS we don't have a more specific description (it is on our task list, though). The best way to see what you can expect is to look at the gpgme code. gpgme/src/verify.c computes the validity of signatures. Processing the NEWSIG status line is in general a good idea so that you don't mix the status lines given for different signatures. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. Thanks for the response. So EXPKEYSIG doesn't mean the key was expired when the signature was made, right? If that shows up along with VALIDSIG, it's ok to trust the signature, correct? What about REVKEYSIG? If a key is revoked, is there an easy way to know if the signature was made prior to revocation, or would it be necessary to just compare the stamps on the signature and the revocation? Thanks, -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Details of signature verification status-fd lines
On Tue, 22 Sep 2009 16:26, bmea...@ieee.org said: Just a quick question on the --status-fd output from a --verify operation: if EXPSIG, EXPKEYSIG, or REVKEYSIG are given, could VALIDSIG or GOODSIG also show up? In other words, are these just for It depends. EXPKEYSIG for example may come in addition to VALIDSIG. VALIDSIG is the modern version of GOODSIG. Except for the description in doc/DETAILS we don't have a more specific description (it is on our task list, though). The best way to see what you can expect is to look at the gpgme code. gpgme/src/verify.c computes the validity of signatures. Processing the NEWSIG status line is in general a good idea so that you don't mix the status lines given for different signatures. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
choosing an encryption target from a User ID
when encrypting messages to a user ID with multiple matching keys with full calculated validity, gpg seems to just choose the first matching key, for some definition of first -- i think it's decided by chronological age of first import into the local keyring. This does not seem to be the best heuristic. here are some other proposed heuristics for choosing among multiple keys with full calculated User ID validity during encryption: 0) choose the most recently-created key 1) choose the key with the strongest supported encryption-capable subkey (by bitlength?) 2) encrypt to *all* matching keys The current implementation does what seems to be the Wrong Thing in the use case where the recipient is going through a key transition, and has two keys (one older, deprecated but not yet expired; and one newer, stronger, preferred). Any thoughts on this? Should i open it as a ticket? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
Daniel Kahn Gillmor wrote: when encrypting messages to a user ID with multiple matching keys with full calculated validity, gpg seems to just choose the first matching key, for some definition of first -- i think it's decided by chronological age of first import into the local keyring. IIRC, it's the first usable key with a matching User ID. Period. First one it can use. PS: Would you touch the membership file on zimmermann.mayfirst.org? ISP DHCPed a new IP when I replaced a dead router over the weekend. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. 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: howto secure older keys after the recent attacks
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 David Shaw wrote: There are occasional debates on who has the better PRNG. The debates usually end with no changes on either side :) That isn't to say there aren't differences between systems - the FreeBSD PRNG (which seems to have been inherited by OSX) is of a fairly different construction than the Linux one, which has led to some mild controversy in the past. Notably, the Linux one blocks if you run out of gathered entropy, and the FreeBSD one does not. FreeBSD /dev/random is similar to Linux's /dev/urandom. That description is not quite accurate. FreeBSD (and OSX, which actually inherited quite a bit of userland and other bits from FreeBSD) uses the Yarrow PRNG. Here is an excerpt from the wikipedia /dev/random article: Yarrow places a lot of emphasis on avoiding any pool compromise and on recovering from it as quickly as possible. It is regularly reseeded; on a system with small amount of network and disk activity, this is done after fraction of a second. http://en.wikipedia.org/wiki//dev/random So while it is correct to say that like a traditional SysV /dev/urandom our /dev/random does not block (except in extraordinary circumstances, unlikely to happen in any real world application), it is not correct to say that it continues handing out bits of dubious quality when it runs out of entropy. (I realize that is not specifically what you said David, but since at least one reader seems to have come to that conclusion based on what you did say so I felt compelled to respond.) As the wikipedia article also points out we have support for hardware entropy devices as well so anyone doing heavy duty crypto stuff has that option available. But for the casual user our current system is more than enough. And yes, I realize that this is an area of debate, which is why I purposely included your first quote above in my reply. :) My purpose is not to debate which is better, rather to bring some light to the topic of what we're actually doing. Anyone interested in more details about Yarrow can read the paper at http://www.schneier.com/paper-yarrow.html. hth, Doug (aka do...@freebsd.org) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.13 (FreeBSD) iEYEAREDAAYFAkq5KD0ACgkQyIakK9Wy8Pv8dwCeMbTkNlTvaK2Npz7acx3zlzCW pxEAoMaj4NhMmoX9xu5c9d4MThuVjTT8 =MsTX -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 John Clizbe wrote: IIRC, it's the first usable key with a matching User ID. Period. First one it can use. My usual 'solution' for this is to 'Disable' the non-preferred or unused Key until such time as it is Revoked or I have been otherwise informed it is deprecated beyond any further use. JOHN ;) Timestamp: Tuesday 22 Sep 2009, 16:09 --400 (Eastern Daylight Time) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJKuS8VAAoJEBCGy9eAtCsPIAMH/iHFYbkgRit0CWEPDq9Oyhdi PvJwBnppkbU1YXF54MEV2y9+88FSl3A5crZyBkLt+MKvMEuYZO906+7xxmNQZ6u6 7wCNYjX5VbiKVHyT4k4N6AJBn4fuZB3jswK9yWylo2Loz2YjDfvnnpXIbxhuM2co ct8aiCjOKPMdvaw9KwhgcczOia0GGZlK9Rp7qCrt6TS/WguRecQX9h/NpZR8jjSY S6MpSIuVXvoPWU/GlednH2Rmp11f7xdOKHwYkwDV9gq03ql8l8sTdzFr6T0LEBY+ tEZRroTaoUfu53+yvJm75kkkqBlRpbVEphKQaGbaSWaxCDaoU5kYkfLlztlxXlQ= =X28H -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Sep 22, 2009, at 1:11 PM, Daniel Kahn Gillmor wrote: when encrypting messages to a user ID with multiple matching keys with full calculated validity, gpg seems to just choose the first matching key, for some definition of first -- i think it's decided by chronological age of first import into the local keyring. This does not seem to be the best heuristic. here are some other proposed heuristics for choosing among multiple keys with full calculated User ID validity during encryption: 0) choose the most recently-created key 1) choose the key with the strongest supported encryption-capable subkey (by bitlength?) 2) encrypt to *all* matching keys The problem with this sort of thing is that for every possible heuristic we can come up with, there is going to be someone who that heuristic breaks. GnuPG has done the first matching key since the beginning, as did (old) PGP[1]. That behavior is baked deeply into systems. David [1] PGP has a GUI nowadays, so this sort of thing doesn't apply in the same way any longer. I don't have my copy of PGP command line online at the moment, so I can't check what it does, but I'd be surprised if it didn't either take the first one or give an error message. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 David Shaw wrote: [1] PGP has a GUI nowadays, so this sort of thing doesn't apply in the same way any longer. I don't have my copy of PGP command line online at the moment, so I can't check what it does, but I'd be surprised if it didn't either take the first one or give an error message. Like GPG it utilizes the 1st encountered Key that matches the Send To: address is valid. JOHN ;) Timestamp: Tuesday 22 Sep 2009, 16:57 --400 (Eastern Daylight Time) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJKuTosAAoJEBCGy9eAtCsPZH8H/1ARVU6lWN9IoaWrMGgf/z86 U33uTXD5rRMUZcdpmoFvwkso6Gc5vU7AM6yYcl5A8yYBWkQ9USfVhGZEVB7pX8/n AGKcHfm2TALDxCknqQWXrI7k1CHY10nQ9gNjwHooHTYIV1gTavm6tQGYPmQOsOds aKBITuxIw3hIcb6tm8gObi4V0I1NT7Qp4oeMWHJAhcDHJJ/KIoSRe4a4N1176eYC vdc2S6VT7tLqiuAH22np4e7Je1epTTq+0QNwnrKuMLTv80EGnYf7qixotOhaNWrC 18TSYarG9t5biEzc/vJEAWQEdCoN6af+mr/2aiGNBX5ikh/mRC/bA180ejtoKR0= =dbA2 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Daniel Kahn Gillmor wrote: On 09/22/2009 04:57 PM, John W. Moore III wrote: Like GPG it utilizes the 1st encountered Key that matches the Send To: address is valid. this is not what gpg does. gpg simply chooses the first key with a matching user ID, whether or irrespective of the calculated validity of the User ID in question. I was referring to the validity of the Key; _not_ the UID. If the Key isn't expired/revoked or disabled; GPG will use it when it comes upon it in the 1st order encountered. So does Command Line PGP. JOHN ;) Timestamp: Tuesday 22 Sep 2009, 17:07 --400 (Eastern Daylight Time) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJKuTygAAoJEBCGy9eAtCsPB+UH/0OUuuUAXhTG7n4lTpXkedjO TwsYHPLsCvTws9Zgym+Ojw/NuPeD27hb82AWHz128mF+iL/88TJ5MCdLb/RV7tm8 fAMlSDVDjJQELUDKwLyhT3+eFKSh3SU+PegRmf0yZzEdj01Fv9LURb9O7e8TxXWQ sOMTxv9b4LL68ievBfWURE+AW2MtVBGRCfrIbbEQfeMsMGjKDD0jTZ+CoOWuaeY3 rWhSHQt8Fn23r3Wxc0D3FL1Tkk3KojKNt39NQI9XBMk/1D3/CIz4YS1Dw3dOVH0z 8FI0eRLTnm7RIN6i5C5cDOLUuUBdAkTmOSJ9zkikBAeOfs7K5i/rQKDDZjjAMe0= =W8qb -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Two tidbits of potential interest
First of all, someone has factored a 512-bit RSA key (the one used to protect a TI programmable calculator, it seems). It took 73 days on a dual-core 1900Mhz Athlon64. It took just under 5 gigs of storage and around 2.5 gigs of RAM. In other words: not much at all. It's not some big distributed project - rather it's a single guy who wanted to factor it and just left it running in the background for 2 and a half months. (This is actually a month old - forgot to send it before now). http://www.unitedti.org/index.php?showtopic= Also, here's the Stick Figure Guide to AES: http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On 09/22/2009 04:09 PM, John W. Moore III wrote: John Clizbe wrote: IIRC, it's the first usable key with a matching User ID. Period. First one it can use. thanks for catching that, John. It appears that if the first key with a matching User ID doesn't have full calculated validity, the user gets a scary warning that There is no assurance this key belongs to the named user, and then: It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. It does this even if there is a full-valid match later in the keyring! This doesn't seem like friendly or reasonable behavior for the power user, let alone the novice user. My usual 'solution' for this is to 'Disable' the non-preferred or unused Key until such time as it is Revoked or I have been otherwise informed it is deprecated beyond any further use. i'm assuming you mean gpg --edit-key 0xDECAFBAD followed by the disable subcommand. What do y'all think should actually be happening here? --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Two tidbits of potential interest
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi List readers, thanks to David Shaw for the nice URL: http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html This one I like very much; The pencil and paper approach. Also, here's the Stick Figure Guide to AES: http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html David however we will need elliptic curve ciphers in the next years or so? Sincerely yours, Morten 0x81802954 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (SunOS) Comment: For keyID and its URL see the OpenPGP message header iEYEARECAAYFAkq5Q6wACgkQ9ymv2YGAKVT7UgCfTAcsbpME8FbBdEhnW7psURR2 5wMAoMb9jmrGS8KrZn0MNGE2YXbMR4+W =ttIc -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Sep 22, 2009, at 4:40 PM, Daniel Kahn Gillmor wrote: On 09/22/2009 04:09 PM, John W. Moore III wrote: John Clizbe wrote: IIRC, it's the first usable key with a matching User ID. Period. First one it can use. thanks for catching that, John. It appears that if the first key with a matching User ID doesn't have full calculated validity, the user gets a scary warning that There is no assurance this key belongs to the named user, and then: It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. It does this even if there is a full-valid match later in the keyring! This doesn't seem like friendly or reasonable behavior for the power user, let alone the novice user. My usual 'solution' for this is to 'Disable' the non-preferred or unused Key until such time as it is Revoked or I have been otherwise informed it is deprecated beyond any further use. i'm assuming you mean gpg --edit-key 0xDECAFBAD followed by the disable subcommand. What do y'all think should actually be happening here? I think the current behavior is the right one. Otherwise we break however many baked-in uses out there (scripts, etc), to say nothing of having to explain to people why a particular key was chosen. We pick the first valid key cannot be misunderstood or confuse anyone. Yes, it's wrong for some situations. But every behavior is wrong for some situations. This particular wrong behavior has almost 20 years of history behind it. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On 09/22/2009 06:30 PM, David Shaw wrote: I think the current behavior is the right one. Otherwise we break however many baked-in uses out there (scripts, etc), to say nothing of having to explain to people why a particular key was chosen. We pick the first valid key cannot be misunderstood or confuse anyone. well, i'm living proof that it can confuse people, and that people can misunderstand it. It took me a while to sort out: a) what it was doing specifically (i originally thought it was sorting by key creation date) b) how to change the ordering of keys in a keyring (so far, i've only figured out how to move a given key to the end of the list: gpg --export --export-options export-local $KEYID tmpfile gpg --delete-key $KEYID gpg --import --import-options import-local tmpfile I suppose i could do arbitrary bubble-sort-ish reorderings with this primitive, too; is there another way?) c) that gpg is even willing to settle on a key with a matching User ID with no calculated validity (e.g. if i added a user ID of Daniel Kahn Gillmor ds...@jabberwocky.com to my key, even if no one else certified it, then anyone who had met me before meeting you would need to specify your key by key ID, instead of by e-mail address!) Yes, it's wrong for some situations. But every behavior is wrong for some situations. This particular wrong behavior has almost 20 years of history behind it. I hear you. I've offered some concrete examples of ways that the current behavior breaks things. Can you give me an example of a script that has this behavior baked in to the point where adopting a better heuristic would break it? Also, i believe this behavior is *only* relevant in situations where the user asks gpg to encrypt something to a name or User ID. Is that right? or are there other circumstances in gpg where the choose the first matching User ID heuristic is used? Thanks for thinking through this with me, --dkg signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: choosing an encryption target from a User ID
On Sep 22, 2009, at 6:54 PM, Daniel Kahn Gillmor wrote: Can you give me an example of a script that has this behavior baked in to the point where adopting a better heuristic would break it? It doesn't work that way. The default is the first valid key. It's been that way in the PGP world since before GPG as a product was written. If you want to propose a specific alternative, I'm ready to listen, but I'm not going to defend the default behavior of 15+ years. Also, i believe this behavior is *only* relevant in situations where the user asks gpg to encrypt something to a name or User ID. Is that right? or are there other circumstances in gpg where the choose the first matching User ID heuristic is used? It's used everywhere user IDs are referenced in the product. --list- keys. --edit-key, --sign-key, etc, etc. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Entropy sources for rngd
Sorry, I know this is only somewhat on topic: if someone can suggest an appropriate mailing-list or news group, that'd be great. I want to use rngd to increase my entropy pool for use with GnuPG, but I don't have a hardware random device. I've seen a lot of references to using /dev/urandom as the input source for rngd, which claim that rngd's randomness test is sufficient for ensuring that the entropy pool remains random. But there's something that really doesn't sit well about that for me. Can anyone offer informed insight on this? Thanks, -Brian -- Feel free to contact me using PGP Encryption: Key Id: 0x3AA70848 Available from: http://keys.gnupg.net ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
