From peter at digitalbrains.com Thu Dec 1 11:11:13 2011 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 01 Dec 2011 11:11:13 +0100 Subject: Possible IPv6 bug for --keyserver option In-Reply-To: <4ED6B28F.40205@dougbarton.us> References: <4ED61F02.1050603@lists.grepular.com> <2891EF58-6DF5-46F9-8C8C-0A0589BE0804@jabberwocky.com> <4ED65D1F.5020701@lists.grepular.com> <3762667F-55C3-4684-B93C-FC2BE5BD4AE6@jabberwocky.com> <4ED6707B.90507@lists.grepular.com> <4ED68315.60103@digitalbrains.com> <4ED6B28F.40205@dougbarton.us> Message-ID: <4ED752C1.6040209@digitalbrains.com> On 30/11/11 23:47, Doug Barton wrote: > This usually happens when the OS has signaled that it has IPv6 > available, but it's not actually configured on any interfaces. The usual > way to fix this is to flip the knob that says "IPv6 is *not* available." Ah, okay. I figured this was not the case because his interfaces don't even have link-local autoconfigured addresses. I thought those would be active as soon as you enable IPv6. > Of course, a better way to fix it is to get IPv6. :) Check. None of my machines do without :). Anyway, GnuPG can't help what the library and OS do. 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 From toskp10 at gmail.com Thu Dec 1 10:02:22 2011 From: toskp10 at gmail.com (Thomas Martin) Date: Thu, 1 Dec 2011 13:02:22 +0400 Subject: Gnupg file formats Message-ID: Hello all, I'm interested in learning more about how cryptography is applied, and I'm trying to understand the file formats used by Gnupg. The RFC4880 has been a great help. In looking at an private key I can find the MPI's for the public and private parameters. In looking at a ciphertext, I can find the Key ID and the RSA encrypted symmetric key. What I'm struggling with is the first few characters of the files. Why does a 1024 RSA private key start with the three bytes \x9501D8? Why does a 2048 bit key start with the four bytes \x99010D04? Why does a ciphertext encrypted with a 1024 bit RSA key start \x848C03? Why is it \x85010C03 for 2048 bit RSA? Is this explained in the RFC somewhere I've missed or is it documented elsewhere? Any help would be appreciated. Thomas. From wk at gnupg.org Thu Dec 1 18:22:15 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2011 18:22:15 +0100 Subject: Card only available to root user In-Reply-To: <4ED69FB7.3090100@enigmail.net> (Olav Seyfarth's message of "Wed, 30 Nov 2011 22:27:19 +0100") References: <20110804212536.GA31134@atlas> <20110804214955.GB31134@atlas> <4ED54046.3090102@privacyfoundation.de> <4ED54965.4050502@enigmail.net> <877h2h91k8.fsf@vigenere.g10code.de> <4ED69FB7.3090100@enigmail.net> Message-ID: <87zkfc5hrs.fsf@vigenere.g10code.de> On Wed, 30 Nov 2011 22:27, olav at enigmail.net said: > And: I can access --card-status as root, just not as user ... Set up your udev rules or whatever is used on your system to setup correct permissions for the USB device. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Dec 1 18:25:59 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 01 Dec 2011 18:25:59 +0100 Subject: Gnupg file formats In-Reply-To: (Thomas Martin's message of "Thu, 1 Dec 2011 13:02:22 +0400") References: Message-ID: <87vcq05hlk.fsf@vigenere.g10code.de> On Thu, 1 Dec 2011 10:02, toskp10 at gmail.com said: > ciphertext encrypted with a 1024 bit RSA key start \x848C03? Why is it > \x85010C03 for 2048 bit RSA? Is this explained in the RFC somewhere > I've missed or is it documented elsewhere? Read section 4.2 of RFC-4880. The length header encoding is a bit complicate. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dpmcgee at gmail.com Thu Dec 1 18:37:52 2011 From: dpmcgee at gmail.com (Dan McGee) Date: Thu, 1 Dec 2011 11:37:52 -0600 Subject: Gnupg file formats In-Reply-To: <87vcq05hlk.fsf@vigenere.g10code.de> References: <87vcq05hlk.fsf@vigenere.g10code.de> Message-ID: On Thu, Dec 1, 2011 at 11:25 AM, Werner Koch wrote: > On Thu, ?1 Dec 2011 10:02, toskp10 at gmail.com said: > >> ciphertext encrypted with a 1024 bit RSA key start \x848C03? Why is it >> \x85010C03 for 2048 bit RSA? Is this explained in the RFC somewhere >> I've missed or is it documented elsewhere? > > Read section 4.2 of RFC-4880. ?The length header encoding is a bit > complicate. The pgpdump source code may be a bit more easy to grasp if you just want to understand the file format. http://www.mew.org/~kazu/proj/pgpdump/en/ -Dan From pat.hall at ddpmo.org Thu Dec 1 19:50:02 2011 From: pat.hall at ddpmo.org (Pat Hall DDPMOSTL) Date: Thu, 1 Dec 2011 12:50:02 -0600 Subject: Gnupg: display p and q lengths of DSA public keys? In-Reply-To: <87vcq05hlk.fsf@vigenere.g10code.de> References: <87vcq05hlk.fsf@vigenere.g10code.de> Message-ID: <02209348E6DA574FB0466CE6CD0A173FD507E0F606@EXCHANGE2007.ddpmo.int> In attempting to determine whether a given GPG public key is still in the "acceptable" category of U.S. NIST SP 800-131A standards as of 2011, for DSA keys I need to be able to verify both the |p| and |q| lengths. In particular, I need to verify that DSA keys have |p| >= 2048 bits AND have |q| >= 224 bits. I can see numbers in the below examples of a DSA key of pkd:1:160 and pkey[1]: [160 bits] - these look like the |q| value (which is in the "Deprecated from 2011 through 2013, and Disallowed after 2013 range), but I'd like verification that. I've tried gpg2 --list-keys --with-key-data which gives something like: pub:-:1024: pkd:0:1024: pkd:1:160: pkd:2:1024: pkd:3:1021: uid:-:::: sub:-:2048: pkd:0:2048: pkd:1:2:02: pkd:2:2046: And gpg --export-options export-minimal --export | gpg --list-packets Which gives something like :public key packet: version 4, algo 17, created ..., expires 0 pkey[0]: [1024 bits] pkey[1]: [160 bits] pkey[2]: [1024 bits] pkey[3]: [1022 bits] keyid: ... :user ID packet: "..." :signature packet: algo 17, keyid ... version 4, created ..., md5len 0, sigclass 0x10 digest algo 2, begin of digest ... hashed subpkt 2 len 4 (sig created ...) hashed subpkt 11 len 6 (pref-sym-algos: ...) hashed subpkt 25 len 1 (primary user ID) hashed subpkt 27 len 4 (key flags: ...) subpkt 16 len 8 (issuer key ID ...) data: [160 bits] data: [160 bits] :public sub key packet: version 4, algo 16, created ..., expires 0 pkey[0]: [2048 bits] pkey[1]: [2 bits] pkey[2]: [2048 bits] keyid: ... :signature packet: algo 17, keyid ... version 4, created ..., md5len 0, sigclass 0x18 digest algo 2, begin of digest ... hashed subpkt 2 len 4 (sig created ...) hashed subpkt 27 len 4 (key flags: ...) subpkt 16 len 8 (issuer key ID ...) data: [159 bits] data: [160 bits] This electronic message is from Delta Dental of Missouri. It may contain confidential or privileged information protected by HIPAA Privacy and HITECH regulations. If this message was delivered to you in error, you may not forward, print or distribute in any way. This footnote also confirms that this email message has passed IRONPORT email anti-virus rules and is virus-free. 01 Dec 2011 18:50:04 -0000 From dshaw at jabberwocky.com Thu Dec 1 22:00:31 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 1 Dec 2011 16:00:31 -0500 Subject: Gnupg: display p and q lengths of DSA public keys? In-Reply-To: <02209348E6DA574FB0466CE6CD0A173FD507E0F606@EXCHANGE2007.ddpmo.int> References: <87vcq05hlk.fsf@vigenere.g10code.de> <02209348E6DA574FB0466CE6CD0A173FD507E0F606@EXCHANGE2007.ddpmo.int> Message-ID: On Dec 1, 2011, at 1:50 PM, Pat Hall DDPMOSTL wrote: > In attempting to determine whether a given GPG public key is still in the "acceptable" category of U.S. NIST SP 800-131A standards as of 2011, for DSA keys I need to be able to verify both the |p| and |q| lengths. > > In particular, I need to verify that DSA keys have |p| >= 2048 bits AND have |q| >= 224 bits. > > I can see numbers in the below examples of a DSA key of pkd:1:160 and pkey[1]: [160 bits] - these look like the |q| value (which is in the "Deprecated from 2011 through 2013, and Disallowed after 2013 range), but I'd like verification that. Yes. When listing a DSA key or subkey, the lengths given in pkd:0 or pkey[0] are for "p", and the lengths given in pkd:1 or pkey[1] are for "q". David From cryptostick at privacyfoundation.de Sun Dec 4 02:52:55 2011 From: cryptostick at privacyfoundation.de (Crypto Stick) Date: Sun, 04 Dec 2011 09:52:55 +0800 Subject: Card only available to root user In-Reply-To: <4ED54965.4050502@enigmail.net> References: <20110804212536.GA31134@atlas> <20110804214955.GB31134@atlas> <4ED54046.3090102@privacyfoundation.de> <4ED54965.4050502@enigmail.net> Message-ID: <4EDAD277.90407@privacyfoundation.de> Hi Olav! Am 30.11.2011 05:06, schrieb Olav Seyfarth: > Hi anonymous "Crypto Stick" and OpenPGP card users on Linux, > >> You need an appropriate UDEV rule. On Debian you can install... > > Thanks for that link! > Will the package find its way to the official debian repositories? I hope so. I submitted a bug report and am waiting for the packet maintainer to integrate it. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648332 Regards, Jan From gnupg at lists.grepular.com Mon Dec 5 13:26:16 2011 From: gnupg at lists.grepular.com (gnupg at lists.grepular.com) Date: Mon, 05 Dec 2011 12:26:16 +0000 Subject: pka-lookups and dnssec Message-ID: <4EDCB868.1070101@lists.grepular.com> Can anyone explain to me the purpose of "--verify-options pka-lookups" ? I have successfully used "--auto-key-locate pka" when encrypting messages, but I can't see how to use "pka-lookups". I assumed it would automatically lookup/download the key in order to do verification, but if you don't have the key already, it doesn't know the UID associated with the key used to sign and therefore can't do the PKA lookup... Is there some additional command line option that I should be using to specify the email address from the UID when verifying this way? Or have I completely misunderstood something? Also. Would it be useful to add a feature to GnuPG so it displays the fact that a PKA record it retrieved was DNSSEC signed, when true? Just for informational purposes. It strikes me as useful information to have... Here is my DNSSEC signed PKA record that I've been experimenting with: mike at server:~$ dig +short txt mike.cardwell._pka.grepular.com "v=pka1\;fpr=35BCAF1D3AA21F843DC3B0CF70A5F5120018461F\;uri=http://grepular.com/0018461F.pub.asc" mike at server:~$ -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Dec 5 14:15:07 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Dec 2011 14:15:07 +0100 Subject: pka-lookups and dnssec In-Reply-To: <4EDCB868.1070101@lists.grepular.com> (gnupg@lists.grepular.com's message of "Mon, 05 Dec 2011 12:26:16 +0000") References: <4EDCB868.1070101@lists.grepular.com> Message-ID: <87sjkzyxb8.fsf@vigenere.g10code.de> On Mon, 5 Dec 2011 13:26, gnupg at lists.grepular.com said: > verification, but if you don't have the key already, it doesn't know the > UID associated with the key used to sign and therefore can't do the PKA > lookup... Is there some additional command line option that I should be Well, PKA requires additional information in the signature: To send this mail, Alice will first sign it using her private key. That signature features one extra signed information for use by PKA: The mail address from the ``From:'' line. The user IDs and mail address as included in the key are not sufficient because it is common to have several mail addresses in a key which might even not match the address as used in the ``From:'' line. Using so-called notation data (OpenPGP) or signed attributes (X.509) this address gets signed along with the actual text of the message. When using OpenPGP the notation for our example would be: \begin{verbatim} pka-address at gnupg.org=alice at example.net \end{verbatim} ``pka-address at gnupg.org'' is the key to identify this as PKA notation data. With gpg you would use this option: --sig-notation "pka-address at gnupg.org=alice at example.net" With GPGME you use the gpgme_sig_notation_add to set such a notation. > Also. Would it be useful to add a feature to GnuPG so it displays the > fact that a PKA record it retrieved was DNSSEC signed, when true? Just > for informational purposes. It strikes me as useful information to have... It does this: log_info (_("automatically retrieved `%s' via %s\n"), name, mechanism); You may want to use something like --auto-key-locate=pka,cert,local to define the order in which lookups are done. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg at lists.grepular.com Mon Dec 5 15:30:05 2011 From: gnupg at lists.grepular.com (gnupg at lists.grepular.com) Date: Mon, 05 Dec 2011 14:30:05 +0000 Subject: pka-lookups and dnssec In-Reply-To: <87sjkzyxb8.fsf@vigenere.g10code.de> References: <4EDCB868.1070101@lists.grepular.com> <87sjkzyxb8.fsf@vigenere.g10code.de> Message-ID: <4EDCD56D.3050506@lists.grepular.com> On 05/12/11 13:15, Werner Koch wrote: >> verification, but if you don't have the key already, it doesn't know the >> UID associated with the key used to sign and therefore can't do the PKA >> lookup... Is there some additional command line option that I should be > > Well, PKA requires additional information in the signature: > > To send this mail, Alice will first sign it using her private key. > That signature features one extra signed information for use by PKA: > The mail address from the ``From:'' line. The user IDs and mail > address as included in the key are not sufficient because it is > common to have several mail addresses in a key which might even not > match the address as used in the ``From:'' line. > > Using so-called notation data (OpenPGP) or signed attributes (X.509) > this address gets signed along with the actual text of the message. > When using OpenPGP the notation for our example would be: > > \begin{verbatim} > pka-address at gnupg.org=alice at example.net > \end{verbatim} > > ``pka-address at gnupg.org'' is the key to identify this as PKA notation > data. > > With gpg you would use this option: > > --sig-notation "pka-address at gnupg.org=alice at example.net" I tried signing something like this: (minus ".NOSPAM") gpg --sig-notation "pka-address at gnupg.org=mike.cardwell.NOSPAM at grepular.com" --clearsign I then tried verifying the output from the above command, by piping it into this, using a gpg homedir that didn't contain my key: gpg --verify-options pka-lookups --verify The result: gpg: Signature made Mon 05 Dec 2011 14:25:17 GMT using RSA key ID C1D1E704 gpg: Can't check signature: No public key Where have I gone wrong? > With GPGME you use the gpgme_sig_notation_add to set such a notation. > >> Also. Would it be useful to add a feature to GnuPG so it displays the >> fact that a PKA record it retrieved was DNSSEC signed, when true? Just >> for informational purposes. It strikes me as useful information to have... > > It does this: > > log_info (_("automatically retrieved `%s' via %s\n"), > name, mechanism); Yes, it displays that the key was retrieved using PKA. It doesn't however state that the PKA record was DNSSEC signed. Knowing that the fingerprint retrieved from the DNS was signed with DNSSEC is worthy of being announced IMHO... Regards, -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon Dec 5 16:32:27 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Dec 2011 16:32:27 +0100 Subject: pka-lookups and dnssec In-Reply-To: <4EDCD56D.3050506@lists.grepular.com> (gnupg@lists.grepular.com's message of "Mon, 05 Dec 2011 14:30:05 +0000") References: <4EDCB868.1070101@lists.grepular.com> <87sjkzyxb8.fsf@vigenere.g10code.de> <4EDCD56D.3050506@lists.grepular.com> Message-ID: <87d3c3yqyc.fsf@vigenere.g10code.de> On Mon, 5 Dec 2011 15:30, gnupg at lists.grepular.com said: > I then tried verifying the output from the above command, by piping it > into this, using a gpg homedir that didn't contain my key: > > gpg --verify-options pka-lookups --verify You may want to use: gpg --verify-options pka-lookups,pka-trust-increase --verify so that gpg returns full trust. Without that you need to evaluate the PKA info yourself. > gpg: Signature made Mon 05 Dec 2011 14:25:17 GMT using RSA key ID C1D1E704 > gpg: Can't check signature: No public key > > Where have I gone wrong? I can't tell. What about posting such a signature or sending them in PM? > Yes, it displays that the key was retrieved using PKA. It doesn't > however state that the PKA record was DNSSEC signed. Knowing that the > fingerprint retrieved from the DNS was signed with DNSSEC is worthy of I don't know how to do it using the standard API. In any case I would not put too much weight into DNSSEC. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 5 19:05:30 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 05 Dec 2011 19:05:30 +0100 Subject: pka-lookups and dnssec In-Reply-To: <87d3c3yqyc.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 05 Dec 2011 16:32:27 +0100") References: <4EDCB868.1070101@lists.grepular.com> <87sjkzyxb8.fsf@vigenere.g10code.de> <4EDCD56D.3050506@lists.grepular.com> <87d3c3yqyc.fsf@vigenere.g10code.de> Message-ID: <8739cyzyfp.fsf@vigenere.g10code.de> On Mon, 5 Dec 2011 16:32, wk at gnupg.org said: > gpg --verify-options pka-lookups,pka-trust-increase --verify Well, you also need the options --keyserver-options honor-pka-record,auto-key-retrieve Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From darby.10 at osu.edu Wed Dec 7 17:42:52 2011 From: darby.10 at osu.edu (muppetmaster) Date: Wed, 7 Dec 2011 08:42:52 -0800 (PST) Subject: GnuPG Windows - pubring.gpg stays locked after failed commands Message-ID: <32929897.post@talk.nabble.com> Hello Everyone, I have inherited gpg (GnuPG) 1.4.7 on Windows Server 2003 box. I only use it from the command line and have it embedded in a bunch of batch scripts that support some EDI transfer automation. It seems that any time a gpg encryption or decryption command fails for any reason, the read lock on pubring.gpg is not released. Every subsequent call fails when the application tries to its underlying rename commands on this file. The errors indicate "file rename error", "permission denied", "error reading file". I can navigate down in the GnuPG Application Data directory and try to hand edit the file and get the typical "File is in use by another process" errors from Windows. Has anyone seen this before? Is it a known bug or anything? -- View this message in context: http://old.nabble.com/GnuPG-Windows---pubring.gpg-stays-locked-after-failed-commands-tp32929897p32929897.html Sent from the GnuPG - User mailing list archive at Nabble.com. From JM.OMara at pervasive.com Thu Dec 8 21:44:16 2011 From: JM.OMara at pervasive.com (JM O'Mara) Date: Thu, 8 Dec 2011 20:44:16 +0000 Subject: GPG Encrypt without Install Message-ID: <4BFCF14A86EC20469025D40801F994C9012C0EF5@PVSWMAIL2010.pervasive.com> Hello There, I am building an application which is using gpg to encrypt files using a Server Side public key. I was wondering if I distribute this app to clients, will each client need to install gpg in order for the encryption to work Client Side? Or is it possible to have a standalone exe that I can utilize to do my client side encryption? Thanks, JM -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg at lists.grepular.com Mon Dec 12 20:05:45 2011 From: gnupg at lists.grepular.com (gnupg at lists.grepular.com) Date: Mon, 12 Dec 2011 19:05:45 +0000 Subject: Leaving comments with subkeys? Message-ID: <4EE65089.9040308@lists.grepular.com> If I have more than one signing subkey in my keypair, is there a way of advertising the purpose of each subkey with the public key that people download? Eg: This subkey is for signing email only This subkey is for signing sourcecode only I've considered generating an entirely separate keypair and then cross-signing them, but that seems inelegant. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 427 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Dec 14 11:39:18 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Dec 2011 05:39:18 -0500 Subject: Leaving comments with subkeys? In-Reply-To: <4EE65089.9040308@lists.grepular.com> References: <4EE65089.9040308@lists.grepular.com> Message-ID: <4EE87CD6.4050301@fifthhorseman.net> On 12/12/2011 02:05 PM, gnupg at lists.grepular.com wrote: > If I have more than one signing subkey in my keypair, is there a way of > advertising the purpose of each subkey with the public key that people > download? Eg: > > This subkey is for signing email only > This subkey is for signing sourcecode only > > I've considered generating an entirely separate keypair and then > cross-signing them, but that seems inelegant. My first thought was to look up the list of standardized "key usage flags", which are defined here: https://tools.ietf.org/html/rfc4880#section-5.2.3.21 But there is no "this key may be used to sign code" usage flag, which it sounds like you'd really want, and 0x02 ("This key may be used to sign data") is generic enough to cover both your cases (it only excludes making other OpenPGP certifications, which is covered by 0x01). Given that allocating new bits for the key flags field is an unwieldy and awkward process, i don't think this is the way to go. Instead, you could add a notation to the subkey signatures. https://tools.ietf.org/html/rfc4880#section-5.2.3.16 Concisely and precisely defining (what exactly counts as "source code"? what if an e-mail contains a tarball with source code? what if an html e-mail contains javascript? etc...) the notation you want to use and getting it embedded in some tools is going to be a bit of work, but not necessarily an insurmountable task. You might want to discuss it with the (very low-traffic at the moment) working group: IETF OpenPGP Working Group Let me also ask the sort-of-nagging questions: what is your endgame here? do you want a subkey whose signatures over anything *but* sourcecode will be rejected for certain purposes? What about a tarball of source code? a gzipped tarball? an lzma-compressed tarball? a blog post containing a 20-line shell script? Do you want a subkey whose signatures over anything *but* e-mail will be rejected? (e.g. if i copy and paste your e-mail into a text file, and then --verify it, should it fail?) Will you be happy with people deciding to accept the key's signatures over *any* source code you distribute, or are you concerned about a particular project? Your answers to these questions should help you think through the best way to proceed to get what you want. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From lists at chrispoole.com Thu Dec 15 18:47:46 2011 From: lists at chrispoole.com (Chris Poole) Date: Thu, 15 Dec 2011 17:47:46 +0000 Subject: Quieten gpg-agent output? Message-ID: Hi, I start gpg-agent with the -q option to make it quiet. I then run a script that executes gpg -qse ... on several files, encrypting and signing them (quietly). I still find output like this in my terminal window: > You need a passphrase to unlock the secret key for > user: "Chris Poole "2048-bit DSA key, ID 7ED39159, created 2010-12-11 (main key ID BAD248F9) I assume that gpg is reporting this, and then it checks for a key held by the agent, which it uses (everything works fine, it's just the output that annoys me). I could quiten gpg totally, by running gpg ... 2>&1 >/dev/null, but then I'd also stop any genuine errors that gpg reports. (I run this command manually, usually, so would see errors.) Is there a better way to get rid of these "errors"? Cheers From wk at gnupg.org Fri Dec 16 15:07:59 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 16 Dec 2011 15:07:59 +0100 Subject: Quieten gpg-agent output? In-Reply-To: (Chris Poole's message of "Thu, 15 Dec 2011 17:47:46 +0000") References: Message-ID: <87hb108v9c.fsf@vigenere.g10code.de> On Thu, 15 Dec 2011 18:47, lists at chrispoole.com said: > Is there a better way to get rid of these "errors"? Yes, use gpg2. Using gpg and gpg-agent is just a kludge. gpg2 requires gpg-agent and thus we don't need those messages there anymore. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From david at systemoverlord.com Fri Dec 16 16:26:04 2011 From: david at systemoverlord.com (David Tomaschik) Date: Fri, 16 Dec 2011 10:26:04 -0500 Subject: Bad Signatures when using check-sigs Message-ID: When executing gpg --check-sigs, there are reports of "bad signatures." What makes a signature "bad"? For example, on a key I signed that has several UIDs, one of my signatures on one UID is reported as bad, but the rest are fine. I looked in the docs, but didn't find anything... hope I'm not missing something obvious. -- David Tomaschik, RHCE, LPIC-1 System Administrator/Open Source Advocate OpenPGP: 0x5DEA789B http://systemoverlord.com david at systemoverlord.com From gnupg at lists.grepular.com Fri Dec 16 16:51:34 2011 From: gnupg at lists.grepular.com (gnupg at lists.grepular.com) Date: Fri, 16 Dec 2011 15:51:34 +0000 Subject: keyserver spam Message-ID: <4EEB6906.8060900@lists.grepular.com> I understand that once you've uploaded something to the keyservers, it can't be removed. Eg, if I sign someone elses key and upload that, it will be attached to their key permanently? What if someone were to generate say, 10,000 keypairs with "offensive" uid names, and then sign my key with each of them, and then upload that to the keyservers? Is there anything to stop that? Is there anything to stop a spammer generating a key with their URL in the uid name and then signing every key they can find and uploading that to the keyservers? Has anything like this happened before? -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Dec 16 18:50:53 2011 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 16 Dec 2011 12:50:53 -0500 Subject: keyserver spam In-Reply-To: <4EEB6906.8060900@lists.grepular.com> References: <4EEB6906.8060900@lists.grepular.com> Message-ID: <4EEB84FD.9020408@fifthhorseman.net> On 12/16/2011 10:51 AM, gnupg at lists.grepular.com wrote: > I understand that once you've uploaded something to the keyservers, it > can't be removed. Eg, if I sign someone elses key and upload that, it > will be attached to their key permanently? yes, this is correct. :( > What if someone were to generate say, 10,000 keypairs with "offensive" > uid names, and then sign my key with each of them, and then upload that > to the keyservers? Is there anything to stop that? nope. flooding like this is currently possible. :( > Is there anything to > stop a spammer generating a key with their URL in the uid name and then > signing every key they can find and uploading that to the keyservers? nope, this is also possible. :( > Has anything like this happened before? well, there's the JBARSE key, which i vaguely recall having been created in a joking way to threaten character assassination, but i can't find any keys that it has actually signed, nor any documentation to explain why i have this recollection, so please take with a grain of salt. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Fri Dec 16 19:28:13 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 16 Dec 2011 13:28:13 -0500 Subject: keyserver spam In-Reply-To: <4EEB6906.8060900@lists.grepular.com> References: <4EEB6906.8060900@lists.grepular.com> Message-ID: On Dec 16, 2011, at 10:51 AM, gnupg at lists.grepular.com wrote: > I understand that once you've uploaded something to the keyservers, it > can't be removed. Eg, if I sign someone elses key and upload that, it > will be attached to their key permanently? Essentially, yes. Things are theoretically removable, but it takes carefully-timed manual editing on the part of all the keyserver operators to expunge something (or the bad data will just come back). The system is just not designed for that. > What if someone were to generate say, 10,000 keypairs with "offensive" > uid names, and then sign my key with each of them, and then upload that > to the keyservers? Is there anything to stop that? Nope. > Is there anything to > stop a spammer generating a key with their URL in the uid name and then > signing every key they can find and uploading that to the keyservers? Nope. > Has anything like this happened before? Yes, but only in a few smallish cases. As far as I recall, nobody has ever done multiple thousands of keys. I'd be more worried about photo IDs on keys. Imagine what could be done with someone using the keyserver network to distribute illegal photos. To be sure, if the point is photo distribution, there are more efficient ways to go about it, but if your goal is to hurt the keyserver network? David From johanw at xs4all.nl Fri Dec 16 17:42:59 2011 From: johanw at xs4all.nl (Johan Wevers) Date: Fri, 16 Dec 2011 17:42:59 +0100 Subject: keyserver spam In-Reply-To: <4EEB6906.8060900@lists.grepular.com> References: <4EEB6906.8060900@lists.grepular.com> Message-ID: <4EEB7513.7050700@xs4all.nl> On 16-12-2011 16:51, gnupg at lists.grepular.com wrote: > I understand that once you've uploaded something to the keyservers, it > can't be removed. Eg, if I sign someone elses key and upload that, it > will be attached to their key permanently? Yes. Of course, you can remove it locally. > What if someone were to generate say, 10,000 keypairs with "offensive" > uid names, and then sign my key with each of them, and then upload that > to the keyservers? Then you might have a problem. > Is there anything to stop that? Not really. > Has anything like this happened before? The only thing that comes close is the keyserver at (I believe) pgp.com, who issues a new signature every few months clogging your key with expired signatures. -- Met vriendelijke groet, Johan Wevers From vedaal at nym.hush.com Fri Dec 16 20:07:36 2011 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Fri, 16 Dec 2011 14:07:36 -0500 Subject: keyserver spam Message-ID: <20111216190736.8497B10E2D6@smtp.hushmail.com> What if keyservers were to limit the amount of keys generated or uploaded to a 'reasonable' amount which no 'real' user would exceed? (i.e. 10/day, or some other number discussed and agreed upon by the various keyservers?) vedaal From jerome at jeromebaum.com Sat Dec 17 03:45:41 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 17 Dec 2011 03:45:41 +0100 Subject: keyserver spam In-Reply-To: <20111216190736.8497B10E2D6@smtp.hushmail.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> Message-ID: <4EEC0255.10503@jeromebaum.com> On 2011-12-16 20:07, vedaal at nym.hush.com wrote: > What if keyservers were to limit the amount of keys generated or > uploaded to a 'reasonable' amount which no 'real' user would > exceed? > > (i.e. 10/day, or some other number discussed and agreed upon by the > various keyservers?) What problem are we solving? Keyserver spam isn't an issue yet. We don't know if it will ever be. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From gnupg at lists.grepular.com Sat Dec 17 14:23:18 2011 From: gnupg at lists.grepular.com (gnupg at lists.grepular.com) Date: Sat, 17 Dec 2011 13:23:18 +0000 Subject: keyserver spam In-Reply-To: <20111216190736.8497B10E2D6@smtp.hushmail.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> Message-ID: <4EEC97C6.5040303@lists.grepular.com> On 16/12/11 19:07, vedaal at nym.hush.com wrote: > What if keyservers were to limit the amount of keys generated or > uploaded to a 'reasonable' amount which no 'real' user would > exceed? > > (i.e. 10/day, or some other number discussed and agreed upon by the > various keyservers?) You could still successfully mess with someone by signing their key with offensive or spammy content ten times a day. I find it strange that the keyservers don't do any sort of email validation before accepting key submissions and that they just allow anyone to upload signatures for your key without verifying if you want to allow them first. This sort of problem just seems inevitable to me. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: OpenPGP digital signature URL: From gnupg at lists.grepular.com Sat Dec 17 14:29:21 2011 From: gnupg at lists.grepular.com (gnupg at lists.grepular.com) Date: Sat, 17 Dec 2011 13:29:21 +0000 Subject: keyserver spam In-Reply-To: <4EEC0255.10503@jeromebaum.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC0255.10503@jeromebaum.com> Message-ID: <4EEC9931.2010407@lists.grepular.com> On 17/12/11 02:45, Jerome Baum wrote: >> What if keyservers were to limit the amount of keys generated or >> uploaded to a 'reasonable' amount which no 'real' user would >> exceed? >> >> (i.e. 10/day, or some other number discussed and agreed upon by the >> various keyservers?) > > What problem are we solving? Keyserver spam isn't an issue yet. We don't > know if it will ever be. The system can be easily abused, therefore it will be abused. It's just a matter of time. How much time, depends on if/when PGP becomes more popular. It doesn't strike me as unreasonable to want to put defences in place before an attack begins. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: OpenPGP digital signature URL: From jerome at jeromebaum.com Sat Dec 17 14:33:20 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 17 Dec 2011 14:33:20 +0100 Subject: keyserver spam In-Reply-To: <4EEC97C6.5040303@lists.grepular.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> Message-ID: <4EEC9A20.80501@jeromebaum.com> On 2011-12-17 14:23, gnupg at lists.grepular.com wrote: > I find it strange that the keyservers don't do any sort of email > validation before accepting key submissions and that they just allow > anyone to upload signatures for your key without verifying if you want > to allow them first. What about keys without an email in the UID? What prevents me from signing your key and distributing the signature in some other way? -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From jerome at jeromebaum.com Sat Dec 17 14:40:41 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 17 Dec 2011 14:40:41 +0100 Subject: keyserver spam In-Reply-To: <4EEC9931.2010407@lists.grepular.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC0255.10503@jeromebaum.com> <4EEC9931.2010407@lists.grepular.com> Message-ID: <4EEC9BD9.3050708@jeromebaum.com> On 2011-12-17 14:29, gnupg at lists.grepular.com wrote: > The system can be easily abused, therefore it will be abused. It's just > a matter of time. How much time, depends on if/when PGP becomes more > popular. It doesn't strike me as unreasonable to want to put defences in > place before an attack begins. Just like you shouldn't write blatantly inefficient code. But there's also a point after which we call this premature optimization. Ditto for putting up security measures for a problem that may well never become one. I would be very happy to see this become a problem in fact. It would imply that OpenPGP is popular enough to attract script kiddies & co. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From gnupg at lists.grepular.com Sat Dec 17 14:54:00 2011 From: gnupg at lists.grepular.com (gnupg at lists.grepular.com) Date: Sat, 17 Dec 2011 13:54:00 +0000 Subject: keyserver spam In-Reply-To: <4EEC9A20.80501@jeromebaum.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <4EEC9A20.80501@jeromebaum.com> Message-ID: <4EEC9EF8.9080400@lists.grepular.com> On 17/12/11 13:33, Jerome Baum wrote: >> I find it strange that the keyservers don't do any sort of email >> validation before accepting key submissions and that they just allow >> anyone to upload signatures for your key without verifying if you want >> to allow them first. > > What about keys without an email in the UID? For the first issue regarding uploading keys, you wouldn't be able to do email validation on a key that doesn't have an email address in the UID. At the same time, for those keys, you wouldn't need to, as no email spoofing has taken place, so that's not an issue... For the second issue regarding uploading signatures. Email in the UID isn't required. You just need to differentiate between signatures that the owner of the key has allowed, and signatures that they haven't. The owner of the key can prove that they are the owner of the key and accept the signature using normal public key crypto. An email in the UID of the key owner would be useful so you can contact them to let them know that somebody has uploaded a signature. Not required though. > What prevents me from signing your key and distributing the signature in some other way? Nothing. The subject at hand is problems with the keyservers. Any other distribution mechanism is irrelevant. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: OpenPGP digital signature URL: From gnupg at lists.grepular.com Sat Dec 17 14:58:58 2011 From: gnupg at lists.grepular.com (gnupg at lists.grepular.com) Date: Sat, 17 Dec 2011 13:58:58 +0000 Subject: keyserver spam In-Reply-To: <4EEC9BD9.3050708@jeromebaum.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC0255.10503@jeromebaum.com> <4EEC9931.2010407@lists.grepular.com> <4EEC9BD9.3050708@jeromebaum.com> Message-ID: <4EECA022.8080602@lists.grepular.com> On 17/12/11 13:40, Jerome Baum wrote: >> The system can be easily abused, therefore it will be abused. It's just >> a matter of time. How much time, depends on if/when PGP becomes more >> popular. It doesn't strike me as unreasonable to want to put defences in >> place before an attack begins. > > Just like you shouldn't write blatantly inefficient code. But there's > also a point after which we call this premature optimization. Ditto for > putting up security measures for a problem that may well never become one. So you agree that there is a point where putting security measures in place is a good idea. Where you disagree with me, is you think it is unlikely that the keyservers will be abused in this manner in the near future. I guess neither of us can see into the future, but the prevalence of this sort of abuse on the Internet, always places me on the side of caution. > I would be very happy to see this become a problem in fact. It would > imply that OpenPGP is popular enough to attract script kiddies & co. It would only take one troll. -- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 598 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sat Dec 17 15:02:04 2011 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 17 Dec 2011 15:02:04 +0100 Subject: keyserver spam In-Reply-To: <4EEC97C6.5040303@lists.grepular.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> Message-ID: <4EECA0DC.4020706@digitalbrains.com> On 17/12/11 14:23, gnupg at lists.grepular.com wrote: > I find it strange that the keyservers don't do any sort of email > validation before accepting key submissions and that they just allow > anyone to upload signatures for your key without verifying if you want > to allow them first. The key property "keyserver no-modify" is meant to allow people to specify that only they can change the key. However, this needs crypto in the keyserver network and the solution to some practical problems. So it currently doesn't work. You're not the first to think about the problem, and there was even acted upon. However, there are key pieces missing in the puzzle before it works. Keyserver synchronization is the biggest obstacle, I believe. In the mean time, if somebody uploads offensive and spammy signatures, be offended by the uploader, not by the person whose key is signed. "--edit-key clean" will remove the cruft you don't need. "--import-options import-clean" can be useful as well. 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 From peter at digitalbrains.com Sat Dec 17 15:07:21 2011 From: peter at digitalbrains.com (Peter Lebbing) Date: Sat, 17 Dec 2011 15:07:21 +0100 Subject: keyserver spam In-Reply-To: <4EECA022.8080602@lists.grepular.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC0255.10503@jeromebaum.com> <4EEC9931.2010407@lists.grepular.com> <4EEC9BD9.3050708@jeromebaum.com> <4EECA022.8080602@lists.grepular.com> Message-ID: <4EECA219.10704@digitalbrains.com> On 17/12/11 14:58, gnupg at lists.grepular.com wrote: > It would only take one troll. Yet, so far so good (in general). And the infrastructure has existed for quite some years already. OpenPGP might never become popular enough to attract childish people to the keyserver network :). I certainly hope it will become popular, but spending a /lot/ of development time on something that will be needed when it is popular... I think that time is better spent on deducing ways to make it popular! STEED perhaps? Funny detail is, STEED doesn't use the keyserver network! 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 From jerome at jeromebaum.com Sat Dec 17 15:07:11 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 17 Dec 2011 15:07:11 +0100 Subject: keyserver spam In-Reply-To: <4EEC9EF8.9080400@lists.grepular.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <4EEC9A20.80501@jeromebaum.com> <4EEC9EF8.9080400@lists.grepular.com> Message-ID: <4EECA20F.4090101@jeromebaum.com> On 2011-12-17 14:54, gnupg at lists.grepular.com wrote: >> What about keys without an email in the UID? > > For the first issue regarding uploading keys, you wouldn't be able to do > email validation on a key that doesn't have an email address in the UID. > At the same time, for those keys, you wouldn't need to, as no email > spoofing has taken place, so that's not an issue... Spoofing is prevented through the WoT. It's not the responsibility of the keyserver. >> What prevents me from signing your key and distributing the signature in some other way? > > Nothing. The subject at hand is problems with the keyservers. Any other > distribution mechanism is irrelevant. I'll pose this differently: Why should the keyserver check with you that you allow the signature to be uploaded? Why would you want to prevent me from uploading the signature to an e.g. SKS keyserver, but not generally from distributing it? (After all, the keyserver is checking with you, you are controlling the upload, so it must be in your interest. This isn't about the keyserver being flooded, it's that you don't like me distributing this signature.) Also note that SKS keyservers (and IIRC all common keyservers besides the PGP ones?) don't do crypto operations on the OpenPGP packets. They only handle the format, and only to merge the set of sub-packets. IIRC. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From jerome at jeromebaum.com Sat Dec 17 15:08:27 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 17 Dec 2011 15:08:27 +0100 Subject: keyserver spam In-Reply-To: <4EECA022.8080602@lists.grepular.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC0255.10503@jeromebaum.com> <4EEC9931.2010407@lists.grepular.com> <4EEC9BD9.3050708@jeromebaum.com> <4EECA022.8080602@lists.grepular.com> Message-ID: <4EECA25B.2030300@jeromebaum.com> On 2011-12-17 14:58, gnupg at lists.grepular.com wrote: > So you agree that there is a point where putting security measures in > place is a good idea. Where you disagree with me, is you think it is > unlikely that the keyservers will be abused in this manner in the near > future. > > I guess neither of us can see into the future, but the prevalence of > this sort of abuse on the Internet, always places me on the side of caution. Yes this is definitely a subjective matter. >> I would be very happy to see this become a problem in fact. It would >> imply that OpenPGP is popular enough to attract script kiddies & co. > > It would only take one troll. Sure. How many trolls do you see on gnupg-users? -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From yoraxe at googlemail.com Sat Dec 17 14:37:45 2011 From: yoraxe at googlemail.com (Xenia) Date: Sat, 17 Dec 2011 14:37:45 +0100 Subject: GPG on meego-phone (nokia n9) Message-ID: <4EEC9B29.1070705@googlemail.com> Dear gnupg-folks, Is there a gpg-application for meego, especially for the Nokia N9? Thanks, Xenia From hj at loosman.org Sat Dec 17 14:26:43 2011 From: hj at loosman.org (Erik Loosman) Date: Sat, 17 Dec 2011 14:26:43 +0100 Subject: keyserver spam In-Reply-To: <4EEB6906.8060900@lists.grepular.com> References: <4EEB6906.8060900@lists.grepular.com> Message-ID: <4EEC9893.8010306@loosman.org> I have uploaded my key to a keyserver at pgp.com: upload a key to their keyserver requires a verification by e-mail. Every id (e-mailaddress) in your key receives an e-mail. Respond to one of those e-mails (clicking link) to verify you issued the key replacement. But when (one of) your e-mail account(s) has been compromised, it could still happen. Erik Loosman OpenPGP: 0x7374C641 at keyserver2.pgp.com On 12/16/2011 04:51 PM, gnupg at lists.grepular.com wrote: > I understand that once you've uploaded something to the keyservers, it > can't be removed. Eg, if I sign someone elses key and upload that, it > will be attached to their key permanently? > > What if someone were to generate say, 10,000 keypairs with "offensive" > uid names, and then sign my key with each of them, and then upload that > to the keyservers? Is there anything to stop that? Is there anything to > stop a spammer generating a key with their URL in the uid name and then > signing every key they can find and uploading that to the keyservers? > > Has anything like this happened before? > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Sat Dec 17 16:17:30 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 17 Dec 2011 10:17:30 -0500 Subject: keyserver spam In-Reply-To: <4EEC97C6.5040303@lists.grepular.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> Message-ID: On Dec 17, 2011, at 8:23 AM, gnupg at lists.grepular.com wrote: > On 16/12/11 19:07, vedaal at nym.hush.com wrote: > >> What if keyservers were to limit the amount of keys generated or >> uploaded to a 'reasonable' amount which no 'real' user would >> exceed? >> >> (i.e. 10/day, or some other number discussed and agreed upon by the >> various keyservers?) > > You could still successfully mess with someone by signing their key with > offensive or spammy content ten times a day. > > I find it strange that the keyservers don't do any sort of email > validation before accepting key submissions and that they just allow > anyone to upload signatures for your key without verifying if you want > to allow them first. There is such a keyserver, made by the PGP company (now run by Symantec, I suppose): http://keyserver.pgp.com/ It's an interesting server, with different semantics than the traditional keyserver net that we were talking about earlier. Most significantly, it emails the keyholder (at the address on the key) before accepting the key into the server. It also signs keys that are submitted to it, which allows people to leverage this email checking in their own trust calculations, but can also "litter" keys with repeated signatures. If I recall, it is (or perhaps was) the default keyserver for PGP installations. Of necessity, this server does not synchronize with other keyservers, which is either a good or bad thing, depending on who you ask ;) David From jerome at jeromebaum.com Sat Dec 17 16:25:56 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 17 Dec 2011 16:25:56 +0100 Subject: keyserver spam In-Reply-To: References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> Message-ID: <4EECB484.6080701@jeromebaum.com> On 2011-12-17 16:17, David Shaw wrote: > It's an interesting server, with different semantics than the > traditional keyserver net that we were talking about earlier. Most > significantly, it emails the keyholder (at the address on the key) > before accepting the key into the server. It also signs keys that > are submitted to it, which allows people to leverage this email > checking in their own trust calculations, but can also "litter" keys > with repeated signatures. If I recall, it is (or perhaps was) the > default keyserver for PGP installations. I doubt the validity of those automated checks and checks on the email anyway. What constitutes "owning" foo at example.com? To legitimately verify this you would need to look at the domain history, conclude who the legit owner of the domain is, contact that owner and then follow the delegation chain to reach a real person. Any technological solution to the problem is easy to compromise: Accounts can be compromised, domains stolen, DNS isn't safe either and the mail server could be penetrated. The only way to know if someone legitimately uses a given email address is to verify the _human_ delegation chain. A computer cannot do that in the current setup. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Sat Dec 17 16:42:04 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 17 Dec 2011 10:42:04 -0500 Subject: keyserver spam In-Reply-To: <4EECB484.6080701@jeromebaum.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <4EECB484.6080701@jeromebaum.com> Message-ID: <0A6C8333-6272-4E7F-82BE-AF9BAE2BF9B0@jabberwocky.com> On Dec 17, 2011, at 10:25 AM, Jerome Baum wrote: > On 2011-12-17 16:17, David Shaw wrote: >> It's an interesting server, with different semantics than the >> traditional keyserver net that we were talking about earlier. Most >> significantly, it emails the keyholder (at the address on the key) >> before accepting the key into the server. It also signs keys that >> are submitted to it, which allows people to leverage this email >> checking in their own trust calculations, but can also "litter" keys >> with repeated signatures. If I recall, it is (or perhaps was) the >> default keyserver for PGP installations. > > I doubt the validity of those automated checks and checks on the email > anyway. What constitutes "owning" foo at example.com? To legitimately > verify this you would need to look at the domain history, conclude who > the legit owner of the domain is, contact that owner and then follow the > delegation chain to reach a real person. > > Any technological solution to the problem is easy to compromise: > Accounts can be compromised, domains stolen, DNS isn't safe either and > the mail server could be penetrated. The only way to know if someone > legitimately uses a given email address is to verify the _human_ > delegation chain. A computer cannot do that in the current setup. Yes. The PGP folks say as much on the site. This was extensively discussed when the server was first put in place. The intent is not to be all things, but rather to be better than just trusting any key based on some text string (i.e. doing nothing). There are those who disagree that this is better, and of course, nobody is forcing them to use the server. David From aaron.toponce at gmail.com Sat Dec 17 16:42:48 2011 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Sat, 17 Dec 2011 08:42:48 -0700 Subject: keyserver spam In-Reply-To: <4EEB6906.8060900@lists.grepular.com> References: <4EEB6906.8060900@lists.grepular.com> Message-ID: <20111217154248.GC10330@poseidon.cocyt.us> On Fri, Dec 16, 2011 at 03:51:34PM +0000, gnupg at lists.grepular.com wrote: > I understand that once you've uploaded something to the keyservers, it > can't be removed. Eg, if I sign someone elses key and upload that, it > will be attached to their key permanently? > > What if someone were to generate say, 10,000 keypairs with "offensive" > uid names, and then sign my key with each of them, and then upload that > to the keyservers? Is there anything to stop that? Is there anything to > stop a spammer generating a key with their URL in the uid name and then > signing every key they can find and uploading that to the keyservers? > > Has anything like this happened before? For spam to be truly effective, there needs to be a reward. Littering the keyservers with bogus keys and signatures, at its current state, wouldn't provide the desired result. Spamming email has shown to be an effective way to make money. Where is the monetary reward here? I guess Anonymous or LULZ Security, or the like, could do it out of sheer entertainment, but it would die quickly, as the effort in maintaining the noise outweighs the benefit of annoying users by several orders of magnitude. I'll pose the scenario differently: How can you trust that the photo identification presented at a human-to-human keysigning party is legitimate? It's not too terribly difficult to forge even government photo identification, and pass it off as legitimate to the average user. I could create a key, call myself "Bruce Schneier", forge a photo identification card that "proves" this is the case, and claim there are two of us in the world- the famous cryptographer, and a lonely sysadmin from North Dakota. After collecting enough signatures, I've created enough noise to cast doubt on which key belongs to the famous security expert, and which doesn't. At least to the casual eye, which we must admit, most of us don't scrutinize our keys at all (when was the last time you did a key refresh, and paid attention to expirations or revocations?). More threatening, than just littering the keyservers with tens of thousands of keys and signatures, are individual attacks, like the one I just mentioned above. Again, there needs to be some good benefit to the cost of doing something like this, other than just "for the lulz", or it will die off quickly. And to be honest, the only reasonable benefit I can conceive of, is hoping to create enough confusion, as to intercept valuable data in some sort of transaction from the person or organization you're attacking. Because OpenPGP hasn't reached mass popularity, I think your initial thoughts are trying to solve a problem, that doesn't exist. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: Digital signature URL: From expires2011 at ymail.com Sat Dec 17 17:04:46 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 17 Dec 2011 16:04:46 +0000 Subject: keyserver spam In-Reply-To: <4EECB484.6080701@jeromebaum.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <4EECB484.6080701@jeromebaum.com> Message-ID: <1111706341.20111217160446@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 17 December 2011 at 3:25:56 PM, in , Jerome Baum wrote: > I doubt the validity of those automated checks and > checks on the email anyway. What constitutes "owning" > foo at example.com? As far as that server's checking is concerned, being able to receive the email they send out to that address and respond to it or click a link. - -- Best regards MFPA mailto:expires2011 at ymail.com Is it possible to be a closet claustrophobic? -----BEGIN PGP SIGNATURE----- iQCVAwUBTuy9o6ipC46tDG5pAQr6OgQAuI5T26SVlJGQrQx5QtjqjCMPbcGKKnYR nbafgCX0CeYxHY6IVv0qw/67qt+dUdbdDdjHmJnn5LT0yqFSf7+sMG1PyBtbGTEk 8y/LeiNOfRkn26+4Fj/BdWoy4v07KW0iNj8ywYpp3EvHBi3vuInrOrVhDXwHD94w 8KFB84qIYvM= =GfRL -----END PGP SIGNATURE----- From expires2011 at ymail.com Sat Dec 17 17:15:37 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 17 Dec 2011 16:15:37 +0000 Subject: keyserver spam In-Reply-To: <4EEC97C6.5040303@lists.grepular.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> Message-ID: <1118309370.20111217161537@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 17 December 2011 at 1:23:18 PM, in , gnupg at lists.grepular.com wrote: > I find it strange that the keyservers don't do any sort > of email validation before accepting key submissions A key's UIDs don't *have to* contain email addresses. But in the case where they do, a verification email would be a useful addition. But whether useful enough to warrant the increased complexity and server load, I have no idea. > and that they just allow anyone to upload signatures > for your key without verifying if you want to allow > them first. Since you don't log into a keyserver when you post, and keyservers store data but do not perform cryptographic functions, this is pretty much inevitable. The "keyserver-no-modify" flag could, in theory, carry with it a requirement that modifications to a key were signed by that key. But, once again, increased complexity and server load. And what about propagating changes between keyservers? - -- Best regards MFPA mailto:expires2011 at ymail.com The greater the power, the more dangerous the abuse. -----BEGIN PGP SIGNATURE----- iQCVAwUBTuzAMKipC46tDG5pAQqDqQP+Lz02ndWZXA4L1lBl9zcL4uHAo7kzm+fc a9NShBJar0Mre9xl1RExq4Af1gPxPwUehuFA0B3oP5F8UtBRhr/WJgKWqHRtvnGw cen76xmgPovfGXSmPP3AuLFPjuRF6rh/gt8AYvnjfSWV4vUzIHNhEs/HOWMKv90W jHcueN9wb00= =/xko -----END PGP SIGNATURE----- From jerome at jeromebaum.com Sat Dec 17 17:34:23 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 17 Dec 2011 17:34:23 +0100 Subject: keyserver spam In-Reply-To: <20111217154248.GC10330@poseidon.cocyt.us> References: <4EEB6906.8060900@lists.grepular.com> <20111217154248.GC10330@poseidon.cocyt.us> Message-ID: <4EECC48F.1080909@jeromebaum.com> On 2011-12-17 16:42, Aaron Toponce wrote: > I guess Anonymous or LULZ Security, or the like, could do it out of sheer > entertainment, but it would die quickly, as the effort in maintaining the > noise outweighs the benefit of annoying users by several orders of > magnitude. I think the point was that with the current keyserver setup, it wouldn't die off at all and there is basically no cost to maintaining the noise. You can easily grow the database to a crazy size and it'll be difficult to shrink it back down, as the keyservers keep syncing and you have to coordinate the entire network or the noise will just keep coming back. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From jerome at jeromebaum.com Sat Dec 17 17:36:19 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 17 Dec 2011 17:36:19 +0100 Subject: keyserver spam In-Reply-To: <1118309370.20111217161537@my_localhost> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <1118309370.20111217161537@my_localhost> Message-ID: <4EECC503.8050409@jeromebaum.com> On 2011-12-17 17:15, MFPA wrote: > Since you don't log into a keyserver when you post, and keyservers > store data but do not perform cryptographic functions, this is pretty > much inevitable. The "keyserver-no-modify" flag could, in theory, > carry with it a requirement that modifications to a key were signed by > that key. But, once again, increased complexity and server load. And > what about propagating changes between keyservers? I just thought about this and while the crypto overhead would always be there, my thinking is: If we're only adding, wouldn't a signature (e.g. of a hash of the sub-packet) be okay? This works fine in terms of propagation. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From pv4 at bk.ru Sat Dec 17 15:22:28 2011 From: pv4 at bk.ru (=?UTF-8?B?VmxhZGltaXIgQS4gUGF2bG92?=) Date: Sat, 17 Dec 2011 18:22:28 +0400 Subject: =?UTF-8?B?SG93IHRvIHNlbGVjdCBhIHBhcnRpY3VsYXIgcHVibGljIGtleSB3aGVuIHZl?= =?UTF-8?B?cmlmeWluZyBhIHNpZ25hdHVyZT8=?= Message-ID: Hi! I'd like to start using gnupg for information exchange but there is an issue I don't understand. I've read gnupg documentation and didn't find a solution so that I even think gnupg is not supposed to do what I expect from it. Consider the following situation. I have two friends: Alice and Bob. I added their publick keys (Alice's AAAAAAAA and Bob's BBBBBBBB) to my keyring. Now Bob sends me a signed file. When I verify the signature the file appears to be signed by Alice's key. But gpg doesn't give me an error, it just tells me the file was signed with AAAAAAAA key so that I have to look at the message and discover the key doesn't correspond to the sender. Bob has obviously got Alice's key that should not happen. But it happened. Alice could revoke her key and create a new one but she doesn't even currently know the key was stolen. One solution to prevent such a situation is to use two different keyrings for Alice's key and Bob's one and store each key in separate keyring. When verifying a file I can use --homedir to select whose key to use. But it seems difficult and not graceful for me especially if I have more friends. Another solution is to select a particular key to be used for verification. I tried -u but it works only when signing a file, not when verifying it. So: 1. Is there a way to select a key to verify a file with? 2. If not, is gnupg expected to deal with issues like the pointed above at all? Or should I just use another program (for example, openssl) to verify signatures? 3. If gnupg can handle the situation above, how can that be done? Do I misunderstand what gnupg is about and should I change my workflow to meet gnupg opportunities? -- Vladimir From expires2011 at ymail.com Sat Dec 17 16:55:05 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 17 Dec 2011 15:55:05 +0000 Subject: keyserver spam In-Reply-To: <4EEB84FD.9020408@fifthhorseman.net> References: <4EEB6906.8060900@lists.grepular.com> <4EEB84FD.9020408@fifthhorseman.net> Message-ID: <1238614878.20111217155505@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 16 December 2011 at 5:50:53 PM, in , Daniel Kahn Gillmor wrote: > well, there's the JBARSE key, which i vaguely recall > having been created in a joking way to threaten > character assassination, but i can't find any keys that > it has actually signed, nor any documentation to > explain why i have this recollection, so please take > with a grain of salt. A couple of years ago, somebody who had joined PGPNET started a discussion about having a PGPNET signing key to sign the keys of all the members, IIRC. He was adamant this was necessary and there was a quite acrimonious discussion. Basically, nobody else wanted it, so he left the group, created his own "PGPNET Signing Key," signed all the members' keys with it, and uploaded them to a keyserver. Quite a few of those keys had not previously been on the servers because not everybody wants their keys on the servers. Shortly afterwards, the "JBARSE" signature appeared on the rogue "PGPNET Signing Key." Which means all those keys now bear a signature from a key that is itself signed by a key with the UID of "Jane's bondage and rubberwear sex emporium " - -- Best regards MFPA mailto:expires2011 at ymail.com There is no job so simple that it cannot be done wrong -----BEGIN PGP SIGNATURE----- iQCVAwUBTuy7YaipC46tDG5pAQq9bQQAtSx6F349tcMEIEgVdyI4lETyhfmkV2Qh g8+jDHVS1EoJIT5Mri/y/OQftPCIvtx/4GwW4zybNG6NggSRr0pyk0lywf6aYWGD rqE4YsQWcaS8Kk63p1P0AkhAU8zlPF0ooVGgYJaZbgdoHBOc8pwKLZbBCB4pSLAy pZVvDbPZ3uU= =Yuau -----END PGP SIGNATURE----- From expires2011 at ymail.com Sat Dec 17 17:48:43 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 17 Dec 2011 16:48:43 +0000 Subject: keyserver spam In-Reply-To: <4EECC48F.1080909@jeromebaum.com> References: <4EEB6906.8060900@lists.grepular.com> <20111217154248.GC10330@poseidon.cocyt.us> <4EECC48F.1080909@jeromebaum.com> Message-ID: <84672130.20111217164843@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 17 December 2011 at 4:34:23 PM, in , Jerome Baum wrote: > On 2011-12-17 16:42, Aaron Toponce wrote: >> I guess Anonymous or LULZ Security, or the like, could do it out of sheer >> entertainment, but it would die quickly, as the effort in maintaining the >> noise outweighs the benefit of annoying users by several orders of >> magnitude. > I think the point was that with the current keyserver > setup, it wouldn't die off at all and there is > basically no cost to maintaining the noise. You can > easily grow the database to a crazy size and it'll be > difficult to shrink it back down, as the keyservers > keep syncing and you have to coordinate the entire > network or the noise will just keep coming back. I guess that either breaks (or at least greatly shrinks) the network. Or else the coding effort is put into solving a problem that actually exists, and a new generation of keyservers comes into being. At the moment the problem doesn't exist. - -- Best regards MFPA mailto:expires2011 at ymail.com Don't talk unless you can improve on the silence -----BEGIN PGP SIGNATURE----- iQCVAwUBTuzH76ipC46tDG5pAQpGwAQAiYFio5Gi8ve+zS3Lxbabf4ZVtxDA/DhR RTeIc/NC/MX7T1g1/wylf66D31FE/xtHI5sxK8cVEb0h9RP26MD9gleHf1SFxJ+e K6oFKqTEhRpF9l1NL+bY2CfiR0NfWwDjFPVqHOc53l5pt+2ocCVfU2+Zs+2z+AUk tA9wdikdgNo= =t/ob -----END PGP SIGNATURE----- From expires2011 at ymail.com Sat Dec 17 17:55:41 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 17 Dec 2011 16:55:41 +0000 Subject: How to select a particular public key when verifying a signature? In-Reply-To: References: Message-ID: <1125568166.20111217165541@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 17 December 2011 at 2:22:28 PM, in , Vladimir A. Pavlov wrote: > Consider the following situation. > I have two friends: Alice and Bob. I added their > publick keys (Alice's AAAAAAAA and Bob's BBBBBBBB) to > my keyring. Now Bob sends me a signed file. When I > verify the signature the file appears to be signed by > Alice's key. But gpg doesn't give me an error, it just > tells me the file was signed with AAAAAAAA key so that > I have to look at the message and discover the key > doesn't correspond to the sender. > Bob has obviously got Alice's key Bob has possibly got Alice's key. The more obvious conclusion is that Bob has simply forwarded a file that Alice signed. Of course, both possibilities need to be considered. - -- Best regards MFPA mailto:expires2011 at ymail.com No man ever listened himself out of a job -----BEGIN PGP SIGNATURE----- iQCVAwUBTuzJlqipC46tDG5pAQoG3gP7BeV+QV6wOZXk9yhtaoOn6qTuyEtFxeXA NQMT7nnPsbOzSXi4HOmBVKuPr4S9ClZHMlIWuXoR8M3qnkPPEcMtPcRsq8vQz4FN 7hpQnuEtHhhBGlMP9NYK1G7Y0Edqwue/QwjoqkELIGctc/n0niBHnYXRNtCP5Nwy uKv+T0MOyFM= =ChN3 -----END PGP SIGNATURE----- From expires2011 at ymail.com Sat Dec 17 17:00:11 2011 From: expires2011 at ymail.com (MFPA) Date: Sat, 17 Dec 2011 16:00:11 +0000 Subject: keyserver spam In-Reply-To: <4EEB6906.8060900@lists.grepular.com> References: <4EEB6906.8060900@lists.grepular.com> Message-ID: <415947583.20111217160011@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 16 December 2011 at 3:51:34 PM, in , gnupg at lists.grepular.com wrote: > I understand that once you've uploaded something to the > keyservers, it can't be removed. Eg, if I sign someone > elses key and upload that, it will be attached to their > key permanently? Yes. Of course, it is pretty poor form to upload it yourself rather than sending the signed copy to the person whose key it is, so that they can make the decision themself to upload. Still, it is easy to accidentally upload, or to deliberately but maliciously upload. Any signatures you encounter on a key are either part of your own decision how far to trust that key, or else useless noise. - -- Best regards MFPA mailto:expires2011 at ymail.com An obstinate man does not hold opinions. They hold him. -----BEGIN PGP SIGNATURE----- iQCVAwUBTuy8kaipC46tDG5pAQqeXQQAvtK85nIyo8XpWaR5RZNP+R4/gkmHzCH0 l5xWqyooH0bMZr3c2e2uWO1vWeVufT+874on/PTQY+eUlU0culW9cq293WHQzC5k h7iN+6qJmjz75A25eDBjxGmEEZ69vIPbosiyIQQBi6rClToBh8sBUbQqzledwuz+ mJaeukngjHc= =18JO -----END PGP SIGNATURE----- From jerome at jeromebaum.com Sat Dec 17 17:58:28 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Sat, 17 Dec 2011 17:58:28 +0100 Subject: keyserver spam In-Reply-To: <1111706341.20111217160446@my_localhost> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <4EECB484.6080701@jeromebaum.com> <1111706341.20111217160446@my_localhost> Message-ID: <4EECCA34.9050809@jeromebaum.com> On 2011-12-17 17:04, MFPA wrote: > On Saturday 17 December 2011 at 3:25:56 PM, in > , Jerome Baum wrote: >> I doubt the validity of those automated checks and >> checks on the email anyway. What constitutes "owning" >> foo at example.com? > > As far as that server's checking is concerned, being able to receive > the email they send out to that address and respond to it or click a > link. Okay so we're assuming that "ownership" means being able to read mail there. Given an attacker that cannot read mail for foo at example.com, if that attacker uploads a key with UID foo at example.com, what value does this verification have? If I don't verify the key, and send an encrypted email to foo at example.com, the attacker presumably cannot read the message anyway. So then I wouldn't even need to encrypt it. So then the key is useless for encryption. So is the check also. For signing, well I don't usually care that "some person who was at a point or currently is able to receive or intercept emails sent to foo at example.com signed this message", I usually care that "John Smith signed it". But let's assume I care whether something really originated with a person that was or is able to read email to foo at example.com, how is this more useful than just emailing them to confirm? i.e. IMO emails on UIDs are bullshit. So are certification policies that say (or don't say but enforce anyway) that you must have an email on your UID. Why refuse to certify _less_ information? Jerome Disclaimer: Of course everyone can make their own choices. I am expressing my viewpoint. My viewpoint may not necessarily be that of the company or companies I work or have worked or will work for. Trademarks are those of their respective owners. Copyrights are those of their respective owners. Database copyrights are those of their respective owners. Someone's name is also theirs. Blue means blue, red means red. The law applies. Do not break the law. Do not read this email if it is not intended for you. If you cannot tell that it is not intended for you, that's your fault. I reserve the right to sue your ass anyway. "Apple" and "i" are trademarks of Apple Inc., co., or something like that. "Orange" is probably a trademark of someone else as well. "Peach" is probably the trademark of the guys who trademarked "Orange", or maybe it's Apple's trademark. Who's in for a bet that "T-", "z", "y" and "x" are also all trademarked? DO NOT USE THIS DISCLAIMER TO OPERATE NUCLEAR POWER PLANTS OR WEAP... DEFENSE TECHNOLOGY. OH SHIT I LEFT MY CAPSLOCK ON ... Do not operate this disclaimer if you are prohibited from doing so. Operate it only when you are not prohibited from operating it. Have a great Christmas (if you celebrate it)! -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From mailinglisten at hauke-laging.de Sun Dec 18 00:24:30 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Sun, 18 Dec 2011 00:24:30 +0100 Subject: How to select a particular public key when verifying a signature? In-Reply-To: References: Message-ID: <201112180024.31083.mailinglisten@hauke-laging.de> Am Samstag, 17. Dezember 2011, 15:22:28 schrieb Vladimir A. Pavlov: > 1. Is there a way to select a key to verify a file with? 1) Create a directory for each key, e.g. /tmp/gpg-aaaaaaaa 2) Import the key: gpg --homedir /tmp/gpg-aaaaaaaa --import aaaaaaaa.asc 3) Check the files: gpg --homedir /tmp/gpg-aaaaaaaa --trusted-key AAAAAAAAAAAAAAAA \ --verify file.sig The solution is to use different gpg calls for the two keys. I would like to add that you are doing something strange: Usually crypto is used to unambigiously connect data to a person. You are trying to do this the other way round: You are using whatever to find out whether the crypto information is correct. See the problem? If somebody is capable of faking your signatures why shouldn't he be able to fake anything else (which you take as a proof of origin) like sending an email from the other ones account? Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From sandals at crustytoothpaste.net Sat Dec 17 23:54:41 2011 From: sandals at crustytoothpaste.net (brian m. carlson) Date: Sat, 17 Dec 2011 22:54:41 +0000 Subject: Bad Signatures when using check-sigs In-Reply-To: References: Message-ID: <20111217225441.GF3599@crustytoothpaste.ath.cx> On Fri, Dec 16, 2011 at 10:26:04AM -0500, David Tomaschik wrote: > When executing gpg --check-sigs, there are reports of "bad > signatures." What makes a signature "bad"? For example, on a key I > signed that has several UIDs, one of my signatures on one UID is > reported as bad, but the rest are fine. I looked in the docs, but > didn't find anything... hope I'm not missing something obvious. It means that one of the following things is true: * The key alleged to have made the signature did not make the signature. * The data on which the signature was made is different than the original data. * Someone made an error in the OpenPGP implementation. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From wk at gnupg.org Sun Dec 18 13:06:22 2011 From: wk at gnupg.org (Werner Koch) Date: Sun, 18 Dec 2011 13:06:22 +0100 Subject: keyserver spam In-Reply-To: <1118309370.20111217161537@my_localhost> (MFPA's message of "Sat, 17 Dec 2011 16:15:37 +0000") References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <1118309370.20111217161537@my_localhost> Message-ID: <87iple6q4h.fsf@vigenere.g10code.de> On Sat, 17 Dec 2011 17:15, expires2011 at ymail.com said: > A key's UIDs don't *have to* contain email addresses. But in the case > where they do, a verification email would be a useful addition. But An interesting way to spam key owners. Not a big deal, it is easy to add a procmail rule to send them to the bit bucket. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sun Dec 18 13:11:35 2011 From: wk at gnupg.org (Werner Koch) Date: Sun, 18 Dec 2011 13:11:35 +0100 Subject: GPG on meego-phone (nokia n9) In-Reply-To: <4EEC9B29.1070705@googlemail.com> (Xenia's message of "Sat, 17 Dec 2011 14:37:45 +0100") References: <4EEC9B29.1070705@googlemail.com> Message-ID: <87ehw26pvr.fsf@vigenere.g10code.de> On Sat, 17 Dec 2011 14:37, yoraxe at googlemail.com said: > Is there a gpg-application for meego, especially for the Nokia N9? Kontact-touch runs on the N900 and has recently be ported to the N950 and N9: http://userbase.kde.org/Kontact_Touch/Harmattan Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From expires2011 at ymail.com Sun Dec 18 23:40:57 2011 From: expires2011 at ymail.com (MFPA) Date: Sun, 18 Dec 2011 22:40:57 +0000 Subject: keyserver spam In-Reply-To: <4EECCA34.9050809@jeromebaum.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <4EECB484.6080701@jeromebaum.com> <1111706341.20111217160446@my_localhost> <4EECCA34.9050809@jeromebaum.com> Message-ID: <72715402.20111218224057@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 17 December 2011 at 4:58:28 PM, in , Jerome Baum wrote: > On 2011-12-17 17:04, MFPA wrote: >> On Saturday 17 December 2011 at 3:25:56 PM, in >> , Jerome Baum wrote: >>> I doubt the validity of those automated checks and >>> checks on the email anyway. What constitutes "owning" >>> foo at example.com? >> As far as that server's checking is concerned, being >> able to receive the email they send out to that >> address and respond to it or click a link. > Okay so we're assuming that "ownership" means being > able to read mail there. Given an attacker that cannot > read mail for foo at example.com, if that attacker uploads > a key with UID foo at example.com, what value does this > verification have? Unless somebody visits the link in the verification email, the key will not be added to the PGP Global Directory. > If I don't verify the key, and send > an encrypted email to foo at example.com, the attacker > presumably cannot read the message anyway. Nor can the person who controls foo at example.com but your email has just provided the service of alerting them of the existence of the attacker's key. > For signing, well I don't usually care that "some > person who was at a point or currently is able to > receive or intercept emails sent to foo at example.com > signed this message", I usually care that "John Smith > signed it". But let's assume I care whether something > really originated with a person that was or is able to > read email to foo at example.com, how is this more useful > than just emailing them to confirm? Convenience. *If* you trust the signature from the server that says they verified the email address for you, you don't need to do it yourself. > i.e. IMO emails on UIDs are bullshit. I would rather use hashes in UIDs, so that if you have my name or email address you can locate my key but inspecting my key does not give you my identity or contact details. > So are > certification policies that say (or don't say but > enforce anyway) that you must have an email on your > UID. Why refuse to certify _less_ information? Why indeed. My government won't issue a passport that doesn't include my date of birth. These days I can't even get a driving licence that doesn't show my date of birth. What does a date of birth have to do with my competence to drive between now and my licence's expiry date, or with my ability to travel across borders? - -- Best regards MFPA mailto:expires2011 at ymail.com If you can't convince them, confuse them. -----BEGIN PGP SIGNATURE----- iQCVAwUBTu5sAaipC46tDG5pAQptawP+NWp3JRBG4zX2M1p+P1UyaaPV/7GQ8Zcg e3fEdS7jqb6AewEpvpvjwI1mEAS935B4I0RpgBHZHpTFYvVUFJfg0wL6QP+b/qHy 45I/aKBu37qnlBxSMqd98eq8s0lNhcmJpcowUcW1nF1qkTA8nF5303VF5P3jnwLJ nCJ4NR7tax0= =sEfb -----END PGP SIGNATURE----- From expires2011 at ymail.com Sun Dec 18 23:48:19 2011 From: expires2011 at ymail.com (MFPA) Date: Sun, 18 Dec 2011 22:48:19 +0000 Subject: keyserver spam In-Reply-To: <87iple6q4h.fsf@vigenere.g10code.de> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <1118309370.20111217161537@my_localhost> <87iple6q4h.fsf@vigenere.g10code.de> Message-ID: <1424859464.20111218224819@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 18 December 2011 at 12:06:22 PM, in , Werner Koch wrote: > An interesting way to spam key owners. Not a big deal, > it is easy to add a procmail rule to send them to the > bit bucket. I'd not considered the scenario of uploading multiple key updates in order to get the servers to spam the key owner with verification emails. Sending them straight to the bit bucket would still have the desired effect of not accepting unwanted updates to your key. - -- Best regard MFPA mailto:expires2011 at ymail.com Only dead fish go with the flow -----BEGIN PGP SIGNATURE----- iQCVAwUBTu5tuKipC46tDG5pAQrk6gQAttIz2o4YjGRs/NSpJ6kTmqm8p/gXqsp5 0qsv4ChYdyoQPr7YpEj6P9qXKzZkgDxyiDRiDC0nw14LLVodRAD5Xb+KiXnh0+C3 MICl1o+yV/DI47trV0cR0l99Fv7STaGAvcbvQWCDEc7OVv88iaVPqVylOkQT/+yU sOQ8sePGIQc= =Y6as -----END PGP SIGNATURE----- From jerome at jeromebaum.com Mon Dec 19 10:31:31 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Mon, 19 Dec 2011 10:31:31 +0100 Subject: keyserver spam In-Reply-To: <72715402.20111218224057@my_localhost> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <4EECB484.6080701@jeromebaum.com> <1111706341.20111217160446@my_localhost> <4EECCA34.9050809@jeromebaum.com> <72715402.20111218224057@my_localhost> Message-ID: <4EEF0473.7090004@jeromebaum.com> On 2011-12-18 23:40, MFPA wrote: >> So are >> certification policies that say (or don't say but >> enforce anyway) that you must have an email on your >> UID. Why refuse to certify _less_ information? > > Why indeed. My government won't issue a passport that doesn't include > my date of birth. These days I can't even get a driving licence that > doesn't show my date of birth. What does a date of birth have to do > with my competence to drive between now and my licence's expiry date, > or with my ability to travel across borders? My understanding is that name + DoB + place of birth together are unique. Sometimes. In theory. But name + email aren't even unique then -- which is why some hosts like Google now refuse to re-register an expired email address, so that you can't receive emails for the previous owner. But again, not everyone does it and policies as well as domain ownership can also change. Wasn't there a nice paper on that problem (naming) linked to from this list maybe a month or two ago? Or maybe it was referenced in the STEED paper? Was definitely an interesting read. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From jerome at jeromebaum.com Mon Dec 19 10:36:33 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Mon, 19 Dec 2011 10:36:33 +0100 Subject: keyserver spam In-Reply-To: <4EEF0473.7090004@jeromebaum.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEC97C6.5040303@lists.grepular.com> <4EECB484.6080701@jeromebaum.com> <1111706341.20111217160446@my_localhost> <4EECCA34.9050809@jeromebaum.com> <72715402.20111218224057@my_localhost> <4EEF0473.7090004@jeromebaum.com> Message-ID: <4EEF05A1.1040004@jeromebaum.com> On 2011-12-19 10:31, Jerome Baum wrote: > My understanding is that name + DoB + place of birth together are > unique. Sometimes. In theory. Oh but that doesn't mean we should all add our DoB to our UIDs now. Remember that your DoB is actually secret and only your credit card company is meant to know it. You know, to verify the person speaking on the phone is really you... (Hmm, they also asked for my account number, which I suppose is also secret and not at all printed on all my invoices. Only a few key people, like everyone ever involved with a wire between them and me, know the account number. I suppose this is getting old...) -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From hka at qbs.com.pl Tue Dec 20 16:49:09 2011 From: hka at qbs.com.pl (Hubert Kario) Date: Tue, 20 Dec 2011 16:49:09 +0100 Subject: keyserver spam In-Reply-To: <4EEF05A1.1040004@jeromebaum.com> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEF0473.7090004@jeromebaum.com> <4EEF05A1.1040004@jeromebaum.com> Message-ID: <201112201649.13228.hka@qbs.com.pl> On Monday 19 of December 2011 10:36:33 Jerome Baum wrote: > On 2011-12-19 10:31, Jerome Baum wrote: > > My understanding is that name + DoB + place of birth together are > > unique. Sometimes. In theory. > > Oh but that doesn't mean we should all add our DoB to our UIDs now. > Remember that your DoB is actually secret and only your credit card > company is meant to know it. You know, to verify the person speaking on > the phone is really you... At least we're getting there. Don't know about the EU Data Protection directive, but the Polish one says specifically, that login reuse is verbotten. > (Hmm, they also asked for my account number, which I suppose is also > secret and not at all printed on all my invoices. Only a few key people, > like everyone ever involved with a wire between them and me, know the > account number. I suppose this is getting old...) Yeah, the kind of "protections" banks use is funny. But then, what can they do when people forget their passwords 5 minutes after they set them or use the same password on facebook and their bank... If only the "horse battery staple correct" method was taught as *the* method for creating and remembering passwords... -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawer?w 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2346 bytes Desc: not available URL: From wk at gnupg.org Tue Dec 20 17:26:49 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Dec 2011 17:26:49 +0100 Subject: GnuPG 2.1 beta 3 released Message-ID: <87fwgf1a5y.fsf@vigenere.g10code.de> Hello! We just released the third *beta version* of GnuPG 2.1. It has been released to give you the opportunity to check out the new features. It is marked as a beta versions and the plan is to release a couple more betas in the next months before we can declare 2.1.0 stable enough for general use. If you need a stable and fully maintained version of GnuPG, you should in general use 2.0.x or even the old 1.4.x. Noteworthy changes in version 2.1.0beta3 ======================================== * Fixed regression in GPG's secret key export function. * Allow generation of card keys up to 4096 bit. * Support the SSH confirm flag. * The Assuan commands KILLAGENT and KILLSCD are working again. * SCdaemon does not anymore block after changing a card (regression fix). * gpg-connect-agent does now proberly display the help output for "SCD HELP" commands. * Preliminary support for the GPGSM validation model "steed". * Improved certificate creation in GPGSM. * New option for GPG_AGENT to select a passphrase mode. The loopback mode may be used to bypass Pinentry. Noteworthy changes already found in beta2: * ECC support for GPG as described by draft-jivsov-openpgp-ecc-06.txt. * New GPGSM feature to create certificates from a parameter file. Add prompt to the --gen-key UI to create self-signed certificates. * Dirmngr has taken over the function of the keyserver helpers. Thus we now have a specified direct interface to keyservers via Dirmngr. LDAP, DNS and mail backends are not yet implemented. * TMPDIR is now also honored when creating a socket using --no-standard-socket and with symcryptrun's temp files. * Fixed a bug where SCdaemon sends a signal to Gpg-agent running in non-daemon mode. * Print "AES128" instead of "AES". This change introduces a little incompatibility for tools using "gpg --list-config". We hope that these tools are written robust enough to accept this new algorithm name as well. * Fixed CRL loading under W32 (bug#1010). * Fixed TTY management for pinentries and session variable update problem. Noteworthy changes already found in beta1: * GPG does not anymore use secring.gpg but delegates all secret key operations to gpg-agent. The import command moves secret keys to the agent. * The OpenPGP import command is now able to merge secret keys. * The G13 tool for disk encryption key management has been added. * If the agent's --use-standard-socket option is active, all tools try to start and daemonize the agent on the fly. In the past this was only supported on W32; on non-W32 systems the new configure option --disable-standard-socket may now be used to disable this new default. * Dirmngr is now a part of this package. Dirmngr is now also expected to run as a system service and the configuration directories are changed to the GnuPG name space. * Removed GPG options: --export-options: export-secret-subkey-passwd --simple-sk-checksum * New GPG options: --try-secret-key * Support DNS lookups for SRV, PKA and CERT on W32. * The default for --include-cert is now to include all certificates in the chain except for the root certificate. * Numerical values may now be used as an alternative to the debug-level keywords. * New GPGSM option --ignore-cert-extension. * Support for Windows CE. * Given sufficient permissions Dirmngr is started automagically. * Bug fixes. Migration from 1.4 or 2.0 to this version ========================================= The major change in 2.1 is that gpg-agent now takes care of the OpenPGP secret keys (those managed by GPG). The former secring.gpg will not be used anymore. Newly generated keys are generated and stored in the agent's key store (~/.gnupg/private-keys-v1.d/). To migrate your existing keys to the agent you should run this command gpg2 --import ~/.gnupg/secring.gpg The agent will you ask for the passphrase of each key. You may use the Cancel button of the Pinentry to skip importing this key. If you want to stop the import process and you use one of the latest pinentries, you should close the pinentry window instead of hitting the cancel button. Secret keys already imported are skipped by the import command. It is advisable to keep the secring.gpg for use with older versions of GPG. Note that gpg-agent now uses a fixed socket by default. All tools will start the gpg-agent as needed. In general there is no more need to set the GPG_AGENT_INFO environment variable. The SSH_AUTH_SOCK environment variable should be set to a fixed value. GPG's smartcard commands --card-edit and --card-status as well as the card related sub-commands of --edit-key are not yet supported. However, signing and decryption with a smartcard does work. The Dirmngr is now part of GnuPG proper. Thus there is no more need to install the separate dirmngr package. The directroy layout of Dirmngr changed to make use of the GnuPG directories; for example you use /etc/gnupg/trusted-certs and /var/lib/gnupg/extra-certs. Dirmngr needs to be started as a system daemon. Getting the Software ==================== GnuPG 2.1 is available at ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0beta3.tar.bz2 ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/gnupg-2.1.0beta3.tar.bz2.sig and soon on all mirrors . Note that libgcrypt >= 1.5 and Libassuan >= 2.0.3 are now required; they are available at ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.5.0.tar.bz2.sig ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.3.tar.bz2 ftp://ftp.gnupg.org/gcrypt/libassuan/libassuan-2.0.3.tar.bz2.sig Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * You are expected to have a trusted version of GnuPG installed, thus you may simply check the supplied signature. For example to check the signature of the file gnupg-2.1.0beta3.tar.bz2 you would use this command: gpg --verify gnupg-2.1.0beta3.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a key server like gpg --recv-key 4F25E3B6 The distribution key 4F25E3B6 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! Internationalization ==================== This version comes only with support for English and German. More languages will be added for the real release. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Future Plans ============ Some tasks we would like to do before a 2.1 release: * Replace the pubring.gpg public key store with the keybox format. * Re-enable importing keys to a smartcard * Re-enable LDAP, kDNS and mail keyserver methods * Replace Pth by the nPth (already done and tested for GNU/Linux) Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or by donating money. Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. A service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 201 bytes Desc: not available URL: From melvincarvalho at gmail.com Tue Dec 20 16:32:23 2011 From: melvincarvalho at gmail.com (Melvin Carvalho) Date: Tue, 20 Dec 2011 16:32:23 +0100 Subject: keyserver spam In-Reply-To: <4EEB84FD.9020408@fifthhorseman.net> References: <4EEB6906.8060900@lists.grepular.com> <4EEB84FD.9020408@fifthhorseman.net> Message-ID: On 16 December 2011 18:50, Daniel Kahn Gillmor wrote: > On 12/16/2011 10:51 AM, gnupg at lists.grepular.com wrote: >> I understand that once you've uploaded something to the keyservers, it >> can't be removed. Eg, if I sign someone elses key and upload that, it >> will be attached to their key permanently? > > yes, this is correct. :( > >> What if someone were to generate say, 10,000 keypairs with "offensive" >> uid names, and then sign my key with each of them, and then upload that >> to the keyservers? Is there anything to stop that? > > nope. ?flooding like this is currently possible. :( > >> Is there anything to >> stop a spammer generating a key with their URL in the uid name and then >> signing every key they can find and uploading that to the keyservers? > > nope, this is also possible. :( > >> Has anything like this happened before? > > well, there's the JBARSE key, which i vaguely recall having been created > in a joking way to threaten character assassination, but i can't find > any keys that it has actually signed, nor any documentation to explain > why i have this recollection, so please take with a grain of salt. I'm wondering if this could be as an attack vector against (say), freedombox, if it became popular e.g. 1. Lets say FBX got a big sponsorship, could the key servers cope with 1 million, 10 million, 100 million new keys? Granted, this is a nice problem to have! :) 2. Could a malicious or anti-freedom oriented entity use this to disrupt the FBX network, for example by using a botnet to keep spamming key servers, similar to email spam botnets. CC: FBX mail list > > ? ? ? ?--dkg > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From johanw at vulcan.xs4all.nl Tue Dec 20 17:34:24 2011 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Tue, 20 Dec 2011 17:34:24 +0100 Subject: keyserver spam In-Reply-To: <201112201649.13228.hka@qbs.com.pl> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <4EEF0473.7090004@jeromebaum.com> <4EEF05A1.1040004@jeromebaum.com> <201112201649.13228.hka@qbs.com.pl> Message-ID: <4EF0B910.7040008@vulcan.xs4all.nl> On 20-12-2011 16:49, Hubert Kario wrote: > Yeah, the kind of "protections" banks use is funny. But then, what can they do > when people forget their passwords 5 minutes after they set them or use the > same password on facebook and their bank... They could use the same system that all banks (minus one, ING, that as a result is the most attacked one here) in The Netherlands use: 2-factor authorization. When I want to login I have to put my debet card into a reader that can access the chip on it. It asks me for a pin code, then I have to enter a code given by the bank on the login screen, press OK and enter the response into the browser. The code I get from the bank is randomly generated by them, and the response depends on the debet card inserted in the device. Some banks work with code generators that don't require the use of your debet card. But a simple login/password combo, no bank would use that here. -- Met vriendelijke groet / With kind regards, Johan Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From hka at qbs.com.pl Tue Dec 20 19:11:42 2011 From: hka at qbs.com.pl (Hubert Kario) Date: Tue, 20 Dec 2011 19:11:42 +0100 Subject: keyserver spam In-Reply-To: <4EF0B910.7040008@vulcan.xs4all.nl> References: <20111216190736.8497B10E2D6@smtp.hushmail.com> <201112201649.13228.hka@qbs.com.pl> <4EF0B910.7040008@vulcan.xs4all.nl> Message-ID: <201112201911.43236.hka@qbs.com.pl> On Tuesday 20 of December 2011 17:34:24 Johan Wevers wrote: > On 20-12-2011 16:49, Hubert Kario wrote: > > Yeah, the kind of "protections" banks use is funny. But then, what can > > they do when people forget their passwords 5 minutes after they set them > > or use the same password on facebook and their bank... > > They could use the same system that all banks (minus one, ING, that as a > result is the most attacked one here) in The Netherlands use: 2-factor > authorization. When I want to login I have to put my debet card into a > reader that can access the chip on it. It asks me for a pin code, then I > have to enter a code given by the bank on the login screen, press OK and > enter the response into the browser. The code I get from the bank is > randomly generated by them, and the response depends on the debet card > inserted in the device. Some banks work with code generators that don't > require the use of your debet card. But a simple login/password combo, > no bank would use that here. I didn't mean the login to a web service. This is, in all cases I saw, always two-factor. I meant the phone service or all the credit card transactions. -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawer?w 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2346 bytes Desc: not available URL: From nicholas.cole at gmail.com Tue Dec 20 19:24:16 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 20 Dec 2011 18:24:16 +0000 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87fwgf1a5y.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: On Tue, Dec 20, 2011 at 4:26 PM, Werner Koch wrote: > ?* GPG does not anymore use secring.gpg but delegates all secret key > ? operations to gpg-agent. ?The import command moves secret keys to > ? the agent. > > ?* The OpenPGP import command is now able to merge secret keys. I see that the man page still refers to the option --secret-keyring. Presumably this option now does nothing? Very exciting to see the new release! N From wk at gnupg.org Wed Dec 21 11:26:17 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2011 11:26:17 +0100 Subject: GnuPG 2.1 beta 3 released In-Reply-To: (Nicholas Cole's message of "Tue, 20 Dec 2011 18:24:16 +0000") References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: <871uryz0dy.fsf@vigenere.g10code.de> On Tue, 20 Dec 2011 19:24, nicholas.cole at gmail.com said: > I see that the man page still refers to the option --secret-keyring. > Presumably this option now does nothing? Right, it is a NOP. It is still there so you are able to use the same gpg.conf for all versions of GnuPG. I will fix the documentation. > Very exciting to see the new release! I did it mainly to tell that 2.1 development is still alive and also to remind me about 14 years of GnuPG. More seriously this will be the last beta which uses Pth - we need to switch over to nPth[1]. This new library will need some time to build and work correctly on non-GNU/Linux systems. Salam-Shalom, Werner [1] http://git.gnupg.org/cgi-bin/gitweb.cgi?p=npth.git -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From pv4 at bk.ru Wed Dec 21 12:48:15 2011 From: pv4 at bk.ru (=?UTF-8?B?VmxhZGltaXIgQS4gUGF2bG92?=) Date: Wed, 21 Dec 2011 15:48:15 +0400 Subject: =?UTF-8?B?UmU6IEhvdyB0byBzZWxlY3QgYSBwYXJ0aWN1bGFyIHB1YmxpYyBrZXkgd2hl?= =?UTF-8?B?biB2ZXJpZnlpbmcgYSBzaWduYXR1cmU/?= In-Reply-To: <201112180024.31083.mailinglisten@hauke-laging.de> References: <201112180024.31083.mailinglisten@hauke-laging.de> Message-ID: > The solution is to use different gpg calls for the two keys. That is exactly what I thought about, I just hoped there is a simplier way. > If somebody is capable of faking your signatures why shouldn't he > be able to fake anything else (which you take as a proof of origin) > like sending an email from the other ones account? I tried to add "one more" verification level to the whole system. Now I guess I should rethink about how gnupg should be used. Thanks. From magnus at trisec.net Wed Dec 21 11:33:17 2011 From: magnus at trisec.net (Magnus Bergman) Date: Wed, 21 Dec 2011 11:33:17 +0100 Subject: Digipass 920 Message-ID: Hi, Has anyone had any luck in getting Digipass 920 to work with GnuPG and OpenPGP smartcards? It has a pin-entry keypad and seems to work fine for doing a --card-status, but not for example signing: "gpg: signing failed: Conditions of use not satisfied" after getting the normal pin entry window. Would this be a problem with GnuPG not supporting Digipass 920 keypad and the digipass blocking access to the card if pin is not supplied by the keypad? //Magnus From rjh at sixdemonbag.org Wed Dec 21 16:00:39 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 21 Dec 2011 10:00:39 -0500 Subject: Holidays Message-ID: <4EF1F497.4080400@sixdemonbag.org> Christmas is upon us. This is traditionally a time for family, charity, giving and thankfulness. For myself, I'm thankful for GnuPG and all the work that Werner and others have put into it -- as are many of us. Let's remember them this holiday season and put out a big round of "thank you"s. Further: in recent years I've encouraged people to donate to the Electronic Frontier Foundation, the Free Software Foundation, or other similar electronic charities, since there was no effective way to donate to GnuPG directly. Thankfully, this is no longer the case. If you have a PayPal account you can contribute directly towards GnuPG development by visiting GnuPG's "Donations" page, at: http://g10code.com/gnupg-donation.html So far, GnuPG has received sixteen donations this year totaling 358 euros. Frankly, that amount seems way too low to me. Let's see if we can't increase those numbers. :) This holiday season, let's all remember -- it's far more blessed to give than to receive! From nsushkin at sushkins.net Wed Dec 21 16:48:35 2011 From: nsushkin at sushkins.net (Nicholas Sushkin) Date: Wed, 21 Dec 2011 10:48:35 -0500 Subject: Who is doing S/MIME enveloping in KMail - gnupg2 or KMail? Message-ID: <2575726.cKntOGZGcN@strela> Hi, I think there is a bug in the way KMail is doing S/Mime envelop for signed but not encrypted messages. I'd like to follow through, but I am not sure if it's gnupg or KMail, which is the proper forum. Does anyone (Werner) know by any chance? Thanks. ps. https://bugs.kde.org/show_bug.cgi?id=280245 -- Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4550 bytes Desc: not available URL: From aaron.toponce at gmail.com Wed Dec 21 18:14:53 2011 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Wed, 21 Dec 2011 10:14:53 -0700 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87fwgf1a5y.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: <20111221171453.GA22507@poseidon.cocyt.us> On Tue, Dec 20, 2011 at 05:26:49PM +0100, Werner Koch wrote: > Noteworthy changes already found in beta2: > > * ECC support for GPG as described by draft-jivsov-openpgp-ecc-06.txt. Eager for this. Will we be seeing ECC support in 1.4.x? -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: Digital signature URL: From aaron.toponce at gmail.com Wed Dec 21 18:25:47 2011 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Wed, 21 Dec 2011 10:25:47 -0700 Subject: Who is doing S/MIME enveloping in KMail - gnupg2 or KMail? In-Reply-To: <2575726.cKntOGZGcN@strela> References: <2575726.cKntOGZGcN@strela> Message-ID: <20111221172547.GB22507@poseidon.cocyt.us> On Wed, Dec 21, 2011 at 10:48:35AM -0500, Nicholas Sushkin wrote: > Hi, I think there is a bug in the way KMail is doing S/Mime envelop for signed > but not encrypted messages. I'd like to follow through, but I am not sure if > it's gnupg or KMail, which is the proper forum. Does anyone (Werner) know by > any chance? Can you explain more? I'm assuming you're using GnuPG 2.0, seeing as though 1.4.* does not support S/MIME. Or are you confusing S/MIME with PGP/MIME? What errors are you seeing? What are you trying to do? Et cetera. Thanks, -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: Digital signature URL: From nsushkin at users.sourceforge.net Wed Dec 21 19:24:27 2011 From: nsushkin at users.sourceforge.net (Nicholas Sushkin) Date: Wed, 21 Dec 2011 13:24:27 -0500 Subject: Who is doing S/MIME enveloping in KMail - gnupg2 or KMail? In-Reply-To: References: Message-ID: <2222495.JQnm4heRr8@strela> Hi, Aaron, KMail 2.1.1 KDE 4.6.5 gpgsm (GnuPG) 2.0.17 libgcrypt 1.4.6 libksba 1.2.0 I send a signed unencrypted email. iPad and Outlook-web recipients cannot see the body of my email, only seeing the smime.p7m attachment. I am getting angry responses implying to stop using SMIME. I am looking at the email source and comparing to SMIME signed emails other people send from Outlook, Thunderbird, and Apple Mail that can be read on iPad and Outlook-web. I am also looking at the SMIME RFC http://tools.ietf.org/html/rfc3851#section-3.4 It seems that KMail is using saying Content-Type: multipart/signed and is using "SignedData format" option of sending out a signed email. It seems that that's against the RFC. The way I understand RFC is that if you do "SignedData format", you need to specify MIME Type "aplication/pcks7-mime". So, I am wondering whether KMail can create signed only messages using the multipart/signed correctly, so that clients that do not support SMIME can properly display them. I found a related bug filed in KMail https://bugs.kde.org/show_bug.cgi?id=280245 and commented on it, but I am not sure if the problem may be with gpgsm instead. Aaron Toponce wrote: > On Wed, Dec 21, 2011 at 10:48:35AM -0500, Nicholas Sushkin wrote: > > Hi, I think there is a bug in the way KMail is doing S/Mime envelop for > > signed but not encrypted messages. I'd like to follow through, but I am > > not sure if it's gnupg or KMail, which is the proper forum. Does anyone > > (Werner) know by any chance? > > Can you explain more? I'm assuming you're using GnuPG 2.0, seeing as though > 1.4.* does not support S/MIME. Or are you confusing S/MIME with PGP/MIME? > What errors are you seeing? What are you trying to do? Et cetera. > > Thanks, -- Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From nsushkin at users.sourceforge.net Wed Dec 21 16:38:04 2011 From: nsushkin at users.sourceforge.net (Nicholas Sushkin) Date: Wed, 21 Dec 2011 10:38:04 -0500 Subject: Who is doing S/MIME enveloping in KMail - gnupg2 or KMail? Message-ID: <29436846.QijIv6W7lQ@strela> Hi, I think there is a bug in the way KMail is doing S/Mime envelop for signed but not encrypted messages. I'd like to follow through, but I am not sure if it's gnupg or KMail, which is the proper forum. Does anyone (Werner) know by any chance? Thanks. ps. https://bugs.kde.org/show_bug.cgi?id=280245 -- Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Dec 21 20:41:55 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Dec 2011 20:41:55 +0100 Subject: Who is doing S/MIME enveloping in KMail - gnupg2 or KMail? In-Reply-To: <2575726.cKntOGZGcN@strela> (Nicholas Sushkin's message of "Wed, 21 Dec 2011 10:48:35 -0500") References: <2575726.cKntOGZGcN@strela> Message-ID: <87mxalww3g.fsf@vigenere.g10code.de> On Wed, 21 Dec 2011 16:48, nsushkin at sushkins.net said: > Hi, I think there is a bug in the way KMail is doing S/Mime envelop for signed > but not encrypted messages. I'd like to follow through, but I am not sure if > it's gnupg or KMail, which is the proper forum. Does anyone (Werner) know by > any chance? It must be a KMail problem. I know that it used to work very nicely all the years since we started the S/MIME support about 10 years ago. Thus I assume there is a regression in KMail. I don't have a current version running here for a quick test. GnuPG (i.e. gpgsm) does not know anything about S/MIME - it merely creates data according to the CMS encryption/signing standard. GPGME (the library between KMail and GnuPG) also has no knowledge about S/MIME. KMail is responsible to pack that into a MIME structure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kloecker at kde.org Wed Dec 21 20:48:26 2011 From: kloecker at kde.org (Ingo =?iso-8859-15?q?Kl=F6cker?=) Date: Wed, 21 Dec 2011 20:48:26 +0100 Subject: Who is doing S/MIME enveloping in KMail - gnupg2 or KMail? In-Reply-To: <2575726.cKntOGZGcN@strela> References: <2575726.cKntOGZGcN@strela> Message-ID: <201112212048.27337@thufir.ingo-kloecker.de> On Wednesday 21 December 2011, Nicholas Sushkin wrote: > Hi, I think there is a bug in the way KMail is doing S/Mime envelop > for signed but not encrypted messages. I'd like to follow through, > but I am not sure if it's gnupg or KMail, which is the proper forum. > Does anyone (Werner) know by any chance? KMail assembles the message. gpg "only" provides the signature. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From karadenizi at gmail.com Tue Dec 20 07:07:22 2011 From: karadenizi at gmail.com (Kara) Date: Tue, 20 Dec 2011 01:07:22 -0500 Subject: 20 Dec 2011: Status of John W. Moore III Message-ID: <4EF0261A.5020000@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 ==== Dear Friends of John W. Moore III You may recall that John's mother unexpectedly died on 6 Jul 2010 and that along with the unexpected complexities of probating her estate and some other things resulted in his having to reluctantly terminate his extensive involvement in crypto and other Internet-related activities. The required surgery on John's right foot went well although they determined they had to remove his little toe and the portion of his foot from there to the back of his heel. As a result John tells me he can now only count up to 9 versus 10. As a result of that surgery and some additional continuing health problems, John still has some major mobility problems and is still currently using a wheelchair to get around. However he's looking forward to being able to do some very limited walking sometime after the first of the year. John has a strong interest in once again becoming active in both his crypto and other Internet interests but currently isn't sure how soon he will be able to begin doing so in 2012. *Currently he has no Internet capability so please* *don't try to email or otherwise try to contact him by* *any other Internet mode*. ==== In the meantime John (UTC -0500) would be very interested in hearing from you and asks you do so via either his: Home address: 10660 Rogers Circle Duluth GA, 30097-1926, USA Home phone: 770-476-3551 Cell phone: 678-469-7535 ==== Finally, John asked that I convey to each of you his very best wishes that you and those you love have a wonderful Dec holiday season and a healthy and prosperous New Year. ==== I join John in extending the same thoughts and wishes to you and yours. Cordially Kara Timestamp: Tue, 20 Dec 2011, 0107 Local (UTC -0500) *Please Note: This email is being sent to the following crypto-related* *mailing lists*: Enigmail Discussion Group GPG-Users GSWoT Introducers PGP-Basics PGPNET ==== . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: For keyID and its URL see the OpenPGP message header iEYEAREIAAYFAk7wJgkACgkQ15k+1L3RO5C2nACfSOOzj5uEmZRzw7E7zh/xpNhQ cTQAoOYKHmm7sr4t4r6jxCsuf9MIxHDW =FPd1 -----END PGP SIGNATURE----- From nicholas.cole at gmail.com Fri Dec 23 19:29:09 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Fri, 23 Dec 2011 18:29:09 +0000 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87fwgf1a5y.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: > ?* GPG does not anymore use secring.gpg but delegates all secret key > ? operations to gpg-agent. ?The import command moves secret keys to > ? the agent. How will this interact with the --homedir option? Will --homedir be passed to gpg-agent or are the two entirely separate? I ask because at the moment it is possible to keep separate keyrings in different home directories, which might be useful to (for example) keep the large debian keyrings separate from personal keys, or to keep a set of keys for testing purposes separate from production keys. Best wishes, Nicholas From wk at gnupg.org Fri Dec 23 20:59:14 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Dec 2011 20:59:14 +0100 Subject: GnuPG 2.1 beta 3 released In-Reply-To: (Nicholas Cole's message of "Fri, 23 Dec 2011 18:29:09 +0000") References: <87fwgf1a5y.fsf@vigenere.g10code.de> Message-ID: <87k45nrre5.fsf@vigenere.g10code.de> On Fri, 23 Dec 2011 19:29, nicholas.cole at gmail.com said: > How will this interact with the --homedir option? Will --homedir be > passed to gpg-agent or are the two entirely separate? No it won't. The gpg-agent has its own --homedir option which allows to have a flexible configuration. By design the gpg-agent may even running on a different box. However that is currently not supported. > I ask because at the moment it is possible to keep separate keyrings > in different home directories, which might be useful to (for example) > keep the large debian keyrings separate from personal keys, or to keep > a set of keys for testing purposes separate from production keys. gpg --homedir is still used of the public keyrings. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nsushkin at users.sourceforge.net Sat Dec 24 01:36:35 2011 From: nsushkin at users.sourceforge.net (Nicholas Sushkin) Date: Fri, 23 Dec 2011 19:36:35 -0500 Subject: Who is doing S/MIME enveloping in KMail - gnupg2 or KMail? In-Reply-To: References: Message-ID: <3962671.2HlCnjF7WV@strela> Ingo, Thanks for clarification. I filed a bug report with KDE https://bugs.kde.org/show_bug.cgi?id=289677 On Friday, December 23, 2011 20:14:21 gnupg-users-request at gnupg.org wrote: > On Wednesday 21 December 2011, Nicholas Sushkin wrote: > > Hi, I think there is a bug in the way KMail is doing S/Mime envelop > > for signed but not encrypted messages. I'd like to follow through, > > but I am not sure if it's gnupg or KMail, which is the proper forum. > > Does anyone (Werner) know by any chance? > > KMail assembles the message. gpg "only" provides the signature. -- Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: From drfarina at acm.org Sun Dec 25 01:23:45 2011 From: drfarina at acm.org (Daniel Farina) Date: Sat, 24 Dec 2011 16:23:45 -0800 Subject: Encrypting using gpgsm and self-signed certificates Message-ID: Hello list, I've been integrating GPG into a backup utility, and while OpenPGP works as expected, I'm having some trouble with trying to also enable self-signed x509 certs via gpgsm as a mechanism for encryption. Unfortunately all I get back from gpgsm is "No Value". The output of a gpgsm invocation without an agent running (as so all output is in one set of output) is as follows: $ gpgsm -v --debug-level=guru -r 'A17951D33720CCE03E1065ABB7BBC16CC11CCBB9' -e < /dev/urandom gpgsm: enabled debug flags: x509 mpi crypto memory cache memstat hashing assuan gpgsm: no key usage specified - assuming all usages gpgsm: DBG: BEGIN Certificate `target': gpgsm: DBG: serial: 00A5BAF1300BFAC1B8 gpgsm: DBG: notBefore: 2010-02-04 03:35:35 gpgsm: DBG: notAfter: 2020-02-02 03:35:35 gpgsm: DBG: issuer: CN=ubuntu gpgsm: DBG: subject: CN=ubuntu gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5 gpgsm: DBG: SHA1 Fingerprint: A1:79:51:D3:37:20:CC:E0:3E:10:65:AB:B7:BB:C1:6C:C1:1C:CB:B9 gpgsm: DBG: END Certificate gpgsm: can't connect to the agent - trying fall back gpgsm: no running gpg-agent - starting one gpgsm: DBG: connection to agent established gpgsm: validation model used: shell gpgsm: can't encrypt to `A17951D33720CCE03E1065ABB7BBC16CC11CCBB9': No value random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 secmem usage: 0/16384 bytes in 0 blocks It looks like I'm not the only one who has been scratching his head when happening upon this error condition, although I think my situation appears slightly different: http://lists.gnupg.org/pipermail/gnupg-devel/2009-April/024937.html I also tried to make use of http://lists.gnupg.org/pipermail/gnupg-users/2004-September/023247.html, but somehow I feel there is a gap in documentation here for the really simple case of: "I have a self signed certificate. I trust it. Encrypt with it", and doing the most obvious thing (--import-key, --encrypt --recipient $FINGERPRINT) fails. By contrast, it's more or less straightforward to generate an OpenPGP key, trust it, and then encrypt an archive with it, and that works as expected. Cheers, -- fdr From nicholas.cole at gmail.com Sun Dec 25 19:00:58 2011 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 25 Dec 2011 18:00:58 +0000 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87k45nrre5.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> <87k45nrre5.fsf@vigenere.g10code.de> Message-ID: On Friday, December 23, 2011, Werner Koch wrote: > On Fri, 23 Dec 2011 19:29, nicholas.cole at gmail.com said: > >> How will this interact with the --homedir option? Will --homedir be >> passed to gpg-agent or are the two entirely separate? > > No it won't. The gpg-agent has its own --homedir option which allows to > have a flexible configuration. By design the gpg-agent may even running > on a different box. However that is currently not supported. > >> I ask because at the moment it is possible to keep separate keyrings >> in different home directories, which might be useful to (for example) >> keep the large debian keyrings separate from personal keys, or to keep >> a set of keys for testing purposes separate from production keys. > > gpg --homedir is still used of the public keyrings. Dear Werner, It would be very good if there were still a way to completely 'sandox' (for want of a better term) an instance of gpg, so that it uses its own key rings and trust databases. I certainly find that for testing purposes it is very useful indeed. On previous versions --homedir does this nicely. I presume the new way will be to make sure that a separate copy of gpg-agent is running and to pass in GPG_AGENT_INFO as an environment variable, as well as specifying a --homedir. Or will there be a better way? Best wishes, Nicholas -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon Dec 26 14:42:26 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Dec 2011 14:42:26 +0100 Subject: GnuPG 2.1 beta 3 released In-Reply-To: (Nicholas Cole's message of "Sun, 25 Dec 2011 18:00:58 +0000") References: <87fwgf1a5y.fsf@vigenere.g10code.de> <87k45nrre5.fsf@vigenere.g10code.de> Message-ID: <87sjk7qwjh.fsf@vigenere.g10code.de> On Sun, 25 Dec 2011 19:00, nicholas.cole at gmail.com said: > It would be very good if there were still a way to completely 'sandox' (for > want of a better term) an instance of gpg, so that it uses its own key > rings and trust databases. I certainly find that for testing purposes it > is very useful indeed. On previous versions --homedir does this nicely. A easy way to do this is: GNUPGHOME=/foo/bar gpg-agent --daemon sh and then do whatever you want in this shell. If you are done run give an exit and with a few seconds that gpg-agent will be terminated. That is how I do almost all tests. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Dec 26 14:57:15 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Dec 2011 14:57:15 +0100 Subject: Encrypting using gpgsm and self-signed certificates In-Reply-To: (Daniel Farina's message of "Sat, 24 Dec 2011 16:23:45 -0800") References: Message-ID: <87obuvqvus.fsf@vigenere.g10code.de> On Sun, 25 Dec 2011 01:23, drfarina at acm.org said: > self-signed x509 certs via gpgsm as a mechanism for encryption. > Unfortunately all I get back from gpgsm is "No Value". The output of That is a misleading error message. You should also enable gpg-agent logging in gpg-agent.conf to see the real problem. > $ gpgsm -v --debug-level=guru -r > 'A17951D33720CCE03E1065ABB7BBC16CC11CCBB9' -e < /dev/urandom Surely you are joking, Daniel. Encrypting an endless random stream is not very practical ;-). > --encrypt --recipient $FINGERPRINT) fails. By contrast, it's more or > less straightforward to generate an OpenPGP key, trust it, and then > encrypt an archive with it, and that works as expected. Welcome to the world of X.509. More seriously, the problem is that you need to trust a given certificate and X.509 requires a PKI for it. Thus you need some kind of root certificate which is flagged as trusted. With the proper options (gpg-agent's --allow-mark-trusted) you can do that for a self-signed certificate. In theory we could add a validation model to gpgsm which always trusts a certificate. In 2.1beta3, we added the validation model "seed" which does something like this. It trusts all root certificates with a special attribute. If you add this this attribute to your certificate you are done. However, the actual idea behind that feature is, that you use a well known private key and certifciate to issue your certificates (dubbed, the STEED Self-Signing Nonthority). In the end it is the same as a self-signed certificate. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From mcmurphy at riseup.net Mon Dec 26 17:46:48 2011 From: mcmurphy at riseup.net (mcmurphy) Date: Mon, 26 Dec 2011 17:46:48 +0100 Subject: German Privacy Foundation Crypto-stick Message-ID: <4EF8A4F8.80200@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, i'm trying to work with the Crypto-stick of the German Privacy Foundation (https://www.privacyfoundation.de/crypto_stick/crypto_stick_english/) under ubuntu 11 64-bit. Unfortunately it works only for root or sudoers. An UNPRVILEGED user gets the following message: $ gpg --card-status gpg: selecting openpgp failed: unknown command gpg: OpenPGP Karte ist nicht vorhanden: Allgemeiner Fehler I searched a lot, tried some udev-rules, i.e. http://dokuwiki.nausch.org/doku.php/centos:cryptos or http://lists.gnupg.org/pipermail/gnupg-users/2011-February/040781.html. It makes no difference. Maybe you have some hints for solving this problem. Thanx mcmurphy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO+KT3AAoJENYLD3BkimK7pzEH/jtHK62jm02cjB8z/3mDA/tE x7vv4rj9YW+3JWitTtubDGQjTAo3s2CBuSRTJuOGpWc99zaaitMrbfo6Y+BVZxLp Xc9DEABLqjJ37pe2SVHp3+rrGA8ejNdyWo7y3MzNjFVaFjI/lOEbV0om+g2MrTo/ noXKzCRgVTKP2diBiwChSpKcf/fyMOwFXXtku37ZIyXnn2VG0TcVekC80mWd6dn9 Z9Z1Or4PIsbK07KlJ+nGRrHCfi0wojXUmm+tzflc3qk6Jd5Rr8SqvRZ1l/UdtWuM 1UxGCXrUJJ6yZFsWhFB3HPkSyteA4ZzArlqKqYo31pNaX0vF5164IdLxC5/kfsA= =aR1G -----END PGP SIGNATURE----- From cryptostick at privacyfoundation.de Tue Dec 27 00:50:40 2011 From: cryptostick at privacyfoundation.de (Crypto Stick) Date: Tue, 27 Dec 2011 07:50:40 +0800 Subject: German Privacy Foundation Crypto-stick In-Reply-To: <4EF8A4F8.80200@riseup.net> References: <4EF8A4F8.80200@riseup.net> Message-ID: <4EF90850.2010707@privacyfoundation.de> Hi! Please install this package (UDEV rule) and it should work. https://www.assembla.com/spaces/cryptostick/documents/ds_EMCisGr4k7QeJe5cbCb/download/ds_EMCisGr4k7QeJe5cbCb Am 27.12.2011 00:46, schrieb mcmurphy: > Hi, > > i'm trying to work with the Crypto-stick of the German Privacy > Foundation > (https://www.privacyfoundation.de/crypto_stick/crypto_stick_english/) > under ubuntu 11 64-bit. Unfortunately it works only for root or > sudoers. An UNPRVILEGED user gets the following message: > > $ gpg --card-status > gpg: selecting openpgp failed: unknown command > gpg: OpenPGP Karte ist nicht vorhanden: Allgemeiner Fehler > > I searched a lot, tried some udev-rules, i.e. > http://dokuwiki.nausch.org/doku.php/centos:cryptos or > http://lists.gnupg.org/pipermail/gnupg-users/2011-February/040781.html. It > makes no difference. > > Maybe you have some hints for solving this problem. > > Thanx > mcmurphy > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From mcmurphy at riseup.net Tue Dec 27 02:00:08 2011 From: mcmurphy at riseup.net (mcmurphy) Date: Tue, 27 Dec 2011 02:00:08 +0100 Subject: German Privacy Foundation Crypto-stick In-Reply-To: <4EF90850.2010707@privacyfoundation.de> References: <4EF8A4F8.80200@riseup.net> <4EF90850.2010707@privacyfoundation.de> Message-ID: <4EF91898.1010603@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, thank you for the answer. There is no difference. I'm not sure, whether the installation works. There is no new rule in /etc/udev/rules.d. Is it gnupg-ccid.rules in /etc/udev/? However: Nothing changed for not-sudoer-user. Maybe there is something wrong with udev or gpg? mcmurphy On 27.12.2011 00:50, Crypto Stick wrote: > Hi! Please install this package (UDEV rule) and it should work. > https://www.assembla.com/spaces/cryptostick/documents/ds_EMCisGr4k7QeJe5cbCb/download/ds_EMCisGr4k7QeJe5cbCb > > > > Am 27.12.2011 00:46, schrieb mcmurphy: >> Hi, >> >> i'm trying to work with the Crypto-stick of the German Privacy >> Foundation >> (https://www.privacyfoundation.de/crypto_stick/crypto_stick_english/) >> >> under ubuntu 11 64-bit. Unfortunately it works only for root or >> sudoers. An UNPRVILEGED user gets the following message: >> >> $ gpg --card-status gpg: selecting openpgp failed: unknown >> command gpg: OpenPGP Karte ist nicht vorhanden: Allgemeiner >> Fehler >> >> I searched a lot, tried some udev-rules, i.e. >> http://dokuwiki.nausch.org/doku.php/centos:cryptos or >> http://lists.gnupg.org/pipermail/gnupg-users/2011-February/040781.html. >> It makes no difference. >> >> Maybe you have some hints for solving this problem. >> >> Thanx mcmurphy >> >> _______________________________________________ Gnupg-users >> mailing list Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO+RiXAAoJENYLD3BkimK7RYQH/3ym926L5ef4gJGuuTdwNvbw ir/7ZPzYvm8butn9YCs57IUF/G+k2Xp7tjyFs+xDaL3+rebAyRTqF1lwrK1fjU6j iQ6vkrQigPBvLo4A4BVvipAu4Aih8lgnPi4jN/a/HjJm0iPGcH6Dd/7X48iFXMZi bnMnV0w5bGHS1FpmErgzpPt4DQRjaJElOepk7XeV758meVnBci+dR6jFXHkStNzl FqAUrxXSOhwqG5+kZxCh5p4lMRP2dI7scWaT6eMVWhmxoPVt9/994AdP3E/mOS7a ntytPEvik33C9VyH2t12IS8kgFBmz8JZSIZ+Ul+7coa3dvwUjuoKVBa+CYxWFS4= =EQ1V -----END PGP SIGNATURE----- From vivarto at gmail.com Mon Dec 26 21:42:25 2011 From: vivarto at gmail.com (Veet Vivarto) Date: Tue, 27 Dec 2011 04:42:25 +0800 Subject: GnuPG 2.1 beta 3 released In-Reply-To: <87sjk7qwjh.fsf@vigenere.g10code.de> References: <87fwgf1a5y.fsf@vigenere.g10code.de> <87k45nrre5.fsf@vigenere.g10code.de> <87sjk7qwjh.fsf@vigenere.g10code.de> Message-ID: Perhaps you find this relevant. I don't even begin to see why you are interested in this. But who knows. On Mon, Dec 26, 2011 at 9:42 PM, Werner Koch wrote: > On Sun, 25 Dec 2011 19:00, nicholas.cole at gmail.com said: > > > It would be very good if there were still a way to completely 'sandox' > (for > > want of a better term) an instance of gpg, so that it uses its own key > > rings and trust databases. I certainly find that for testing purposes it > > is very useful indeed. On previous versions --homedir does this nicely. > > A easy way to do this is: > > GNUPGHOME=/foo/bar gpg-agent --daemon sh > > and then do whatever you want in this shell. If you are done run give > an exit and with a few seconds that gpg-agent will be terminated. That > is how I do almost all tests. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivarto at gmail.com Mon Dec 26 22:02:20 2011 From: vivarto at gmail.com (Veet Vivarto) Date: Tue, 27 Dec 2011 05:02:20 +0800 Subject: GnuPG 2.1 beta 3 released In-Reply-To: References: <87fwgf1a5y.fsf@vigenere.g10code.de> <87k45nrre5.fsf@vigenere.g10code.de> <87sjk7qwjh.fsf@vigenere.g10code.de> Message-ID: sorry my previous message was sent in error. Please disregard. Thank you. On Tue, Dec 27, 2011 at 4:42 AM, Veet Vivarto wrote: > Perhaps you find this relevant. I don't even begin to see why you are > interested in this. But who knows. > > On Mon, Dec 26, 2011 at 9:42 PM, Werner Koch wrote: > >> On Sun, 25 Dec 2011 19:00, nicholas.cole at gmail.com said: >> >> > It would be very good if there were still a way to completely 'sandox' >> (for >> > want of a better term) an instance of gpg, so that it uses its own key >> > rings and trust databases. I certainly find that for testing purposes >> it >> > is very useful indeed. On previous versions --homedir does this nicely. >> >> A easy way to do this is: >> >> GNUPGHOME=/foo/bar gpg-agent --daemon sh >> >> and then do whatever you want in this shell. If you are done run give >> an exit and with a few seconds that gpg-agent will be terminated. That >> is how I do almost all tests. >> >> >> Salam-Shalom, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vedaal at nym.hush.com Tue Dec 27 23:14:09 2011 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 27 Dec 2011 17:14:09 -0500 Subject: maximum passphrase for symmetric encryption ? Message-ID: <20111227221409.DA1BB14DBD8@smtp.hushmail.com> Is there a maximum size for a passphrase for symmetric encryption in gnupg, or does a passphrase exceeding a certain size not add any further security to the process? Example, The session key for AES 256 is 64 hexadecimal characters. The approximate equivalent in brute force work is 20 diceware words. [ 7776^19 < 2^256 < 7776^20 ]. A string of 15 diceware words is often more than 64 characters. Does increasing the passphrase string to more than 64 characters add any security? Truecrypt full disk encryption insists on a maximum of 64 characters for the passphrase. (This is even more relevant in my case, where I routinely use 3DES ;-) ) (am not familiar enough with the primitives of symmetric encryption in how a string to key symmetric encryption works.) TIA, vedaal From jerome at jeromebaum.com Tue Dec 27 23:23:50 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Tue, 27 Dec 2011 23:23:50 +0100 Subject: maximum passphrase for symmetric encryption ? In-Reply-To: <20111227221409.DA1BB14DBD8@smtp.hushmail.com> References: <20111227221409.DA1BB14DBD8@smtp.hushmail.com> Message-ID: <4EFA4576.7010502@jeromebaum.com> On 2011-12-27 23:14, vedaal at nym.hush.com wrote: > Is there a maximum size for a passphrase for symmetric encryption > in gnupg, or does a passphrase exceeding a certain size not add any > further security to the process? > > Example, > The session key for AES 256 is 64 hexadecimal characters. > > The approximate equivalent in brute force work is 20 diceware > words. > [ 7776^19 < 2^256 < 7776^20 ]. > > A string of 15 diceware words is often more than 64 characters. I can't tell for gpg specifically but it's not so much about "characters". It's about entropy. Natural language is redundant, and diceware uses words from natural language. Let's say we all adopted the convention to write every character twice, to recover from errors in transmission. Is ttrraannssmmiissssiioonn any more secure than transmission, given that an attacker knows you're doubling every letter? No, because it doesn't have more entropy. So don't measure characters, your upper bound is entropy, so 20 diceware words apparently contain 256 bits of entropy (based on your numbers). That means any more than 20 words isn't going to add for the case of AES-256. Like I said, this is not gpg-specific. For all I know, gpg might cut off after the 64th character and drop entropy from your passphrase. But that sounds unlikely. Wikipedia is great for further reading. -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From aaron.toponce at gmail.com Wed Dec 28 00:27:00 2011 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Tue, 27 Dec 2011 16:27:00 -0700 Subject: maximum passphrase for symmetric encryption ? In-Reply-To: <4EFA4576.7010502@jeromebaum.com> References: <20111227221409.DA1BB14DBD8@smtp.hushmail.com> <4EFA4576.7010502@jeromebaum.com> Message-ID: <20111227232700.GP22507@poseidon.cocyt.us> There may be some errors in my reply, so if so, please notify me. On Tue, Dec 27, 2011 at 11:23:50PM +0100, Jerome Baum wrote: > On 2011-12-27 23:14, vedaal at nym.hush.com wrote: > > The approximate equivalent in brute force work is 20 diceware > > words. > > [ 7776^19 < 2^256 < 7776^20 ]. > > > > A string of 15 diceware words is often more than 64 characters. > > I can't tell for gpg specifically but it's not so much about > "characters". It's about entropy. Natural language is redundant, and > diceware uses words from natural language. Yes, but each word in the diceware list contains about 12.9 bits of entropy, due to the random nature of rolling a fair D6. So, for a passphrase that is 20 diceware words, it contains roughly 258-bits of entropy, as he identified. It's easy to calculate entropy in a truly random environment: H = L*log2(N) where 'H' is the entropy value in binary bits, 'L' is the length of the message, 'log2()' is the log base-2 function, and 'N' is the possible number of characters the system can have. The only time when this equation becomes more complicated, is when predictable patterns, such as can be found in human language, are found. > So don't measure characters, your upper bound is entropy, so 20 diceware > words apparently contain 256 bits of entropy (based on your numbers). > That means any more than 20 words isn't going to add for the case of > AES-256. And this is the point, right here. A passphrase that has more binary bits of entropy, than the containing system, won't provide you with any additional benefit, or security. So, in the case with a 20 word, diceware passphrase, provided that the RNG building the AES 256-bit environment is truly random data, any additional entropy in the passphrase, won't buy you any additional security in the encrypted data. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: Digital signature URL: From jerome at jeromebaum.com Wed Dec 28 00:32:44 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Wed, 28 Dec 2011 00:32:44 +0100 Subject: maximum passphrase for symmetric encryption ? In-Reply-To: <20111227232700.GP22507@poseidon.cocyt.us> References: <20111227221409.DA1BB14DBD8@smtp.hushmail.com> <4EFA4576.7010502@jeromebaum.com> <20111227232700.GP22507@poseidon.cocyt.us> Message-ID: <4EFA559C.2000704@jeromebaum.com> On 2011-12-28 00:27, Aaron Toponce wrote: > On Tue, Dec 27, 2011 at 11:23:50PM +0100, Jerome Baum wrote: >> I can't tell for gpg specifically but it's not so much about >> "characters". It's about entropy. Natural language is redundant, and >> diceware uses words from natural language. > > Yes, but each word in the diceware list contains about 12.9 bits of > entropy, due to the random nature of rolling a fair D6. How is this in conflict with what I said? -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From cryptostick at privacyfoundation.de Wed Dec 28 01:05:07 2011 From: cryptostick at privacyfoundation.de (Crypto Stick) Date: Wed, 28 Dec 2011 08:05:07 +0800 Subject: German Privacy Foundation Crypto-stick In-Reply-To: <4EF91898.1010603@riseup.net> References: <4EF8A4F8.80200@riseup.net> <4EF90850.2010707@privacyfoundation.de> <4EF91898.1010603@riseup.net> Message-ID: <4EFA5D33.2000403@privacyfoundation.de> After installing the package the UDEV rule should be located at /lib/udev/rules.d/40-cryptostick.rules Please check. Am 27.12.2011 09:00, schrieb mcmurphy: > Hi, > > thank you for the answer. There is no difference. I'm not sure, > whether the installation works. There is no new rule in > /etc/udev/rules.d. Is it gnupg-ccid.rules in /etc/udev/? However: > Nothing changed for not-sudoer-user. Maybe there is something wrong > with udev or gpg? > > mcmurphy > > On 27.12.2011 00:50, Crypto Stick wrote: >> Hi! Please install this package (UDEV rule) and it should work. >> https://www.assembla.com/spaces/cryptostick/documents/ds_EMCisGr4k7QeJe5cbCb/download/ds_EMCisGr4k7QeJe5cbCb > > > >> Am 27.12.2011 00:46, schrieb mcmurphy: >>> Hi, >>> >>> i'm trying to work with the Crypto-stick of the German Privacy >>> Foundation >>> (https://www.privacyfoundation.de/crypto_stick/crypto_stick_english/) >>> >>> > under ubuntu 11 64-bit. Unfortunately it works only for root or >>> sudoers. An UNPRVILEGED user gets the following message: >>> >>> $ gpg --card-status gpg: selecting openpgp failed: unknown >>> command gpg: OpenPGP Karte ist nicht vorhanden: Allgemeiner >>> Fehler >>> >>> I searched a lot, tried some udev-rules, i.e. >>> http://dokuwiki.nausch.org/doku.php/centos:cryptos or >>> http://lists.gnupg.org/pipermail/gnupg-users/2011-February/040781.html. >>> It makes no difference. >>> >>> Maybe you have some hints for solving this problem. >>> >>> Thanx mcmurphy >>> >>> _______________________________________________ Gnupg-users >>> mailing list Gnupg-users at gnupg.org >>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From vedaal at nym.hush.com Wed Dec 28 01:54:05 2011 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Tue, 27 Dec 2011 19:54:05 -0500 Subject: maximum passphrase for symmetric encryption ? Message-ID: <20111228005406.28DA414DBD8@smtp.hushmail.com> Jerome Baum jerome at jeromebaum.com wrote on Tue Dec 27 23:23:50 CET 2011 : >gpg might cut off after the 64th character and drop entropy from your >passphrase. But that sounds unlikely. That's exactly my question. Does gnupg have a maximum string length for a passphrase, and restrict itself to the entropy contained within that length? (Apparently not.) I tried symmetrically encrypting, using a string of 65 characters, and it works, and requires exactly those 65 characters to decrypt. (Substituting any other character for the 65th character does not decrypt). Curious as to why Truecrypt does not accept more than 64, for whole disk encryption. vedaal From jw72253 at verizon.net Wed Dec 28 03:08:15 2011 From: jw72253 at verizon.net (John A. Wallace) Date: Tue, 27 Dec 2011 20:08:15 -0600 Subject: --trusted-key Message-ID: <000501ccc505$8f7e7700$ae7b6500$@net> --trusted-key long key ID Assume that the specified key (which must be given as a full 8 byte key ID) is as trustworthy as one of your own secret keys. This option is useful if you don't want to keep your secret keys (or one of them) online but still want to be able to check the validity of a given recipient's or signator's key. I read this definition online, but I can't seem to get a grasp on what it is used for. As it sounds as though it may have use for something I want to do, I was hoping someone could elaborate a bit on this. It may be clear as glass to most of you, but I am not seeing it (sorry). Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at hauke-laging.de Wed Dec 28 03:23:10 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Wed, 28 Dec 2011 03:23:10 +0100 Subject: --trusted-key In-Reply-To: <000501ccc505$8f7e7700$ae7b6500$@net> References: <000501ccc505$8f7e7700$ae7b6500$@net> Message-ID: <201112280323.15730.mailinglisten@hauke-laging.de> Am Mittwoch, 28. Dezember 2011, 03:08:15 schrieb John A. Wallace: > Assume that the specified key (which must be given as a full 8 byte key ID) > is as trustworthy as one of your own secret keys. This option is useful if > you don't want to keep your secret keys (or one of them) online but still > want to be able to check the validity of a given recipient's or signator's > key. > I read this definition online, but I can't seem to get a grasp on what it > is used for. See --export-secret-subkeys. (gpg main key offline) as input for your favorite search engine answers possibly remaing questions. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From jerome at jeromebaum.com Wed Dec 28 03:25:33 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Wed, 28 Dec 2011 03:25:33 +0100 Subject: --trusted-key In-Reply-To: <000501ccc505$8f7e7700$ae7b6500$@net> References: <000501ccc505$8f7e7700$ae7b6500$@net> Message-ID: <4EFA7E1D.8080003@jeromebaum.com> On 2011-12-28 03:08, John A. Wallace wrote: > --trusted-key long key ID > > Assume that the specified key (which must be given as a full 8 byte key ID) > is as trustworthy as one of your own secret keys. This option is useful if > you don't want to keep your secret keys (or one of them) online but still > want to be able to check the validity of a given recipient's or signator's > key. > I read this definition online, but I can't seem to get a grasp on what it is > used for. As it sounds as though it may have use for something I want to > do, I was hoping someone could elaborate a bit on this. It may be clear as > glass to most of you, but I am not seeing it (sorry). Thanks. You can't set ultimate trust on a public key unless you have the corresponding private key. So this is a way of telling gnupg not to require that, e.g. if you have the key on another computer and gnupg can't know that. For instance, I keep two key: 0x215236DA and 0xC58C753A. But only 0xC58C753A is on my machine, 0x215236DA is stored somewhere safe, so I don't want it on here. But I still want to ultimately trust 0x215236DA because, well, it's my key. So my gpg.conf says "trusted-key 215236DA". -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From sandals at crustytoothpaste.net Wed Dec 28 02:36:56 2011 From: sandals at crustytoothpaste.net (brian m. carlson) Date: Wed, 28 Dec 2011 01:36:56 +0000 Subject: maximum passphrase for symmetric encryption ? In-Reply-To: <20111228005406.28DA414DBD8@smtp.hushmail.com> References: <20111228005406.28DA414DBD8@smtp.hushmail.com> Message-ID: <20111228013656.GB3284@crustytoothpaste.ath.cx> On Tue, Dec 27, 2011 at 07:54:05PM -0500, vedaal at nym.hush.com wrote: > That's exactly my question. > Does gnupg have a maximum string length for a passphrase, and > restrict itself to the entropy contained within that length? Not to my knowledge. OpenPGP does not specify a maximum string length for a passphrase, and it's limited only to the amount of memory you have, or in some cases 2^61 bytes (which is essentially unlimited). > I tried symmetrically encrypting, using a string of 65 characters, > and it works, and requires exactly those 65 characters to decrypt. > (Substituting any other character for the 65th character does not > decrypt). Yes. When you use a passphrase to encrypt, the entire passphrase is hashed, so if the input is at all different, the passphrase will be rejected. Most modern OpenPGP implementations repeatedly hash the passphrase and use salt (8 bytes of random data stored with the passphrase to make the hash unique even if you reuse the passphrase). This makes brute-force attempts slower since more computation is required. -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: From johanw at vulcan.xs4all.nl Wed Dec 28 08:25:04 2011 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Wed, 28 Dec 2011 08:25:04 +0100 Subject: --trusted-key In-Reply-To: <000501ccc505$8f7e7700$ae7b6500$@net> References: <000501ccc505$8f7e7700$ae7b6500$@net> Message-ID: <4EFAC450.9070709@vulcan.xs4all.nl> On 28-12-2011 3:08, John A. Wallace wrote: > --trusted-key long key ID > > Assume that the specified key (which must be given as a full 8 byte key > ID) Perhaps it would be better to expand this option so it will also accept the full key signature (and also check against the full sig) now that intentional collisions of the 8-byte keyID can be generated. -- Met vriendelijke groet / With kind regards, Johan Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From jerry at seibercom.net Wed Dec 28 12:13:41 2011 From: jerry at seibercom.net (Jerry) Date: Wed, 28 Dec 2011 06:13:41 -0500 Subject: Short ID Collision Message-ID: <20111228061341.58bbc849@scorpio> Did anyone read about this reported problem with GnuPG and short keys? I found this on SlashDot this morning: http://yro.slashdot.org/story/11/12/27/0044242/gnupg-short-id-collision-has-occurred?utm_source=headlines&utm_medium=email -- Jerry ? Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ From rjh at sixdemonbag.org Wed Dec 28 13:45:14 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 28 Dec 2011 07:45:14 -0500 Subject: Short ID Collision In-Reply-To: <20111228061341.58bbc849@scorpio> References: <20111228061341.58bbc849@scorpio> Message-ID: <4EFB0F5A.9010309@sixdemonbag.org> On 12/28/11 6:13 AM, Jerry wrote: > Did anyone read about this reported problem with GnuPG and short > keys? There is no problem. We've known for quite a long time that short key ID collisions are possible: that's why you can't rely on a short key ID as a fingerprint. There's room for some healthy debate on whether GnuPG should be sending full fingerprints to query for keys, but honestly, calling this a "problem" is really overstating things. There's some behavior that some users find less than optimal, but that's not the same as saying there's a bug in GnuPG that can cause crashes, reveal your data, or anything else like that. From aaron.toponce at gmail.com Wed Dec 28 15:35:16 2011 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Wed, 28 Dec 2011 07:35:16 -0700 Subject: maximum passphrase for symmetric encryption ? In-Reply-To: <4EFA559C.2000704@jeromebaum.com> References: <20111227221409.DA1BB14DBD8@smtp.hushmail.com> <4EFA4576.7010502@jeromebaum.com> <20111227232700.GP22507@poseidon.cocyt.us> <4EFA559C.2000704@jeromebaum.com> Message-ID: <20111228143516.GQ22507@poseidon.cocyt.us> On Wed, Dec 28, 2011 at 12:32:44AM +0100, Jerome Baum wrote: > On 2011-12-28 00:27, Aaron Toponce wrote: > > On Tue, Dec 27, 2011 at 11:23:50PM +0100, Jerome Baum wrote: > >> I can't tell for gpg specifically but it's not so much about > >> "characters". It's about entropy. Natural language is redundant, and > >> diceware uses words from natural language. > > > > Yes, but each word in the diceware list contains about 12.9 bits of > > entropy, due to the random nature of rolling a fair D6. > > How is this in conflict with what I said? It is not in conflict. I am only extending the discussion. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: Digital signature URL: From dshaw at jabberwocky.com Wed Dec 28 17:57:40 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 28 Dec 2011 11:57:40 -0500 Subject: Short ID Collision In-Reply-To: <20111228061341.58bbc849@scorpio> References: <20111228061341.58bbc849@scorpio> Message-ID: <8706BEE8-CB0F-480E-AA41-4AD9AE60A7BC@jabberwocky.com> On Dec 28, 2011, at 6:13 AM, Jerry wrote: > Did anyone read about this reported problem with GnuPG and short keys? > I found this on SlashDot this morning: > > http://yro.slashdot.org/story/11/12/27/0044242/gnupg-short-id-collision-has-occurred?utm_source=headlines&utm_medium=email The proper title of the article should have been "Easy method for making a OpenPGP short collision re-discovered. Again." To his credit, the original blog poster more or less says that. Unfortunately, as various other sites picked it up, the issue and focus mutated a bit. Short key ID collisions are nothing new. They're obvious, and handling them is built into the system. It's also not hard to make one - just generate keys over and over until you get a collision. On a fast system, that won't take very long at all. Now to the "bug", such as it is. Using the key from the blog post, if I do: gpg --recv-keys 70096AD1 I'll get two keys. The reason for that is that I am requesting something ambiguous. There are two keys with that short key ID, so the server (correctly) returns both. It's up to the caller (me) to decide which is the "right" one, using the web of trust, or whatever means I want to verify keys. The keyserver is just a database, and does not say that a given key is right or wrong. That's not the problem. However, if I do: gpg --recv-keys EC4B033C70096AD1 I'll also get two keys. Even though I gave enough information to specify one of the keys in particular, I still got both. The reason why is due to the history of PGP keyservers. When the GPG side of the keyserver code was written, the server side (a program called pksd) was not capable of understanding anything *other* than the short key ID. Because of this, GPG intentionally truncates all key IDs to their short representation when requesting keys from that type of keyserver. Other keyservers (LDAP) did not have that limitation, and so the longest possible representation is used there. Since that code was written, time has moved on, and the old pksd server is dead and replaced by the sks server, which is capable of understanding more than the short key ID. So given that there aren't any pksd servers to support any longer, it has been suggested (see https://bugs.g10code.com/gnupg/issue1340) that we should do like we do for LDAP, which never had this limitation in the first place, and send the longest key ID we can. It's a reasonable thing to do - if the user gives us 64 bits, use all 64 bits. So is this a security problem? No, for many reasons, most of which were mentioned in the responses to the blog post. Allow me to add one more reason: keyservers aren't capable of saying if a key is the right one or not. They're just a searchable database that anyone can submit to. A person who trusts a particular key is correct just because they found it on a keyserver is fooling themselves. That's what we have a web of trust and/or fingerprint checking for. David From jerry at seibercom.net Wed Dec 28 21:55:25 2011 From: jerry at seibercom.net (Jerry) Date: Wed, 28 Dec 2011 15:55:25 -0500 Subject: Short ID Collision In-Reply-To: <8706BEE8-CB0F-480E-AA41-4AD9AE60A7BC@jabberwocky.com> References: <20111228061341.58bbc849@scorpio> <8706BEE8-CB0F-480E-AA41-4AD9AE60A7BC@jabberwocky.com> Message-ID: <20111228155525.2b8c671b@scorpio> On Wed, 28 Dec 2011 11:57:40 -0500 David Shaw articulated: > On Dec 28, 2011, at 6:13 AM, Jerry wrote: > > > Did anyone read about this reported problem with GnuPG and short > > keys? I found this on SlashDot this morning: > > > > http://yro.slashdot.org/story/11/12/27/0044242/gnupg-short-id-collision-has-occurred?utm_source=headlines&utm_medium=email > > The proper title of the article should have been "Easy method for > making a OpenPGP short collision re-discovered. Again." To his > credit, the original blog poster more or less says that. > Unfortunately, as various other sites picked it up, the issue and > focus mutated a bit. > > Short key ID collisions are nothing new. They're obvious, and > handling them is built into the system. It's also not hard to make > one - just generate keys over and over until you get a collision. On > a fast system, that won't take very long at all. > > Now to the "bug", such as it is. Using the key from the blog post, > if I do: > > gpg --recv-keys 70096AD1 > > I'll get two keys. The reason for that is that I am requesting > something ambiguous. There are two keys with that short key ID, so > the server (correctly) returns both. It's up to the caller (me) to > decide which is the "right" one, using the web of trust, or whatever > means I want to verify keys. The keyserver is just a database, and > does not say that a given key is right or wrong. That's not the > problem. > > However, if I do: > > gpg --recv-keys EC4B033C70096AD1 > > I'll also get two keys. Even though I gave enough information to > specify one of the keys in particular, I still got both. The reason > why is due to the history of PGP keyservers. When the GPG side of > the keyserver code was written, the server side (a program called > pksd) was not capable of understanding anything *other* than the > short key ID. Because of this, GPG intentionally truncates all key > IDs to their short representation when requesting keys from that type > of keyserver. Other keyservers (LDAP) did not have that limitation, > and so the longest possible representation is used there. > > Since that code was written, time has moved on, and the old pksd > server is dead and replaced by the sks server, which is capable of > understanding more than the short key ID. So given that there aren't > any pksd servers to support any longer, it has been suggested (see > https://bugs.g10code.com/gnupg/issue1340) that we should do like we > do for LDAP, which never had this limitation in the first place, and > send the longest key ID we can. It's a reasonable thing to do - if > the user gives us 64 bits, use all 64 bits. > > So is this a security problem? No, for many reasons, most of which > were mentioned in the responses to the blog post. Allow me to add > one more reason: keyservers aren't capable of saying if a key is the > right one or not. They're just a searchable database that anyone can > submit to. A person who trusts a particular key is correct just > because they found it on a keyserver is fooling themselves. That's > what we have a web of trust and/or fingerprint checking for. It would seem, and this is strictly my own opinion, that if the "old pksd" servers are dead then there is no logical reason to continue to support them. Just my 2?. -- Jerry ? Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ From jw72253 at verizon.net Thu Dec 29 03:45:08 2011 From: jw72253 at verizon.net (John A. Wallace) Date: Wed, 28 Dec 2011 20:45:08 -0600 Subject: --trusted-key In-Reply-To: References: Message-ID: <001101ccc5d3$e0cf11e0$a26d35a0$@net> > ------------------------------ > > Message: 5 > Date: Wed, 28 Dec 2011 03:25:33 +0100 > From: Jerome Baum > To: gnupg-users at gnupg.org > Subject: Re: --trusted-key > Message-ID: <4EFA7E1D.8080003 at jeromebaum.com> > Content-Type: text/plain; charset="utf-8" > > On 2011-12-28 03:08, John A. Wallace wrote: > > --trusted-key long key ID > > > > Assume that the specified key (which must be given as a full 8 byte > key ID) > > is as trustworthy as one of your own secret keys. This option is > useful if > > you don't want to keep your secret keys (or one of them) online but > still > > want to be able to check the validity of a given recipient's or > signator's > > key. > > > > I read this definition online, but I can't seem to get a grasp on > what it is > > used for. As it sounds as though it may have use for something I > want to > > do, I was hoping someone could elaborate a bit on this. It may be > clear as > > glass to most of you, but I am not seeing it (sorry). Thanks. > > You can't set ultimate trust on a public key unless you have the > corresponding private key. So this is a way of telling gnupg not to > require that, e.g. if you have the key on another computer and gnupg > can't know that. > > For instance, I keep two key: 0x215236DA and 0xC58C753A. But only > 0xC58C753A is on my machine, 0x215236DA is stored somewhere safe, so I > don't want it on here. But I still want to ultimately trust 0x215236DA > because, well, it's my key. So my gpg.conf says "trusted-key 215236DA". > I have a couple of questions about this idea. First, why would you not have assigned ultimate trust to the public key ID 0x215236DA when you created it and had your secret key available to do so? I mean, why the delay; what value to you is your key without having it so trusted? (What point about trust am I not factoring in here?) Secondly, you said, " So my gpg.conf says 'trusted-key 215236DA'." Where you shortening it for sake of brevity, as that is not an 8 byte long key ID? Finally, (and this part may very well relate to my lack of fully understanding the trust procedures) would I be specifying and ID in "--trusted-key long key ID" for a key that is one of mine? If so, why would I need one of "my" keys, as the definition states, in order "...to check the validity of a given recipient's or signator's key"? I know I must be missing some critical point ----> woosh! Thanks. john From jerome at jeromebaum.com Thu Dec 29 04:04:15 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 29 Dec 2011 04:04:15 +0100 Subject: --trusted-key In-Reply-To: <001101ccc5d3$e0cf11e0$a26d35a0$@net> References: <001101ccc5d3$e0cf11e0$a26d35a0$@net> Message-ID: <4EFBD8AF.9080108@jeromebaum.com> On 2011-12-29 03:45, John A. Wallace wrote: > I have a couple of questions about this idea. First, why would you not have > assigned ultimate trust to the public key ID 0x215236DA when you created it > and had your secret key available to do so? I mean, why the delay; what > value to you is your key without having it so trusted? (What point about > trust am I not factoring in here?) I created the key on another computer, so the secret key was never on this machine in the first place. > Secondly, you said, " So my gpg.conf says > 'trusted-key 215236DA'." Where you shortening it for sake of brevity, as > that is not an 8 byte long key ID? Yeah, another 8 characters would have made the line wrap around. :) > Finally, (and this part may very well > relate to my lack of fully understanding the trust procedures) would I be > specifying and ID in "--trusted-key long key ID" for a key that is one of > mine? If so, why would I need one of "my" keys, as the definition states, in > order "...to check the validity of a given recipient's or signator's key"? > I know I must be missing some critical point ----> woosh! Thanks. Yes, just like in my example, you would usually specify the ID of one of your own keys. So say I've certified your key with my 215236DA. That key is not on this machine, but I'd like my gnupg to consider your email signatures valid. What I'm telling gnupg is that 215236DA is my own key, so any other key that is certified by 215236DA must be valid (presumably because I personally checked this before certifying). trusted-key is really there for the above scenario -- it is my key, but it isn't on this computer, so gnupg can't know unless I tell it. There's basically not much more to it.* * Now, that's a meaningful sentence right there. "Ignoring anything else there is to it, there's not much more to it." -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- nameserver 217.79.186.148 nameserver 178.63.26.172 http://opennicproject.org/ -- No situation is so dire that panic cannot make it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 878 bytes Desc: OpenPGP digital signature URL: From John at enigmail.net Thu Dec 29 09:18:04 2011 From: John at enigmail.net (John Clizbe) Date: Thu, 29 Dec 2011 02:18:04 -0600 Subject: Short ID Collision In-Reply-To: <20111228155525.2b8c671b@scorpio> References: <20111228061341.58bbc849@scorpio> <8706BEE8-CB0F-480E-AA41-4AD9AE60A7BC@jabberwocky.com> <20111228155525.2b8c671b@scorpio> Message-ID: <4EFC223C.70104@enigmail.net> Jerry wrote: > > It would seem, and this is strictly my own opinion, that if the "old > pksd" servers are dead then there is no logical reason to continue to > support them. Just my 2?. If only all software support decisions were that cut and dried. Oh well... David Shaw committed patches to the 1.4, 2.0, & 2.1 branches of GnuPG yesterday afternoon (28-Dec). The change will be in the next release of each branch. -- John P. Clizbe Inet: John ( a ) Enigmail DAWT org FSF Assoc #995 / FSFE Fellow #1797 hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at 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" From stayvoid at gmail.com Thu Dec 29 12:57:01 2011 From: stayvoid at gmail.com (Stayvoid) Date: Thu, 29 Dec 2011 14:57:01 +0300 Subject: How to sign my own public key? Message-ID: Hi there! How to sign my own public key? I've read that this is important. Here is the link: http://www.heureka.clara.net/sunrise/pgpsign.htm Cheers. From aaron.toponce at gmail.com Thu Dec 29 14:19:21 2011 From: aaron.toponce at gmail.com (Aaron Toponce) Date: Thu, 29 Dec 2011 06:19:21 -0700 Subject: How to sign my own public key? In-Reply-To: References: Message-ID: <20111229131921.GZ22507@poseidon.cocyt.us> On Thu, Dec 29, 2011 at 02:57:01PM +0300, Stayvoid wrote: > How to sign my own public key? > I've read that this is important. > Here is the link: http://www.heureka.clara.net/sunrise/pgpsign.htm Whenever you make changes to your key, it's automatically signed by you. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 519 bytes Desc: Digital signature URL: From mcmurphy at riseup.net Thu Dec 29 14:51:22 2011 From: mcmurphy at riseup.net (mcmurphy) Date: Thu, 29 Dec 2011 14:51:22 +0100 Subject: German Privacy Foundation Crypto-stick In-Reply-To: <4EFA5D33.2000403@privacyfoundation.de> References: <4EF8A4F8.80200@riseup.net> <4EF90850.2010707@privacyfoundation.de> <4EF91898.1010603@riseup.net> <4EFA5D33.2000403@privacyfoundation.de> Message-ID: <4EFC705A.7050909@riseup.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, thank you very much. I found the file, but at the same time I found the following: $ gpg --card-status gpg: selecting openpgp failed: unknown command gpg: OpenPGP Karte ist nicht vorhanden: Allgemeiner Fehler $ mv /tmp/keyring-ooi9FI/gpg /tmp/keyring-ooi9FI/gpgOLD @latitude:~$ gpg --card-status can't connect to `/tmp/keyring-ooi9FI/gpg': Datei oder Verzeichnis nicht gefunden Application ID ...: *** Version ..........: 2.0 Manufacturer .....: ZeitControl Serial number ....: *** Name of cardholder: [nicht gesetzt] Language prefs ...: de Sex ..............: unbestimmt URL of public key : [nicht gesetzt] Login data .......: [nicht gesetzt] Private DO 1 .....: [nicht gesetzt] Private DO 2 .....: [nicht gesetzt] Signature PIN ....: zwingend Key attributes ...: 2048R 2048R 2048R Max. PIN lengths .: 32 32 32 PIN retry counter : 3 0 3 Signature counter : 0 Signature key ....: [none] Encryption key....: [none] Authentication key: [none] General key info..: [none] So somehow /tmp/keyring-ooi9FI/gpg blocks the connection to the crypto-stick. Why? Is this a new security feature? :-) How can I fix it? mcmurphy On 28.12.2011 01:05, Crypto Stick wrote: > After installing the package the UDEV rule should be located at > /lib/udev/rules.d/40-cryptostick.rules > > Please check. > > Am 27.12.2011 09:00, schrieb mcmurphy: >> Hi, >> >> thank you for the answer. There is no difference. I'm not sure, >> whether the installation works. There is no new rule in >> /etc/udev/rules.d. Is it gnupg-ccid.rules in /etc/udev/? However: >> Nothing changed for not-sudoer-user. Maybe there is something >> wrong with udev or gpg? >> >> mcmurphy >> >> On 27.12.2011 00:50, Crypto Stick wrote: >>> Hi! Please install this package (UDEV rule) and it should >>> work. >>> >>> https://www.assembla.com/spaces/cryptostick/documents/ds_EMCisGr4k7QeJe5cbCb/download/ds_EMCisGr4k7QeJe5cbCb >> >> >> >>> >>> >>> Am 27.12.2011 00:46, schrieb mcmurphy: >>>> Hi, >>>> >>>> i'm trying to work with the Crypto-stick of the German >>>> Privacy Foundation >>>> (https://www.privacyfoundation.de/crypto_stick/crypto_stick_english/) >>>> >>>> >> >>>> >>>> under ubuntu 11 64-bit. Unfortunately it works only for root or >>>> sudoers. An UNPRVILEGED user gets the following message: >>>> >>>> $ gpg --card-status gpg: selecting openpgp failed: unknown >>>> command gpg: OpenPGP Karte ist nicht vorhanden: Allgemeiner >>>> Fehler >>>> >>>> I searched a lot, tried some udev-rules, i.e. >>>> http://dokuwiki.nausch.org/doku.php/centos:cryptos or >>>> http://lists.gnupg.org/pipermail/gnupg-users/2011-February/040781.html. >>>> >>>> >>>> It makes no difference. >>>> >>>> Maybe you have some hints for solving this problem. >>>> >>>> Thanx mcmurphy >>>> >>>> _______________________________________________ Gnupg-users >>>> mailing list Gnupg-users at gnupg.org >>>> http://lists.gnupg.org/mailman/listinfo/gnupg-users >>>> >> >> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO/HBaAAoJENYLD3BkimK7G9cH/iUJ+/xqB29ri3pJZx8qwoit r7y8vUdJ8JXIW+pYwr7xcbl8N9GRd3jpLkc5BUxEjFSNRZ3HmiCKIkbwz7ZwzG7G l0+qh7TbF/h6YucxiiuGm4Rs4yZjOJqSFsR5nmKdgAUlZENE5o6tVZO4ipGDUt3t lVkOuleUhL/9UXo2S0OYDTsMgKP3Ludm4kj2R0ZI8IrBMK9i3CBSp4naKmTtjXWF wt6YLhl8RrducF6MMr6HiF6fLFe/NSK2Pz7SdOAteikNJuDLlkF7pd8cgf7OyXSv LKO/KRcVPm+NWdWx4t/SyiCDjQI+p/2+P4sFCqylFyyuVx2GpCgeUJExARYgnCM= =odqw -----END PGP SIGNATURE----- From stayvoid at gmail.com Thu Dec 29 16:08:08 2011 From: stayvoid at gmail.com (Stayvoid) Date: Thu, 29 Dec 2011 18:08:08 +0300 Subject: How to sign my own public key? In-Reply-To: <20111229131921.GZ22507@poseidon.cocyt.us> References: <20111229131921.GZ22507@poseidon.cocyt.us> Message-ID: A key is already signed after creation, right? From mailinglisten at hauke-laging.de Thu Dec 29 16:16:36 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 29 Dec 2011 16:16:36 +0100 Subject: How to sign my own public key? In-Reply-To: References: <20111229131921.GZ22507@poseidon.cocyt.us> Message-ID: <201112291616.42412.mailinglisten@hauke-laging.de> Am Donnerstag, 29. Dezember 2011, 16:08:08 schrieb Stayvoid: > A key is already signed after creation, right? That's right for keys which have been created by GnuPG. you can check that by gpg --list-sigs See --allow-non-selfsigned-uid (in the block "Doing things one usually doesn't want to do."...) Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Thu Dec 29 16:19:49 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 29 Dec 2011 10:19:49 -0500 Subject: How to sign my own public key? In-Reply-To: References: <20111229131921.GZ22507@poseidon.cocyt.us> Message-ID: <4EFC8515.4070104@sixdemonbag.org> On 12/29/11 10:08 AM, Stayvoid wrote: > A key is already signed after creation, right? Per spec, it must be. GnuPG enforces this. However, it's possible to find some (likely deliberately mangled) certificates that are missing self-signatures. From dshaw at jabberwocky.com Thu Dec 29 18:19:43 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 29 Dec 2011 12:19:43 -0500 Subject: How to sign my own public key? In-Reply-To: References: Message-ID: On Dec 29, 2011, at 6:57 AM, Stayvoid wrote: > Hi there! > > How to sign my own public key? > I've read that this is important. > Here is the link: http://www.heureka.clara.net/sunrise/pgpsign.htm It is important, and so GnuPG does it automatically for you. That page dates from a long while ago back when PGP version 2 didn't automatically do it. David From dshaw at jabberwocky.com Thu Dec 29 18:21:12 2011 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 29 Dec 2011 12:21:12 -0500 Subject: How to sign my own public key? In-Reply-To: <4EFC8515.4070104@sixdemonbag.org> References: <20111229131921.GZ22507@poseidon.cocyt.us> <4EFC8515.4070104@sixdemonbag.org> Message-ID: <09216124-74AF-4B95-AB89-CD91957DD099@jabberwocky.com> On Dec 29, 2011, at 10:19 AM, Robert J. Hansen wrote: > On 12/29/11 10:08 AM, Stayvoid wrote: >> A key is already signed after creation, right? > > Per spec, it must be. GnuPG enforces this. However, it's possible to > find some (likely deliberately mangled) certificates that are missing > self-signatures. The OpenPGP spec actually doesn't require it, for compatibility with the original spec which also didn't require it. The implementations do tend to require it (which makes sense, as it is important for many reasons). These days, if you see a non-self-signed key, something is wrong. David From jw72253 at verizon.net Thu Dec 29 19:01:15 2011 From: jw72253 at verizon.net (John A. Wallace) Date: Thu, 29 Dec 2011 12:01:15 -0600 Subject: Gnupg-users Digest, Vol 99, Issue 15 In-Reply-To: References: Message-ID: <000b01ccc653$dbd0a110$9371e330$@net> > Message: 6 > Date: Thu, 29 Dec 2011 04:04:15 +0100 > From: Jerome Baum > To: gnupg-users at gnupg.org > Subject: Re: --trusted-key > Message-ID: <4EFBD8AF.9080108 at jeromebaum.com> > Content-Type: text/plain; charset="utf-8" > > > > Finally, (and this part may very well > > relate to my lack of fully understanding the trust procedures) would > I be > > specifying and ID in "--trusted-key long key ID" for a key that is > one of > > mine? If so, why would I need one of "my" keys, as the definition > states, in > > order "...to check the validity of a given recipient's or signator's > key"? > > I know I must be missing some critical point ----> woosh! Thanks. > > Yes, just like in my example, you would usually specify the ID of one > of > your own keys. > > So say I've certified your key with my 215236DA. That key is not on > this > machine, but I'd like my gnupg to consider your email signatures valid. > What I'm telling gnupg is that 215236DA is my own key, so any other key > that is certified by 215236DA must be valid (presumably because I > personally checked this before certifying). > > trusted-key is really there for the above scenario -- it is my key, but > it isn't on this computer, so gnupg can't know unless I tell it. > There's > basically not much more to it.* That is now clear for me. Thanks. I believe the part that threw me off was that I apparently misunderstood where the trust components resided. I thought that, because the trust was maintained in your database independently of the keys themselves, the presence of the database on your machine would have sufficed to carry the weight of the trusted key that was not present. I suppose now that this component of trust, using the command "--trusted-key", has been manually inserted into the present database as it was not relocated in some way on to the present machine without the trusted key from which it was derived. The trust components and interplay is something I obviously need to continue studying. From stayvoid at gmail.com Thu Dec 29 19:47:36 2011 From: stayvoid at gmail.com (Stayvoid) Date: Thu, 29 Dec 2011 21:47:36 +0300 Subject: How to sign my own public key? In-Reply-To: <09216124-74AF-4B95-AB89-CD91957DD099@jabberwocky.com> References: <20111229131921.GZ22507@poseidon.cocyt.us> <4EFC8515.4070104@sixdemonbag.org> <09216124-74AF-4B95-AB89-CD91957DD099@jabberwocky.com> Message-ID: I'm using GPGTools (Mac OS version). I've tried to verify the public key with Services - Verify (GUI method). (I assume it's used for verifying a signed message.) Just to clarify, here is an output of the gpg --list-sigs: pub *** uid *** sig 3 *** > sub *** sig *** Do I have any unsigned keys? "sub" stands for the secret key, right? Are there any differences between sig 3 and sig? (Those keys have the same output.) Can I accidentally encrypt my mail using my own secret key? (I assume it will become unsafe after that, right?) For example: gpg -se What kind of key will be used in this case? I know that the program will ask for the User ID. Will it automatically use User ID's public key? Thanks for your help. From mailinglisten at hauke-laging.de Fri Dec 30 01:24:08 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Fri, 30 Dec 2011 01:24:08 +0100 Subject: How to sign my own public key? In-Reply-To: References: <09216124-74AF-4B95-AB89-CD91957DD099@jabberwocky.com> Message-ID: <201112300124.09521.mailinglisten@hauke-laging.de> Am Donnerstag, 29. Dezember 2011, 19:47:36 schrieb Stayvoid: > I'm using GPGTools (Mac OS version). > > I've tried to verify the public key with Services - Verify (GUI method). > (I assume it's used for verifying a signed message.) > > Just to clarify, here is an output of the gpg --list-sigs: > pub *** > uid *** > sig 3 *** > > sub *** > sig *** > > Do I have any unsigned keys? No. > "sub" stands for the secret key, right? For subkey. The signature given above refers to the public subkey. It would be useless to sign private keys. > Are there any differences between sig 3 and sig? (Those keys have the > same output.) See --ask-cert-level I think that GnuPG always uses 3 for UID self signatures and never gives such a statement for subkeys (maybe that's not even possible), wouldn't make sense anyway. > Can I accidentally encrypt my mail using my own secret key? Mail cannot be encrypted by secret keys at all. Public keys are for encryption and signature verification, private keys are for decryption and signature creation. It probably makes sense that you have a look at some beginners tutorial. > For example: gpg -se > What kind of key will be used in this case? > I know that the program will ask for the User ID. Will it > automatically use User ID's public key? It will automatically use the right one. Great, isn't it? I.e. in this case first your private key for the signature and then the recipient's public key for the encryption. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From stayvoid at gmail.com Fri Dec 30 08:39:24 2011 From: stayvoid at gmail.com (Stayvoid) Date: Fri, 30 Dec 2011 10:39:24 +0300 Subject: How to sign my own public key? In-Reply-To: <201112300124.09521.mailinglisten@hauke-laging.de> References: <09216124-74AF-4B95-AB89-CD91957DD099@jabberwocky.com> <201112300124.09521.mailinglisten@hauke-laging.de> Message-ID: Thanks again. From xecycle at gmail.com Fri Dec 30 09:23:24 2011 From: xecycle at gmail.com (XeCycle) Date: Fri, 30 Dec 2011 16:23:24 +0800 Subject: Agent failed to get password from pinentry-gtk-2 Message-ID: <87obuqa2o3.fsf@gmail.com> Hello, I added gpg-agent to my .profile recently, but I cannot use it now. By some debugging I found it failed to get the entered password from pinentry-gtk-2; with pinentry-curses it works. pinentry-qt4 is even worse, it complained about "no pinentry", though I have it installed and is sure I have the path right. What can I do in this case? I use gpg mainly from Emacs so I don't think I'll be able to use pinentry-curses all the way. Here's the versions I use: gpg-agent (GnuPG) 2.0.18 libgcrypt 1.5.0 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pinentry-gtk2 0.8.1 gpg (GnuPG) 2.0.18 libgcrypt 1.5.0 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Thanks for any help. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591