From bdc at topenergy.co.nz Fri Feb 1 00:16:04 2008 From: bdc at topenergy.co.nz (Bruce Cowin) Date: Fri, 01 Feb 2008 12:16:04 +1300 Subject: more than one recipient Message-ID: This is probably a dumb, basic question but is it possible to list more than one key name for the -recipient option when encrypting a file? Thanks. Regards, Bruce From dshaw at jabberwocky.com Fri Feb 1 01:20:17 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 31 Jan 2008 19:20:17 -0500 Subject: more than one recipient In-Reply-To: References: Message-ID: <20080201002016.GB8814@jabberwocky.com> On Fri, Feb 01, 2008 at 12:16:04PM +1300, Bruce Cowin wrote: > This is probably a dumb, basic question but is it possible to list more > than one key name for the -recipient option when encrypting a file? Yes. Most people encrypt to two (themselves and the intended recipient) as a matter of course. Just repeat -r for each one: gpg -r person-1 -r person-2 -r person-3 ... David From jmoore3rd at bellsouth.net Fri Feb 1 01:54:11 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 31 Jan 2008 19:54:11 -0500 Subject: more than one recipient In-Reply-To: References: Message-ID: <47A26DB3.6080803@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 - -------- Original Message -------- Subject: more than one recipient From: Bruce Cowin To: gnupg-users at gnupg.org Date: Thursday, January 31, 2008 6:16:04 PM > This is probably a dumb, basic question but is it possible to list more > than one key name for the -recipient option when encrypting a file? Dumb? NO...how else Ya gonna learn. Answer = YES! JOHN 8-) Timestamp: Thursday 31 Jan 2008, 19:54 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9-svn4675: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/9ubue iQEcBAEBCgAGBQJHom2yAAoJEBCGy9eAtCsPKLMIAJeMxtKqr9KeLKCzBmeCX0W1 8Mv6Kz6Ha0klDgPT3x7ZAdm3i6Mb6dvAs9cthb65Io9AI64H5VOzZj/2d3ZRSJqd IDRXRtdICZeQquoM656bZ4bLkFQ6INpIrOxF1biXft15GitQPYYplq1hUSdhP0GA 9neXTFhBuALGd0ZByXoBt8STkMprvmohteq/YYFuswvg+OBL2jITFcbt142GQjkc k+8Qe7c4Vy7eVdQUvO0OssJc3CBcEAzsSikUP81x4hGGgu0KUG/Kkk66wC/7kGdA UPRPl8y7r5hzey1+6tVHISyUwoV5ByEwq4XNItUSOW1jIKtr0bom6kawxBStyxU= =cEzN -----END PGP SIGNATURE----- From sithtracy at yahoo.com Fri Feb 1 01:48:33 2008 From: sithtracy at yahoo.com (Tracy D. Bossong) Date: Thu, 31 Jan 2008 16:48:33 -0800 (PST) Subject: more than one recipient Message-ID: <620990.77309.qm@web56703.mail.re3.yahoo.com> --recipeint user1 --recipient user2 (or -r for short) ----- Original Message ---- From: Bruce Cowin To: gnupg-users at gnupg.org Sent: Thursday, January 31, 2008 5:16:04 PM Subject: more than one recipient This is probably a dumb, basic question but is it possible to list more than one key name for the -recipient option when encrypting a file? Thanks. Regards, Bruce _______________________________________________ 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 bdc at topenergy.co.nz Fri Feb 1 03:15:50 2008 From: bdc at topenergy.co.nz (Bruce Cowin) Date: Fri, 01 Feb 2008 15:15:50 +1300 Subject: more than one recipient Message-ID: Cool, thanks everyone for the responses. Regards, Bruce >>> David Shaw 1/02/2008 1:20:17 p.m. >>> On Fri, Feb 01, 2008 at 12:16:04PM +1300, Bruce Cowin wrote: > This is probably a dumb, basic question but is it possible to list more > than one key name for the -recipient option when encrypting a file? Yes. Most people encrypt to two (themselves and the intended recipient) as a matter of course. Just repeat -r for each one: gpg -r person-1 -r person-2 -r person-3 ... David _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From kevhilton at gmail.com Mon Feb 4 06:48:13 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sun, 3 Feb 2008 23:48:13 -0600 Subject: Can you clarify when data compression is used? Message-ID: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> Is the data compression algorithm applied to the text prior to being converted to ciphertext, or is the ciphertext compressed, or is it the combination of the ciphertext and encrypted session key that is compressed? I can't seem to find any documentation discussing this. -- Kevin Hilton -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Feb 4 08:07:46 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 04 Feb 2008 01:07:46 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> Message-ID: <47A6B9C2.2000905@sixdemonbag.org> Kevin Hilton wrote: > Is the data compression algorithm applied to the text prior to being > converted to ciphertext, or is the ciphertext compressed, or is it the > combination of the ciphertext and encrypted session key that is > compressed? Prior. Ciphertext from a strong algorithm cannot be compressed. From kevhilton at gmail.com Mon Feb 4 08:17:48 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 4 Feb 2008 01:17:48 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> Message-ID: <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> On Feb 4, 2008 1:17 AM, Kevin Hilton wrote: > Although not supported on all systems (and not included on ubuntu by > default if you can believe it), does bzip2 offers the highest compression? > I know that --personal-compress-preferences may be included in the > gpg.conf file to take advantage of bzip2 or zlib if desired. Does PGP > still only recognize ZIP or no compression? > -- Kevin Hilton -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Mon Feb 4 08:48:14 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 04 Feb 2008 01:48:14 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> Message-ID: <47A6C33E.9010300@sixdemonbag.org> Kevin Hilton wrote: > Although not supported on all systems (and not included on ubuntu > by default if you can believe it), does bzip2 offers the highest > compression? The question is meaningless. It's predicated on the assumption that there exists a ranking scheme by which bzip2 will always beat zip for compression, or vice-versa. The reality is that compression algorithms have certain tasks they're good at and certain tasks they're awful at. E.g., try compressing ciphertext sometime with either bzip2 or zip. You won't see any meaningful difference; both are equally awful at this. Compressing PE/COFF versus ELF binaries will give different results. Etc., etc., etc. I can give only two bits of very broad advice, and one piece of specific advice. The two generals: * In most categories people care about, bzip2 offers better compression but is much slower. * Bandwidth is cheap. It's not worth introducing interoperability problems just to get a slightly smaller file. The one specific piece of advice: * Unless you can articulate a clear need why the defaults will not work for your purpose, stick with the defaults. From kevhilton at gmail.com Mon Feb 4 14:35:11 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 4 Feb 2008 07:35:11 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <47A6C33E.9010300@sixdemonbag.org> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> Message-ID: <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> > > > The one specific piece of advice: > > * Unless you can articulate a clear need why the defaults will not > work for your purpose, stick with the defaults. I think I've seen this piece of advice before, and for the most part I agree with it. The problem I have, is that no where in the documentation are the defaults specified. You want me to trust the defaults, but my contention is, at least tell me what the defaults are -- no explanation needed. We had this discussion with the default cipher and hash choices. When you tell me that dsa2 is enabled by default (in newer GnuPG versions), however in the man pages there is still a --enable-dsa2 flag, I hope you understand my confusion. I'm still confused what default cipher is chosen automatically (for me its AES). Again the man pages should accurately represent the defaults, and changes should be made to the documentation when changes to the defaults are added or subtracted. I don't think the current GnuPG manual is complete in any way nor in any way conveys what are the default settings. Its disingenuous for the program creators to expect me to trust the defaults without at least conveying them to me. Rant over, I apologize to the community. -- Kevin Hilton From dshaw at jabberwocky.com Mon Feb 4 15:36:00 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 Feb 2008 09:36:00 -0500 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> Message-ID: <20080204143600.GA27579@jabberwocky.com> On Sun, Feb 03, 2008 at 11:48:13PM -0600, Kevin Hilton wrote: > Is the data compression algorithm applied to the text prior to being > converted to ciphertext, or is the ciphertext compressed, or is it the > combination of the ciphertext and encrypted session key that is compressed? Prior. Ciphertext doesn't compress particularly well. Plus, there is a minor (as in "don't rely on it, but it's nice to have") security improvement in encrypting already-compressed data. > I can't seem to find any documentation discussing this. RFC-4880 documents this. David From dshaw at jabberwocky.com Mon Feb 4 15:44:18 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 Feb 2008 09:44:18 -0500 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> Message-ID: <20080204144418.GB27579@jabberwocky.com> On Mon, Feb 04, 2008 at 01:17:48AM -0600, Kevin Hilton wrote: > On Feb 4, 2008 1:17 AM, Kevin Hilton wrote: > > > Although not supported on all systems (and not included on ubuntu by > > default if you can believe it), does bzip2 offers the highest compression? It depends on what you are compressing. BZip2 tends to do better than zip against straight text, for example. > > I know that --personal-compress-preferences may be included in the > > gpg.conf file to take advantage of bzip2 or zlib if desired. Does PGP > > still only recognize ZIP or no compression? Current PGP handles BZip2, ZLIB, and Zip (and of course no compression). Even if you're communicating with a person whose program doesn't support BZip2, it is safe to put BZip2 in your personal-compress-preferences. Those preferences are only used if all parties agree, so you won't accidentally create an interoperability problem. This is true of all the personal-(whatever)-preferences lists. David From dshaw at jabberwocky.com Mon Feb 4 19:18:38 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 Feb 2008 13:18:38 -0500 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> Message-ID: <20080204181838.GA30533@jabberwocky.com> On Mon, Feb 04, 2008 at 07:35:11AM -0600, Kevin Hilton wrote: > > > > > > The one specific piece of advice: > > > > * Unless you can articulate a clear need why the defaults will not > > work for your purpose, stick with the defaults. > > I think I've seen this piece of advice before, and for the most part I > agree with it. The problem I have, is that no where in the > documentation are the defaults specified. You want me to trust the > defaults, but my contention is, at least tell me what the defaults are > -- no explanation needed. We had this discussion with the default > cipher and hash choices. When you tell me that dsa2 is enabled by > default (in newer GnuPG versions), however in the man pages there is > still a --enable-dsa2 flag, I hope you understand my confusion. DSA2 is not enabled by default. It can be enabled with --openpgp or --rfc4880 (or --enable-dsa2 of course). > I'm still confused what default cipher is chosen automatically (for > me its AES). There isn't a straightforward answer. Basically, there is a list of ciphers that is put in each key by default. Currently that list is AES256, AES192, AES, CAST5, and 3DES, but it can be changed at key generation time (via the --default-preference-list option), or any time afterwards (via the --edit-key command "setpref"). At encryption time, the list of possible ciphers is retrieved from each recipient key, and a cipher is chosen that all recipients can handle. This guarantees that you never send a message that your recipient won't be able to read. It isn't always AES for you - it's just that for that particular message, AES happened to work for all the recipients. David From rjh at sixdemonbag.org Mon Feb 4 19:57:34 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 04 Feb 2008 12:57:34 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> Message-ID: <47A7601E.8000107@sixdemonbag.org> Kevin Hilton wrote: > The problem I have, is that no where in the documentation are the > defaults specified. >From the first full paragraph of the manpage: "[GnuPG] is a tool to provide digital encryption and signing services using the OpenPGP standard. [GnuPG] features complete key management and all bells and whistles you can expect from a decent OpenPGP implementation." To me, that language is pretty clear about where you should look--the OpenPGP standard, aka RFC4880, or its immediate predecessor RFC2440. That said, just because I think it's clear doesn't necessarily means it /is/ clear. If it turns out that language is confusing or unclear, it should definitely be changed to point people in the right direction. I wonder who the GnuPG documentation czar is. Hmm. I don't know if that's ever been mentioned on the list--David, Werner, who's responsible for the docs? > I'm still confused what default cipher is chosen automatically (for > me its AES). http://en.wikipedia.org/wiki/Stable_marriage_problem Everyone has a ranked list of preferences. The preferences of all recipients are considered and the stable marriage problem solved. The outcome of that computation is what algorithm GnuPG will use. 3DES is implicitly in everyone's preference list, so it can be fairly said that 3DES is the default cipher preference. Even if everything else goes to hell, 3DES will be available and will be selected. From vedaal at hush.com Mon Feb 4 20:07:45 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Mon, 04 Feb 2008 14:07:45 -0500 Subject: gnupg for file splitting and re-constituting Message-ID: <20080204190745.9BFEDD005F@mailserver10.hushmail.com> if someone has a large program, or file, (*any* file type) and wants to split it, send the fragments and reconstitute it, it is a trivial (although minorly tedious) thing to do using gnupg All that is necessary is to armor the program, and then split the resulting textfile into smaller parts of suitable message size, and send it as numbered inline e-mail texts, and then concatenate the texts of all the fragments, and then restore the program by de-armoring it. have put up an example of a 2.5 mb truecrypt container, containing two files, where the truecrypt container was armored signed and encrypted, and the armored pgp ouput split into five parts, which when concatenated, decrypts back to the original truecrypt container http://www.angelfire.com/pr/pgpf/pgpoddities.html (scroll down to section [11], otherwise you may suffer hunger, thirst or incredible boredom if you try to read from the beginning ;-)) ) anyone interested in writing a short script in bash, python, perl etc. to automate the file splitting and reconstituting, using gnupg commandline? TIA, vedaal any ads or links below this message are added by hushmail without -- Click to get 150,000 in student loans and find the lowest rates http://tagline.hushmail.com/fc/Ioyw6h4d7FblA8fts9RldEtVjBZ67iel92xTbg7eHSTqWXVXLl5xd9/ my endorsement or awareness of the nature of the link From vedaal at hush.com Mon Feb 4 20:16:54 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Mon, 04 Feb 2008 14:16:54 -0500 Subject: gnupg for file splitting and re-constituting // typo, sorry Message-ID: <20080204191654.7F17FD005F@mailserver10.hushmail.com> vedaal at hush.com vedaal at hush.com wrote on Mon Feb 4 20:07:45 CET 2008: >(scroll down to section [11], sorry, meant to type *section [10]* ;-(( vedaal any ads or links below this message are added by hushmail without -- Click for FHA loan, $0 lender fees, low rates & approvals nationwide http://tagline.hushmail.com/fc/Ioyw6h4dOJ6o88XU5bd16tB8wnSBZ5mmHJiQTUxJgzchd7VwfKf1R1/ my endorsement or awareness of the nature of the link From dshaw at jabberwocky.com Mon Feb 4 21:24:21 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 Feb 2008 15:24:21 -0500 Subject: Can you clarify when data compression is used? In-Reply-To: <47A7601E.8000107@sixdemonbag.org> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> Message-ID: <20080204202421.GB30533@jabberwocky.com> On Mon, Feb 04, 2008 at 12:57:34PM -0600, Robert J. Hansen wrote: > Kevin Hilton wrote: > > The problem I have, is that no where in the documentation are the > > defaults specified. > > >From the first full paragraph of the manpage: "[GnuPG] is a tool to > provide digital encryption and signing services using the OpenPGP > standard. [GnuPG] features complete key management and all bells and > whistles you can expect from a decent OpenPGP implementation." > > To me, that language is pretty clear about where you should look--the > OpenPGP standard, aka RFC4880, or its immediate predecessor RFC2440. > > That said, just because I think it's clear doesn't necessarily means it > /is/ clear. If it turns out that language is confusing or unclear, it > should definitely be changed to point people in the right direction. The RFC doesn't specify default algorithms, aside from requiring 3DES as the algorithm of last resort. All decisions about algorithm ranking are made by the implementations and indirectly, the user. It's hard to list default algorithms in the man page mainly because there isn't a single answer. Different people will get a different default algorithm depending on who they are sending a message to, and possibly even by the order in which they specify the recipients on the command line (see below). All of this would need many paragraphs of explanation, and that's not really appropriate for a man page. I do agree it would be good for it to be documented somewhere, though. > > I'm still confused what default cipher is chosen automatically (for > > me its AES). > > http://en.wikipedia.org/wiki/Stable_marriage_problem GPG doesn't use the Stable Marriage Problem when picking algorithms, as this gives too much "power" to the recipients in choosing which algorithm is used. Rather, the intersection of preferences for all recipients is generated, leaving an unordered list of algorithms that are possible contenders for use. At this point, note that it would be possible to pick an algorithm from the list randomly, as there is no algorithm on the list that isn't usable for all recipients. GPG uses the personal-(whatever)-preferences as the final decider. It works its way down the personal preferences list in ranked order, consulting the personal preferences against the generated intersection list of recipient algorithms. This gives the user the power to decide what algorithms he or she generates, which is putting the power in the right place. If there are no personal-foo-preferences in use, then GPG uses the first key specified as the decider. This key is frequently the user's key, so is a reasonable choice to pick the favored algorithm. David From rjh at sixdemonbag.org Mon Feb 4 21:44:33 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 04 Feb 2008 14:44:33 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <20080204202421.GB30533@jabberwocky.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> <20080204202421.GB30533@jabberwocky.com> Message-ID: <47A77931.90609@sixdemonbag.org> David Shaw wrote: > GPG doesn't use the Stable Marriage Problem when picking algorithms, > as this gives too much "power" to the recipients in choosing which > algorithm is used. It wasn't my intention to claim the SMP was used directly, but rather that it was an analogous process. It's a good introduction to the idea of mathematical preference matching. I apologize for any confusion generated there. From kevhilton at gmail.com Tue Feb 5 04:26:14 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 4 Feb 2008 21:26:14 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <47A7601E.8000107@sixdemonbag.org> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> Message-ID: <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> Im aware of the personal cipher preferences and personal hash preferences, but when talking about the defaults I specifically asking if gpg were installed from source -- no modifications made -- and gpg keys were created - what default cipher and hash would be listed first in the list with the keys? Without any intervention gpg-key-gen It appears to manually choose a DSA signing key (DSA vs DSA2 -- ambiguous since the man pages contain a switch to --enable-dsa2 in the gpg.conf file) with SHA1 hash -- or at least the SHA1 hash is ranked first in the key preference list For the encryption key - a ElGamal 2048 bit key is the default with AES chosen as the first cipher contained in the key cipher preference. Basically I'm aware of the --default-preference-list option in the gpg.conf file that control preferences during key generation. I know how to use this option, but sadly I think the explanation is really lacking: --default-preference-list string Set the list of default preferences to string. This prefer- ence list is used for new keys and becomes the default for "setpref" in the edit menu. What I want to know is obviously GnuPG comes with a --default-preference-list "built-in". If I dont specify this setting in the gpg.conf file, what string is used by default? This would basically reveal the order and list of all the defaults for ciphers, hashes, and compression settings. From dshaw at jabberwocky.com Tue Feb 5 04:52:22 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 4 Feb 2008 22:52:22 -0500 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> Message-ID: <20080205035222.GD31603@jabberwocky.com> On Mon, Feb 04, 2008 at 09:26:14PM -0600, Kevin Hilton wrote: > Im aware of the personal cipher preferences and personal hash > preferences, but when talking about the defaults I specifically asking > if gpg were installed from source -- no modifications made -- and gpg > keys were created - what default cipher and hash would be listed first > in the list with the keys? > > Without any intervention > gpg-key-gen > > It appears to manually choose a DSA signing key (DSA vs DSA2 -- > ambiguous since the man pages contain a switch to --enable-dsa2 in the > gpg.conf file) with SHA1 hash -- or at least the SHA1 hash is ranked > first in the key preference list As I said earlier, DSA. Trust me. It's really DSA. DSA doesn't have a particular hash (so it can't have SHA1 or anything else as a hash). It has a hash length. Don't get hung up on the DSA/DSA2 thing. In actuality, there is no such algorithm as "DSA2". Most people call DSA with a key larger than 1024 bits or a hash larger than 160 bits "DSA2" for convenience. All the --enable-dsa2 switch does (and again, it's off by default in 1.4.8 and 2.0.8), is allow you to generate a DSA key that is larger than 1024 bits or has a hash larger than 160 bits. > For the encryption key - a ElGamal 2048 bit key is the default with > AES chosen as the first cipher contained in the key cipher preference. No. The first cipher is AES256. AES and AES256 are not the same cipher (AES in OpenPGP is AES128). > What I want to know is obviously GnuPG comes with a > --default-preference-list "built-in". If I dont specify this setting > in the gpg.conf file, what string is used by default? This would > basically reveal the order and list of all the defaults for ciphers, > hashes, and compression settings. As of 1.4.8 and 2.0.8, and subject to change in future versions: Cipher: AES256, AES192, AES, CAST5, 3DES Hash: SHA1, SHA256, RIPEMD160 Compression: ZLIB, BZIP2, ZIP, None You could see this for yourself: generate a key, and run "showpref" on it (which is in the manual, by the way). David From kevhilton at gmail.com Tue Feb 5 05:18:01 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 4 Feb 2008 22:18:01 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> Message-ID: <96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com> >As of 1.4.8 and 2.0.8, and subject to change in future versions: > >Cipher: AES256, AES192, AES, CAST5, 3DES >Hash: SHA1, SHA256, RIPEMD160 >Compression: ZLIB, BZIP2, ZIP, None You are absolutely correct about these settings. Perhaps this should be included in documentation (and changed when needed), since I would consider these to be the default settings for cipher, hash, and compression choice. >All the --enable-dsa2 switch >does (and again, it's off by default in 1.4.8 and 2.0.8), is allow you >to generate a DSA key that is larger than 1024 bits or has a hash >larger than 160 bits. This seems peculiar to me. Why is this setting turned off by default? I'm not at war with anyone in these forums, but many have acknowledged the shortcomings of using 160 bit hashes -- at least with the SHA1 hash. In the same vain, aren't keys sizes larger than 1024 bits actually now recommended? The default fallback allows the creation of a 1024 bit DSA key utilizing the SHA-1 hash -- the preferred preference. Again I know nothing about cryptography but based on the links provided by users' of this forum, it would seem that the choice or a larger DSA key and different hash would be preferable?. From rjh at sixdemonbag.org Tue Feb 5 06:12:02 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 04 Feb 2008 23:12:02 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> <96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com> Message-ID: <47A7F022.5030807@sixdemonbag.org> Kevin Hilton wrote: > In the same vain, aren't keys sizes larger than 1024 > bits actually now recommended? As I understand it, it's largely due to engineering concerns than mathematical concerns. The RFC which specifies the OpenPGP protocol first came out in 1998. It began to receive revisions almost immediately (the -bis series: RFC2440bis1, RFC2440bis2, etc.). These -bis series were meant as previews of the next official RFC, whenever it would be published. However, the original RFC remained canonical. That specified DSA-1024. In order to closely follow the RFC, GnuPG left the default as DSA-1024. This was probably the right call to make for interoperability reasons. As an example of what happens when people decide to move beyond the RFC, look at PGP 7.0. Management at PGP Security decided that Twofish was the likely winner of the AES competition, and so they put Twofish into PGP. This put pressure on GnuPG to put Twofish into GnuPG, in order to interoperate with PGP. Twofish is almost entirely abandoned nowadays, but it still exists in PGP and GnuPG. Once a bad decision is made in engineering, the engineers are stuck supporting it forever. Take a look through the archives sometime and see how many people have bitterly complained about TIGER192 no longer being supported, despite the fact it was part of GnuPG for about three and a half milliseconds. I suspect--although I do not know--that a similar motivation drove GnuPG's decision to leave DSA-1024 as the standard. Now that RFC4880 has come out, supplanting RFC2440, I imagine the way is clear to make all new keys DSA-2048 or DSA-3072. After all, now it's part of the standard. From philb328 at yahoo.co.uk Tue Feb 5 15:29:01 2008 From: philb328 at yahoo.co.uk (Phil Brooke) Date: Tue, 5 Feb 2008 14:29:01 +0000 (GMT) Subject: Using notations on data signatures Message-ID: <947421.45671.qm@web23005.mail.ird.yahoo.com> Hi, I'm a bit confused about --sig-notation. Suppose I detach-sign a file; is it reasonable to use notations to briefly comment on it? e.g., --sig-notation user at some.domain="This loan application is approved." (Not dealing with loans really, but needed some example....) Is the notation part of the signed data (whereas the comment headers aren't) so that tampering with the notation is evident? Thanks, Phil. __________________________________________________________ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com From dshaw at jabberwocky.com Tue Feb 5 15:42:16 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 5 Feb 2008 09:42:16 -0500 Subject: Using notations on data signatures In-Reply-To: <947421.45671.qm@web23005.mail.ird.yahoo.com> References: <947421.45671.qm@web23005.mail.ird.yahoo.com> Message-ID: <20080205144216.GA32503@jabberwocky.com> On Tue, Feb 05, 2008 at 02:29:01PM +0000, Phil Brooke wrote: > Hi, > > I'm a bit confused about --sig-notation. Suppose I detach-sign a file; is it > reasonable to use notations to briefly comment on it? e.g., > --sig-notation user at some.domain="This loan application is approved." > (Not dealing with loans really, but needed some example....) Yes, that is a reasonable use of a notation. Notations (and especially user notations) are basically the escape hatch in the OpenPGP design: they're intended for adding stuff to signatures. What stuff if up to the adder. See also --sig-policy-url for another, but more standard, way to add information about a signature. > Is the notation part of the signed data (whereas the comment headers aren't) > so that tampering with the notation is evident? Yes. David From dshaw at jabberwocky.com Tue Feb 5 17:17:38 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 5 Feb 2008 11:17:38 -0500 Subject: Can you clarify when data compression is used? In-Reply-To: <47A7F022.5030807@sixdemonbag.org> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> <96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com> <47A7F022.5030807@sixdemonbag.org> Message-ID: <20080205161738.GA2400@jabberwocky.com> On Mon, Feb 04, 2008 at 11:12:02PM -0600, Robert J. Hansen wrote: > I suspect--although I do not know--that a similar motivation drove > GnuPG's decision to leave DSA-1024 as the standard. That's basically the reason. While GPG fully supports DSA2 signatures today, there are a large installed base that cannot handle them. Because of this, we decided to fully accept DSA2 keys and signatures from elsewhere, but won't generate a new DSA2 key unless the user opts in with --enable-dsa2. > Now that RFC4880 has come out, supplanting RFC2440, I imagine the way is > clear to make all new keys DSA-2048 or DSA-3072. After all, now it's > part of the standard. The way is clear, and we'll get there eventually, but the installed base is still pretty old. Using --rfc4880 or --openpgp does enable DSA2, but the default is still off. David From thurston at cs.queensu.ca Tue Feb 5 18:02:48 2008 From: thurston at cs.queensu.ca (Adrian Thurston) Date: Tue, 05 Feb 2008 12:02:48 -0500 Subject: can you see any problem with this? Message-ID: <47A896B8.9070703@cs.queensu.ca> Hi, I'd like to serve messages that have been encrypted to a large number of people, however I don't want to reveal the list of recipients so I'm going to use --throw-keys. But speed at the decryption end is a concern, so I thought I would break up an encrypted message into packets and when a client requests it serve up only the packet that corresponds to the session key encrypted to them, then the content packet. I haven't tried it yet, but it seems as though it should work. I'd like to know if there is any non-obvious reason why it is a bad idea. Thanks, Adrian From program.spe at home.pl Fri Feb 1 09:58:12 2008 From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=) Date: Fri, 01 Feb 2008 09:58:12 +0100 Subject: Safe decryption with GnuPG? Message-ID: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> Dear friends: I have a file that I encrypted for myself and I want to read some information from it. The file is a text file and I need to read several lines of it. The following requirements must be met: 1. The decrypted information must not make it to any persistent medium (I understand gpg '-d' already guarantees it as long as it manages the decrypted text, but what happens after it leaves gpg?) 2. The decrypted text must not be stored in volatile memory any longer than it is needed. In particular, it should be converted to a human-viewable bitmap and the computer-readable representation must be immediately erased. 3. Only the information I need should be displayed. 4. The bitmap must not be updated automatically (the containing window must not display it when it is in the background, whatever it means). (It would be best to forget the bitmap altogether and regenerate it upon request, but it seems to be a hard thing to do because the gpg output stream is not scrollable backwards). 5. The bitmap itself should not make it to any persistent medium and it should be scrambled, if possible, in the volatile memory. 6. It should not be possible to make a snapshot of the graphic in the window with any programmatic means (you can of course make a picture of the screen with a camera). 7. If more information is requested, it should be displayed in small chunks. The program should be fully unaware of the content of the chunks that are not being displayed. (That probably means a garbage-collected language cannot be used). 8. The application should be as lightweight as possible (for source code audit). Can you direct me to some implementation meeting these requirements? Best regards, Chris From nobody at mixmaster.it Sat Feb 2 06:16:23 2008 From: nobody at mixmaster.it (George Orwell) Date: Sat, 2 Feb 2008 06:16:23 +0100 (CET) Subject: Anti-Tempest Fonts, Where? Message-ID: man gpg the above cmd mentions anti tempest fonts. what does this mean exactly? where are the anti-tempest fonts? i've searched the net for them and cannot find them. the only mention of soft tempest fonts were within a .zip containing image files claimed to be for example only. do tempest resistant fonts exist? Il mittente di questo messaggio|The sender address of this non corrisponde ad un utente |message is not related to a real reale ma all'indirizzo fittizio|person but to a fake address of an di un sistema anonimizzatore |anonymous system Per maggiori informazioni |For more info https://www.mixmaster.it From rjh at sixdemonbag.org Tue Feb 5 18:25:54 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 05 Feb 2008 11:25:54 -0600 Subject: can you see any problem with this? In-Reply-To: <47A896B8.9070703@cs.queensu.ca> References: <47A896B8.9070703@cs.queensu.ca> Message-ID: <47A89C22.5090409@sixdemonbag.org> Adrian Thurston wrote: > But speed at the decryption end is a concern, so I thought I would break > up an encrypted message into packets and when a client requests it serve > up only the packet that corresponds to the session key encrypted to > them, then the content packet. I haven't tried it yet, but it seems as > though it should work. I'd like to know if there is any non-obvious > reason why it is a bad idea. At first blush it seems like a case of there being way too much hammer for the nail you have in mind. 1. Compose a single message: "the magic words are... [insert passphrase here]". 2. Write a script to encrypt each message to each recipient's key and mail it to them. If this takes more than 20 lines of Perl, something's wrong. 3. Compose your future traffic as normal, but symmetrically encrypt it and send it on to your recipients. ... Admittedly, I don't know the particulars of your environment, so this might be inappropriate for your needs. But it's the first thing that comes to mind as I read your description of what's happening. From david at miradoiro.com Tue Feb 5 18:29:16 2008 From: david at miradoiro.com (=?iso-8859-1?Q?David_Pic=F3n_=C1lvarez?=) Date: Tue, 5 Feb 2008 18:29:16 +0100 Subject: Safe decryption with GnuPG? References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> Message-ID: <000501c8681c$a1ca1e90$0302a8c0@Nautilus> Sorry, but what you're asking for is impossible. > The decrypted information must not make it to any persistent medium > (I understand gpg '-d' already guarantees it > as long as it manages the decrypted text, > but what happens after it leaves gpg?) That's the business of the viewer. > In particular, it should be converted to a human-viewable bitmap > and the computer-readable representation must be immediately erased. This doesn't buy you much, especially since there's OCR and the computer generated bitmap is likely to be very regular. > 3. Only the information I need should be displayed. How does the viewer know which information you need? > The bitmap must not be updated automatically > (the containing window must not display it > when it is in the background, whatever it means). > (It would be best to forget the bitmap altogether > and regenerate it upon request, > but it seems to be a hard thing to do > because the gpg output stream is not scrollable backwards). Updated automatically? Not sure I see what you mean here. > The bitmap itself should not make it to any persistent medium > and it should be scrambled, if possible, in the volatile memory. Scrambling isn't of much use. If someone can read your memory they can read the key, which must lie somewhere in memory as well. > It should not be possible > to make a snapshot of the graphic in the window > with any programmatic means > (you can of course make a picture of the screen with a camera). This is impossible, unless you have: 1) trusted hardware, DRM style, or 2) a specifically built OS to ensure it. > The application should be as lightweight as possible > (for source code audit). Good luck, you're proposing an application that would have to take full control of video RAM to ensure noone can read it, that would have to do all sorts of graphical manipulation to generate a bitmap from a text, etc. --David. From rjh at sixdemonbag.org Tue Feb 5 18:36:06 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 05 Feb 2008 11:36:06 -0600 Subject: Safe decryption with GnuPG? In-Reply-To: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> Message-ID: <47A89E86.9010800@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Krzysztof ?elechowski wrote: > The decrypted information must not make it to any persistent medium GnuPG is almost certainly the wrong tool for your job. GnuPG has little control over low-level operating systems details like swap files. It is possible for cleartext to be stored in some manner. > (I understand gpg '-d' already guarantees it > as long as it manages the decrypted text, > but what happens after it leaves gpg?) [many other requirements snipped] Many of your requirements belong in the application stack alongside or above GnuPG, but are pretty much unrelated to GnuPG. After it leaves GnuPG it's no longer GnuPG's problem. Many of your requirements are also impossible to meet. I don't mean "impossible" as in "it would require a lot of engineering", I mean "impossible" as in "it's like violating the Second Law of Thermodynamics". > Can you direct me to some implementation meeting these requirements? There exists no such implementation. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iFYEAREIAAYFAkeonoYACgkQf2XByo0Cu7Or6ADcDcxgGCAxE2/Dp6NkFzwXBNg4 MI15KpzntdSaJADgkHHfzS/T0/3BnLSkZCVQ0OJ5OFYmxl1Nw4cypIkBHAQBAQgA BgUCR6iehgAKCRC3APSC/q+BCS9PB/sEIUftJVfX2hYNijy+ml6IAPYhGhIl73eP si/FvVWVP9WIYAOIz4Q68x1en+zXOncQc8cTUO8HB8hJeuWwe8Zoi/V2cB8nJ9Q1 +mwAcY7q7QuipRJhCpMG/pIS+BY6lDrDWDS1FOlWajDiZnO9Yo81PNCp85B+SC3B d69h2f6PBJY45DWHfQR224k/hEx9C522FlyPJVN6ZIn7fHSZonb4iTUyZ7Gh5mqW AOwBGPfyxYcAiXaBJPvOrdBV3b9kg0Gzf+rCRBDLpJsgmWssQOdGrRIXcOuW9n0C L94jJamwjgpP4YdTuirG4IZDwdcOw5vBoqjNrLpkvK8aoPWnf2AN =b/yU -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Feb 5 18:43:11 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 05 Feb 2008 11:43:11 -0600 Subject: Anti-Tempest Fonts, Where? In-Reply-To: References: Message-ID: <47A8A02F.3080808@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 George Orwell wrote: > do tempest resistant fonts exist? First, it's not "tempest resistant". TEMPEST is the name of the NSA's standard on Van Eck-resistant hardware. What you're talking about is Van Eck surveillance. I know, I know, PGP Corporation calls it "Tempest resistance". They're wrong, too. Anyway, taking off the pedantry hat... I am unaware of any empirical evidence that suggests PGP's Van Eck-resistant fonts really offer much, if any, security against Van Eck surveillance. If you're dealing with people who are willing to park a van down the block and dedicate a crew of surveillance experts and a few thousand bucks of directional antennas and custom-built FPGAs at you, my best advice is to (a) run away and (b) build a Faraday cage. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iFYEAREIAAYFAkeooC4ACgkQf2XByo0Cu7M8WgDbBHkrkNUpHMFZfykVffOsaTFw 9E3JVJ1mXBHmPgDdEdXJcN3vftBtGKw3va7zIPmNgVS/GmVFShYAWYkBHAQBAQgA BgUCR6igLgAKCRC3APSC/q+BCZ2ECACMdFOEH47rTF03Cm834FWFNnegnGs8UGXD z/uBEtrO212nIBSKXqEfLxL0137dnx8Y9e6NmU4XfxS5DhbpWY2baqiuJcSGVx7S VSQPHffe1QO31ehlWEChHysKQDZRC+TGpyg/d6JWx+QVn8iixq5qB4N9qIRUrLAK SV1pV4kA8TCPVCh/V8VfR77wdTjE4y5/vIn1iXcVpIZyieZUF3/5yYxN9fLU4m8H UJI7BZTd3KU5PnDmA0X/xPbQaf4fITq+BBc22omDsLu5UEdWpXxw/R92J+1+0op7 uoqxqh3Hq51GoIsItirFTGLvLElcYAKBZKHWeeauxktOcnrjwRrH =3//e -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Tue Feb 5 19:00:54 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 5 Feb 2008 13:00:54 -0500 Subject: can you see any problem with this? In-Reply-To: <47A896B8.9070703@cs.queensu.ca> References: <47A896B8.9070703@cs.queensu.ca> Message-ID: <20080205180054.GB2400@jabberwocky.com> On Tue, Feb 05, 2008 at 12:02:48PM -0500, Adrian Thurston wrote: > Hi, > > I'd like to serve messages that have been encrypted to a large number of > people, however I don't want to reveal the list of recipients so I'm > going to use --throw-keys. > > But speed at the decryption end is a concern, so I thought I would break > up an encrypted message into packets and when a client requests it serve > up only the packet that corresponds to the session key encrypted to > them, then the content packet. I haven't tried it yet, but it seems as > though it should work. I'd like to know if there is any non-obvious > reason why it is a bad idea. It's hard to really answer this as there isn't enough information to say one way or another. Speaking strictly to your question, and not the "is this wise" question, if I understand it, you are proposing encrypting to a large number of people, breaking the resultant encrypted message into many PKESK packets (one per recipient) and one encrypted packet. Then, send each recipient their own PKESK plus the encrypted packet. So, yes, that would work. GPG even ships with the tools to make such a message. And it's safe to do so with the caveat that every user will have the same encrypted message and be able to decrypt it. On the one hand, no big deal, becuase you sent everyone the same message, so you clearly wanted them to have it. On the other hand, it gives Alice the ability to know that Baker got the same message that Alice did. Whether that is important or not depends on what you are doing. Also, given that you are only sending each recipient their own PKESK, why bother to use --throw-keyid ? It might be easier to just encrypt the whole message to each recipient individually rather than do all the packet surgery. David From rjh at sixdemonbag.org Tue Feb 5 19:14:59 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 05 Feb 2008 12:14:59 -0600 Subject: Safe decryption with GnuPG? In-Reply-To: <1202235036.6608.29.camel@a1dmin.vola.spe.com.pl> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <47A89E86.9010800@sixdemonbag.org> <1202235036.6608.29.camel@a1dmin.vola.spe.com.pl> Message-ID: <47A8A7A3.7010802@sixdemonbag.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Krzysztof ?elechowski wrote: > GnuPG claims it locks memory pages so that they are never dumped. On systems where that's supported, sure. On systems where that's not supported, it doesn't. Ergo, tread carefully. > (although I am quite surprised > because the requirements are quite obvious to me; > for what is the benefit of encryption > when a bad robot can read over your shoulder?) If your hardware is compromised then you are absolutely screwed, and there is nothing you can do about it. Bang, period, game over, end of sentence, end of discussion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iFYEAREIAAYFAkeop6MACgkQf2XByo0Cu7OxvwDfeijBBMNF/zNFxk+faY5nERLG 6pT/D0jGRqHUdADfWJNvfqN7oPk1vNRBiXeIyQ0AVoV1BJT9y91soYkBHAQBAQgA BgUCR6inowAKCRC3APSC/q+BCefVB/9hzIe10SvQlTThBAEZoGvD4s4HrIEWyIOo j45mAzB63Z6TZyWwozjQsK8IVN2+TNY4fkOfmZSqo2P3O7Oz3dQ+0VY9FcCV2n1g FqBZ1WuxEYMYJ37cLLbhN2s3fYKoBPW4Cv0atScC9hjeDyB7lUO5Gdm3BVw1XhPd KI8Ke6syImfx1niXgTs3J2ZkkQueUkKvz/yGKeevAP+u8fg9U9NymQnKMlbyxPaf oNkOdm64eJc0NMbA/KLwOoFgEv9CZpbRoZ8LeS9nZ3zpTtA+vlv/kivzR/aTZnR5 t7ttR64NXq5lnQOuiUxq8XyBwWhlmscXPiOg7H6X4QmqF0L7Zqmf =fDSZ -----END PGP SIGNATURE----- From thurston at cs.queensu.ca Tue Feb 5 19:10:02 2008 From: thurston at cs.queensu.ca (Adrian Thurston) Date: Tue, 05 Feb 2008 13:10:02 -0500 Subject: can you see any problem with this? In-Reply-To: <47A89C22.5090409@sixdemonbag.org> References: <47A896B8.9070703@cs.queensu.ca> <47A89C22.5090409@sixdemonbag.org> Message-ID: <47A8A67A.1000703@cs.queensu.ca> My system can be described as encrypted news feeds. I considered that approach and I like it because it's doesn't require taking apart PGP messages. The problem is that in my system I need the ability to revoke access to any single user. With a session key unique to each message I can just re-encrypt and drop a user. If the session key comes separately I need to ensure that the clients always have the current symmetric key. The easiest way to do that is to just send it with each message. But then I've just got ... well you see :) Adrian Robert J. Hansen wrote: > Adrian Thurston wrote: >> But speed at the decryption end is a concern, so I thought I would break >> up an encrypted message into packets and when a client requests it serve >> up only the packet that corresponds to the session key encrypted to >> them, then the content packet. I haven't tried it yet, but it seems as >> though it should work. I'd like to know if there is any non-obvious >> reason why it is a bad idea. > > At first blush it seems like a case of there being way too much hammer > for the nail you have in mind. > > 1. Compose a single message: "the magic words are... [insert passphrase > here]". > > > 2. Write a script to encrypt each message to each recipient's key and > mail it to them. If this takes more than 20 lines of Perl, something's > wrong. > > 3. Compose your future traffic as normal, but symmetrically encrypt it > and send it on to your recipients. > > > ... Admittedly, I don't know the particulars of your environment, so > this might be inappropriate for your needs. But it's the first thing > that comes to mind as I read your description of what's happening. > > From thurston at cs.queensu.ca Tue Feb 5 19:28:08 2008 From: thurston at cs.queensu.ca (Adrian Thurston) Date: Tue, 05 Feb 2008 13:28:08 -0500 Subject: can you see any problem with this? In-Reply-To: <20080205180054.GB2400@jabberwocky.com> References: <47A896B8.9070703@cs.queensu.ca> <20080205180054.GB2400@jabberwocky.com> Message-ID: <47A8AAB8.4030200@cs.queensu.ca> My application is here: http://www.cs.queensu.ca/~thurston/fif/ I'm encrypting messages and making them publicly available over static HTTP. Anyone who knows the right URL can grab a message and I don't want recipients to be identifiable. Another issue is that the number of recipients and the size of messages may both get very large. A single encrypted message is therefore very attractive. Thanks, Adrian David Shaw wrote: > On Tue, Feb 05, 2008 at 12:02:48PM -0500, Adrian Thurston wrote: >> Hi, >> >> I'd like to serve messages that have been encrypted to a large number of >> people, however I don't want to reveal the list of recipients so I'm >> going to use --throw-keys. >> >> But speed at the decryption end is a concern, so I thought I would break >> up an encrypted message into packets and when a client requests it serve >> up only the packet that corresponds to the session key encrypted to >> them, then the content packet. I haven't tried it yet, but it seems as >> though it should work. I'd like to know if there is any non-obvious >> reason why it is a bad idea. > > It's hard to really answer this as there isn't enough information to > say one way or another. > > Speaking strictly to your question, and not the "is this wise" > question, if I understand it, you are proposing encrypting to a large > number of people, breaking the resultant encrypted message into many > PKESK packets (one per recipient) and one encrypted packet. Then, > send each recipient their own PKESK plus the encrypted packet. > > So, yes, that would work. GPG even ships with the tools to make such > a message. And it's safe to do so with the caveat that every user > will have the same encrypted message and be able to decrypt it. On > the one hand, no big deal, becuase you sent everyone the same message, > so you clearly wanted them to have it. On the other hand, it gives > Alice the ability to know that Baker got the same message that Alice > did. Whether that is important or not depends on what you are doing. > > Also, given that you are only sending each recipient their own PKESK, > why bother to use --throw-keyid ? It might be easier to just encrypt > the whole message to each recipient individually rather than do all > the packet surgery. > > David > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > From dshaw at jabberwocky.com Tue Feb 5 19:50:56 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 5 Feb 2008 13:50:56 -0500 Subject: can you see any problem with this? In-Reply-To: <47A8AAB8.4030200@cs.queensu.ca> References: <47A896B8.9070703@cs.queensu.ca> <20080205180054.GB2400@jabberwocky.com> <47A8AAB8.4030200@cs.queensu.ca> Message-ID: <20080205185056.GC2400@jabberwocky.com> On Tue, Feb 05, 2008 at 01:28:08PM -0500, Adrian Thurston wrote: > My application is here: > > http://www.cs.queensu.ca/~thurston/fif/ > > I'm encrypting messages and making them publicly available over static > HTTP. Anyone who knows the right URL can grab a message and I don't want > recipients to be identifiable. > > Another issue is that the number of recipients and the size of messages > may both get very large. A single encrypted message is therefore very > attractive. In that case, doing something like this may work for you: gpg -o output.gpg -R recipient1 -R recipient2 -e thefile.txt gpgsplit output.gpg for i in *.pk_enc do cat $i *.encrypted > `echo $i | sed -e 's/\-001\.pk_enc//'` done You'll end up with a directory full of files, one per recipient, and each a valid OpenPGP message, but all of them protected via throw-keyid. I'll leave it as an exercise for the reader to determine which file goes with which recipient ;) Caveats: If Alice and Baker both get a message, and Alice knows which file Baker got, Alice can decrypt Baker's message using her own session key, thus revealing to Alice that Baker got the same message that Alice did. The "non-identifiable" feature with -R (aka throw-keyid) is only as good as throw-keyid is, which is pretty good but not perfect. You may or may not care about these caveats. David From dshaw at jabberwocky.com Tue Feb 5 20:00:34 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 5 Feb 2008 14:00:34 -0500 Subject: Anti-Tempest Fonts, Where? In-Reply-To: References: Message-ID: <20080205190034.GD2400@jabberwocky.com> On Sat, Feb 02, 2008 at 06:16:23AM +0100, George Orwell wrote: > man gpg > > the above cmd mentions anti tempest fonts. what does this mean > exactly? where are the anti-tempest fonts? i've searched the > net for them and cannot find them. the only mention of soft > tempest fonts were within a .zip containing image files claimed > to be for example only. > > do tempest resistant fonts exist? No. Or at least, not any longer. There was a font package available a few years ago that was an offshoot of some work done by Markus Kuhn and Ross Anderson at the University of Cambridge. More recently, they improved the attack enough that the fonts were no longer effective. See http://www.cl.cam.ac.uk/~mgk25/emsec/softtempest-faq.html I'll update the manual so it does not reference the fonts any longer. David From thurston at cs.queensu.ca Tue Feb 5 20:24:15 2008 From: thurston at cs.queensu.ca (=?utf-8?B?QWRyaWFuIFRodXJzdG9u?=) Date: Tue, 5 Feb 2008 19:24:15 +0000 Subject: can you see any problem with this? In-Reply-To: <20080205185056.GC2400@jabberwocky.com> References: <47A896B8.9070703@cs.queensu.ca> <20080205180054.GB2400@jabberwocky.com> <47A8AAB8.4030200@cs.queensu.ca><20080205185056.GC2400@jabberwocky.com> Message-ID: <1285006927-1202239420-cardhu_decombobulator_blackberry.rim.net-704829373-@bxe008.bisx.prod.on.blackberry> Yes I think I can live with those characteristics of the system. Thanks for your analysis! -Adrian -----Original Message----- From: David Shaw Date: Tue, 5 Feb 2008 13:50:56 To:Adrian Thurston Cc:gnupg-users at gnupg.org Subject: Re: can you see any problem with this? On Tue, Feb 05, 2008 at 01:28:08PM -0500, Adrian Thurston wrote: > My application is here: > > http://www.cs.queensu.ca/~thurston/fif/ > > I'm encrypting messages and making them publicly available over static > HTTP. Anyone who knows the right URL can grab a message and I don't want > recipients to be identifiable. > > Another issue is that the number of recipients and the size of messages > may both get very large. A single encrypted message is therefore very > attractive. In that case, doing something like this may work for you: gpg -o output.gpg -R recipient1 -R recipient2 -e thefile.txt gpgsplit output.gpg for i in *.pk_enc do cat $i *.encrypted > `echo $i | sed -e 's/\-001\.pk_enc//'` done You'll end up with a directory full of files, one per recipient, and each a valid OpenPGP message, but all of them protected via throw-keyid. I'll leave it as an exercise for the reader to determine which file goes with which recipient ;) Caveats: If Alice and Baker both get a message, and Alice knows which file Baker got, Alice can decrypt Baker's message using her own session key, thus revealing to Alice that Baker got the same message that Alice did. The "non-identifiable" feature with -R (aka throw-keyid) is only as good as throw-keyid is, which is pretty good but not perfect. You may or may not care about these caveats. David From hidekis at gmail.com Wed Feb 6 02:30:01 2008 From: hidekis at gmail.com (Hideki Saito) Date: Tue, 5 Feb 2008 17:30:01 -0800 Subject: Anti-Tempest Fonts, Where? In-Reply-To: <20080205190034.GD2400@jabberwocky.com> References: <20080205190034.GD2400@jabberwocky.com> Message-ID: Makes me curious, how relevant is it these days, especially with age of (presumably) lower emission LCD screen? On Feb 5, 2008 11:00 AM, David Shaw wrote: > On Sat, Feb 02, 2008 at 06:16:23AM +0100, George Orwell wrote: > > man gpg > > > > the above cmd mentions anti tempest fonts. what does this mean > > exactly? where are the anti-tempest fonts? i've searched the > > net for them and cannot find them. the only mention of soft > > tempest fonts were within a .zip containing image files claimed > > to be for example only. > > > > do tempest resistant fonts exist? > > No. Or at least, not any longer. There was a font package available > a few years ago that was an offshoot of some work done by Markus Kuhn > and Ross Anderson at the University of Cambridge. More recently, they > improved the attack enough that the fonts were no longer effective. > > See > http://www.cl.cam.ac.uk/~mgk25/emsec/softtempest-faq.html > > I'll update the manual so it does not reference the fonts any longer. > > David > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Hideki Saito From rjh at sixdemonbag.org Wed Feb 6 02:59:29 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 05 Feb 2008 19:59:29 -0600 Subject: Anti-Tempest Fonts, Where? In-Reply-To: References: <20080205190034.GD2400@jabberwocky.com> Message-ID: <47A91481.9080907@sixdemonbag.org> Hideki Saito wrote: > Makes me curious, how relevant is it these days, especially with age > of (presumably) lower emission LCD screen? An unshielded monitor cable puts out a lot of RF, regardless of what kind of monitor it's plugged into. LCDs can be Van Ecked, just as can CRTs. From kevhilton at gmail.com Wed Feb 6 05:36:41 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Tue, 5 Feb 2008 22:36:41 -0600 Subject: Any plans for GnuPG to implement decrypting to RAM? Message-ID: <96c450350802052036idffa463r6620bfde704f6eca@mail.gmail.com> Just wonder if GnuPG, similar to PGP, would implement decrypting files to RAM rather than swap, or to allow user to pick location. -- Kevin Hilton From dshaw at jabberwocky.com Wed Feb 6 05:44:59 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 5 Feb 2008 23:44:59 -0500 Subject: Any plans for GnuPG to implement decrypting to RAM? In-Reply-To: <96c450350802052036idffa463r6620bfde704f6eca@mail.gmail.com> References: <96c450350802052036idffa463r6620bfde704f6eca@mail.gmail.com> Message-ID: <20080206044459.GB3782@jabberwocky.com> On Tue, Feb 05, 2008 at 10:36:41PM -0600, Kevin Hilton wrote: > Just wonder if GnuPG, similar to PGP, would implement decrypting files > to RAM rather than swap, or to allow user to pick location. What does decrypt to swap mean? For that matter, what does decrypt to RAM mean? Decryption: gpg -o /pick/your/own/destination -d file-to-decrypt.gpg gpg -d file-to-decrypt.gpg > redirect-to-a-file gpg -d file-to-decrypt.gpg | pipe-to-whatever-you-want It's in the manual. David From pg at futureware.at Wed Feb 6 02:22:09 2008 From: pg at futureware.at (Philipp =?iso-8859-1?q?G=FChring?=) Date: Wed, 6 Feb 2008 02:22:09 +0100 Subject: Safe decryption with GnuPG? In-Reply-To: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> Message-ID: <200802060222.10599.pg@futureware.at> Hi, > 1. > The decrypted information must not make it to any persistent medium > (I understand gpg '-d' already guarantees it > as long as it manages the decrypted text, > but what happens after it leaves gpg?) Use a full-disc encryption system for all your persistent media. > 2. > The decrypted text must not be stored in volatile memory > any longer than it is needed. You can use TaintedBochs or TaintedQemu to investigate that. > In particular, it should be converted to a human-viewable bitmap > and the computer-readable representation must be immediately erased. Doesn?t help much to try that, I would say. But feel free to try ... > 3. Only the information I need should be displayed. You need a Do-What-I-Mean system for that. > 4. > The bitmap must not be updated automatically > (the containing window must not display it > when it is in the background, whatever it means). > (It would be best to forget the bitmap altogether > and regenerate it upon request, > but it seems to be a hard thing to do > because the gpg output stream is not scrollable backwards). Use Overlay mode to display it. > > 5. > The bitmap itself should not make it to any persistent medium > and it should be scrambled, if possible, in the volatile memory. Implement the viewer in the graphic card, with the CUDA SDK or something similar. > 6. > It should not be possible > to make a snapshot of the graphic in the window > with any programmatic means > (you can of course make a picture of the screen with a camera). Overlay mode does that. > 7. > If more information is requested, > it should be displayed in small chunks. > The program should be fully unaware > of the content of the chunks that are not being displayed. > (That probably means a garbage-collected language cannot be used). I don?t understand why you need that. I would suggest that you seperate the small chunks into seperated encrypted files, to ensure that the reader only gets those chunks that you actually decrypted. > 8. > The application should be as lightweight as possible > (for source code audit). Agreed. > Can you direct me to some implementation meeting these requirements? I think your specification isn?t complete yet. You forgot about half of the requirements. I guess that: * You want a machine that seperates code from data (to be secure against trojans, virii and other malware) * You want secure documents, that can?t change dynamically, or otherwise contain invisible contents * You want a secure path to the user (and some more requirements that I forgot at the moment) What?s your budget for this small project? Best regards, Philipp G?hring From steve at srevilak.net Wed Feb 6 16:27:13 2008 From: steve at srevilak.net (Steve Revilak) Date: Wed, 6 Feb 2008 10:27:13 -0500 (EST) Subject: Safe decryption with GnuPG? Message-ID: > I have a file that I encrypted for myself and I want to read some information > from it. The file is a text file and I need to read several lines of it. > > The following requirements must be met: I was going to suggest gpg --decrypt file.gpg | grep "interesting stuff" | banner | less >/dev/null but I'll try to be more serious. :) Out of curiosity, what kind of a threat vector are you anticipating? By reading your list of requirements, the ones I've extracted are * Access to sensitive data via system memory is a threat. * Access to sensitive data via the file system (i.e. by examining swap space) is a threat. * Access to sensitive data via the graphics system framebuffer is a threat. * Access to sensitive data via visual observation (someone sees the text on the screen, or takes a picture of the text on the screen) is a threat. As someone else mentioned, this brings up a lot of issues in the area of trusting the hardware, trusting the operating system and so fourth. Granted, they are interesting issues, but my gut instinct tells me that this problem might be easier to solve with physical security. For example, the first three threats imply that the data has to leave the system where it is being viewed. Removing network access to that system (unplug the ethernet cable, remove any wireless/bluetooth hardware), would mitigate those threats, no? As for threat #4, if you're viewing the data in a small, bare-walled, locked room, you'd be able to tell (a) whether someone else was in the room looking over your shoulder or (b) whether there was a camera being pointed at your screen. And if you don't trust the isolated computer in the small locked room, you could even go as far as removing its hard drive -- you'd walk in with a bootable CD that contained your encrypted file, boot up, read what you needed, then halt. Steve > From: Philipp G?hring > Date: Wed, 6 Feb 2008 02:22:09 +0100 > Subject: Re: Safe decryption with GnuPG? > Message-ID: <200802060222.10599.pg at futureware.at> > To: gnupg-users at gnupg.org > Cc: Krzysztof ?elechowski > > Hi, > >> 1. >> The decrypted information must not make it to any persistent medium >> (I understand gpg '-d' already guarantees it >> as long as it manages the decrypted text, >> but what happens after it leaves gpg?) > > Use a full-disc encryption system for all your persistent media. > >> 2. >> The decrypted text must not be stored in volatile memory >> any longer than it is needed. > > You can use TaintedBochs or TaintedQemu to investigate that. > >> In particular, it should be converted to a human-viewable bitmap >> and the computer-readable representation must be immediately erased. > > Doesn?t help much to try that, I would say. But feel free to try ... > >> 3. Only the information I need should be displayed. > > You need a Do-What-I-Mean system for that. > >> 4. >> The bitmap must not be updated automatically >> (the containing window must not display it >> when it is in the background, whatever it means). >> (It would be best to forget the bitmap altogether >> and regenerate it upon request, >> but it seems to be a hard thing to do >> because the gpg output stream is not scrollable backwards). > > Use Overlay mode to display it. > >> >> 5. >> The bitmap itself should not make it to any persistent medium >> and it should be scrambled, if possible, in the volatile memory. > > Implement the viewer in the graphic card, with the CUDA SDK or something > similar. > >> 6. >> It should not be possible >> to make a snapshot of the graphic in the window >> with any programmatic means >> (you can of course make a picture of the screen with a camera). > > Overlay mode does that. > >> 7. >> If more information is requested, >> it should be displayed in small chunks. >> The program should be fully unaware >> of the content of the chunks that are not being displayed. > >> (That probably means a garbage-collected language cannot be used). > > I don?t understand why you need that. > I would suggest that you seperate the small chunks into seperated encrypted > files, to ensure that the reader only gets those chunks that you actually > decrypted. > >> 8. >> The application should be as lightweight as possible >> (for source code audit). > > Agreed. > >> Can you direct me to some implementation meeting these requirements? > > I think your specification isn?t complete yet. You forgot about half of the > requirements. > > I guess that: > > * You want a machine that seperates code from data (to be secure against > trojans, virii and other malware) > > * You want secure documents, that can?t change dynamically, or otherwise > contain invisible contents > > * You want a secure path to the user > > (and some more requirements that I forgot at the moment) > > What?s your budget for this small project? > > Best regards, > Philipp G?hring > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From steve at srevilak.net Wed Feb 6 16:03:09 2008 From: steve at srevilak.net (Steve Revilak) Date: Wed, 6 Feb 2008 10:03:09 -0500 (EST) Subject: Safe decryption with GnuPG? In-Reply-To: <200802060222.10599.pg@futureware.at> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <200802060222.10599.pg@futureware.at> Message-ID: > I have a file that I encrypted for myself > and I want to read some information from it. > The file is a text file and I need to read several lines of it. > > The following requirements must be met: I was going to suggest gpg --decrypt file.gpg | grep "interesting stuff" | banner | less >/dev/null but I'll try to be more serious. :) Out of curiosity, what kind of a threat vector are you anticipating? By reading your list of requirements, the ones I've extracted are * Access to sensitive data via system memory is a threat. * Access to sensitive data via the file system (i.e. by examining swap space) is a threat. * Access to sensitive data via the graphics system framebuffer is a threat. * Access to sensitive data via visual observation (someone sees the text on the screen, or takes a picture of the text on the screen) is a threat. As someone else mentioned, this brings up a lot of issues in the area of trusting the hardware, trusting the operating system and so fourth. Granted, they are interesting issues, but my gut instinct tells me that this problem might be easier to solve with physical security. For example, the first three threats imply that the data has to leave the system where it is being viewed. Removing network access to that system (unplug the ethernet cable, remove any wireless/bluetooth hardware), would mitigate those threats, no? As for threat #4, if you're viewing the data in a small, bare-walled, locked room, you'd be able to tell (a) whether someone else was in the room looking over your shoulder or (b) whether there was a camera being pointed at your screen. And if you don't trust the isolated computer in the small locked room, you could even go as far as removing its hard drive -- you'd walk in with a bootable CD that contained your encrypted file, boot up, read what you needed, then halt. Steve > From: Philipp G?hring > Date: Wed, 6 Feb 2008 02:22:09 +0100 > Subject: Re: Safe decryption with GnuPG? > Message-ID: <200802060222.10599.pg at futureware.at> > To: gnupg-users at gnupg.org > Cc: Krzysztof ?elechowski > > Hi, > >> 1. >> The decrypted information must not make it to any persistent medium >> (I understand gpg '-d' already guarantees it >> as long as it manages the decrypted text, >> but what happens after it leaves gpg?) > > Use a full-disc encryption system for all your persistent media. > >> 2. >> The decrypted text must not be stored in volatile memory >> any longer than it is needed. > > You can use TaintedBochs or TaintedQemu to investigate that. > >> In particular, it should be converted to a human-viewable bitmap >> and the computer-readable representation must be immediately erased. > > Doesn?t help much to try that, I would say. But feel free to try ... > >> 3. Only the information I need should be displayed. > > You need a Do-What-I-Mean system for that. > >> 4. >> The bitmap must not be updated automatically >> (the containing window must not display it >> when it is in the background, whatever it means). >> (It would be best to forget the bitmap altogether >> and regenerate it upon request, >> but it seems to be a hard thing to do >> because the gpg output stream is not scrollable backwards). > > Use Overlay mode to display it. > >> >> 5. >> The bitmap itself should not make it to any persistent medium >> and it should be scrambled, if possible, in the volatile memory. > > Implement the viewer in the graphic card, with the CUDA SDK or something > similar. > >> 6. >> It should not be possible >> to make a snapshot of the graphic in the window >> with any programmatic means >> (you can of course make a picture of the screen with a camera). > > Overlay mode does that. > >> 7. >> If more information is requested, >> it should be displayed in small chunks. >> The program should be fully unaware >> of the content of the chunks that are not being displayed. > >> (That probably means a garbage-collected language cannot be used). > > I don?t understand why you need that. > I would suggest that you seperate the small chunks into seperated encrypted > files, to ensure that the reader only gets those chunks that you actually > decrypted. > >> 8. >> The application should be as lightweight as possible >> (for source code audit). > > Agreed. > >> Can you direct me to some implementation meeting these requirements? > > I think your specification isn?t complete yet. You forgot about half of the > requirements. > > I guess that: > > * You want a machine that seperates code from data (to be secure against > trojans, virii and other malware) > > * You want secure documents, that can?t change dynamically, or otherwise > contain invisible contents > > * You want a secure path to the user > > (and some more requirements that I forgot at the moment) > > What?s your budget for this small project? > > Best regards, > Philipp G?hring > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From SeidlS at schneider.com Wed Feb 6 22:28:49 2008 From: SeidlS at schneider.com (SeidlS at schneider.com) Date: Wed, 6 Feb 2008 15:28:49 -0600 Subject: SMIME vs PGP Message-ID: I am not a encryption expert, and need some help from the GnuPG user group. We have a new software product that has the capability of encrypting documents using SMIME. How common is SMIME and used outside of email clients? Is it compatible with the OpenPGP standard, and thus GnuPG? Is there a good website discussing the differences between the two standards? Thanks Scott Enterprise Integration Services This document, and any attachments therein, contains proprietary and confidential information that may not be disclosed without the prior written permission of Schneider National, Inc. and its subsidiaries. Unauthorized use or misuse of this information and its contents is strictly prohibited. Schneider National, Inc. vigorously protects its rights. From rjh at sixdemonbag.org Wed Feb 6 23:18:29 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 06 Feb 2008 16:18:29 -0600 Subject: SMIME vs PGP In-Reply-To: References: Message-ID: <47AA3235.3090905@sixdemonbag.org> SeidlS at schneider.com wrote: > I am not a encryption expert, and need some help from the GnuPG user > group. While you can probably get some good pointers here, if you're looking for an answer you can rely on you will either need to do a fair bit of homework or else contract with an outside information security consultant. Information security is a subtle subject and many people who claim to know things actually know very little about those things. I, of course, am no exception. > We have a new software product that has the capability of encrypting > documents using SMIME. How common is SMIME and used outside of email > clients? S/MIME support (note the slash) is built into virtually every proprietary email client as a standard feature, and is present in many of the open-source ones. Outlook, Thunderbird, Lotus Notes, Apple's Mail.app, and more, all support it out-of-the-box. S/MIME integration with mail clients is substantially better than OpenPGP's integration with mail clients. > Is it compatible with the OpenPGP standard, and thus GnuPG? On some level, theoretically, sure, given that S/MIME uses X.509 certificates, and X.509 certificates can be finessed into the Web of Trust. However, you will need a lot of elbow grease and a really big crowbar, and the resulting Frankenstein's Monster will not be pretty. I have never seen this done in practice. S/MIME and OpenPGP interoperability is, AFAIK, a theoretical chimera. > Is there a good website discussing the differences between the two > standards? I can't answer this without knowing what level of detail you're interested in, difference-wise. From an end-user perspective S/MIME and OpenPGP provide essentially identical capabilities. Slightly more involved than that, S/MIME and OpenPGP use many of the same algorithms. More involved than that, they handle all manner of internal things differently. If you want to come to a fairly comprehensive understanding of both, I would recommend reading RFC3852 ( http://tools.ietf.org/html/rfc3852 ) and RFC4880 ( http://tools.ietf.org/html/rfc4880 ). S/MIME is based upon the former, and OpenPGP is defined by the latter. From alex at bofh.net.pl Wed Feb 6 23:32:46 2008 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Wed, 6 Feb 2008 23:32:46 +0100 Subject: SMIME vs PGP In-Reply-To: References: Message-ID: <20080206223246.GC3595@hell.pl> On Wed, Feb 06, 2008 at 03:28:49PM -0600, SeidlS at schneider.com wrote: > I am not a encryption expert, and need some help from the GnuPG user group. That's why we are here. > We have a new software product that has the capability of encrypting > documents using SMIME. How common is SMIME and used outside of email > clients? Is it compatible with the OpenPGP standard, and thus GnuPG? Is > there a good website discussing the differences between the two standards? S/MIME is a PKI (as in X.509 standard) counterpart of some subset of OpenPGP standard (as defined in RFC 4880). OpenPGP defines a way to sign, encrypt and then format data for transmission or storage. Another standard, PGP/MIME, defines a way to ue OpenPGP capabilities within e-mail. OpenPGP uses its own format of keys with its own way how to decide to trust them. S/MIME is based on X.509 certificates (with its hierarchy of trust), and specifies only a way to sign and/or encrypt data within e-mail based MIME structure. A counterpart just to encrypt random data is called CMS (Cryptographic Message Syntax). S/MIME was based on PKCS#7, now is based on CMS (which was developed after first version of S/MIME), which now positions CMS as PKI counterpart to OpenPGP. To muddy waters further, there are other PKI based-standards, like XML-DSIG which aren't compatible with CMS or OpenPGP. GNU Privacy Guard 1.x talks only OpenPGP. GNU Privacy Guard 2.x talks OpenPGP and S/MIME, I'm not sure if it talks plain CMS. > This document, and any attachments therein, contains proprietary and > confidential information that may not be disclosed without the prior > written permission of Schneider National, Inc. and its subsidiaries. > Unauthorized use or misuse of this information and its contents is strictly > prohibited. Schneider National, Inc. vigorously protects its rights. This is a stupid footer to attach while posting to public mailing list. Alex -- JID: alex at hell.pl PGP: 0x46399138 od zwracania uwagi na detale s? lekarze, adwokaci, programi?ci i zegarmistrze -- Czerski From JPClizbe at tx.rr.com Wed Feb 6 23:48:08 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Wed, 06 Feb 2008 16:48:08 -0600 Subject: SMIME vs PGP In-Reply-To: References: Message-ID: <47AA3928.9090609@tx.rr.com> SeidlS at schneider.com wrote: > I am not a encryption expert, and need some help from the GnuPG user group. > > We have a new software product that has the capability of encrypting > documents using SMIME. How common is SMIME and used outside of email > clients? Is it compatible with the OpenPGP standard, and thus GnuPG? Is > there a good website discussing the differences between the two standards? S/MIME is common in a majority of email clients (http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients#Features ), much more so than its use. The Wikipedia S/MIME article summarizes some of the more common obstacles to S/MIME adoption as well as a few caveats. S/MIME itself is not used outside of email apps, however the certificates (keys), sometimes referred to as X.509 certificates, S/MIME uses are able to be used by other apps, eg for digital signatures in applications such as Open Office, MS Office and Adobe Acrobat, and for encryption in IM programs such as AIM. The creation and management of the certificates themselves, the Certificate Authority (CA), is usually the major task of establishing an enterprise PKI. Regards. -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT com Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 658 bytes Desc: OpenPGP digital signature URL: From pg at futureware.at Thu Feb 7 00:11:25 2008 From: pg at futureware.at (Philipp =?utf-8?q?G=C3=BChring?=) Date: Thu, 7 Feb 2008 00:11:25 +0100 Subject: SMIME vs PGP In-Reply-To: <47AA3928.9090609@tx.rr.com> References: <47AA3928.9090609@tx.rr.com> Message-ID: <200802070011.26393.pg@futureware.at> Hi, > S/MIME itself is not used outside of email apps, however the certificates > (keys), sometimes referred to as X.509 certificates, S/MIME uses are able > to be used by other apps, eg for digital signatures in applications such as > Open Office, OpenOffice uses XML-DSig, not S/Mime. > and Adobe Acrobat, The PDF Format uses PKCS#7, not S/Mime. XML-DSig, PKCS#7 and S/Mime are all using X.509 certificates. (And even CMS, but I haven?t seen that one in practice yet) Best regards, Philipp G?hring From wk at gnupg.org Thu Feb 7 16:03:38 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Feb 2008 16:03:38 +0100 Subject: SMIME vs PGP In-Reply-To: <200802070011.26393.pg@futureware.at> ("Philipp =?utf-8?Q?G?= =?utf-8?Q?=C3=BChring=22's?= message of "Thu, 7 Feb 2008 00:11:25 +0100") References: <47AA3928.9090609@tx.rr.com> <200802070011.26393.pg@futureware.at> Message-ID: <87tzkklsfp.fsf@wheatstone.g10code.de> On Thu, 7 Feb 2008 00:11, pg at futureware.at said: > OpenOffice uses XML-DSig, not S/Mime. Oh dear. > XML-DSig, PKCS#7 and S/Mime are all using X.509 certificates. > (And even CMS, but I haven?t seen that one in practice yet) CMS is the same as PKCS#7, it is just a new name with some minor semantic changes. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From wk at gnupg.org Thu Feb 7 16:05:54 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Feb 2008 16:05:54 +0100 Subject: SMIME vs PGP In-Reply-To: <20080206223246.GC3595@hell.pl> (Janusz A. Urbanowicz's message of "Wed, 6 Feb 2008 23:32:46 +0100") References: <20080206223246.GC3595@hell.pl> Message-ID: <87prv8lsbx.fsf@wheatstone.g10code.de> On Wed, 6 Feb 2008 23:32, alex at bofh.net.pl said: > GNU Privacy Guard 1.x talks only OpenPGP. GNU Privacy Guard 2.x talks > OpenPGP and S/MIME, I'm not sure if it talks plain CMS. GnuPG (gpgsm) support plain CMS and no S/MIME. S/MIME requires all that MIME stuff. It is the same as with OpenPGP vs. PGP/MIME; GnuPG (gpg or gpg2) does not directly support PGP/MIME. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From vedaal at hush.com Thu Feb 7 17:03:02 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Thu, 07 Feb 2008 11:03:02 -0500 Subject: OT // truecrypt 5 // whole disk encryption Message-ID: <20080207160303.19B651A0039@mailserver8.hushmail.com> truecrypt 5 was released Feb/5 http://www.truecrypt.org/docs/?s=version-history it offers whole disk encryption, (except for the boot partition with the mbr or grub) have not yet tried it with grub and dual booting, but it looks 'promising' (now if they could get it to work with a blackberry ... vedaal any ads or links below this message are added by hushmail without -- Click to get 150,000 in student loans and find the lowest rates http://tagline.hushmail.com/fc/Ioyw6h4d7FbHSnjUBiaNcF6fn0lDWVMsxILIjCtH390RCflBga3x51/ my endorsement or awareness of the nature of the link From bruno.capeleto at free.fr Fri Feb 8 02:49:04 2008 From: bruno.capeleto at free.fr (Bruno CAPELETO) Date: Fri, 08 Feb 2008 02:49:04 +0100 Subject: passphrase works ONLY with enigmail Message-ID: <47ABB510.3060002@free.fr> Dear all, I'm becoming crazy and begging for help. I generated a pair of key one month ago with gpg command line, I use GPG with Thunderbird/Enigmail. Everything fine until I tried gpg with gajim : my passphrase was systematically refused. As my passphrase contains accent (eg "? la ville, j'y vais de suite"), I thought I should try to change it to remove the accent (eg "a la ville, j'y vais de suite"). Then I realized that my passphrase is also refused on the command line ! I tried to change the locale (UTF-8, ISO-8859-1...) with no success. I also tried gpa with no success. As a conclusion, I can't change my passphrase, because it is accepted ONLY in Enigmail ! Please help... Bruno From bruno.capeleto at free.fr Fri Feb 8 03:38:39 2008 From: bruno.capeleto at free.fr (Bruno CAPELETO) Date: Fri, 08 Feb 2008 03:38:39 +0100 Subject: passphrase works ONLY with enigmail Message-ID: <47ABC0AF.3070200@free.fr> I found the solution. I had a carefull look at Enigmail Debug Console. I found out some weird characters, that were only reproducible in a console in X mode when default locale was ISO-8859-1. In addition, the option --charset utf8 was used with gpg. I fixed to this locale, restarted X, and use gpg --charset utf8 in a console in X (didn't work outside X!) to change my passphrase. Maybe this can help someone else... Bruno CAPELETO a ?crit : > Dear all, > > I'm becoming crazy and begging for help. > > I generated a pair of key one month ago with gpg command line, I use GPG > with Thunderbird/Enigmail. > > Everything fine until I tried gpg with gajim : my passphrase was > systematically refused. > > As my passphrase contains accent (eg "? la ville, j'y vais de suite"), I > thought I should try to change it to remove the accent (eg "a la ville, > j'y vais de suite"). > > Then I realized that my passphrase is also refused on the command line ! > > I tried to change the locale (UTF-8, ISO-8859-1...) with no success. > I also tried gpa with no success. > > As a conclusion, I can't change my passphrase, because it is accepted > ONLY in Enigmail ! > > Please help... > > Bruno > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From rodhash at gmail.com Fri Feb 8 15:30:13 2008 From: rodhash at gmail.com (Rodrigo Hashimoto) Date: Fri, 8 Feb 2008 12:30:13 -0200 Subject: Key Server Message-ID: Hello everybody, Which key-server can I use?? And how? Thanks -- Rodrigo Hashimoto *"...amar n?o ? olhar um para o outro, mas olharem ambos na mesma dire??o". Vivam juntos um belo ideal. Saint Exup?ry, Livro: "Pequeno Pr?ncipe" * -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Fri Feb 8 16:55:57 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 08 Feb 2008 09:55:57 -0600 Subject: Key Server In-Reply-To: References: Message-ID: <47AC7B8D.7020302@sixdemonbag.org> Rodrigo Hashimoto wrote: > Which key-server can I use?? Add "keyserver x-hkp://pool.sks-keyservers.net" to your gpg.conf file. From sinux at fsfe.org Fri Feb 8 21:07:21 2008 From: sinux at fsfe.org (Sebastien Chassot) Date: Fri, 08 Feb 2008 21:07:21 +0100 Subject: How know who is a file encrypted for ? Message-ID: <1202501241.1029.22.camel@dell.sinux.seb> Hi, I can't find how list who's a file encrypted for ? I've encrypt several files with different recipients, but I don't remember which. In general how can I make difference between file encrypted for one user, several user ? symmetric encrypted, asymmetric ? Thank you. -- Sebastien From dshaw at jabberwocky.com Fri Feb 8 21:23:02 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 8 Feb 2008 15:23:02 -0500 Subject: How know who is a file encrypted for ? In-Reply-To: <1202501241.1029.22.camel@dell.sinux.seb> References: <1202501241.1029.22.camel@dell.sinux.seb> Message-ID: <20080208202301.GB17716@jabberwocky.com> On Fri, Feb 08, 2008 at 09:07:21PM +0100, Sebastien Chassot wrote: > Hi, > > I can't find how list who's a file encrypted for ? I've encrypt several > files with different recipients, but I don't remember which. > > In general how can I make difference between file encrypted for one > user, several user ? symmetric encrypted, asymmetric ? Just run 'gpg' on the file, and don't give a passphrase. It prints all the possible recipients. David From jeandavid8 at verizon.net Sat Feb 9 18:54:44 2008 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Sat, 09 Feb 2008 12:54:44 -0500 Subject: How true can this be? In-Reply-To: <20080128115827.GB9019@hell.pl> References: <15112665.post@talk.nabble.com> <20080127183904.GA9019@hell.pl> <479CF63A.9050402@bellsouth.net> <20080128115827.GB9019@hell.pl> Message-ID: <47ADE8E4.70603@verizon.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Janusz A. Urbanowicz wrote: > On Sun, Jan 27, 2008 at 04:23:06PM -0500, John W. Moore III wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> - -------- Original Message -------- >> Subject: Re: How true can this be? >> From: Janusz A. Urbanowicz >> To: Raygene >> Cc: gnupg-users at gnupg.org >> Date: Sunday, January 27, 2008 1:39:04 PM >> >> >>> if a), then b) would land him in jail, quickly >> More likely a fatal traffic accident or victim of a street mugging with >> similar outcome. People communicate in and from Jails. > > Blabbering about classified stuff is a breach of security procedures and > NDA-s, that leads to administrative action, prosecution and usually jail > sentence (or a hefty fine). Long ago I had a secret security clearance. The secrets were laughable, but I have never disclosed them. Mine had nothing to do with encryption. When getting the clearance, I had to read some of the laws that pertained. In addition to jail and fines, another punishment option was death. But I imagine it would be done officially. > > The approach you mention would be probably used on someone who would like to > play the game (as in sell the info to another country), not for some random > blabberer. > > Alex - -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key: 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jersey http://counter.li.org ^^-^^ 12:50:01 up 16 days, 2:36, 2 users, load average: 5.02, 5.03, 4.68 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org iD8DBQFHrejkPtu2XpovyZoRAgC9AJ9DknvNBSUr0NU7jxdHUr3PGWHKYACgg2Lo eVMtegDw54+UQDnlz+fGK+8= =YzkQ -----END PGP SIGNATURE----- From kfitzner at excelcia.org Sun Feb 10 00:45:22 2008 From: kfitzner at excelcia.org (Kurt Fitzner) Date: Sat, 09 Feb 2008 15:45:22 -0800 Subject: GPGee development restarted - need bugs Message-ID: <47AE3B12.9060301@excelcia.org> After almost two years of neglect, I've got time enough to start working on GPGee again. I was informed some time ago that work is underway to replace it. I don't see a replacement yet, so I'm going to put out a release that fixes some bugs and incorporates a French translation I was given. This can act as a stop-gap until the replacement is completed. If the replacement is going to be some time yet, I'll also entertain requests for new features. Bugs I've fixed so far include: - Disappearing keys (requires GnuPG >= 1.4 to fix) - Verifications of signatures made with expired subkeys not showing the correct expiry date of the subkey and giving incorrect warnings of signatures being made after the key expired - Password requests not showing correct data (type & size) for the subkey identified - SHA224 signatures not being correctly identified If you are still using GPGee (or want to) and have experienced bugs not mentioned above, please respond here, on a thread I've made in the GPGee forums (http://www.excelcia.org/modules.php?name=Forums&file=viewforum&f=1), or by personal e-mail to me. I apologize for any previous e-mails that haven't been replied to. Regards, Kurt Fitzner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 313 bytes Desc: OpenPGP digital signature URL: From kevhilton at gmail.com Sun Feb 10 06:29:08 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sat, 9 Feb 2008 23:29:08 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <47A7F022.5030807@sixdemonbag.org> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> <96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com> <47A7F022.5030807@sixdemonbag.org> Message-ID: <96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com> >Twofish is almost entirely abandoned nowadays, but it still exists in >PGP and GnuPG. Once a bad decision is made in engineering, the >engineers are stuck supporting it forever. Is this statement really true or just opinion? Bruce Schneier is one of my favorite cryptoanalysts. From rjh at sixdemonbag.org Sun Feb 10 08:35:46 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 10 Feb 2008 01:35:46 -0600 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com> References: <96c450350802032148h35bbea77vbe658f77d5127c8e@mail.gmail.com> <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> <96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com> <47A7F022.5030807@sixdemonbag.org> <96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com> Message-ID: <47AEA952.2070206@sixdemonbag.org> Kevin Hilton wrote: > Is this statement really true or just opinion? Bruce Schneier is one > of my favorite cryptoanalysts. Bruce recommends against using Twofish for crypto applications. He has never backed off from either of two claims: 1. Twofish is a secure cipher that would have made an excellent AES. 2. People should use AES for symmetric crypto needs. He has said #1 many times and keeps a page on his site devoted to the most recent research into Twofish. He has said #2 many times, particularly in his book _Practical Cryptography_. From dshaw at jabberwocky.com Sun Feb 10 15:32:27 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Feb 2008 09:32:27 -0500 Subject: Can you clarify when data compression is used? In-Reply-To: <96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com> References: <47A6B9C2.2000905@sixdemonbag.org> <96c450350802032317m688c4954v471d576d152c6fbb@mail.gmail.com> <96c450350802032317o592dd239x1c5fbc46219d4f79@mail.gmail.com> <47A6C33E.9010300@sixdemonbag.org> <96c450350802040535i6f0a9a9dl34855a6ee6020047@mail.gmail.com> <47A7601E.8000107@sixdemonbag.org> <96c450350802041926u41da421ei6c3cf9c2bd8723a5@mail.gmail.com> <96c450350802042018v6c2c0143k81b02a78bbe6089d@mail.gmail.com> <47A7F022.5030807@sixdemonbag.org> <96c450350802092129x60ddeecy58ae8ba4dade0773@mail.gmail.com> Message-ID: <20080210143227.GA11807@jabberwocky.com> On Sat, Feb 09, 2008 at 11:29:08PM -0600, Kevin Hilton wrote: > >Twofish is almost entirely abandoned nowadays, but it still exists in > >PGP and GnuPG. Once a bad decision is made in engineering, the > >engineers are stuck supporting it forever. > > Is this statement really true or just opinion? Bruce Schneier is one > of my favorite cryptoanalysts. It's basically true, at least in the context of OpenPGP. Note that the statement doesn't say that Twofish is insecure. It's just that when AES came along, it eclipsed many/most of the ciphers with similar capabilities. >From the perspective of the researcher who wants to attack a cipher, they'll attack AES because lots of people use it. From the perspective of the user of crypto, they'll use AES because of all the research on it. Repeat this cycle enough times, and you can see why Twofish isn't used much. David From program.spe at home.pl Tue Feb 5 19:10:35 2008 From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=) Date: Tue, 05 Feb 2008 19:10:35 +0100 Subject: Safe decryption with GnuPG? In-Reply-To: <47A89E86.9010800@sixdemonbag.org> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <47A89E86.9010800@sixdemonbag.org> Message-ID: <1202235036.6608.29.camel@a1dmin.vola.spe.com.pl> Dnia 05-02-2008, Wt o godzinie 11:36 -0600, Robert J. Hansen pisze: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Krzysztof ?elechowski wrote: > > The decrypted information must not make it to any persistent medium > > GnuPG is almost certainly the wrong tool for your job. GnuPG has little > control over low-level operating systems details like swap files. It is > possible for cleartext to be stored in some manner. GnuPG claims it locks memory pages so that they are never dumped. > > > (I understand gpg '-d' already guarantees it > > as long as it manages the decrypted text, > > but what happens after it leaves gpg?) > > [many other requirements snipped] > > Many of your requirements belong in the application stack alongside or > above GnuPG, but are pretty much unrelated to GnuPG. After it leaves > GnuPG it's no longer GnuPG's problem. I just thought the answer would be quick, straightforward and positive, and that there should exist such highly confidential software on top of GnuPG. Since nothing of this sort was mention on the Web page, I dared ask. > Many of your requirements are > also impossible to meet. I don't mean "impossible" as in "it would > require a lot of engineering", I mean "impossible" as in "it's like > violating the Second Law of Thermodynamics". Well, it seems it is impossible to prohibit taking a screen shot; hopefully a user mode application cannot do this without a kernel driver. > > > Can you direct me to some implementation meeting these requirements? > > There exists no such implementation. Thanks a lot, mine is going to be the first :-) (although I am quite surprised because the requirements are quite obvious to me; for what is the benefit of encryption when a bad robot can read over your shoulder?) For the time being, I am inclined to implement the following scheme: 1. Open a new console session. 2. Run gpg '-d' | fgrep 3. Read the result. 4. Close the session. This obviously does not meet the requirements because the text mode console driver stores the content of the console in a character buffer and does not do all the funny things with scrambling and all. The mitigating factor is, as always, that the session is short-lived. Chris From program.spe at home.pl Wed Feb 6 09:14:58 2008 From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=) Date: Wed, 06 Feb 2008 09:14:58 +0100 Subject: Safe decryption with GnuPG? In-Reply-To: <200802060222.10599.pg@futureware.at> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <200802060222.10599.pg@futureware.at> Message-ID: <1202285698.6645.17.camel@a1dmin.vola.spe.com.pl> Thanks a lot for the keywords, the hints and the missing parts. Indeed, I hoped that such an application did not need a custom implementation because IMHO encrypting information is useless if you cannot view the information without exposure to eavesdropping or tracing. I have to review what is available and what is needed before I can come up with a budget. Specific comments below. Thx, Chris Dnia 06-02-2008, ?r o godzinie 02:22 +0100, Philipp G?hring pisze: > Hi, > > > 1. > > The decrypted information must not make it to any persistent medium > > (I understand gpg '-d' already guarantees it > > as long as it manages the decrypted text, > > but what happens after it leaves gpg?) > > Use a full-disc encryption system for all your persistent media. That is overkill if it only can be avoided. > > > 2. > > The decrypted text must not be stored in volatile memory > > any longer than it is needed. > > You can use TaintedBochs or TaintedQemu to investigate that. > > > In particular, it should be converted to a human-viewable bitmap > > and the computer-readable representation must be immediately erased. > > Doesn?t help much to try that, I would say. But feel free to try ... > > > 3. Only the information I need should be displayed. > > You need a Do-What-I-Mean system for that. In this particular case, Do-What-I-Mean means displaying only matching information ? la fgrep. The keywords are not secret. > > 7. > > If more information is requested, > > it should be displayed in small chunks. > > The program should be fully unaware > > of the content of the chunks that are not being displayed. > > > (That probably means a garbage-collected language cannot be used). > > I don?t understand why you need that. > I would suggest that you seperate the small chunks into seperated encrypted > files, to ensure that the reader only gets those chunks that you actually > decrypted. I shall consider that but I do not like this idea at the first glance; I am afraid there would be some maintenance overhead. > > > 8. > > The application should be as lightweight as possible > > (for source code audit). > > Agreed. > > > Can you direct me to some implementation meeting these requirements? > > I think your specification isn?t complete yet. You forgot about half of the > requirements. > > I guess that: > > * You want a machine that seperates code from data (to be secure against > trojans, virii and other malware) > > * You want secure documents, that can?t change dynamically, or otherwise > contain invisible contents I thought GnuPG-encrypted files are immutable, aren't they? > > * You want a secure path to the user > > (and some more requirements that I forgot at the moment) > > What?s your budget for this small project? > > Best regards, > Philipp G?hring > From program.spe at home.pl Wed Feb 6 16:48:17 2008 From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=) Date: Wed, 06 Feb 2008 16:48:17 +0100 Subject: Safe decryption with GnuPG? In-Reply-To: References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <200802060222.10599.pg@futureware.at> Message-ID: <1202312897.6645.46.camel@a1dmin.vola.spe.com.pl> Dnia 06-02-2008, ?r o godzinie 10:03 -0500, Steve Revilak pisze: > > I have a file that I encrypted for myself > > and I want to read some information from it. > > The file is a text file and I need to read several lines of it. > > > > The following requirements must be met: > > I was going to suggest > > gpg --decrypt file.gpg | grep "interesting stuff" | banner | less >/dev/null > > but I'll try to be more serious. :) Yep, that is my current workaround, sort of, in a dedicated xterm. > > Out of curiosity, what kind of a threat vector are you anticipating? > By reading your list of requirements, the ones I've extracted are > > * Access to sensitive data via system memory is a threat. > > * Access to sensitive data via the file system (i.e. by examining > swap space) is a threat. > > * Access to sensitive data via the graphics system framebuffer is a > threat. > > * Access to sensitive data via visual observation (someone sees the > text on the screen, or takes a picture of the text on the screen) > is a threat. > That is basically what I had in mind. > As someone else mentioned, this brings up a lot of issues in the area > of trusting the hardware, trusting the operating system and so fourth. > Granted, they are interesting issues, but my gut instinct tells me > that this problem might be easier to solve with physical security. That requires a specialised hardware device; I am more interested in a software solution for the time being because I think it is more convenient and versatile. Of course, if I would have to guard something really dangerous, like ICBM launcher codes, I would choose a hardware solution (and I would not ask the members of this mailing list). > > For example, the first three threats imply that the data has to leave > the system where it is being viewed. Removing network access to that > system (unplug the ethernet cable, remove any wireless/bluetooth > hardware), would mitigate those threats, no? Certainly, but it is not always possible temporarily, and it is almost always impossible once and for all. And unplugging everything for a short time does not really help. > > As for threat #4, if you're viewing the data in a small, bare-walled, > locked room, you'd be able to tell (a) whether someone else was in the > room looking over your shoulder or (b) whether there was a camera > being pointed at your screen. I did not intend to address this problem at all. > > And if you don't trust the isolated computer in the small locked room, > you could even go as far as removing its hard drive -- you'd walk in > with a bootable CD that contained your encrypted file, boot up, read > what you needed, then halt. Good point, it can even be a Free DOS floppy disk with a RAM disk driver. I have not thought of that. Thanks, Chris From texaskilt at yahoo.com Wed Feb 6 20:35:14 2008 From: texaskilt at yahoo.com (Texaskilt) Date: Wed, 6 Feb 2008 11:35:14 -0800 (PST) Subject: Corporate use of gnupg Message-ID: <15312177.post@talk.nabble.com> Apologies if this has already been asked. Honestly, I did my homework and looked in the archives! I am wanting to setup up users to use GnuPG for encrypting email, mainly for internal e-mail. Unfortunately, the "powers-that-be" want everyone that encrypts an email to also encrypt it to the "corporate secret key". Their reasoning is that if a person leaves, they want to have access to the old emails in case there is a "business critical" email in there. Is there a way to "force" users to encrypt to a corporate key, in addition to the receipient's key? Thanks, TK -- View this message in context: http://www.nabble.com/Corporate-use-of-gnupg-tp15312177p15312177.html Sent from the GnuPG - User mailing list archive at Nabble.com. From Juha.Tuomala at iki.fi Thu Feb 7 17:36:55 2008 From: Juha.Tuomala at iki.fi (Juha Tuomala) Date: Thu, 7 Feb 2008 18:36:55 +0200 Subject: Kmail/gnupg fails to encrypt on F8 Message-ID: <200802071836.55497.Juha.Tuomala@iki.fi> Any glues which might cause this? https://bugzilla.redhat.com/show_bug.cgi?id=427500 Br, Tuju PS: I'm not subscribing the list. -- Varo hattup?isi? autoilijoita. From dshaw at jabberwocky.com Sun Feb 10 20:57:26 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Feb 2008 14:57:26 -0500 Subject: Corporate use of gnupg In-Reply-To: <15312177.post@talk.nabble.com> References: <15312177.post@talk.nabble.com> Message-ID: <20080210195726.GC12706@jabberwocky.com> On Wed, Feb 06, 2008 at 11:35:14AM -0800, Texaskilt wrote: > > Apologies if this has already been asked. Honestly, I did my homework and > looked in the archives! > > I am wanting to setup up users to use GnuPG for encrypting email, mainly for > internal e-mail. > > Unfortunately, the "powers-that-be" want everyone that encrypts an email to > also encrypt it to the "corporate secret key". Their reasoning is that if a > person leaves, they want to have access to the old emails in case there is a > "business critical" email in there. This is essentially the rationale behind the "ADK" (additional decryption key) feature of PGP. > Is there a way to "force" users to encrypt to a corporate key, in addition > to the receipient's key? It depends on how strong the term "force" is. Even in PGP, the ADK system can be circumvented if the person tries hard enough. If you trust your employees to not hack you, then you can just stick a "encrypt-to (the keyid)" in everyone's gpg.conf file and give everyone a copy of the corporate public key. Note that this isn't safe because of the crypto math. It's "safe" because you can fire people that don't do it ;) David From Lance at TheHaverkamps.net Sun Feb 10 21:47:38 2008 From: Lance at TheHaverkamps.net (Lance W. Haverkamp) Date: Sun, 10 Feb 2008 20:47:38 +0000 Subject: Signing Multiple Files Message-ID: <47AF62EA.1080503@TheHaverkamps.net> Having looked through much documentation & some trial and error; it seems there is no way to sign (detached) multiple files. I need to sign dozens (or hundreds) of photos at a time. I am *not* a programmer. I did coble together a (Linux) script: #!/bin/bash for i in $( ls ); do gpg -b $i done There must be a better way, but this will sign everything in a folder. I don't code enough to be able to tell the file browser to sign multiple selected files recursively. Am I missing something obvious here? -- Thanks! Lance W. Haverkamp Lance at TheHaverkamps.net Contact & encryption info: http://thehaverkamps.net/?Lance:Contact_Me <>< <>< <>< *** This email has been stamped using Penny Post. Stamping email helps combat spam. Find out more about stamping your email at: http://pennypost.sourceforge.net From kevhilton at gmail.com Sun Feb 10 23:47:37 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sun, 10 Feb 2008 16:47:37 -0600 Subject: Are DSA2 signing keys backwards compatible? Message-ID: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> Are DSA2 signing keys (or simply DSA keys that are larger than 1024 bits) backwards compatible with older GnuPG versions prior to 1.48? -- Kevin Hilton From JPClizbe at tx.rr.com Mon Feb 11 01:15:42 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Sun, 10 Feb 2008 18:15:42 -0600 Subject: Signing Multiple Files In-Reply-To: <47AF62EA.1080503@TheHaverkamps.net> References: <47AF62EA.1080503@TheHaverkamps.net> Message-ID: <47AF93AE.5060608@tx.rr.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lance W. Haverkamp wrote: > Having looked through much documentation & some trial and error; it > seems there is no way to sign (detached) multiple files. I need to sign > dozens (or hundreds) of photos at a time. I am *not* a programmer. > > I did coble together a (Linux) script: > > #!/bin/bash > for i in $( ls ); do > gpg -b $i > done > > > There must be a better way, but this will sign everything in a folder. > I don't code enough to be able to tell the file browser to sign multiple > selected files recursively. > > Am I missing something obvious here? That will sign everything in a given directory, but won't recurse. 'ls -R' will recurse, but won't give you filenames in a usable format to pass It will also attempt to sign everything in addition to the images find . -name "*.jpeg" -print is probably more along the lines of what you're looking for instead of ls above for i in $(find . -name "*.jpeg" -print \;) do gpg -b $i -o ${i}.sig done You may wish to use one of the --passphrase options,eg '--passphrase-file ' or '--passphrase ', or temporarily remove the passphrase from the signing key to spare yourself the 'joy' of typing the passphrase potentially 100s of times. Some reason you moved the thread to GnuPG-Users from PGP-Basics? - -- John P. Clizbe Inet: John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. PGP/GPG KeyID: 0x608D2A10/0x18BB373A "what's the key to success?" / "two words: good decisions." "what's the key to good decisions?" / "one word: experience." "how do i get experience?" / "two words: bad decisions." "Just how do the residents of Haiku, Hawai'i hold conversations?" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (WinXP Pent3) Comment: When cryptography is outlawed, b25seSBvdXRsYXdzIHdpbGwgdXNlIG Comment: Be part of the ?33t ECHELON -- Use Strong Encryption. Comment: It's YOUR right - for the time being. Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iJwEAQECAAYFAkevk6cACgkQvh+YERi7NzrAJwP+L9RfQp371S7a+0bfRECYclf0 5cZKVcK2GlYrLbKTooAFMEnA4hAy8tFYnASQiOgIG/b3a3N2dp71zjrwhbOWq30I uECx85/KN79ibeDbkbeF3c2M36c2XX3vT12v2zqh+o6NKbFZoEd3RYG+GqC7keXd VhMuTUod8sESX8Tr/K2IRgQBEQIABgUCR6+TpwAKCRAdBKxKYI0qEBlDAJkBoh4g yXxfxg59pPg9Owmu+MOWLACgzLyPuL8wjpZr7tpDt8MIXpRH//g= =6N+0 -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Feb 11 02:15:49 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Feb 2008 20:15:49 -0500 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> Message-ID: <20080211011549.GD12706@jabberwocky.com> On Sun, Feb 10, 2008 at 04:47:37PM -0600, Kevin Hilton wrote: > Are DSA2 signing keys (or simply DSA keys that are larger than 1024 > bits) backwards compatible with older GnuPG versions prior to 1.48? Basically, no. It's the main reason why --enable-dsa2 is off by default. David From kevhilton at gmail.com Mon Feb 11 03:30:24 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sun, 10 Feb 2008 20:30:24 -0600 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> Message-ID: <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> Just to clarify for some other users, What version of GnuPG were the DSA2 keys (or longer DSA signing keys) and the additional SHA hashes introduced? A little of topic, but I'm predicting a future foreseeable bump in the road when the Secure Hash Standard is named in 2011 (or whenever the recent NIST hash analysis is concluded). I guess however the personal-hash-preferences would bypass this problem and default to SHA1 if a new hash (or series of new hashes) is introduced. Hopefully md5 support is abandoned, however I guess for historical purposes this would be unlikely to happen. Even more challenging will be when longer DSA keys become the de-facto standard. I would guess there is not any similar workaround. I guess users of older GnuPG versions would simply have to upgrade. From kevhilton at gmail.com Mon Feb 11 03:48:13 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sun, 10 Feb 2008 20:48:13 -0600 Subject: Authenticate capability of DSA or RSA signing keys Message-ID: <96c450350802101848k2fb778b0q606c1f3e558b7974@mail.gmail.com> When I perform a gpg --expert --gen-key Im given the following options: Please select what kind of key you want: (1) DSA and Elgamal (default) (2) DSA (sign only) (3) DSA (set your own capabilities) (5) RSA (sign only) (7) RSA (set your own capabilities) Your selection? If I select either 3 or 7, Im given the choice similar to below (note the following was produced with option #3): Possible actions for a DSA key: Sign Certify Authenticate Current allowed actions: Sign Certify (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished I believe I'm aware of the signing capabilities, but how does Certify differ from Authenticate? Obviously I'm confused on the meaning of Certify vs Authenticate. I thought the public DSA signing key did certification/authentication whereas the private DSA key performed the signing. Thanks for any explanation! -- Kevin Hilton From dshaw at jabberwocky.com Mon Feb 11 04:01:42 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Feb 2008 22:01:42 -0500 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> Message-ID: <20080211030142.GE12706@jabberwocky.com> On Sun, Feb 10, 2008 at 08:30:24PM -0600, Kevin Hilton wrote: > Just to clarify for some other users, > > What version of GnuPG were the DSA2 keys (or longer DSA signing keys) > and the additional SHA hashes introduced? They were not introduced at the same time. As you said in your earlier mail, DSA2 was introduced in 1.4.8. The new SHA hashes were introduced in the 1.3.x development series. All 1.4 and later GPGs (including the 2.x series) have them. > A little of topic, but I'm predicting a future foreseeable bump in the > road when the Secure Hash Standard is named in 2011 (or whenever the > recent NIST hash analysis is concluded). I guess however the > personal-hash-preferences would bypass this problem and default to > SHA1 if a new hash (or series of new hashes) is introduced. It doesn't work that way. SHA-1 doesn't even work with DSA2 keys. DSA2 doesn't mean "a bigger DSA key". It means "a bigger hash with a bigger DSA key". DSA2 allows for any hash size that is equal to or greater than the hash size that was used when generating the key. Thus, for example, it is legal (albeit silly) to use SHA-512 with a old DSA key (which uses a 160-bit hash). We just truncate to fit. There is no special magic with the new hashes - once they exist, we'll use them. > Hopefully md5 support is abandoned, however I guess for historical > purposes this would be unlikely to happen. Have you tried using MD5 recently? > Even more challenging will be when longer DSA keys become the de-facto > standard. I would guess there is not any similar workaround. I guess > users of older GnuPG versions would simply have to upgrade. This is not how it works. There is nothing becoming de-facto here. Longer DSA keys are the de-jure standard today, and people are just going to have to upgrade. David From dshaw at jabberwocky.com Mon Feb 11 04:08:46 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Feb 2008 22:08:46 -0500 Subject: Authenticate capability of DSA or RSA signing keys In-Reply-To: <96c450350802101848k2fb778b0q606c1f3e558b7974@mail.gmail.com> References: <96c450350802101848k2fb778b0q606c1f3e558b7974@mail.gmail.com> Message-ID: <20080211030846.GF12706@jabberwocky.com> On Sun, Feb 10, 2008 at 08:48:13PM -0600, Kevin Hilton wrote: > When I perform a > > gpg --expert --gen-key > > Im given the following options: > > Please select what kind of key you want: > (1) DSA and Elgamal (default) > (2) DSA (sign only) > (3) DSA (set your own capabilities) > (5) RSA (sign only) > (7) RSA (set your own capabilities) > Your selection? > > If I select either 3 or 7, Im given the choice similar to below (note > the following was produced with option #3): > Possible actions for a DSA key: Sign Certify Authenticate > Current allowed actions: Sign Certify > > (S) Toggle the sign capability > (A) Toggle the authenticate capability > (Q) Finished > > I believe I'm aware of the signing capabilities, but how does Certify > differ from Authenticate? Obviously I'm confused on the meaning of > Certify vs Authenticate. I thought the public DSA signing key did > certification/authentication whereas the private DSA key performed the > signing. The public/private question is not relevant here. Sign = sign some data Certify = sign a key Authenticate = prove you are you Authenticate is used for things like using an OpenPGP key for ssh. David From dshaw at jabberwocky.com Mon Feb 11 04:10:59 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Feb 2008 22:10:59 -0500 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <20080211030142.GE12706@jabberwocky.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <20080211030142.GE12706@jabberwocky.com> Message-ID: <20080211031058.GG12706@jabberwocky.com> On Sun, Feb 10, 2008 at 10:01:42PM -0500, David Shaw wrote: > On Sun, Feb 10, 2008 at 08:30:24PM -0600, Kevin Hilton wrote: > > Just to clarify for some other users, > > > > What version of GnuPG were the DSA2 keys (or longer DSA signing keys) > > and the additional SHA hashes introduced? > > They were not introduced at the same time. As you said in your > earlier mail, DSA2 was introduced in 1.4.8. The new SHA hashes were > introduced in the 1.3.x development series. All 1.4 and later GPGs > (including the 2.x series) have them. I should clarify this. DSA2 was enabled as part of standard OpenPGP in 1.4.8. We knew it was coming, though, so it exists as far back as 1.4.4 (June 2006). David From kevhilton at gmail.com Mon Feb 11 05:13:11 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sun, 10 Feb 2008 22:13:11 -0600 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> Message-ID: <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> >It doesn't work that way. SHA-1 doesn't even work with DSA2 keys. >DSA2 doesn't mean "a bigger DSA key". It means "a bigger hash with a >bigger DSA key". DSA2 allows for any hash size that is equal to or >greater than the hash size that was used when generating the key. >Thus, for example, it is legal (albeit silly) to use SHA-512 with a >old DSA key (which uses a 160-bit hash). We just truncate to fit. So just to clarify -- A 3096 bit DSA signing key could only be used with the SHA-512 hash? Thanks for the explanation! From dshaw at jabberwocky.com Mon Feb 11 05:33:59 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Feb 2008 23:33:59 -0500 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> Message-ID: <20080211043359.GA15319@jabberwocky.com> On Sun, Feb 10, 2008 at 10:13:11PM -0600, Kevin Hilton wrote: > >It doesn't work that way. SHA-1 doesn't even work with DSA2 keys. > >DSA2 doesn't mean "a bigger DSA key". It means "a bigger hash with a > >bigger DSA key". DSA2 allows for any hash size that is equal to or > >greater than the hash size that was used when generating the key. > >Thus, for example, it is legal (albeit silly) to use SHA-512 with a > >old DSA key (which uses a 160-bit hash). We just truncate to fit. > > So just to clarify -- > A 3096 bit DSA signing key could only be used with the SHA-512 hash? No. A 3096 bit DSA key that uses SHA-1 is possible and legal in OpenPGP. It is silly though, and GPG won't create it unless you modify the code. Outside of code modification, a 3096 bit key would use a 256-bit hash (SHA-256, not SHA-512). You could use SHA-512 with it if you liked, but the hash would be truncated to 256 bits. We follow the advice in FIPS 180-3: L = 1024, N = 160 L = 2048, N = 224 L = 3072, N = 256 So a 1024 bit key gets a 160 bit hash. 1025-2048 gets a 224 bit hash. 2049-3072 gets a 256 bit hash. We don't generate keys less than 1024 bits or greater than 3072 bits. Other programs may behave differently, so GPG will naturally follow what the key encoding says if it comes down to that. David From kevhilton at gmail.com Mon Feb 11 05:34:51 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sun, 10 Feb 2008 22:34:51 -0600 Subject: Authenticate capability of DSA or RSA signing keys In-Reply-To: <96c450350802101848k2fb778b0q606c1f3e558b7974@mail.gmail.com> References: <96c450350802101848k2fb778b0q606c1f3e558b7974@mail.gmail.com> Message-ID: <96c450350802102034q207de46u63f2b5d933bcc2ab@mail.gmail.com> >Sign = sign some data >Certify = sign a key >Authenticate = prove you are you >Authenticate is used for things like using an OpenPGP key for ssh. I forgot about the certifying of keys, sorry about that. I knew openssh utilized rsa or dsa keys, but didn't know that the same gpg keys could be used for this purpose. That's very interesting. I suppose however the reverse is not true. I suppose I could not take my rsa openssh keypair, and somehow make them work with gpg? From dshaw at jabberwocky.com Mon Feb 11 05:46:47 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Feb 2008 23:46:47 -0500 Subject: Authenticate capability of DSA or RSA signing keys In-Reply-To: <96c450350802102034q207de46u63f2b5d933bcc2ab@mail.gmail.com> References: <96c450350802101848k2fb778b0q606c1f3e558b7974@mail.gmail.com> <96c450350802102034q207de46u63f2b5d933bcc2ab@mail.gmail.com> Message-ID: <20080211044647.GB15319@jabberwocky.com> On Sun, Feb 10, 2008 at 10:34:51PM -0600, Kevin Hilton wrote: > >Sign = sign some data > >Certify = sign a key > >Authenticate = prove you are you > > >Authenticate is used for things like using an OpenPGP key for ssh. > > I forgot about the certifying of keys, sorry about that. > > I knew openssh utilized rsa or dsa keys, but didn't know that the same > gpg keys could be used for this purpose. That's very interesting. I > suppose however the reverse is not true. I suppose I could not take > my rsa openssh keypair, and somehow make them work with gpg? Math is math. You could make an OpenSSH key into an OpenPGP key (or vice versa) if you wanted. It's just a file format change and some related glue. Doing this doesn't really give you anything useful though. The OpenPGP authentication key allows you to authenticate to things like ssh - it doesn't make the key into an ssh key, just allows it to act as if it was one. David From jmoore3rd at bellsouth.net Mon Feb 11 05:48:58 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Sun, 10 Feb 2008 23:48:58 -0500 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> Message-ID: <47AFD3BA.2060306@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 - -------- Original Message -------- Subject: Re: Are DSA2 signing keys backwards compatible? From: Kevin Hilton To: gnupg-users at gnupg.org Date: Sunday, February 10, 2008 11:13:11 PM > So just to clarify -- > A 3096 bit DSA signing key could only be used with the SHA-512 hash? '3096'? I think You meant either 3072 or 4096. :-\ JOHN ;) Timestamp: Sunday 10 Feb 2008, 23:48 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9-svn4691: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJHr9O4AAoJEBCGy9eAtCsPwsMH/Axk1WH8sL0s3zVSgOotqoRc gn8DCdEQSHohw+ET/cjREWkT9j37aeDzcC+dT6GPSs6tDOuhvmwaYuWZEhVGlQ3B gTlv7vChE3V3F3jPiViC9MPJKAYFahEDjcPXZLbmOIslDiy/NtE2CSQFksFRwQZT ktB3jXUTq6GXR4O/73UceK7RELQK2kraNEwP00Zrk3GMSHxoHPkSMYBTAv5ChFEb F1gaHwlgjvdaCEmJeOI8C9EE82lLu+AWLoMysll+W4tpG0rVNWb30FKAcD9qCBFA JNlDASQGB5KsHG19MghVHgCTPmdisVbDiKAvzobh5msN6sJjXnWk8AfAe/yPTVo= =THjg -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Mon Feb 11 04:51:03 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 10 Feb 2008 21:51:03 -0600 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <20080211030142.GE12706@jabberwocky.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <20080211030142.GE12706@jabberwocky.com> Message-ID: <47AFC627.2030602@sixdemonbag.org> David Shaw wrote: > This is not how it works. There is nothing becoming de-facto here. > Longer DSA keys are the de-jure standard today, and people are just > going to have to upgrade. I think that's reversed: DSA2 is quickly becoming a de facto standard, but it is not a de jure standard. De facto: "in fact". De jure: "in law". De jure standards exist on paper but are not respected, de facto standards exist in reality but may not exist on paper. If I am mistaken as to what you meant to say, please correct me. :) From dshaw at jabberwocky.com Mon Feb 11 05:58:57 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 10 Feb 2008 23:58:57 -0500 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <47AFC627.2030602@sixdemonbag.org> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <20080211030142.GE12706@jabberwocky.com> <47AFC627.2030602@sixdemonbag.org> Message-ID: <20080211045857.GC15319@jabberwocky.com> On Sun, Feb 10, 2008 at 09:51:03PM -0600, Robert J. Hansen wrote: > David Shaw wrote: >> This is not how it works. There is nothing becoming de-facto here. >> Longer DSA keys are the de-jure standard today, and people are just >> going to have to upgrade. > > I think that's reversed: DSA2 is quickly becoming a de facto standard, but > it is not a de jure standard. > > De facto: "in fact". De jure: "in law". De jure standards exist on paper > but are not respected, de facto standards exist in reality but may not > exist on paper. > > If I am mistaken as to what you meant to say, please correct me. :) I really did mean what I said. De jure doesn't mean it exists on paper and is not respected. It just means it exists on paper, period. As you say, "in law". RFC-4880 is the published OpenPGP standard, and it specifies DSA2. Thus, de jure. It will take some time for the "facts" to catch up with the "law" here. Hence the need for people to upgrade. David From kevhilton at gmail.com Mon Feb 11 05:53:23 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Sun, 10 Feb 2008 22:53:23 -0600 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> Message-ID: <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> >You could use SHA-512 with >it if you liked, but the hash would be truncated to 256 bits. Interesting. Are the higher or lower bits truncated? >We follow the advice in FIPS 180-3: > > L = 1024, N = 160 > L = 2048, N = 224 > L = 3072, N = 256 Ok. So back to the ever asking defaults question, so why when I produce a 3072 bit DSA signing key, why isnt my first digest hash preference or choice SHA-256? Here is what I am getting: pub 3072D/0053175A created: 2007-11-14 expires: never usage: SC trust: unknown validity: unknown sub 4096g/51BFA0E0 created: 2007-11-14 expires: never usage: E [ unknown] (1). ----------------------------------------------------- Command> showpref [ unknown] (1). ----------------------------------------------------- Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify It would seem in fact that my digest preferences should only be SHA256 or SHA512 based on the information provided! SHA1 or RIPEMD160 shouldn't even be listed here, correct? From wk at gnupg.org Mon Feb 11 08:33:34 2008 From: wk at gnupg.org (Werner Koch) Date: Mon, 11 Feb 2008 08:33:34 +0100 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> (Kevin Hilton's message of "Sun, 10 Feb 2008 22:13:11 -0600") References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> Message-ID: <87d4r4dk1d.fsf@wheatstone.g10code.de> On Mon, 11 Feb 2008 05:13, kevhilton at gmail.com said: > A 3096 bit DSA signing key could only be used with the SHA-512 hash? It is possible to use it with a shorter hash but that does not make sense. Please think twice before you start to generate such a long key. It needs a lot more of performance. There are only a very vew application with a need for it. Using it on Internet connected box is ridiculous because there are uncountable ways to attack the data or the signature without attacking the math. You exclude all users of slower computers with such a long key. In particular users of PDAs and other small devices. Actually those small devices are a very good way to create high valuable signatures because it is easier to secure such devices (in contrast to general purpose desktop boxes). Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dshaw at jabberwocky.com Mon Feb 11 14:23:10 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 11 Feb 2008 08:23:10 -0500 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> Message-ID: <20080211132310.GA16915@jabberwocky.com> On Sun, Feb 10, 2008 at 10:53:23PM -0600, Kevin Hilton wrote: > >You could use SHA-512 with > >it if you liked, but the hash would be truncated to 256 bits. > > Interesting. Are the higher or lower bits truncated? RFC-4880: DSA signatures MUST use hashes that are equal in size to the number of bits of q, the group generated by the DSA key's generator value. If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. > >We follow the advice in FIPS 180-3: > > > > L = 1024, N = 160 > > L = 2048, N = 224 > > L = 3072, N = 256 > > Ok. So back to the ever asking defaults question, so why when I > produce a 3072 bit DSA signing key, why isnt my first digest hash > preference or choice SHA-256? Here is what I am getting: > > pub 3072D/0053175A created: 2007-11-14 expires: never usage: SC > trust: unknown validity: unknown > sub 4096g/51BFA0E0 created: 2007-11-14 expires: never usage: E > [ unknown] (1). ----------------------------------------------------- > > Command> showpref > [ unknown] (1). ----------------------------------------------------- > Cipher: AES256, AES192, AES, CAST5, 3DES > Digest: SHA1, SHA256, RIPEMD160 > Compression: ZLIB, BZIP2, ZIP, Uncompressed > Features: MDC, Keyserver no-modify > > It would seem in fact that my digest preferences should only be SHA256 > or SHA512 based on the information provided! SHA1 or RIPEMD160 > shouldn't even be listed here, correct? No. Preferences, including the digest preferences, are not relevant here at all. This is a signature *you* are making. The digest preferences are consulted when someone *else* is making a signature, and wants to know if you can handle it. It has nothing to do with what your key needs because your key is not involved. David From kevhilton at gmail.com Mon Feb 11 14:31:43 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 11 Feb 2008 07:31:43 -0600 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> Message-ID: <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> On Feb 10, 2008 10:53 PM, Kevin Hilton wrote: > >You could use SHA-512 with > >it if you liked, but the hash would be truncated to 256 bits. > > Interesting. Are the higher or lower bits truncated? > > >We follow the advice in FIPS 180-3: > > > > L = 1024, N = 160 > > L = 2048, N = 224 > > L = 3072, N = 256 > > Ok. So back to the ever asking defaults question, so why when I > produce a 3072 bit DSA signing key, why isnt my first digest hash > preference or choice SHA-256? Here is what I am getting: > > pub 3072D/0053175A created: 2007-11-14 expires: never usage: SC > trust: unknown validity: unknown > sub 4096g/51BFA0E0 created: 2007-11-14 expires: never usage: E > [ unknown] (1). ----------------------------------------------------- > > Command> showpref > [ unknown] (1). ----------------------------------------------------- > Cipher: AES256, AES192, AES, CAST5, 3DES > Digest: SHA1, SHA256, RIPEMD160 > Compression: ZLIB, BZIP2, ZIP, Uncompressed > Features: MDC, Keyserver no-modify > > It would seem in fact that my digest preferences should only be SHA256 > or SHA512 based on the information provided! SHA1 or RIPEMD160 > shouldn't even be listed here, correct? > My reason for asking these questions is in regards to a documentation Im trying to compose for a user's group. Obviously I'm very much a novice in both the mathematics beyonds GnuPG but in also its implementation. Its clear to me you are following both the FIPS and OpenGPG RFC 8440 in implementing the program, however the truncation of longer hash products, along with attempting to predict which hash the program based on the output available will actually use is very troubling and extremely difficult to document given all the nuances of the program, particularly in relation to DSA keys. Given the above example (just one example), where a 3072 DSA key actually uses either a SHA256 or SHA512 bit hash (truncated to 256 bits), despite what is listed when showprefs is displayed -- How do you actually document this scenario? Im sure the situation is similar with 2048 DSA keys. This is particularly troublesome given the fact that many actually recommend the use of 2048 DSA keys -> meaning all hashes used are going to be trucated to 224 bits and that 160 bit hashes will never be used despite what would be suggested by the preference statement. Are RSA signing keys subject to some of the same nuances as DSA keys? Practically could a 1024 bit RSA key be used with a 512 hash? Again its all very confusing to me -- math aside and practical considerations why you wouldn't want to mix and match key types and hash lengths. Again Robert Hansen has wisely suggested use the defaults -- I'm understanding this more and more -- however when I see showpref statements that would suggest SHA-1 is the default hash, when in actuality with larger DSA keys it is not, I get rather frustrated. Thank you for your help. -- Kevin Hilton From david at miradoiro.com Mon Feb 11 14:44:32 2008 From: david at miradoiro.com (=?iso-8859-1?Q?David_Pic=F3n_=C1lvarez?=) Date: Mon, 11 Feb 2008 14:44:32 +0100 Subject: Are DSA2 signing keys backwards compatible? References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com><96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com><96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com><96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> Message-ID: <001301c86cb4$3b729fe0$0302a8c0@Nautilus> > Again its all very confusing to me -- math aside and practical > considerations why you wouldn't want to mix and match key types and > hash lengths. Again Robert Hansen has wisely suggested use the > defaults -- I'm understanding this more and more -- however when I see > showpref statements that would suggest SHA-1 is the default hash, when > in actuality with larger DSA keys it is not, I get rather frustrated. I think you have some level of misunderstanding about what, where, and how different algorithms are used, and what prefs refer to. I'll try to explain it in short, and forgive me if this is old for you and I assumed wrongly. A keypair contains (simplifying) a public and private key plus metadata. Among the metadata there is a self signature, by which the private key signs the hash of the public key and other key elements. This hash is NOT determined by key preferences, key preferences are means to signal to other people what hashes they should use when they issue signatures for you. Likewise, the private key is encrypted on secring.gpg, and the algorithm used to encrypt it has nothing to do with key preferences, it is a private matter. Key preferences are ALWAYS hints to someone else about what algorithms you are willing and able to deal with when THEY send you data. They have nothing to do with the algorithms you use for encrypting to others, encrypting symetrically, hashing your key, and so on, beyond the obvious fact that you should be able to deal with all algorithms you place in prefs, as well as those used for your own key. These decisions are taken mostly through defaults, although it is also possible to use modifiers on the command line or options file in order to determine which hashes, or which algorithms to use for encrypting the private key. HTH, --David. From kevhilton at gmail.com Mon Feb 11 14:48:12 2008 From: kevhilton at gmail.com (Kevin Hilton) Date: Mon, 11 Feb 2008 07:48:12 -0600 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> Message-ID: <96c450350802110548i5fd0c321x9d7d62bc1f70d6c2@mail.gmail.com> >No. Preferences, including the digest preferences, are not relevant >here at all. This is a signature *you* are making. The digest >preferences are consulted when someone *else* is making a signature, >and wants to know if you can handle it. It has nothing to do with >what your key needs because your key is not involved. Sorry I was writing my last reply when I received yours. Thank your for clarification. I understand the difference. However given the fact that I could produce for example SHA256 hashes, wouldn't I prefer the same hash length in return for security reasons? Meaning woundn't it be preferable for the showpref statement to read SHA256, SHA1, RIPEMD160 rather than SHA1, SHA256, RIPEMD160 Again, Im aware of the default-preference-list within the gpg.conf file, This controls the preference order of the hashes, ciphers with key creation within my own set of keys. Other than consulting this in the gpg.conf file, there is no other place this default list could be consulted? Meaning this is no command I could type that would give me the Hash Algorithm I would be using before signing the document -- once the document is signed its easy to see the hash that was used. I suppose the same discussion type could be stated with cipher type. Other than consulting the default preference list within the gpg.conf file (is there is one), is there any way to predict or show a preference list in relation to my own keys? Again if the showpref statement is meant for the other party, is there an equivalent statement or command for myself? From dshaw at jabberwocky.com Mon Feb 11 14:55:28 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 11 Feb 2008 08:55:28 -0500 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> Message-ID: <20080211135528.GB16915@jabberwocky.com> On Mon, Feb 11, 2008 at 07:31:43AM -0600, Kevin Hilton wrote: > On Feb 10, 2008 10:53 PM, Kevin Hilton wrote: > > >You could use SHA-512 with > > >it if you liked, but the hash would be truncated to 256 bits. > > > > Interesting. Are the higher or lower bits truncated? > > > > >We follow the advice in FIPS 180-3: > > > > > > L = 1024, N = 160 > > > L = 2048, N = 224 > > > L = 3072, N = 256 > > > > Ok. So back to the ever asking defaults question, so why when I > > produce a 3072 bit DSA signing key, why isnt my first digest hash > > preference or choice SHA-256? Here is what I am getting: > > > > pub 3072D/0053175A created: 2007-11-14 expires: never usage: SC > > trust: unknown validity: unknown > > sub 4096g/51BFA0E0 created: 2007-11-14 expires: never usage: E > > [ unknown] (1). ----------------------------------------------------- > > > > Command> showpref > > [ unknown] (1). ----------------------------------------------------- > > Cipher: AES256, AES192, AES, CAST5, 3DES > > Digest: SHA1, SHA256, RIPEMD160 > > Compression: ZLIB, BZIP2, ZIP, Uncompressed > > Features: MDC, Keyserver no-modify > > > > It would seem in fact that my digest preferences should only be SHA256 > > or SHA512 based on the information provided! SHA1 or RIPEMD160 > > shouldn't even be listed here, correct? > > > > My reason for asking these questions is in regards to a documentation > Im trying to compose for a user's group. Obviously I'm very much a > novice in both the mathematics beyonds GnuPG but in also its > implementation. Its clear to me you are following both the FIPS and > OpenGPG RFC 8440 in implementing the program, however the truncation > of longer hash products, along with attempting to predict which hash > the program based on the output available will actually use is very > troubling and extremely difficult to document given all the nuances of > the program, particularly in relation to DSA keys. Given the above > example (just one example), where a 3072 DSA key actually uses either > a SHA256 or SHA512 bit hash (truncated to 256 bits), despite what is > listed when showprefs is displayed -- How do you actually document > this scenario? First of all, leave out 'showpref' from your documentation of this question as it has nothing at all to do with hash choice when you make a signature. It's only relevant for other people making signatures and sending them to you. That leaves the question of which hashes are usable for a given DSA key. The answer is that all DSA keys contain a number called the 'q' value. That value specifies how large the hash must be when making signatures with that key. There are a few differences, but the main difference between DSA1 and DSA2 is that DSA1 keys have q=160 and it cannot change. This is why DSA1 keys need SHA-1 or RIPEMD160 as their hash: they are both 160-bit hashes, to match q=160. DSA2 keys can have different q values. In DSA2, you can use whatever hash you like as long as it is equal to, or greater than your q size. > Are RSA signing keys subject to some of the same nuances as DSA keys? > Practically could a 1024 bit RSA key be used with a 512 hash? Yes. It's silly, as the hash is vastly stronger than the key, but it's legal, and GPG can do it. > Again its all very confusing to me -- math aside and practical > considerations why you wouldn't want to mix and match key types and > hash lengths. Again Robert Hansen has wisely suggested use the > defaults -- I'm understanding this more and more -- however when I see > showpref statements that would suggest SHA-1 is the default hash, when > in actuality with larger DSA keys it is not, I get rather frustrated. Robert is quite right about the defaults. There are some very complex issues here and GPG is a very configurable program. It's excellent that people spend the time to understand the issues, but I find that most people who spend the time to learn the issues also use the defaults :) Daxvid From email at sven-radde.de Mon Feb 11 14:58:37 2008 From: email at sven-radde.de (Sven Radde) Date: Mon, 11 Feb 2008 14:58:37 +0100 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <20080211132310.GA16915@jabberwocky.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> <20080211132310.GA16915@jabberwocky.com> Message-ID: <47B0548D.9030507@sven-radde.de> David Shaw schrieb: > No. Preferences, including the digest preferences, are not relevant > here at all. This is a signature *you* are making. The digest > preferences are consulted when someone *else* is making a signature, > and wants to know if you can handle it. How would "someone else" (i.e. his GnuPG application) know that he is signing *for me*? Except, that is, if he is encrypting to me at the same time. For me, it would appear that consulting the preferences of the signing key is sensible when deciding about the hash function to use in the signature. Of course, given that you create signatures at your own system, looking at personal-hash-preferences is also sensible (although one might have different preferences when using different keys - i.e. to match sizes). What is GnuPG's way to choose a hash function, when no recipient is apparent (e.g., detached signing of software packages) and no preferences are available? Conservatively, I would say SHA-1, it being the only MUST algorithm of the RFC (or did this change with 4880?). But for DSA2, this seems not viable. So, is it the shortest SHA-x for the DSA2 key's size, in this case? cu, Sven From dshaw at jabberwocky.com Mon Feb 11 16:06:03 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 11 Feb 2008 10:06:03 -0500 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <47B0548D.9030507@sven-radde.de> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> <20080211132310.GA16915@jabberwocky.com> <47B0548D.9030507@sven-radde.de> Message-ID: <20080211150602.GC16915@jabberwocky.com> On Mon, Feb 11, 2008 at 02:58:37PM +0100, Sven Radde wrote: > David Shaw schrieb: > > No. Preferences, including the digest preferences, are not relevant > > here at all. This is a signature *you* are making. The digest > > preferences are consulted when someone *else* is making a signature, > > and wants to know if you can handle it. > How would "someone else" (i.e. his GnuPG application) know that he is > signing *for me*? Except, that is, if he is encrypting to me at the same > time. Exactly what you said - it only happens if he is encrypting to you at the same time. > For me, it would appear that consulting the preferences of the signing > key is sensible when deciding about the hash function to use in the > signature. Of course, given that you create signatures at your own > system, looking at personal-hash-preferences is also sensible (although > one might have different preferences when using different keys - i.e. to > match sizes). > > What is GnuPG's way to choose a hash function, when no recipient is > apparent (e.g., detached signing of software packages) and no > preferences are available? If there is a personal-hash-preference set, we use them. For RSA, that means to take the first one on the list, and if none are set, use SHA-1. For DSA, that means take the first one that is legal given the signing key (i.e. large enough). If there are no personal hash preferences set, or none of the supplied preferences are legal, then take the shortest SHA-x that matches the DSA2 key size. David From rjh at sixdemonbag.org Mon Feb 11 16:18:35 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 11 Feb 2008 09:18:35 -0600 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802110548i5fd0c321x9d7d62bc1f70d6c2@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> <96c450350802110548i5fd0c321x9d7d62bc1f70d6c2@mail.gmail.com> Message-ID: <47B0674B.5090300@sixdemonbag.org> Kevin Hilton wrote: > Sorry I was writing my last reply when I received yours. Thank your > for clarification. I understand the difference. However given the > fact that I could produce for example SHA256 hashes, wouldn't I prefer > the same hash length in return for security reasons? Not necessarily. Imagine you're in an environment where your cipher selection is constrained by law. You may be able to produce SHA256, SHA384, SHA512, MD5, TIGER192 and WHIRLPOOL (just to come up with an absurdly comprehensive list of hashes), but you may be constrained by either law or corporate policy to only use SHA-1 for your signatures. Other people outside this environment who are communicating with you would not be constrained by those regulations, and could use whatever is necessary in their environment. E.g., you may be required to use SHA-1, someone else may be required to use RIPEMD160, despite the fact both of you are capable of using much longer (and better) hashes. From rjh at sixdemonbag.org Mon Feb 11 16:30:57 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 11 Feb 2008 09:30:57 -0600 Subject: Are DSA2 signing keys backwards compatible? In-Reply-To: <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> References: <96c450350802101447g714fba64q47a6a06bea37eab0@mail.gmail.com> <96c450350802101830u330fa55es6bf221b69cc79b7@mail.gmail.com> <96c450350802102013ua6425d0w6418b8218a2f98fd@mail.gmail.com> <96c450350802102053k256ada43i909eb95665296da2@mail.gmail.com> <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> Message-ID: <47B06A31.7090103@sixdemonbag.org> Kevin Hilton wrote: > My reason for asking these questions is in regards to a documentation > Im trying to compose for a user's group. If you are interested, I have about half of a GnuPG user's manual written up in DocBook format. Right now it only covers the mathematical and conceptual side of GnuPG, leaving a lot of practical stuff to be done, but it may be useful to you. > Its clear to me you are following both the FIPS and OpenGPG RFC 8440 > in implementing the program 4880, not 2440. > however the truncation of longer hash products ... is very troubling > and extremely difficult to document RFC4880 documents the truncation process pretty well: leftmost bits only, etc. The truncation process itself should not be troubling. Any set of bits could be truncated--high order, low order, high-order even bits, low-order odd bits, bit positions that lie along a Riemann zeta, etc. A hash should be indistinguishable from noise. Any selection from noise is just as random as any other selection. Hash truncation is very well documented within the field of cryptography and cryptanalysis. If you like, check the _Handbook of Applied Cryptography_, which is available for free online or in dead-tree form from any decent university library. > Given the above example (just one example), where a 3072 DSA key > actually uses either a SHA256 or SHA512 bit hash (truncated to 256 > bits), despite what is listed when showprefs is displayed -- How do > you actually document this scenario? Showprefs is a hint to GnuPG, not an absolute rule. GnuPG is within its rights to reject a preference if GnuPG determines that the preference is irrelevant to a particular environment. Document that DSA1024 requires a 160-bit hash and thus any preference for MD5 will be ignored, DSA2048 requires a 224-bit hash and thus any pref for MD5, SHA1 or RIPEMD160 will be ignored, DSA3072 requires a 256-bit hash and thus any pref for MD5, SHA1, RIPEMD160 or SHA224 will be ignored. > Are RSA signing keys subject to some of the same nuances as DSA keys? > Practically could a 1024 bit RSA key be used with a 512 hash? RSA signing keys may be used with any length of hash. I think this is probably a misfeature, but it is what it is. People have this really annoying habit of believing GnuPG needs to be tweaked to get good communications security. It leads people to doing things like generating a 1024-bit RSA signing key since that's all that will fit on their smartcard, but using SHA512 as a hash algorithm to try and 'compensate' for their short RSA signing key. Just as ridiculous, IMO, is the conventional wisdom that symmetric key lengths, asymmetric key lengths and hash lengths should all be 'balanced'. Etc., etc. Hence, as you've remarked, my usual curt recommendation to stick with the defaults and not worry about it. From dave at my-iop.com Mon Feb 11 22:30:17 2008 From: dave at my-iop.com (Dave (My-IOP)) Date: Mon, 11 Feb 2008 16:30:17 -0500 Subject: need example of passing clear text to gpg from another app without using temp files Message-ID: Hi, I want to pass clear text from a text editor to gpg for encryption (on a Linux system). Currently it is being done by writing the clear text to a temp file and having gpg read that temp file and then write it back out as an encrypted file. Obviously, it would be much better to avoid ever writing the clear text to disk. How can I pass the clear text to gpg via a pipe and avoid using the temp file on disk? I am a noob (to both Linux and gpg), so a very clear example is greatly appreciated. Regards, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke at lukepowell.net Tue Feb 12 00:57:17 2008 From: luke at lukepowell.net (Luke Powell) Date: Mon, 11 Feb 2008 17:57:17 -0600 Subject: need example of passing clear text to gpg from another app without using temp files In-Reply-To: References: Message-ID: <47B0E0DD.9000304@lukepowell.net> On 02/11/2008 03:30 PM, Dave (My-IOP) wrote: > Hi, > I want to pass clear text from a text editor to gpg for encryption (on a > Linux system). Currently it is being done by writing the clear text to a > temp file and having gpg read that temp file and then write it back out > as an encrypted file. Obviously, it would be much better to avoid ever > writing the clear text to disk. > > How can I pass the clear text to gpg via a pipe and avoid using the temp > file on disk? > > I am a noob (to both Linux and gpg), so a very clear example is greatly > appreciated. > Well, it really depends a lot on your text editor. I use Vim, so my command is gg!Ggpg -ae -r luke at lukepowell.net That goes to the beginning of the file and filters all the text through the the process gpg -ae -r luke at lukepowell.net. As for how to do it under Emacs, I'm sure another of these fine people can help. Also, if security is important, you'll want to make sure that any hard drive writes or backups are disabled. In Vim, you'll want to turn off the scratch file. Hope that helps, Luke Powell From dave at my-iop.com Tue Feb 12 02:00:48 2008 From: dave at my-iop.com (Dave (My-IOP)) Date: Mon, 11 Feb 2008 20:00:48 -0500 Subject: need example of passing clear text to gpg from another app without using temp files In-Reply-To: <47B0E0DD.9000304@lukepowell.net> References: <47B0E0DD.9000304@lukepowell.net> Message-ID: On Feb 11, 2008 6:57 PM, Luke Powell wrote: > On 02/11/2008 03:30 PM, Dave (My-IOP) wrote: > > Hi, > > I want to pass clear text from a text editor to gpg for encryption (on a > > Linux system). Currently it is being done by writing the clear text to a > > temp file and having gpg read that temp file and then write it back out > > as an encrypted file. Obviously, it would be much better to avoid ever > > writing the clear text to disk. > > > > How can I pass the clear text to gpg via a pipe and avoid using the temp > > file on disk? > > > > I am a noob (to both Linux and gpg), so a very clear example is greatly > > appreciated. > > > > Well, it really depends a lot on your text editor. I use Vim, so my > command is > > gg!Ggpg -ae -r luke at lukepowell.net > > That goes to the beginning of the file and filters all the text through > the the process gpg -ae -r luke at lukepowell.net. > > As for how to do it under Emacs, I'm sure another of these fine people > can help. Also, if security is important, you'll want to make sure that > any hard drive writes or backups are disabled. In Vim, you'll want to > turn off the scratch file. > > Hope that helps, > > Luke Powell Hi Luke, Thanks for the feedback. I'm using Cream, which is based on Vim. It is similar, but the script commands are written with a different style -- everything is a function, for example. (I'm no expert on it by any means -- just a noob.) The problem I face is that Cream apparently has to pass the clear text to be encrypted as a command argument when only a portion of the text is being encrypted. For example, if I have the following text: Line one. Line two. Last line. Say I want to encrypt line two in place in the document. The result should look like this: Line one. -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.6 (GNU/Linux) hQIOA4rUTS1Awtq6EAf/Sk/lP0i9WI+jZmhpOm/mWxAtoYC7YV5pNQAW70bcCaAM [snip] FG7/enHW7UV+SvdNyz5oap/vfTqYRSU= =kJVc -----END PGP MESSAGE----- Last line. I do not know how to get Cream/Vim to pass the register contents that hold the selected text to gpg via a pipe (without a temp file being used). I now know how to do this sequence of eventgs on the command line, but not in Cream. Using temp files, the code looks something like this: " cut selection into register normal "xx " encrypt call writefile([@x], tmpfile) " command silent execute 'silent! !gpg -ae --default-recipient-self -o "' . tmpfile . '.gpg" "' . tmpfile . '"' The main issue is how to avoid using a temp file and that's where I'm stuck. I have some help from someone who knows Cream well, but he doesn't know gpg well. (And unfortunately, I don't know either of them well!) Thanks, Dave P.S. Should I reply to all when replying to this list? -------------- next part -------------- An HTML attachment was scrubbed... URL: From skrewz at skrewz.dk Tue Feb 12 11:59:02 2008 From: skrewz at skrewz.dk (Anders Breindahl) Date: Tue, 12 Feb 2008 11:59:02 +0100 Subject: Safe decryption with GnuPG? In-Reply-To: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> Message-ID: <20080212105902.GC12525@skrewz.dk> Hello, On 200802010958, Krzysztof ?elechowski wrote: > 1. The decrypted information must not make it to any persistent medium Use full-disk encryption, as has been stated before. That way, you can be confident that nothing leaks into unencrypted places, since such do not exist in the running system. > 2. The decrypted text must not be stored in volatile memory any longer > than it is needed. In particular, it should be converted to a > human-viewable bitmap and the computer-readable representation must be > immediately erased. That I can't understand your motivation for. I suppose you're afraid that once compromised, your adversary can't search through memory for certain strings. But he could still be monitoring your actions, and copy whatever data you construct in RAM---including the adversary-readable bitmap. As Robert stated, many of your other requirements are void, if your adversary gains control of your machine. > 8. The application should be as lightweight as possible (for source > code audit). Right, agreed. > Can you direct me to some implementation meeting these requirements? I wrote a such script once, that satisfies much of (the serious amongst) your requirements. Email me personally, if you're interested. Other than that you may want to look at this vim plugin, which is along the lines of what you seek: http://vim.sourceforge.net/scripts/script.php?script_id=661 But I still hold that your requirements for protecting against a system-controlling adversary are silly! :) Regards, skrewz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From dave at my-iop.com Tue Feb 12 19:32:26 2008 From: dave at my-iop.com (Dave (My-IOP)) Date: Tue, 12 Feb 2008 13:32:26 -0500 Subject: Safe decryption with GnuPG? In-Reply-To: <20080212105902.GC12525@skrewz.dk> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <20080212105902.GC12525@skrewz.dk> Message-ID: 2008/2/12 Anders Breindahl : > Hello, > > On 200802010958, Krzysztof ?elechowski wrote: > [snip] > > Other than that you may want to look at this vim plugin, which is along > the lines of what you seek: > > http://vim.sourceforge.net/scripts/script.php?script_id=661 > > > Regards, skrewz. Hi skrewz -- is it possible to make the vim plugin work similar to the gedit gpg plugin? What I want to do it encrypt a portion of a text file -- not the whole file. In gedit, I can select the text to be encrypted and choose a menu option to encrypt it. The original text is replaced by gpg ascii armored encrypted text in place. The decrypt option reverses the process. If gedit can do it, I would think vim can do it too. Unfortunately, as a noob, I don't know much about (really nothing) vim scripting. Is there an existing solution for this? Regards, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Feb 12 17:25:28 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 12 Feb 2008 17:25:28 +0100 Subject: [Announce] Libksba 1.0.3 released Message-ID: <87bq6mgn0n.fsf@wheatstone.g10code.de> Hello! We are pleased to announce version 1.0.3 of Libksba. Libksba is an X.509 and CMS (PKCS#7) library. It is for example required to build the S/MIME part of GnuPG-2 (gpgsm). The only build requirement for Libksba itself is the libgpg-error package. There are no other dependencies; actual cryptographic operations need to be done by the user. Libksba is distributed under the GPLv3+. There are no user tools accompanying this software, thus it is mostly relevant to developers. This is a bug fix release. You may download the library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.0.3.tar.bz2 (513k) ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.0.3.tar.bz2.sig As an alternative you may use a patch file to upgrade the previous version of the library: ftp://ftp.gnupg.org/gcrypt/libksba/libksba-1.0.2-1.0.3.diff.bz2 (13k) or from any mirror of that server (http://www.gnupg.org/mirrors.html). SHA-1 checksums are: 7a4b3a8340087ed360269b567881ebfb9b67441b libksba-1.0.3.tar.bz2 ecbeb0f381db55f387753f5c873e20be59c9b65f libksba-1.0.2-1.0.3.diff.bz2 Noteworthy changes in version 1.0.3 (2008-02-12) ------------------------------------------------ * Minor bug fixes. * Include the used hash algorithm in sig-val structures. * Fix for unknown tags in issuerAltName and subjectAltName. Commercial support contracts for Libksba are available, and they help finance continued maintenance. g10 Code, a Duesseldorf based company owned and headed by Libksba's principal author, is currently funding its development. We are always looking for interesting development projects. See also http://www.gnupg.org/service.html . Happy hacking, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From supraexpress at globaleyes.net Tue Feb 12 20:49:37 2008 From: supraexpress at globaleyes.net (User 1001) Date: Tue, 12 Feb 2008 13:49:37 -0600 Subject: need example of passing clear text to gpg from another app without using temp files In-Reply-To: <47B0E0DD.9000304__26467.8218438805$1202776587$gmane$org@lukepowell.net> References: <47B0E0DD.9000304__26467.8218438805$1202776587$gmane$org@lukepowell.net> Message-ID: Luke Powell wrote: > On 02/11/2008 03:30 PM, Dave (My-IOP) wrote: >> Hi, >> I want to pass clear text from a text editor to gpg for encryption (on >> a Linux system). Currently it is being done by writing the clear text >> to a temp file and having gpg read that temp file and then write it >> back out as an encrypted file. Obviously, it would be much better to >> avoid ever writing the clear text to disk. >> >> How can I pass the clear text to gpg via a pipe and avoid using the >> temp file on disk? >> >> I am a noob (to both Linux and gpg), so a very clear example is >> greatly appreciated. Gedit has a Text Encryption plugin to encrypt text provided from Seahorse which is a front-end to GnuPG from seahorse makefile: GEDIT "Enable GEdit plug-in support" on (don't know if it uses a temporary file or not). From mk at fsfe.org Wed Feb 13 14:51:45 2008 From: mk at fsfe.org (Matthias Kirschner) Date: Wed, 13 Feb 2008 14:51:45 +0100 Subject: Problem getting smartcard reader working !!! In-Reply-To: <200801171101.16559.joerg@schmitz-linneweber.de> References: <200801131246.32667.a.cloos@webspeed.dk> <200801171101.16559.joerg@schmitz-linneweber.de> Message-ID: <20080213135145.GO4409@mbwg.de> * J?rg Schmitz-Linneweber [2008-01-17 11:01:07 +0100]: > The only known card which supports the OpenPGP card application is the OpenPGP > card and the FSEcard... > [ http://www.kernelconcepts.de/shop/products/security.shtml?hardware ] > [ https://www.fsfe.org/card/ ] Technically those cards are equal. Best wishes, Matthias From jnimety at perimeterusa.com Wed Feb 13 16:48:54 2008 From: jnimety at perimeterusa.com (Joel Nimety) Date: Wed, 13 Feb 2008 10:48:54 -0500 Subject: using a key server with gpgme Message-ID: <47B31166.2090204@perimeterusa.com> Is it possible to retrieve/publish keys to/from a key server using gpgme? I've discovered gpgme_set_keylist_mode and GPGME_KEYLIST_MODE_EXTERN but how do I specify the keyserver and have gpgme publish a public key to the key server after generating a new key pair? -- Joel Nimety -- The sender of this email subscribes to Perimeter eSecurity's email anti-virus service. This email has been scanned for malicious code and is believed to be virus free. For more information on email security please visit: http://www.perimeterusa.com/email-defense-content.html This communication is confidential, intended only for the named recipient(s) above and may contain trade secrets or other information that is exempt from disclosure under applicable law. Any use, dissemination, distribution or copying of this communication by anyone other than the named recipient(s) is strictly prohibited. If you have received this communication in error, please delete the email and immediately notify our Command Center at 203-541-3444. Thanks From shaz.zeb at aciworldwide.com Wed Feb 13 18:37:36 2008 From: shaz.zeb at aciworldwide.com (shaz.zeb at aciworldwide.com) Date: Wed, 13 Feb 2008 11:37:36 -0600 Subject: New to GnuPG and OpenGPG Message-ID: Hello everyone, I am rookie to GPG, so please bare with me when I ask some 'rookie' questions ... :-) I am trying to import keys into OpenPGP on an AIX box, which were created using GnuPG (version 1.48) on windows. I am getting the following error: - %: IBMpgp -verify my-win-key IBMpgp Tool - RFC 2440 implementation on AIX Support Information Asymmetric algorithms: RSA, DSA Symmetric algorithms : Triple-DES, CAST5 Hash algorithms : SHA1, MD5 Compression/Decompression : Not yet supported Key Flags: Not handling at the moment ... skipping. Failed to verify the signature I can import the keys into GnuPG on my windows machine, that were created by OpenPGP on the AIX box. Is there a compatibility issue? Do I have to work with GnuPG version 2.08 to make this work. Thanks in advance Cheers, Shaz Zeb -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg at ethen.de Wed Feb 13 21:30:06 2008 From: gnupg at ethen.de (gnupg at ethen.de) Date: Wed, 13 Feb 2008 21:30:06 +0100 Subject: Corporate use of gnupg In-Reply-To: <15312177.post@talk.nabble.com> References: <15312177.post@talk.nabble.com> Message-ID: <200802132130.07257.gnupg@ethen.de> And what do they want to do with the recieved emails? The only possibility I see is to put everyone's private keys and passowrds into a safe - then you can decrypt sent and received mail later. > Apologies if this has already been asked. Honestly, I did my homework and > looked in the archives! > > I am wanting to setup up users to use GnuPG for encrypting email, mainly > for internal e-mail. > > Unfortunately, the "powers-that-be" want everyone that encrypts an email to > also encrypt it to the "corporate secret key". Their reasoning is that if > a person leaves, they want to have access to the old emails in case there > is a "business critical" email in there. > > Is there a way to "force" users to encrypt to a corporate key, in addition > to the receipient's key? > > Thanks, > > TK From rjh at sixdemonbag.org Thu Feb 14 06:24:14 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 13 Feb 2008 21:24:14 -0800 Subject: Corporate use of gnupg In-Reply-To: <200802132130.07257.gnupg@ethen.de> References: <15312177.post@talk.nabble.com> <200802132130.07257.gnupg@ethen.de> Message-ID: <20080213212414.qomjthkgn4w0wk8s@mail.monkeyblade.net> Quoting gnupg at ethen.de: > And what do they want to do with the recieved emails? The only possibility I > see is to put everyone's private keys and passowrds into a safe - then you > can decrypt sent and received mail later. Same problem exists with PGP's ADK feature, which should really be named an ARR, for Additional Recipient Request. While ADK usage can be enforced within the ADK-using group (mostly: there are some caveats), emails from outside the group going in to the group are under no such restrictions. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From hs2412 at gmail.com Thu Feb 14 07:34:32 2008 From: hs2412 at gmail.com (Hardeep Singh) Date: Thu, 14 Feb 2008 12:04:32 +0530 Subject: SPOJ signature - may be offtopic Message-ID: Hi The Sphere online judge is signing the certificates like this: http://www.spoj.pl/status/hardeeps/signedlist/ I am not able to understand if this is a simple hash of the contents, or if this is a gpg-based sign (it doesnt look like correct format). There is no public key on their site. Could anyone try and understand what kind of signature this is, what hash function is used? Just hashing the content doesnt prove anything - anybody could change both the content and the hash. Thanks & Regards Hardeep Singh From program.spe at home.pl Wed Feb 13 11:41:53 2008 From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=) Date: Wed, 13 Feb 2008 11:41:53 +0100 Subject: Safe decryption with GnuPG? In-Reply-To: <20080212105902.GC12525@skrewz.dk> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <20080212105902.GC12525@skrewz.dk> Message-ID: <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> Dnia 12-02-2008, Wt o godzinie 11:59 +0100, Anders Breindahl pisze: > Hello, > > On 200802010958, Krzysztof ?elechowski wrote: > > 1. The decrypted information must not make it to any persistent medium > > Use full-disk encryption, as has been stated before. That way, you can > be confident that nothing leaks into unencrypted places, since such do > not exist in the running system. Full disk encryption makes the system unnecessarily slow, especially if applied to swap space. I am seeking an intermediate solution for desktop computers where the amount of confidential data is small. The system as a whole should not be affected (unless, of course, it is a dedicated device, but that is another story). > > > 2. The decrypted text must not be stored in volatile memory any longer > > than it is needed. In particular, it should be converted to a > > human-viewable bitmap and the computer-readable representation must be > > immediately erased. > > That I can't understand your motivation for. I suppose you're afraid > that once compromised, your adversary can't search through memory for > certain strings. That is right. > > But he could still be monitoring your actions, and copy whatever data > you construct in RAM---including the adversary-readable bitmap. Certainly. But unless the intruder is a root-kit, it cannot run a continuous memory scan unnoticed. On the other hand, immediate disposal of intermediate data can make casual inspection harder. > > As Robert stated, many of your other requirements are void, if your > adversary gains control of your machine. Admittedly the protection will never be perfect but I would like it to be as good as can be. > > > 8. The application should be as lightweight as possible (for source > > code audit). > > Right, agreed. > > > Can you direct me to some implementation meeting these requirements? > > I wrote a such script once, that satisfies much of (the serious amongst) > your requirements. Email me personally, if you're interested. If you are so kind, or just the idea if you do not want it to be adapted and published. > > Other than that you may want to look at this vim plugin, which is along > the lines of what you seek: > > http://vim.sourceforge.net/scripts/script.php?script_id=661 > It is not because it keeps encrypted data in memory. > But I still hold that your requirements for protecting against a > system-controlling adversary are silly! :) As you wish. Regards, Chris From kenneth_kammer at reyrey.com Wed Feb 13 21:47:27 2008 From: kenneth_kammer at reyrey.com (Kammer, Kenneth A (Ken)) Date: Wed, 13 Feb 2008 15:47:27 -0500 Subject: Multiple users of GPG Message-ID: I have installed GPG on a virtual server and everything works fine for me. I now want to allow users to also encrypt their files using the public and private keys I have established. But when another user connects to my virtual server, they can not see any keys on the keyring. Has anyone else come across this situation? Can anyone offer me any suggestions to fix this problem? Thanks, Ken Kammer .NET Developer SIMS2 Team 937/485-8077 www.reyrey.com This message is confidential and may contain confidential information it is intended only for the individual[s] named herein. If this message is being sent from a member of the legal department, it may also be legally privileged. If you are not the named addressee[s] you must delete this email immediately do not disseminate, distribute or copy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shaz.zeb at aciworldwide.com Wed Feb 13 17:45:30 2008 From: shaz.zeb at aciworldwide.com (shaz.zeb at aciworldwide.com) Date: Wed, 13 Feb 2008 10:45:30 -0600 Subject: New to GnuPG and OpenGPG Message-ID: Hello everyone, I am rookie to GPG, so please bare with me when I ask some 'rookie' questions ... :-) I am trying to import keys into OpenPGP on an AIX box, which were created using GnuPG (version 1.48) on windows. I am getting the following error: - %: IBMpgp -verify my-win-key IBMpgp Tool - RFC 2440 implementation on AIX Support Information Asymmetric algorithms: RSA, DSA Symmetric algorithms : Triple-DES, CAST5 Hash algorithms : SHA1, MD5 Compression/Decompression : Not yet supported Key Flags: Not handling at the moment ... skipping. Failed to verify the signature I can import the keys into GnuPG on my windows machine, that were created by OpenPGP on the AIX box. Is there a compatibility issue? Do I have to work with GnuPG version 2.08 to make this work. Thanks in advance Cheers, Shaz Zeb -------------- next part -------------- An HTML attachment was scrubbed... URL: From anonymous at remailer.metacolo.com Thu Feb 14 10:44:37 2008 From: anonymous at remailer.metacolo.com (Anonymous Sender) Date: Thu, 14 Feb 2008 09:44:37 +0000 (UTC) Subject: Kmail/gnupg fails to encrypt on F8 In-Reply-To: <200802071836.55497.Juha.Tuomala@iki.fi> References: <96c450350802110531y6ad1035dt8a1a03d4f99a97e5@mail.gmail.com> <001301c86cb4b729fe0/var/tmp/mixmail.sm14186.1302a8c0@Nautilus> Message-ID: > Is there a way to "force" users to encrypt to a corporate key, in > addition to the receipient's key? Use a wrapper around 'gpg' which adds '-r corporate_key' to the user-supplied options (only when encrpypting, obviously) and then exec()'s the original 'gpg' with the modified options. From max.allan at nbs.co.uk Thu Feb 14 12:09:24 2008 From: max.allan at nbs.co.uk (Max Allan) Date: Thu, 14 Feb 2008 11:09:24 +0000 Subject: Corporate use of gnupg In-Reply-To: <20080213212414.qomjthkgn4w0wk8s@mail.monkeyblade.net> References: <15312177.post@talk.nabble.com> <200802132130.07257.gnupg@ethen.de> <20080213212414.qomjthkgn4w0wk8s@mail.monkeyblade.net> Message-ID: <010201c86efa$0ef02e40$5dc810ac@maxpc> You're cracking the wrong nut. We've concluded : You can't enforce everyone to ensure their email is decryptable. So the solution is to make sure they don't get encrypted email. Use GPG at a gateway level and deny any internal mail that can't be decrypted. This is the way PGPU can work. All internal users' keys are stored on the PGPU server, users don't need to know their passwords or anything about their keys. The server decrypts or encrypts as required. All traffic on your local network is in the clear. We used to have a TFS server doing something similar using GPG. (you need to buy TFS, I don't know if there is a free solution out there) Of course if your encryption policy is designed to prevent colleagues reading each others email, then this doesn't work. But if people can access each others mailboxes, you've got a different problem (with file permissions)! If it's too many people with root/administrator account that can read everyone's mail causing fear, then move the mail server to a new, more secure box and only one person has the password (probably you should have sudo or similar setup so you can do admin tasks). Max > -----Original Message----- > From: gnupg-users-bounces at gnupg.org > [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Robert J. Hansen > Sent: 14 February 2008 05:24 > To: gnupg-users at gnupg.org > Subject: Re: Corporate use of gnupg > > Quoting gnupg at ethen.de: > > And what do they want to do with the recieved emails? The only > > possibility I see is to put everyone's private keys and > passowrds into > > a safe - then you can decrypt sent and received mail later. > > Same problem exists with PGP's ADK feature, which should > really be named an ARR, for Additional Recipient Request. > While ADK usage can be enforced within the ADK-using group > (mostly: there are some caveats), emails from outside the > group going in to the group are under no such restrictions. > > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > 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: PGP.sig Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From alex at bofh.net.pl Thu Feb 14 14:20:53 2008 From: alex at bofh.net.pl (Janusz A. Urbanowicz) Date: Thu, 14 Feb 2008 14:20:53 +0100 Subject: Safe decryption with GnuPG? In-Reply-To: <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <20080212105902.GC12525@skrewz.dk> <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> Message-ID: <20080214132053.GM13299@hell.pl> On Wed, Feb 13, 2008 at 11:41:53AM +0100, Krzysztof ?elechowski wrote: > > Dnia 12-02-2008, Wt o godzinie 11:59 +0100, Anders Breindahl pisze: > > Hello, > > > > On 200802010958, Krzysztof ?elechowski wrote: > > > 1. The decrypted information must not make it to any persistent medium > > > > Use full-disk encryption, as has been stated before. That way, you can > > be confident that nothing leaks into unencrypted places, since such do > > not exist in the running system. > > Full disk encryption makes the system unnecessarily slow, > especially if applied to swap space. > I am seeking an intermediate solution for desktop computers > where the amount of confidential data is small. > The system as a whole should not be affected > (unless, of course, it is a dedicated device, > but that is another story). I am under an stron impression that you want the system secure, without defining a coherent threat model. All the world's encryption and RAM-keeping won't protect you against TEMPEST. Sit back, define your threat: spooks? trojans? identity thieves? snoopy spouse? laptop thieves? You can't be secure against all possible threat. Decide which one you choose and concentrate on defending against this particular thread. Alex -- JID: alex at hell.pl PGP: 0x46399138 od zwracania uwagi na detale s? lekarze, adwokaci, programi?ci i zegarmistrze -- Czerski From rjh at sixdemonbag.org Thu Feb 14 15:44:32 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 14 Feb 2008 08:44:32 -0600 Subject: Safe decryption with GnuPG? In-Reply-To: <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <20080212105902.GC12525@skrewz.dk> <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> Message-ID: <79F6C1B5-0EEC-4D15-B71F-656EB1CDC7D3@sixdemonbag.org> > Full disk encryption makes the system unnecessarily slow, > especially if applied to swap space. Not necessarily so. A lot of people make a big deal out of a couple of papers published on how much whole-disk encryption slows down OpenBSD, but the flip side to that is the file and network systems of OpenBSD are not as efficient as those of many other OSes. If you've done your own empirical tests with your own OS and discovered it's too slow, then by all means, it's too slow. Otherwise, you may wish to do some empirical tests. > Certainly. > But unless the intruder is a root-kit, If the attacker has access to your hardware, then you're out of luck, the game is over. The only systems I can think of which may (may!) be exceptions to this are certain esoteric systems designed to reach the highest levels of Common Criteria evaluation, where classified and non- classified data operate on entirely different CPUs, entirely different RAM, etc., etc., with an information diode to control how information flows between them. From dennis at discworld.ping.de Thu Feb 14 15:30:50 2008 From: dennis at discworld.ping.de (Dennis Heitmann) Date: Thu, 14 Feb 2008 15:30:50 +0100 Subject: Multiple users of GPG In-Reply-To: References: Message-ID: <47B4509A.7050706@discworld.ping.de> You should tell more details, like the OS of your virtual server. Regards, Dennis Kammer, Kenneth A (Ken) schrieb: > I have installed GPG on a virtual server and everything works fine for > me. I now want to allow users to also encrypt their files using the > public and private keys I have established. But when another user > connects to my virtual server, they can not see any keys on the > keyring. Has anyone else come across this situation? Can anyone offer > me any suggestions to fix this problem? From dshaw at jabberwocky.com Thu Feb 14 19:07:05 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 14 Feb 2008 13:07:05 -0500 Subject: Safe decryption with GnuPG? In-Reply-To: <79F6C1B5-0EEC-4D15-B71F-656EB1CDC7D3@sixdemonbag.org> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <20080212105902.GC12525@skrewz.dk> <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> <79F6C1B5-0EEC-4D15-B71F-656EB1CDC7D3@sixdemonbag.org> Message-ID: <20080214180705.GA4466@jabberwocky.com> On Thu, Feb 14, 2008 at 08:44:32AM -0600, Robert J. Hansen wrote: >> Full disk encryption makes the system unnecessarily slow, >> especially if applied to swap space. > > Not necessarily so. A lot of people make a big deal out of a couple of > papers published on how much whole-disk encryption slows down OpenBSD, but > the flip side to that is the file and network systems of OpenBSD are not as > efficient as those of many other OSes. If you've done your own empirical > tests with your own OS and discovered it's too slow, then by all means, > it's too slow. Otherwise, you may wish to do some empirical tests. Definitely. It is also important to test with different methods of disk encryption. On most systems there are a number of tunable parameters that can significantly affect performance. For example, AES is going to be faster than 3DES. Does the kernel do disk readahead? If so, how much? Another question is how you're using it: a small file, written once and read many times will be much faster on average than a large file written once and read back once. It's not as simple as just saying "unnecessarily slow". I worked on a disk encryption system a while back. In design discussions, we spent a lot of time discussing potential performance issues and how that would affect the users of the system. Finally, I advised this: 1) Understand how you're going to use it. What are you protecting against? Given that encrypted disks are mounted and readable on a running system (effectively bypassing the encryption), often you're really just protecting against theft or a disk "sprouting legs" and going missing. 2) Tune the system for best performance for your particular usage. 3) Measure that performance. 4) Quantify in terms of money just how much the performance hit hurts you. Call this "A". 5) Find out how much it would cost to hire someone big with a gun to stand in front of the server 24/7. Call this "B". 6) Which is cheaper? I've found that at the end of step 6, people tend to ask the smart questions, and really start to understand step 1. David From aolsen at standard.com Thu Feb 14 19:07:05 2008 From: aolsen at standard.com (Alan Olsen) Date: Thu, 14 Feb 2008 10:07:05 -0800 Subject: Safe decryption with GnuPG? In-Reply-To: <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> Message-ID: <92A893260738B0408497A64189BC1E62032CE492@MSEXCHANGE305.corp.standard.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >From: Krzysztof Zelechowski >Dnia 12-02-2008, Wt o godzinie 11:59 +0100, Anders Breindahl pisze: >> Hello, >> >> On 200802010958, Krzysztof ?elechowski wrote: >> > 1. The decrypted information must not make it to any persistent >> > medium >> >> Use full-disk encryption, as has been stated before. That way, you can >> be confident that nothing leaks into unencrypted places, since such do >> not exist in the running system. > >Full disk encryption makes the system unnecessarily slow, >especially if applied to swap space. >I am seeking an intermediate solution for desktop computers where the amount of confidential data is small. >The system as a whole should not be affected >(unless, of course, it is a dedicated device, >but that is another story). I am using full disk encryption on Fedora 9 alpha and it has not caused much slowdown at all. Since it encrypted the entire logical volume swap is included. If hitting swap is an issue, you have other problems. (You need to buy more RAM.) It speed is really an issue here, then you need to look at a hardware upgrade. Of course, this depends on what operating system you are using. If you are using Windows, then I cannot help you. (Except maybe in getting off that insecure monstrocity.) -----BEGIN PGP SIGNATURE----- Version: 9.5.3 (Build 5003) wsBVAwUBR7SDSWqdmbpu7ejzAQp6pQgAvGW3It94LMUp9j2bIlP4QcdDbjCewo/N onxKwR06YKuCT+Vwme4ny0fONXDjk6KHtAsHSVYXS8JKU6b8fYbgeb1b/SvdzvjL 1mrALWJ6EKcVhmf2XjyEIT05FfMVefNCWz9XU6ZU3DgCp3hvdFJjiJq4UZu2lOGS qx31iO9vDSyYxwQECSIyCcI9HCpvRuQyBQbSOeMMGe2HqHiYoISVeFU/HYdXF3Dn 7LuWxhOZZkEG3x8esVLM85qIq5MY8oNoLJDbMxXvhxqFZAvrnlS74tGMfZ6iHKYU I15NIdmuyomd35+q4mdwFz5C6DnDHyNgHrAXfOcm3UUZO7RObnVRJQ== =UnvY -----END PGP SIGNATURE----- From skrewz at skrewz.dk Thu Feb 14 22:02:03 2008 From: skrewz at skrewz.dk (Anders Breindahl) Date: Thu, 14 Feb 2008 22:02:03 +0100 Subject: Safe decryption with GnuPG? In-Reply-To: <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <20080212105902.GC12525@skrewz.dk> <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> Message-ID: <20080214210203.GA31296@skrewz.dk> Hello, On 200802131141, Krzysztof ?elechowski wrote: > Dnia 12-02-2008, Wt o godzinie 11:59 +0100, Anders Breindahl pisze: > > Use full-disk encryption, as has been stated before. > Full disk encryption makes the system unnecessarily slow, especially > if applied to swap space. I'm not under that impression. Besides, a (pessimistic) 5/2 latency rise/speed decrease of swap is not much of a loss. If one wanted speed, one would generally have to avoid swap, anyway, and the major slowdown with swap lies in the mechanics. > I am seeking an intermediate solution for desktop computers where the > amount of confidential data is small. My solution may just be an attempt at doing that. See below. > > As Robert stated, many of your other requirements are void, if your > > adversary gains control of your machine. > > Admittedly the protection will never be perfect but I would like it to > be as good as can be. Right. But to that purpose, hiding from non-rootkit (?) cracks still seem like a bad way of using your time. Leave the assumption-that-the-administrator-doesn't-know-his-stuff work to Microsoft, and let's assume that the user isn't compromised (or stupid). > > > Can you direct me to some implementation meeting these > > > requirements? > > > > I wrote a such script once, that satisfies much of (the serious > > amongst) your requirements. Email me personally, if you're > > interested. > > If you are so kind, or just the idea if you do not want it to be > adapted and published. It's not at all what you seem to want. But I've refactored a bit and made it more serious. It's available at: http://publish.skrewz.dk/encfilewrapper.sh Regards, skrewz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: Digital signature URL: From matt at mattstone.net Fri Feb 15 03:00:09 2008 From: matt at mattstone.net (Matt Richards) Date: Fri, 15 Feb 2008 02:00:09 +0000 Subject: pgp servers hanging Message-ID: <20080215020009.GA17587@mattstone.net> Hello, I'm having an issue with GnuPG, I currently use it with mutt and everything was ok but now when I view an email that has sign ed data and I dont have the key of the person that signed the email, mutt hangs. This appears to be due to gnupg attempting to request the key via a keyserver and not having much success. The keyserver I was using with no problems is hkp://subkeys.pgp.net and since then I have tried a number of keyservers including mit's without much success, I did find one keyserver that i could connect to (LDAP based i think) but there didn't appear to be many keys avaliable. I'm not behind any proxy servers or anything like that. Does anybody know what might be going on? or are the keyservers just down? Thanks, Matt. -- File not found. Should I fake it? (Y/N) Matt Richards -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From JPClizbe at tx.rr.com Fri Feb 15 22:23:52 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Fri, 15 Feb 2008 15:23:52 -0600 Subject: pgp servers hanging In-Reply-To: <20080215020009.GA17587@mattstone.net> References: <20080215020009.GA17587@mattstone.net> Message-ID: <47B602E8.3070007@tx.rr.com> Matt Richards wrote: > Hello, > > I'm having an issue with GnuPG, I currently use it with mutt and everything > was ok but now when I view an email that has signed data and I dont have the > key of the person that signed the email, mutt hangs. > > This appears to be due to gnupg attempting to request the key via a keyserver > and not having much success. > > The keyserver I was using with no problems is hkp://subkeys.pgp.net and since > then I have tried a number of keyservers including mit's without much success, I > did find one keyserver that i could connect to (LDAP based i think) but there > didn't appear to be many keys avaliable. > > I'm not behind any proxy servers or anything like that. > > Does anybody know what might be going on? or are the keyservers just down? Are they down? Mine's not. try hkp://pool.sks-keyservers.net pool.sks-keyservers.net is a DNS round-robin consisting of 25 online and synced SKS keyservers. hkp://subkeys.pgp.net is a six server round-robin -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks keyserver hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 658 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Sat Feb 16 01:14:41 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 15 Feb 2008 19:14:41 -0500 Subject: pgp servers hanging In-Reply-To: <20080215020009.GA17587@mattstone.net> References: <20080215020009.GA17587@mattstone.net> Message-ID: <20080216001441.GA9797@jabberwocky.com> On Fri, Feb 15, 2008 at 02:00:09AM +0000, Matt Richards wrote: > Hello, > > I'm having an issue with GnuPG, I currently use it with mutt and everything was ok but now when I view an email that has sign > ed data and I dont have the key of the person that signed the email, mutt hangs. > > This appears to be due to gnupg attempting to request the key via a keyserver and not having much success. > > The keyserver I was using with no problems is hkp://subkeys.pgp.net and since then I have tried a number of keyservers including mit's without much success, I did find one keyserver that i could connect to (LDAP based i think) but there didn't appear to be many keys avaliable. > > I'm not behind any proxy servers or anything like that. > > Does anybody know what might be going on? or are the keyservers just down? subkeys.pgp.net is a virtual keyserver. The name actually points to multiple different servers run by different people. If any of these servers are down, keyserver requests can block for a while until there is a timeout and GPG gives up. You can change the timeout value (it defaults to 2 minutes) with: keyserver-options timeout=xxxxx Where xxxxx is the number of seconds to wait for the keyserver. David From noiano at x-privat.org Sat Feb 16 16:15:50 2008 From: noiano at x-privat.org (Noiano) Date: Sat, 16 Feb 2008 16:15:50 +0100 Subject: pgp servers hanging In-Reply-To: <47B602E8.3070007__10743.7500417747$1203110864$gmane$org@tx.rr.com> References: <20080215020009.GA17587@mattstone.net> <47B602E8.3070007__10743.7500417747$1203110864$gmane$org@tx.rr.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 John Clizbe wrote: > Are they down? Mine's not. > > try hkp://pool.sks-keyservers.net > > pool.sks-keyservers.net is a DNS round-robin consisting of 25 online and synced > SKS keyservers. hkp://subkeys.pgp.net is a six server round-robin > Are there any pgp server quality statistics like remailers? For example: "this server is fast and reliable, this other often goes timeout" Noiano -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iE8DBQFHtv4m+JjGoasQ6NIRCObtAN4m1LwmSoWwNU5Kfg6PcfB+OQjYR3HOveUi kRbuAN9ytkrMRyFuSNLT4OOPVHwHOseKCnfrUZQnekAX =2QTs -----END PGP SIGNATURE----- From 210525p42015 at denstarfarm.us Sun Feb 17 15:33:18 2008 From: 210525p42015 at denstarfarm.us (Robert D.) Date: Sun, 17 Feb 2008 09:33:18 -0500 Subject: Q about verifying sig's Message-ID: <47B845AE.8010009@denstarfarm.us> I was reading traffic from Daigle, on PGP-Basics and noticed a lack of ability to verify his signed email. In fact, I thought I'd already had his imported and verified. The GPG window pop-up was this screenshot seen here: http://img176.imageshack.us/img176/2121/picture1qt8.jpg a line in it suggested I look at http://www.gnupg.org/faq/subkey-cross-certify.html%20for%20more%20information when I got there, I was met with error 404 ... Thus, two questions, what original gpg key-verification error was the pop-up talking about and how do I find that page I was originally referred to? thanks From 210525p42015 at denstarfarm.us Sun Feb 17 16:10:22 2008 From: 210525p42015 at denstarfarm.us (Robert D.) Date: Sun, 17 Feb 2008 10:10:22 -0500 Subject: Q about verifying sig's In-Reply-To: References: <47B845AE.8010009@denstarfarm.us> Message-ID: <47B84E5E.8020602@denstarfarm.us> David Shaw said the following: > > http://www.gnupg.org/faq/subkey-cross-certify.html%20for%20more%20information > > http://www.gnupg.org/faq/subkey-cross-certify.html oh, ouch, I am stupido! I must have, or rather *did*, highlight waaaay too much for the link, then didn't bother to read the URL after rx-ing the error and thanks.... because what I read on that page was something I did not know. From dshaw at jabberwocky.com Sun Feb 17 16:13:48 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 17 Feb 2008 10:13:48 -0500 Subject: Q about verifying sig's In-Reply-To: <47B845AE.8010009@denstarfarm.us> References: <47B845AE.8010009@denstarfarm.us> Message-ID: <20080217151348.GA15749@jabberwocky.com> On Sun, Feb 17, 2008 at 09:33:18AM -0500, Robert D. wrote: > I was reading traffic from Daigle, on PGP-Basics and noticed a lack of > ability to verify his signed email. In fact, I thought I'd already had his > imported and verified. > > The GPG window pop-up was this screenshot seen here: > > http://img176.imageshack.us/img176/2121/picture1qt8.jpg > > a line in it suggested I look at > http://www.gnupg.org/faq/subkey-cross-certify.html%20for%20more%20information > > when I got there, I was met with error 404 ... The page you are looking for is http://www.gnupg.org/faq/subkey-cross-certify.html David From mlisten at hammernoch.net Sun Feb 17 15:49:58 2008 From: mlisten at hammernoch.net (=?ISO-8859-1?Q?Ludwig_H=FCgelsch=E4fer?=) Date: Sun, 17 Feb 2008 15:49:58 +0100 Subject: Q about verifying sig's In-Reply-To: <47B845AE.8010009@denstarfarm.us> References: <47B845AE.8010009@denstarfarm.us> Message-ID: <47B84996.7040703@hammernoch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Robert D. wrote on 17.02.2008 15:33 Uhr: > I was reading traffic from Daigle, on PGP-Basics and noticed a lack of > ability to verify his signed email. In fact, I thought I'd already had his > imported and verified. > > The GPG window pop-up was this screenshot seen here: > > http://img176.imageshack.us/img176/2121/picture1qt8.jpg > > a line in it suggested I look at > http://www.gnupg.org/faq/subkey-cross-certify.html%20for%20more%20information > > when I got there, I was met with error 404 ... > > Thus, two questions, what original gpg key-verification error was the > pop-up talking about and > > how do I find that page I was originally referred to? It seems you have copied too much out of enigmails information window, the link should be http://www.gnupg.org/faq/subkey-cross-certify.html and is well available here. This page should give you enogh to read on the subject. HTH Ludwig -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBR7hJllYnpxVXVowdAQp1swgAlPg/UGpaZtNikUetZEet3sz87moBjjvb xurBgB8xgI9T8z22XiaNeeYeNrrKucN7f6UdUL1+0aownnD3yggQP5HAw/dozy1i lKafgP9qAm27qMRBWQlWQG9n1Zz7MTYXVFmjwWZfmoilAUAn4oaoulIQjlgqYzKq YElLjdS+qgd1KvtPvOH66Qi5a6QBL0o1wzvy4+5HRhwHU/wiAC4i3gxDfMNlffeK 6R8aicJwCSwbfts0AP50LZCi/I6vSqdZymIzp2UsLhOM37J0b/SpmeplRn6/L0/0 8sznf/32I3fvmcE5eBYl/1x560zKXwsx2kjiSJBrTJfOepUxHe110Q== =kORh -----END PGP SIGNATURE----- From grahamtodd2 at googlemail.com Mon Feb 18 17:05:20 2008 From: grahamtodd2 at googlemail.com (Graham) Date: Mon, 18 Feb 2008 16:05:20 +0000 Subject: pgp servers hanging In-Reply-To: References: <20080215020009.GA17587@mattstone.net> <47B602E8.3070007__10743.7500417747$1203110864$gmane$org@tx.rr.com> Message-ID: On Sat, 16 Feb 2008 16:15:50 +0100 Noiano wrote: > Are there any pgp server quality statistics like remailers? For > example: "this server is fast and reliable, this other often goes > timeout" > > Noiano Yes, and regularly given to this list - forget by whom as I've just cleared a lot of emails. -- Graham Todd From stein at ir.iit.edu Sun Feb 17 20:30:56 2008 From: stein at ir.iit.edu (S3) Date: Sun, 17 Feb 2008 13:30:56 -0600 Subject: pinentry stdin problems In-Reply-To: References: Message-ID: <47B88B70.2000603@ir.iit.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I recently upgraded from GPG v1.4 to GPG v2. Previously, I was able to do this: tar c | gpg -s > a.tar.gpg However, with the new version that uses pinentry, it does not allow me to insert my password whenever I redirect stdin as above. I don't even get the ncurses password entry box. Is there a way to make this work as before? Can pinentry be made to fallback to the plain text password entry, should the other ones fail? - -- echo 'scale=49861;sqrt(7)' | BC_LINE_LENGTH=81 bc -l \ | tail -n 1 | tr '0-9' 'eeniSg tlr' -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHuItwxzVgPqtIcfsRAoXBAJ4i+i/Ne3+W8IqLnV0GCbQQuJmC9gCfUYW0 chlLNEhB5CK9M5ecLJzxch4= =Z3gc -----END PGP SIGNATURE----- From dbotham at infoblox.com Tue Feb 19 02:35:33 2008 From: dbotham at infoblox.com (David Botham) Date: Mon, 18 Feb 2008 17:35:33 -0800 Subject: Cannot Set the Expiration Date on Secure Subkeys Message-ID: <083AD28775D80048925EE4273AFD4103019C084C@thor.infoblox.com> All, I am having problems setting the expiration date on my private subkey. I can set it, however, when I quit and then re-edit the key, the expiration date is set to 'never', instead of what I had set it to in the previous editing session. I am missing something? Here is a transcript of my gpg sessions that demonstrate this problem (key ID A734F56B is the one that switches back to 'never'): ======================================================================= C:\local\David\gpg>gpg --edit-key test at nowhere.com gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Secret key is available. pub 1024D/8B1A6E74 created: 2008-02-18 expires: never usage: SC trust: ultimate validity: ultimate sub 1024g/890CB2FF created: 2008-02-18 expires: never usage: E [ultimate] (1). Test User Command> toggle sec 1024D/8B1A6E74 created: 2008-02-18 expires: never ssb 1024g/890CB2FF created: 2008-02-18 expires: never (1) Test User Command> toggle pub 1024D/8B1A6E74 created: 2008-02-18 expires: never usage: SC trust: ultimate validity: ultimate sub 1024g/890CB2FF created: 2008-02-18 expires: never usage: E [ultimate] (1). Test User Command> addkey Key is protected. You need a passphrase to unlock the secret key for user: "Test User " 1024-bit DSA key, ID 8B1A6E74, created 2008-02-18 Please select what kind of key you want: (2) DSA (sign only) (4) Elgamal (encrypt only) (5) RSA (sign only) (6) RSA (encrypt only) Your selection? 4 ELG-E keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 1024 Requested keysize is 1024 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 1 Key expires at 02/19/08 15:44:11 Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. ++++++++++++++++++++++++++++++++++++++++^^^ pub 1024D/8B1A6E74 created: 2008-02-18 expires: never usage: SC trust: ultimate validity: ultimate sub 1024g/890CB2FF created: 2008-02-18 expires: never usage: E sub 1024g/A734F56B created: 2008-02-18 expires: 2008-02-19 usage: E [ultimate] (1). Test User Command> toggle sec 1024D/8B1A6E74 created: 2008-02-18 expires: never ssb 1024g/890CB2FF created: 2008-02-18 expires: never ssb 1024g/A734F56B created: 2008-02-18 expires: 2008-02-19 (1) Test User Command> q Save changes? (y/N) y C:\local\David\gpg>gpg --edit-key test at nowhere.com gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Secret key is available. pub 1024D/8B1A6E74 created: 2008-02-18 expires: never usage: SC trust: ultimate validity: ultimate sub 1024g/890CB2FF created: 2008-02-18 expires: never usage: E sub 1024g/A734F56B created: 2008-02-18 expires: 2008-02-19 usage: E [ultimate] (1). Test User Command> toggle sec 1024D/8B1A6E74 created: 2008-02-18 expires: never ssb 1024g/890CB2FF created: 2008-02-18 expires: never ssb 1024g/A734F56B created: 2008-02-18 expires: never (1) Test User ======================================================================= Any help you can give me would me sincerely appreciated. Thank you, David From jmoore3rd at bellsouth.net Tue Feb 19 05:09:52 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Mon, 18 Feb 2008 23:09:52 -0500 Subject: Cannot Set the Expiration Date on Secure Subkeys In-Reply-To: <083AD28775D80048925EE4273AFD4103019C084C@thor.infoblox.com> References: <083AD28775D80048925EE4273AFD4103019C084C@thor.infoblox.com> Message-ID: <47BA5690.7060909@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 - -------- Original Message -------- Subject: Cannot Set the Expiration Date on Secure Subkeys From: David Botham To: gnupg-users at gnupg.org Date: Monday, February 18, 2008 8:35:33 PM > All, > > I am having problems setting the expiration date on my private subkey. > I can set it, however, when I quit and then re-edit the key, the > expiration date is set to 'never', instead of what I had set it to in > the previous editing session. > > I am missing something? Are You finishing with: quit or save If You just terminate with 'quit' then everything You just did is forgotten. :( Terminate with 'save' and all Your Setting changes will take and the job will be done. JOHN ;) Timestamp: Monday 18 Feb 2008, 23:09 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9-svn4691: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJHulaOAAoJEBCGy9eAtCsPxjcH/ifiKJ+qO3jaDFu8vHSQh0TR xf6+2n0sr8eocr6e/pM1Y9v0GVzi2WWS8PAY82Cbp1eoZhJib3t6HDtGhaeRm43r CUUsBgFh6M90Yd2TEjW9DnGsmWcuH0F1XNp/k0rta2dlXG/+gEnFbBltkHdlwi9R W6sN9OyyBI3Ql72juhvlY6RupEekGMF7qnHpJJXX5B9/ytEQmWTqOOQWqbFX7w2r Vw5qH5hjjqwdy/112j0ZD+ZJue2V7sMreeOwU/TuC3En8Ymq9OQoHG9pQAawHtDi YcrLkmM/MnPQ3705iIjmYTHkgMkm9u9Xe257su9zgwM7k2hfw97L1Sk8xJQAD5k= =EtlF -----END PGP SIGNATURE----- From program.spe at home.pl Fri Feb 15 14:31:01 2008 From: program.spe at home.pl (Krzysztof =?UTF-8?Q?=C5=BBelechowski?=) Date: Fri, 15 Feb 2008 14:31:01 +0100 Subject: Safe decryption with GnuPG? In-Reply-To: <20080214210203.GA31296@skrewz.dk> References: <1201856292.6474.49.camel@a1dmin.vola.spe.com.pl> <20080212105902.GC12525@skrewz.dk> <1202899313.6691.10.camel@a1dmin.vola.spe.com.pl> <20080214210203.GA31296@skrewz.dk> Message-ID: <1203082261.6529.12.camel@a1dmin.vola.spe.com.pl> Dnia 14-02-2008, Cz o godzinie 22:02 +0100, Anders Breindahl pisze: > > Admittedly the protection will never be perfect but I would like it to > > be as good as can be. > > Right. But to that purpose, hiding from non-rootkit (?) cracks still > seem like a bad way of using your time. Leave the > assumption-that-the-administrator-doesn't-know-his-stuff work to > Microsoft, and let's assume that the user isn't compromised (or stupid). Good guess, the idea of purging sensitive data from memory as soon as possible comes from our favourite bug provider indeed. > > > > > Can you direct me to some implementation meeting these > > > > requirements? > > > > > > I wrote a such script once, that satisfies much of (the serious > > > amongst) your requirements. Email me personally, if you're > > > interested. > > > > If you are so kind, or just the idea if you do not want it to be > > adapted and published. > > It's not at all what you seem to want. But I've refactored a bit and > made it more serious. It's available at: > > http://publish.skrewz.dk/encfilewrapper.sh I never intended to make impression I want security by obscurity. I am sorry you have perceived my question this way; it seems I should have formulated it better. Quite interesting, although make_hard_to_read really should drop the ASCII encoding, as far as I am concerned. I like Steve's idea of using banner for that purpose where no better tool is available. Alternatively, we could convert it on the fly to image/png and send it to Firefox as a data URL (that is, without saving). Note: no "backupping" (backing up, if you please :-) Thx a 107, Chris. From texaskilt at yahoo.com Sat Feb 16 04:00:12 2008 From: texaskilt at yahoo.com (Texaskilt) Date: Fri, 15 Feb 2008 19:00:12 -0800 (PST) Subject: Corporate use of gnupg In-Reply-To: <20080210195726.GC12706@jabberwocky.com> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> Message-ID: <15514362.post@talk.nabble.com> I guess what we are wanting is for every mail user to have their own public/private key. This way they can encrypt their own email on the corporate system. In addition, every email would also be encrypted using the "corporate key" that would be in the hands of a select few (supposedly). For example, the sales force can send encrypted mail to each other, but when a salesperson leaves the company, the Email Admin can retreive and decrypt the email so that the salesperson's replacement can pick up their accounts without too much disruption. Looks like this is ADK. Is there any way to do this on gpg? Thanks, TK David Shaw wrote: > > On Wed, Feb 06, 2008 at 11:35:14AM -0800, Texaskilt wrote: >> >> Apologies if this has already been asked. Honestly, I did my homework >> and >> looked in the archives! >> >> I am wanting to setup up users to use GnuPG for encrypting email, mainly >> for >> internal e-mail. >> >> Unfortunately, the "powers-that-be" want everyone that encrypts an email >> to >> also encrypt it to the "corporate secret key". Their reasoning is that >> if a >> person leaves, they want to have access to the old emails in case there >> is a >> "business critical" email in there. > > This is essentially the rationale behind the "ADK" (additional > decryption key) feature of PGP. > >> Is there a way to "force" users to encrypt to a corporate key, in >> addition >> to the receipient's key? > > It depends on how strong the term "force" is. Even in PGP, the ADK > system can be circumvented if the person tries hard enough. > > If you trust your employees to not hack you, then you can just stick a > "encrypt-to (the keyid)" in everyone's gpg.conf file and give everyone > a copy of the corporate public key. > > Note that this isn't safe because of the crypto math. It's "safe" > because you can fire people that don't do it ;) > > David > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- View this message in context: http://www.nabble.com/Corporate-use-of-gnupg-tp15312177p15514362.html Sent from the GnuPG - User mailing list archive at Nabble.com. From kenneth_kammer at reyrey.com Mon Feb 18 13:00:02 2008 From: kenneth_kammer at reyrey.com (Kammer, Kenneth A (Ken)) Date: Mon, 18 Feb 2008 07:00:02 -0500 Subject: Multiple users of GPG Message-ID: The OS of the virtual server is Windows Server 2003 SR2. I'm using Windows XP systems to Remote Desktop into the virtual server. Thanks, Ken Kammer .NET Developer SIMS2 Team 937/485-8077 www.reyrey.com This message is confidential and may contain confidential information it is intended only for the individual[s] named herein. If this message is being sent from a member of the legal department, it may also be legally privileged. If you are not the named addressee[s] you must delete this email immediately do not disseminate, distribute or copy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From theprestig3 at gmail.com Tue Feb 19 03:23:19 2008 From: theprestig3 at gmail.com (Ronald Richardson) Date: Mon, 18 Feb 2008 21:23:19 -0500 Subject: a pgpme error Message-ID: I keep getting an error that says; gpgme gave error: no passphrase ---- does anyone know what could have caused it? Although it says it has no passphrase my key does has a passphrase and has been imported/export into my keyring when I ran my script. From nicholas.cole at gmail.com Tue Feb 19 13:28:17 2008 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 19 Feb 2008 12:28:17 +0000 Subject: Corporate use of gnupg In-Reply-To: <15514362.post@talk.nabble.com> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> Message-ID: On Sat, Feb 16, 2008 at 3:00 AM, Texaskilt wrote: > > Looks like this is ADK. Is there any way to do this on gpg? GPG does not implement ADK. I think that, historically, it seemed too much like the kind of key escrow systems that governments have from time to time talked about wanting, although clearly there is a difference. I know that ADK can be circumvented by a determined attacker, but it strikes me as a useful feature, and I have never quite understood the opposition to it. It would have made encryption more palatable in corporate settings, which surely would have been a good thing! But I'm not an expert, and I'm probably missing a point somewhere... From christoph.anton.mitterer at physik.uni-muenchen.de Tue Feb 19 13:00:51 2008 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Tue, 19 Feb 2008 13:00:51 +0100 Subject: /dev/tty problem and other questions Message-ID: <1203422451.1093.29.camel@etppc19> Hi. I'm writing a support script for using dm-crypt/luks for root-filesystem encryption, that will be used from an initramfs. The iniramfs-scripts parse /etc/cryptab which specifies the file that contains the key. It also allows to specify a so called keyscript, that is invoked with the keyfile as parameter. Those keyscripts are used to support stuff like ssl/openct/opensc-encrypted keys and are expected to write (only) the key to stdout. Unfortunately there is no finished script to support gpg encrypted key-files and I'd like to write one, but I have some problems: 1) When using a basic test-keyscript like #!/bin/sh gpg --decrypt "$1" and I boot from the initramfs I'll get the following error: gpg:cannot open /dev/tty: No such device or address. and gpg doesn't offer a prompt to enter the passphares Of course I've googled around but I found no practical solution. The --no-tty --pasphrase-fd 0 is not a solution as it will print the password in cleartext. read -s only available in bash but not sh. Any ideas here? 2) gpg creates some files in ~/.gnupg which is not a real problem in the initramfs but I'd like to avoid this, so no files should be written to disk at all. Is this fully achieved by using --no-options or do I have to use other stuff like --no-random-seed-file or something else? 3) As everything written to stdout is used as key, I must secure that only the decrypted data is written to stdout. I know the --batch option but it doesn't specify if it prints anything (except the decrypted data) to stdout and it also disables promting for the passphrase (see point 1). Of course error meassages should still be printed, but are they always written to stderr? What about informal messages (like no mdc detected)? Are they written to stderr or stdout? 4) As I cannot check the return value of gpg if the decryption succeeded (the output from the keyscript is piped to cryptsetup) I must have other means to check whether the decryption was successful. Any ideas here? And what does gpg write to stdout, if the decryption fails? Thans and best wishes, Chris. From david at miradoiro.com Tue Feb 19 14:23:18 2008 From: david at miradoiro.com (=?iso-8859-1?Q?David_Pic=F3n_=C1lvarez?=) Date: Tue, 19 Feb 2008 14:23:18 +0100 Subject: Corporate use of gnupg References: <15312177.post@talk.nabble.com><20080210195726.GC12706@jabberwocky.com><15514362.post@talk.nabble.com> Message-ID: <002b01c872fa$98998ed0$0302a8c0@Nautilus> > I know that ADK can be circumvented by a determined attacker, but it > strikes me as a useful feature, and I have never quite understood the > opposition to it. It would have made encryption more palatable in > corporate settings, which surely would have been a good thing! IMO there are two possibilities: 1) your users are forgetful but honest, 2) your users are dishonest. For case 1, an equivalent of ADK can be obtained with a line on GPG's configuration file. For case 2, you are screwed, and ADK is only going to give you a false sense of security. Thus ADK is either pointless or unnecessary. --David. From rjh at sixdemonbag.org Tue Feb 19 14:25:32 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 19 Feb 2008 07:25:32 -0600 Subject: Corporate use of gnupg In-Reply-To: References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> Message-ID: <47BAD8CC.8050804@sixdemonbag.org> Nicholas Cole wrote: > I know that ADK can be circumvented by a determined attacker, but it > strikes me as a useful feature, and I have never quite understood the > opposition to it. PGP Corporation has a patent on ADKs. That's the number one reason why the other OpenPGP implementations do not support it. From dshaw at jabberwocky.com Tue Feb 19 14:33:55 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 19 Feb 2008 08:33:55 -0500 Subject: Corporate use of gnupg In-Reply-To: <15514362.post@talk.nabble.com> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> Message-ID: <20080219133354.GA13415@jabberwocky.com> On Fri, Feb 15, 2008 at 07:00:12PM -0800, Texaskilt wrote: > > I guess what we are wanting is for every mail user to have their own > public/private key. This way they can encrypt their own email on the > corporate system. > > In addition, every email would also be encrypted using the "corporate key" > that would be in the hands of a select few (supposedly). > > For example, the sales force can send encrypted mail to each other, but when > a salesperson leaves the company, the Email Admin can retreive and decrypt > the email so that the salesperson's replacement can pick up their accounts > without too much disruption. > > Looks like this is ADK. Is there any way to do this on gpg? Yes. Put "encrypt-to (the-adk-key)" in everyone's gpg.conf. Of course, they could turn around and take it right out again. Unless you have pretty tight control over the environment, ADKs or encrypt-tos are not foolproof (and that applies to both PGP and GPG). As I said before, note that this isn't safe because of the crypto math. It's "safe" because you can fire people who don't do it. David From email at sven-radde.de Tue Feb 19 14:57:57 2008 From: email at sven-radde.de (Sven Radde) Date: Tue, 19 Feb 2008 14:57:57 +0100 Subject: Corporate use of gnupg In-Reply-To: <20080219133354.GA13415@jabberwocky.com> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <20080219133354.GA13415@jabberwocky.com> Message-ID: <47BAE065.8060506@sven-radde.de> David Shaw schrieb: >> Looks like this is ADK. Is there any way to do this on gpg? >> > Yes. Put "encrypt-to (the-adk-key)" in everyone's gpg.conf. I thought that ADKs would work whenever encrypting to a key with that feature enabled (i.e. also for incoming emails)? I.e. it is per-key and not a per-user setting? Of course, for outgoing mail you'd still need the additional encrypt-to (unless you regularly encrypt to your own key which would have the ADK). Furthermore, PGP has this fascinating key-splitting options that allow you to distribute shares of a secret key to a group and define how many shares would be necessary to conduct secret-key operations. There, you would actually have "the math" ensuring that the boss can read the email. This would allow advances schemes like: "Either the original owner alone or the boss in cooperation with the company's notary public can decrypt mail." Or, leaving ADK-related use-cases aside, "3 of 5 board members are required to approve an order by digitally signing it." It seems that GnuPG has no capability to ensure decrypt-ability for incoming encrypted data, apart from outright key-escrow. It has been a while since I was last using the commercial PGPs, and I could remember falsely. So, feel free to correct me if I'm wrong (in particular, I have no idea whether these features are still present in recent (freeware) versions). cu, Sven From nicholas.cole at gmail.com Tue Feb 19 15:19:18 2008 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 19 Feb 2008 14:19:18 +0000 Subject: Corporate use of gnupg In-Reply-To: References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> Message-ID: Just to address the original point of the thread, though, could you not use sub-keys to achieve the most of the effect you want? Have everyone share an encryption/decryption subkey, but have their own separate signing keys. The disadvantage would be that anyone in the group (ie not just an administrator or the like) could decrypt anyone else's email - but in many settings that might be acceptable or even advantageous. Best, N From nicholas.cole at gmail.com Tue Feb 19 15:54:07 2008 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Tue, 19 Feb 2008 14:54:07 +0000 Subject: Corporate use of gnupg In-Reply-To: <002b01c872fa$98998ed0$0302a8c0@Nautilus> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <002b01c872fa$98998ed0$0302a8c0@Nautilus> Message-ID: On Tue, Feb 19, 2008 at 1:23 PM, David Pic?n ?lvarez wrote: > > I know that ADK can be circumvented by a determined attacker, but it > > strikes me as a useful feature, and I have never quite understood the > > opposition to it. It would have made encryption more palatable in > > corporate settings, which surely would have been a good thing! > > IMO there are two possibilities: 1) your users are forgetful but honest, 2) > your users are dishonest. > > For case 1, an equivalent of ADK can be obtained with a line on GPG's > configuration file. > > For case 2, you are screwed, and ADK is only going to give you a false sense > of security. > > Thus ADK is either pointless or unnecessary. This just simply isn't true. Putting a line in a config file may be fine for internal mail, but does nothing to help you to be able to decrypt mail sent from outside your organisation. It also locks everyone into using gpg - I thought the whole point of gpg / opengpg was to be inter-operative. Secondly, there might be any number of reasons why a user might not be able to give you access to a key. He might be incompetent, he might be unexpectedly ill or worse. And so on, and so forth. But my real point is this: gpg in most areas says "This is a tool. Your threat models will vary, and we give you a tool which you can deploy". But in the area of ADK, even when for years people have said on this list and elsewhere, "ADK would help with the threat/organizational model we have", GPG refuses to help. "alter your config file" solves (at best) half of the problem. There may be very good technical reasons why ADKs are a bad idea, but I've never seen them explained. There was, I know, an attack on PGP which relied upon them a while ago, but IIRC that bug was easily fixed. Best wishes, N From dbotham at infoblox.com Tue Feb 19 16:29:02 2008 From: dbotham at infoblox.com (David Botham) Date: Tue, 19 Feb 2008 07:29:02 -0800 Subject: Cannot Set the Expiration Date on Secure Subkeys In-Reply-To: <47BA5690.7060909@bellsouth.net> References: <083AD28775D80048925EE4273AFD4103019C084C@thor.infoblox.com> <47BA5690.7060909@bellsouth.net> Message-ID: <083AD28775D80048925EE4273AFD4103019C0894@thor.infoblox.com> John, Thanks for you reply. > > Are You finishing with: > > quit > > or > > save Yes, I used quit, however, I did Save on exit... See below... Notice that for key 'A734F56B', the public subkey has an expiration of 2008-02-19, however, after exiting and re-editing, the secret subkey has an expiration of 'never' (see my original post for the complete transcript where this subkey initially has an expiration of 2008-02-19): Command> q Save changes? (y/N) y C:\local\David\gpg>gpg --edit-key test at nowhere.com gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc. This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the file COPYING for details. Secret key is available. pub 1024D/8B1A6E74 created: 2008-02-18 expires: never usage: SC trust: ultimate validity: ultimate sub 1024g/890CB2FF created: 2008-02-18 expires: never usage: E sub 1024g/A734F56B created: 2008-02-18 expires: 2008-02-19 usage: E [ultimate] (1). Test User Command> toggle sec 1024D/8B1A6E74 created: 2008-02-18 expires: never ssb 1024g/890CB2FF created: 2008-02-18 expires: never ssb 1024g/A734F56B created: 2008-02-18 expires: never (1) Test User From dshaw at jabberwocky.com Tue Feb 19 17:06:28 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 19 Feb 2008 11:06:28 -0500 Subject: Cannot Set the Expiration Date on Secure Subkeys In-Reply-To: <083AD28775D80048925EE4273AFD4103019C084C@thor.infoblox.com> References: <083AD28775D80048925EE4273AFD4103019C084C@thor.infoblox.com> Message-ID: <20080219160628.GA16013@jabberwocky.com> On Mon, Feb 18, 2008 at 05:35:33PM -0800, David Botham wrote: > All, > > I am having problems setting the expiration date on my private subkey. > I can set it, however, when I quit and then re-edit the key, the > expiration date is set to 'never', instead of what I had set it to in > the previous editing session. > > I am missing something? Nope, you're quite right, and it's a bug. It's a display bug, as the right data makes it into the key packet, but --edit-key doesn't properly display it. You can see this by doing a --list-secret-keys on that particular key, and seeing the proper expiration is set. David From shaz.zeb at aciworldwide.com Tue Feb 19 17:15:40 2008 From: shaz.zeb at aciworldwide.com (shaz.zeb at aciworldwide.com) Date: Tue, 19 Feb 2008 10:15:40 -0600 Subject: Importing GnuPG (v1.48 on Win32) Keys into IBMpgp (on Unix) Message-ID: Hello all, I can import IBMpgp generated pubkeys into GnuPG (on my windows machine), but am unable to do so the other way around. If I try to import the GnuPG created keys into IBMpgp, I get "Failed to verify the signature" Thoughts? Cheers, Shaz Zeb -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudolf.deilmann at gmail.com Tue Feb 19 16:19:02 2008 From: rudolf.deilmann at gmail.com (Rudolf Deilmann) Date: Tue, 19 Feb 2008 16:19:02 +0100 Subject: /dev/tty problem and other questions In-Reply-To: <1203422451.1093.29.camel@etppc19> References: <1203422451.1093.29.camel@etppc19> Message-ID: <47baf318.0405560a.69af.0d03@mx.google.com> Am Tue, 19 Feb 2008 13:00:51 +0100 schrieb Christoph Anton Mitterer : > 1) When using a basic test-keyscript like > > #!/bin/sh > gpg --decrypt "$1" > > and I boot from the initramfs I'll get the following error: > gpg:cannot open /dev/tty: No such device or address. > and gpg doesn't offer a prompt to enter the passphares > > Of course I've googled around but I found no practical solution. > The --no-tty --pasphrase-fd 0 is not a solution as it will print the > password in cleartext. > > read -s only available in bash but not sh. > > > Any ideas here? a) copy stty to your initial ramdisk -- stty_orig=`stty -g 4) As I cannot check the return value of gpg if the decryption > succeeded (the output from the keyscript is piped to cryptsetup) I > must have other means to check whether the decryption was successful. Do it in two steps? CRYPTSETUP_PASS=$(echo "$PASS" | gpg -d --passphrase-fd 0 ...) if [ "$?" -eq "0" ]; then echo "$CRYPTSETUP_PASS" | cryptsetup ...... .... From wk at gnupg.org Tue Feb 19 18:21:36 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 19 Feb 2008 18:21:36 +0100 Subject: Corporate use of gnupg In-Reply-To: <47BAD8CC.8050804@sixdemonbag.org> (Robert J. Hansen's message of "Tue, 19 Feb 2008 07:25:32 -0600") References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <47BAD8CC.8050804@sixdemonbag.org> Message-ID: <873arorhen.fsf@wheatstone.g10code.de> On Tue, 19 Feb 2008 14:25, rjh at sixdemonbag.org said: > PGP Corporation has a patent on ADKs. That's the number one reason > why the other OpenPGP implementations do not support it. Frankly, I did not knew about this patent until now. I consider the ADK the wrong solution to a problem which can't be solved by a tool. The assumed threat model is that an encrypted mail is received by an employee and then other employees are not able to read this mail. In particular if the original recipient is on vacation or not anymore with the company. Or well, he willfully keeps that (company) mail private. The latter case is actually identical to snail mail: How do you assure that all mail to a company really receives the company and not just one person? The internal post office opens the envelope, stamps it, sometimes makes a copy and then distributes it to the actual recipient. Problem solved. Also solves the problem of keeping archives of all business mail (which is a legal requirment in Germany). You can and need do do the same with email: Either use a central gateway or create pool keys for the employees. It is merely an organisational matter that an employee does not use his private key for business tasks. And if he does anyway, it is the same as with snail mail: The address on the envelope is marked "private" and not to be opened by the company. We won't add ARR (aka ADK) to GnuPG. It would be more useful to add a re-encode feature to add another public or symmetric key for decryption. A mail framework may the use this to enforce a mail policy. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From aolsen at standard.com Tue Feb 19 18:38:25 2008 From: aolsen at standard.com (Alan Olsen) Date: Tue, 19 Feb 2008 09:38:25 -0800 Subject: Corporate use of gnupg In-Reply-To: Message-ID: <92A893260738B0408497A64189BC1E62032CE49D@MSEXCHANGE305.corp.standard.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >From: Nicholas Cole >Sent: Tuesday, February 19, 2008 6:54 AM >To: gnupg-users at gnupg.org >Subject: Re: Corporate use of gnupg >On Tue, Feb 19, 2008 at 1:23 PM, David Pic?n ?lvarez wrote: >> > I know that ADK can be circumvented by a determined attacker, but it >> > strikes me as a useful feature, and I have never quite understood >> the > opposition to it. It would have made encryption more palatable >> in > corporate settings, which surely would have been a good thing! >> >> IMO there are two possibilities: 1) your users are forgetful but >> honest, 2) your users are dishonest. >> >> For case 1, an equivalent of ADK can be obtained with a line on GPG's >> configuration file. >> >> For case 2, you are screwed, and ADK is only going to give you a >> false sense of security. >> >> Thus ADK is either pointless or unnecessary. >This just simply isn't true. >Putting a line in a config file may be fine for internal mail, but does nothing to help you to be able to decrypt mail sent from outside your organisation. >It also locks everyone into using gpg - I thought the whole point of gpg / opengpg was to be inter-operative. >Secondly, there might be any number of reasons why a user might not be able to give you access to a key. He might be incompetent, he might be unexpectedly >ill or worse. And so on, and so forth. >But my real point is this: gpg in most areas says "This is a tool. Your threat models will vary, and we give you a tool which you can deploy". But in the >area of ADK, even when for years people have said on this list and elsewhere, "ADK would help with the threat/organizational model we have", GPG refuses to >help. "alter your config file" solves (at best) half of the problem. >There may be very good technical reasons why ADKs are a bad idea, but I've never seen them explained. There was, I know, an attack on PGP which relied >upon them a while ago, but IIRC that bug was easily fixed. Someone else brought up the issue of the technique being patented. (Seems like a pretty obvious idea, but so are most software patents.) In a corporate setting, you really just want key escrow. Have a "official" company signing key. When new employees come on board, they are issued a PGP/GPG key that is signed and the secret key data is copied to non-volitile media and stored in a safe. It is only available under restricted circumstances (to prevent managers from exploiting the keys for their own gain). It also gives some authenticity to the key by having some sort of web of trust internally. Something like this takes manpower and time to manage, but so does manageing employee keycards and other authorization data. Not that I have ever seen a company that does this. Even companies that make heavy use of encryption do not seem to have anyone at a mamagement level that understands how it needs to be managed. -----BEGIN PGP SIGNATURE----- Version: 9.5.3 (Build 5003) wsBVAwUBR7sUEWqdmbpu7ejzAQo+CQf/apv9Vb0gI8fpaURwxyXJlxcJCNfOcnMU WwBQxdL0p2v6H+H8OMf+seAMixmoNl9EzT3NMalmdISP6H9g0656Fte+IemawBOj N0gPB/i2FqmbgW7XlEaULl8LTqwBKfZ9VCqas/HC+ur4q1BrcgHOmlp939R+9fdC u+ByXAF+bdLAwKMoRj5+rCLZ8UV1YYPe8mKIVIlVp4O62iLRENpPtFDF8hYJMO3O 3YSZ/L/+Gq8wjfB690ufhMs2Lvb3QF+8rFx2jsopEPVAedjKjtKq/1h3KbXql6// VrtGCkMM3wmxDkdRDmAwMhNMSyo5TPoeA1VITRQAoc2IR/MzxBrAmg== =8YBw -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Tue Feb 19 18:49:56 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 19 Feb 2008 12:49:56 -0500 Subject: ADKs (was: Corporate use of gnupg) In-Reply-To: References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <002b01c872fa$98998ed0$0302a8c0@Nautilus> Message-ID: <20080219174956.GB16013@jabberwocky.com> On Tue, Feb 19, 2008 at 02:54:07PM +0000, Nicholas Cole wrote: > On Tue, Feb 19, 2008 at 1:23 PM, David Pic?n ?lvarez > wrote: > > > I know that ADK can be circumvented by a determined attacker, but it > > > strikes me as a useful feature, and I have never quite understood the > > > opposition to it. It would have made encryption more palatable in > > > corporate settings, which surely would have been a good thing! > > > > IMO there are two possibilities: 1) your users are forgetful but honest, 2) > > your users are dishonest. > > > > For case 1, an equivalent of ADK can be obtained with a line on GPG's > > configuration file. > > > > For case 2, you are screwed, and ADK is only going to give you a false sense > > of security. > > > > Thus ADK is either pointless or unnecessary. > > This just simply isn't true. > > Putting a line in a config file may be fine for internal mail, but > does nothing to help you to be able to decrypt mail sent from outside > your organisation. It also locks everyone into using gpg - I thought > the whole point of gpg / opengpg was to be inter-operative. Let's define some terms, so we're all talking about the same thing in the same way. An ADK, for "Additional Decryption Key", sometimes called ARR for "Additional Recipient Request", is a packet that is added to a key. It is hashed into the key self-signature, so the key itself is needed to add it. This implies acceptance (or at least knowledge) of the existence of the packet by the key owner, and if nothing else, they can simply look at the key to see the ADK is there. (There was a bug a few years back where PGP accepted ADKs that weren't part of the self-signature, but that has been fixed). The main point of an ADK is to allow companies to get the benefit of encryption, but help avoid the big risk of an employee encrypting something in such a way that the company can't get it back. The employee could encrypt it and then quit (either maliciously or coincidentally), or encrypt it and lose their key, and so on. It's a real risk. The ADK contains two pieces of data: First, a key fingerprint. This is the key that the key owner is asking you to also encrypt to. Secondly, there is a bunch of flags that tell you how strongly the key owner feels about this. The key owner can say either "Please also encrypt to this key" or "You MUST also encrypt to this key". In use, an ADK is just another recipient. It's more or less equivalent to automatically adding a "-r the-adk-key" to a GPG command line. Finally, note that the ADK is *not* part of OpenPGP. It is a proprietary extension of the PGP product. It is also patented, which prevents those other than PGP from implementing it. (The PGP folks are actually very reasonable about interoperability issues, but as far as I know, nobody has asked about this.) Now, in a closed environment (say, internal email) where everyone is using PGP, it's great. Every message is also encrypted to the ADK key, and the company has assurance they won't lose any critical data. In a mixed (PGP + GPG) but still closed environment, it's still pretty good: those people using PGP will follow the ADK, and those people using something else won't. In the case of disaster, some data will potentially not be recoverable. This can be handled via the "encrypt-to the-adk-key" in gpg.conf method. To be sure, an employee in this closed environment could hack up something that doesn't respect the ADK. That's not a problem with the software. That's a problem with the employee. The more difficult case is a completely open environment (say, email for a company that also wants to encrypt their external email). In this case, those people using PGP will use the ADK, and others won't. It's not possible to require every external person to do what you want (they don't work for the company and have no reason to follow the ADK). In these cases, there isn't much that can be done aside from key escrow, or running some sort of mail gateway system that can be the keeper of the secret keys, or possibly even bounce messages back that don't have an ADK (eg "You won't use the ADK, so I'm not talking to you"). > But my real point is this: gpg in most areas says "This is a tool. > Your threat models will vary, and we give you a tool which you can > deploy". But in the area of ADK, even when for years people have said > on this list and elsewhere, "ADK would help with the > threat/organizational model we have", GPG refuses to help. "alter > your config file" solves (at best) half of the problem. Even if the patent issue was resolved, it doesn't really solve much to have GPG follow the ADK. GPG is distributed as source - easy enough for someone to simply comment out the ADK code if they didn't want it to take effect. David From rjh at sixdemonbag.org Tue Feb 19 18:54:45 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 19 Feb 2008 11:54:45 -0600 Subject: Corporate use of gnupg In-Reply-To: <873arorhen.fsf@wheatstone.g10code.de> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <47BAD8CC.8050804@sixdemonbag.org> <873arorhen.fsf@wheatstone.g10code.de> Message-ID: <47BB17E5.3020602@sixdemonbag.org> Werner Koch wrote: > Frankly, I did not knew about this patent until now. US Patent 6314190, for those who want to check it out. > I consider the ADK the wrong solution to a problem which can't be solved > by a tool. Mostly agreed. > We won't add ARR (aka ADK) to GnuPG. It would be more useful to add a > re-encode feature to add another public or symmetric key for decryption. The patent language on #6314190 is sufficiently broad that it would arguably cover this, too, depending on how it's implemented. From vedaal at hush.com Tue Feb 19 21:55:18 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Tue, 19 Feb 2008 15:55:18 -0500 Subject: Corporate use of gnupg Message-ID: <20080219205518.EE45E1A003A@mailserver8.hushmail.com> >> We won't add ARR (aka ADK) to GnuPG. It would be more useful to >add a >> re-encode feature to add another public or symmetric key for >decryption. > >The patent language on #6314190 is sufficiently broad that it >would >arguably cover this, too, depending on how it's implemented. a simple corporate solution, is for the company to generate a gnupg keypair for each employee, have the employee change the passphrase as desired, and have the employees generate their own separate signing keys (not subkeys) then the company can simply inform all employees that any and all encrypted mail sent or received by the company must have a recipient key id that is on the company's 'accepted' list of employee encryption keys, or the corporate mail filter will discard it this way, the employees are responsible for their own signatures, which cannot be forged by the company, and are aware that the company can read all company related e-mail, and no patents are even remotely infringed upon employees who really want to deceive the company, can send encrypted files another way, (cdrw truecrypt containers by snail mail, using gnupg on private home computers etc.), and there is no simple solution to stop it. vedaal any ads or links below this message are added by hushmail without my endorsement or awareness of the nature of the link -- The Perfect Baby Gift. Click Here http://tagline.hushmail.com/fc/Ioyw6h4eUCjMPYjHbFDlJl4GLFkdg5rzznRGZDWJt71njDIDf5WCr9/ From rjh at sixdemonbag.org Tue Feb 19 22:14:55 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 19 Feb 2008 15:14:55 -0600 Subject: Corporate use of gnupg In-Reply-To: <20080219205518.EE45E1A003A@mailserver8.hushmail.com> References: <20080219205518.EE45E1A003A@mailserver8.hushmail.com> Message-ID: <47BB46CF.7010105@sixdemonbag.org> vedaal at hush.com wrote: > a simple corporate solution, Again, check the patent and then check with a patent lawyer. The patent language is suitably broad that this sort of thing might be construed by a court to fall under the patent. Technical fixes to provide ADK-like functionality are well and good, but if you aren't looking at the patent and creating this new technology with an eye towards avoiding the patent, you're playing the legal version of Russian roulette. If you want ADK-like functionality, you have two real choices: (a) buy a commercial PGP product, (b) spend $200/hr on a patent attorney to make sure your solution doesn't infringe. Of course, all this is null and void if you live in a jurisdiction where software cannot be patented. From vedaal at hush.com Tue Feb 19 22:54:24 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Tue, 19 Feb 2008 16:54:24 -0500 Subject: Corporate use of gnupg Message-ID: <20080219215424.6CA1C1A0039@mailserver8.hushmail.com> On Tue, 19 Feb 2008 16:14:55 -0500 "Robert J. Hansen" wrote: >Technical fixes to provide ADK-like functionality are well and >good, but >if you aren't looking at the patent and creating this new >technology >with an eye towards avoiding the patent, you're playing the legal >version of Russian roulette. there is no 'technical fix' the company is simply keeping its own copy of a keypair that it generates for an employee, just as it would hold onto a copy of the physical key it generates for the lock on the employee's office door that said, it's always a good idea to consult with the legal people before any such solutions are implemented it just seemed reasonable enough and inexpensive enough, to suggest it to any companies that need it, and leave the legal follow-up to them the more companies that adopt a gnupg/pgp solution, the more that employees will become familiar with encryption, and are likely to begin to use it privately on their own vedaal any ads or links below this message are added by hushmail without my endorsement or awareness of the nature of the link -- Get a Business Credit Card. Click Here. http://tagline.hushmail.com/fc/Ioyw6h4dNfiMChL8gOF9EycnxyE5x2Ge8KfoA1hsccGnGUtv9gjYOj/ From kayameti at gmail.com Tue Feb 19 22:25:41 2008 From: kayameti at gmail.com (Metin KAYA) Date: Tue, 19 Feb 2008 23:25:41 +0200 Subject: why do not "gpgme-1.1.4/tests/gpg/t-decrypt.c" and "gpgme-1.1.4/tests/gpg/t-encrypt.c" working? Message-ID: Hi all, I'm new user of gpgme. I installed gpgme-1.1.4 and studied examples of it. But when I try to run t-decrypt and t-encrypt binaries, they give this error: # ./t-encrypt t-encrypt.c:60: GPGME: End of file # ./t-decrypt t-decrypt.c:64: GPGME: Decryption failed I'm using Fedora Core 8 (2.6.23.9-85.fc8) and I want to use gpgme to encrypt/decrypt and assign plain data. Can you help me? How can I encrypt/decrypt/assign plain data via gpgme library functions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From maury.markowitz at gmail.com Tue Feb 19 20:35:55 2008 From: maury.markowitz at gmail.com (Maury Markowitz) Date: Tue, 19 Feb 2008 14:35:55 -0500 Subject: passphrase doesn't work? Message-ID: <5bdbc9050802191135g35fd5149q41a9210f8052eaa6@mail.gmail.com> I'm being sent a file that's encrypted using our PK by some version of PGP using IDEA (or course). I'd like to decrypt it using gpg, in a CMD shell, under Windows XP. To get started, I downloaded and installed gpg, downloaded and copied over idea.dll, copied over our PGP keyrings and renamed them to ".gpg", used --homedir to point everything to the network folder where I put it all, and started experimenting... gpg --homedir o:\utilities\ --list-keys returns a list of keys in "pubring.gpg" (should it do the same for secring?). One of the keys in the list is the 2048-bit key that I'm trying to use. It seems to be working so far! Ok, let's try to open the file... gpg --homedir o:\utilities\ --load-extension o:\utilities\idea.dll -d o:\temp\downloaded_20080219.txt.pgp You need a passphrase to [...] [type in the passphrase] gpg: Invalid passphrase; please try again ... [repeat, making very sure] gpg: Invalid passphrase; please try again ... Ok, the passphrase is correct. Any ideas what's going on here? Maury From nicholas.cole at gmail.com Wed Feb 20 01:18:30 2008 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 20 Feb 2008 00:18:30 +0000 Subject: ADKs (was: Corporate use of gnupg) In-Reply-To: <20080219174956.GB16013@jabberwocky.com> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <002b01c872fa$98998ed0$0302a8c0@Nautilus> <20080219174956.GB16013@jabberwocky.com> Message-ID: On Tue, Feb 19, 2008 at 5:49 PM, David Shaw wrote: > Even if the patent issue was resolved, it doesn't really solve much to > have GPG follow the ADK. GPG is distributed as source - easy enough > for someone to simply comment out the ADK code if they didn't want it > to take effect. Dear David, Thank you for your long and clear reply. I take the point about the patent issues completely. However, just for a moment assuming that the patent issue could be solved in a way that would not upset PGP... OpenPGP has done well in 'closed' environments (as you define them), but has always stumbled in more potentially open settings. This has always seemed to me a huge shame. There seem to be at least some settings where ADK makes sense and would encourage the use of PGP. Of course, it is simply a 'request', but it is a reasonable request and (as far as I can see) a much better way to handle these issues than saying to people 'please always encrypt to my corporate key manually'. The point about ADK being something that can be circumvented is not, I think, a real issue. It has always seemed to me that ADK is something much more akin to all the other preferences already stored on a key - a request to PGP-compatible programs to encrypt data in a particular way. Since it would encourage the use of encryption in environments where it is not currently used, I would see it as nothing but a good thing. Although, of course, if there really are patent issues, it can't happen, but perhaps PGP Corp would/could be flexible on this point. Best wishes, N. From rjh at sixdemonbag.org Wed Feb 20 02:34:24 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 19 Feb 2008 19:34:24 -0600 Subject: ADKs In-Reply-To: References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <002b01c872fa$98998ed0$0302a8c0@Nautilus> <20080219174956.GB16013@jabberwocky.com> Message-ID: <47BB83A0.10505@sixdemonbag.org> Nicholas Cole wrote: > Although, of course, if there really are patent issues, it can't > happen, but perhaps PGP Corp would/could be flexible on this point. Not happening. GnuPG is already making inroads enough on the server market. ADK is one of the few features which (a) PGP can claim over GnuPG and (b) businesses want. If GnuPG implemented ADK-like features, that would likely present enough of a competitive threat to encourage PGP to wave the patent hammer. The last time I talked to a patent lawyer about software (I had a nifty thing I wanted to implement and needed to make sure I wasn't walking into a patent lawsuit), I paid my $200/hr and got this bit of professional advice: "in today's software market, patents are used a lot more to keep other people out than to bring money in." Assuming that my lawyer is accurate, the ADK patent would seem like an obvious one to use in such a way: it is more useful to PGP to have it around to keep competitors out of a certain part of the market than it would be to have it around to license to competitors to allow them into that certain part of the market. From steve at srevilak.net Wed Feb 20 03:19:39 2008 From: steve at srevilak.net (Steve Revilak) Date: Tue, 19 Feb 2008 21:19:39 -0500 (EST) Subject: pinentry stdin problems In-Reply-To: <47B88B70.2000603@ir.iit.edu> References: <47B88B70.2000603@ir.iit.edu> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: S3 > Subject: pinentry stdin problems > I recently upgraded from GPG v1.4 to GPG v2. > Previously, I was able to do this: > tar c | gpg -s > a.tar.gpg > > However, with the new version that uses pinentry, > it does not allow me to insert my password > whenever I redirect stdin as above. I don't > even get the ncurses password entry box. > > Is there a way to make this work as before? > Can pinentry be made to fallback to the plain text > password entry, should the other ones fail? I noticed a (slightly) similar thing when moving from gpg to gpg2, but I happened to be going in the other direction. Here's a small bit of text that was encrypted with gpg2 --armour - --symmetric. The passphrase is "gpg". - -----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.8 (Darwin) jA0EAgMCwmLYzXKpwBxgySkGIGW4LYjxGKTNBJDIslO1M0GLMlbjW9ZqJk2HZis7 wqsB2DBwAHpVZw== =juzP - -----END PGP MESSAGE----- With gpg 1.4.8, one could select the text starting with the "BEGIN" line, ending with the "END" line, and paste it as stdin to "gpg - --decrypt". gpg would ask for the passphrase, then decrypt the message. If you try to do the same thing with "gpg2 --decrypt", pinentry-curses winds up getting "-----END PGP MESSAGE-----" as the passphrase. (In my case, the workaround is "don't select the END line". I'm not sure about yours, though). Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (Darwin) iEYEARECAAYFAke7jj4ACgkQX7YJI4BuyDStLQCfVRnC2wUQL42VpH3TNA0WZ2FF evcAnjNNN8jRHI/Ej4BMEHFaEapLkUpj =XaHo -----END PGP SIGNATURE----- From maury.markowitz at gmail.com Wed Feb 20 15:34:19 2008 From: maury.markowitz at gmail.com (Maury Markowitz) Date: Wed, 20 Feb 2008 09:34:19 -0500 Subject: Moving from PGP to GPG Message-ID: <5bdbc9050802200634i4a1f1df9r8a0301b87c4f5382@mail.gmail.com> I'm in the process of automating a number of manual tasks. Several of these require a user to manually download e-mail attachments to a folder, decrypt them using PGP, and then open them in Excel. So far I have managed to redirect the mail to a public folder in Exchange, find and download the attachments (MS does NOT make that easy!) and in the unencrypted cases, open the files and automatically process them. Now there's the encrypted ones. I have downloaded and installed both GPG and IDEA.DLL on a network share. I then copied over our keyfiles from the existing PGP installs, and renamed them ".gpg" which seems to make life simpler (do I need to do this? is can I specify the file directly and thus leave it named ".skr" and ".pkr"?) After the install I did: gpg --homedir o:\utilities\ --list-keys and got a list of the expected keys. One of these is our 2048-bit public key that I know the other side is using to encrypt the file in question. So then I try the actual extraction... gpg --homedir o:\utilities\ --load-extension o:\utilities\idea.dll -d o:\downloads\cds_20080219.txt.pgp And this gets me: You need a passphrase to unlock the secret key for... Ok, no problem, so I type in the passphrase... gpg: Invalid passphrase; please try again ... Uhhh, no, it's NOT invalid. And this is where I am stuck. So am I correct in thinking that I should be able to copy the keyfiles over? If not, is there some sort of process I can use to do so? Is there such thing as a "cross platform" keyfile that works in both GPG and PGP? Maury From JPClizbe at tx.rr.com Wed Feb 20 19:53:21 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Wed, 20 Feb 2008 12:53:21 -0600 Subject: Moving from PGP to GPG In-Reply-To: <5bdbc9050802200634i4a1f1df9r8a0301b87c4f5382@mail.gmail.com> References: <5bdbc9050802200634i4a1f1df9r8a0301b87c4f5382@mail.gmail.com> Message-ID: <47BC7721.7000801@tx.rr.com> Maury Markowitz wrote: > I'm in the process of automating a number of manual tasks. Several of > these require a user to manually download e-mail attachments to a > folder, decrypt them using PGP, and then open them in Excel. So far I > have managed to redirect the mail to a public folder in Exchange, find > and download the attachments (MS does NOT make that easy!) and in the > unencrypted cases, open the files and automatically process them. > > Now there's the encrypted ones. I have downloaded and installed both > GPG and IDEA.DLL on a network share. I then copied over our keyfiles > from the existing PGP installs, and renamed them ".gpg" which seems to > make life simpler (do I need to do this? is can I specify the file > directly and thus leave it named ".skr" and ".pkr"?) > > So am I correct in thinking that I should be able to copy the key files > over? If not, is there some sort of process I can use to do so? Is > there such thing as a "cross platform" keyfile that works in both GPG > and PGP? At the present, keyring files in PGP and GnuPG are just sequential collections of key packets. GnuPG is expecting the .gpg extension. You don't have to rename the files, so long as you tell GnuPG what the names are: no-default-keyring keyring O:\utilities\pubring.pkr primary-keyring O:\utilities\pubring.pkr secret-keyring O:\utilities\secring.skr included in \gpg.conf, or specified on the commend line by prefixing '--'. I usually import the files: gpg --import secring.skr gpg --import pubring.skr Either way, there's one detail to take care of: key trust. PGP calls it 'Implicit Trust' and stores it as part of the key. GnuPG calls it 'Ultimate trust' and stores it in trustdb.gpg. You set it by editing the key: gpg --edit-key 0xdecafbad trust Select 5 to select Ultimate trust, confirm with y, then exit with save. For the passphrase issue: the times I've seen this, it is usually due to the passphrase having characters that don't map into the command line code-page. You may wish to try clearing the passphrase in PGP before copying the keyrings and then resetting it in GnuPG. -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 658 bytes Desc: OpenPGP digital signature URL: From maury.markowitz at gmail.com Wed Feb 20 21:40:08 2008 From: maury.markowitz at gmail.com (Maury Markowitz) Date: Wed, 20 Feb 2008 15:40:08 -0500 Subject: Moving from PGP to GPG In-Reply-To: <47BC7721.7000801@tx.rr.com> References: <5bdbc9050802200634i4a1f1df9r8a0301b87c4f5382@mail.gmail.com> <47BC7721.7000801@tx.rr.com> Message-ID: <5bdbc9050802201240p412495bft40f2acfe3d7ed417@mail.gmail.com> On Wed, Feb 20, 2008 at 1:53 PM, John Clizbe wrote: > At the present, keyring files in PGP and GnuPG are just sequential collections > of key packets. > > GnuPG is expecting the .gpg extension. You don't have to rename the files, so > long as you tell GnuPG what the names are: Ok, this is much more in keeping with my experience. Thanks for that, I thought I was going crazy! > Either way, there's one detail to take care of: key trust. PGP calls it > 'Implicit Trust' and stores it as part of the key. GnuPG calls it 'Ultimate > trust' and stores it in trustdb.gpg. Ok, I put ultimate trust on both of our public keys. Do I need to do the same for the private ones? If so, it's not entirely obvious how to do so, because the hex doesn't show up when I --list-keys, is there some additional option I need? The bad news: it still says my passphrase is wrong! Which increasingly leads me to believe my passphrase is wrong... I will try removing it first. Maury From nikola.lecic at anthesphoria.net Wed Feb 20 23:22:39 2008 From: nikola.lecic at anthesphoria.net (Nikola =?UTF-8?B?TGXEjWnEhw==?=) Date: Wed, 20 Feb 2008 23:22:39 +0100 Subject: Orphaned secret subkeys In-Reply-To: <20080131023710.2061a1d8@anthesphoria.net> References: <20080131023710.2061a1d8@anthesphoria.net> Message-ID: <20080220232239.59fe2a61@anthesphoria.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Thu, 31 Jan 2008 02:37:10 +0100 Nikola Le?i? wrote: > I wasn't aware that one had to 'save' a key immediately after deleting > a subkey (using delkey) in order to replace that subkey with a new one > (using addkey). Now I have this situation: Hi again, It seems that not so many mails remain unanswered on this list... So please let me know if I should report my question with more details or clarify something. Thanks. - -- Nikola Le?i? = ?????? ????? fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQCVAwUBR7yoQvzDP9K2CKGYAQMNaQQAhtDN7kpShCeEvfBF0hP+USldcdxKc5hX gODQLB2JwQig/1OMa8xc5cQEohhenaSxxVk3SZXPGuO39EMIv7T4gPKqI8C1eFmV rF4ZSfjlno/TBEF/j6GPqJW7bGH4ldGndnsrhWfvGjdl3rd5abpmwlsigwnShLCO TrIRN3J5sVM= =HX1r -----END PGP SIGNATURE----- From sinux at fsfe.org Thu Feb 21 15:11:57 2008 From: sinux at fsfe.org (Sebastien Chassot) Date: Thu, 21 Feb 2008 15:11:57 +0100 Subject: Orphaned secret subkeys In-Reply-To: <20080220232239.59fe2a61@anthesphoria.net> References: <20080131023710.2061a1d8@anthesphoria.net> <20080220232239.59fe2a61@anthesphoria.net> Message-ID: <1203603117.995.14.camel@dell.sinux.seb> On Wed, 2008-02-20 at 23:22 +0100, Nikola Le?i? wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > On Thu, 31 Jan 2008 02:37:10 +0100 > Nikola Le?i? wrote: > > > I wasn't aware that one had to 'save' a key immediately after deleting > > a subkey (using delkey) in order to replace that subkey with a new one > > (using addkey). Now I have this situation: > > Hi again, > > It seems that not so many mails remain unanswered on this list... So > please let me know if I should report my question with more details or > clarify something. Hi, You just have to toggle to secret keyring, select key (> key 4) and run delkey. You'd be asked if you realy want delete a secret subkey. That's what you did in public keyring but there is two keyring one public and one secret. You could have run "gpg --delete-keys" and "gpg --delete-secret-keys" too. First message: http://lists.gnupg.org/pipermail/gnupg-users/2008-January/032528.html -- Sebastien From hardeeps at hcl.in Tue Feb 19 14:39:38 2008 From: hardeeps at hcl.in (Hardeep Singh, Noida) Date: Tue, 19 Feb 2008 19:09:38 +0530 Subject: Corporate use of gnupg In-Reply-To: <20080219133354.GA13415@jabberwocky.com> References: <15312177.post@talk.nabble.com><20080210195726.GC12706@jabberwoc ky.com><15514362.post@talk.nabble.com> <20080219133354.GA13415@jabberwocky.com> Message-ID: Hi All Isnt it pretty easy to have a script on the server (try to) decrypt each email. If the email decrypts, fine else not allow the email to go through. That will force people to retain the option in conf file if they want their message to reach. Regards Hardeep Singh http://www.SeeingWithC.org/ -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of David Shaw Sent: Tuesday, February 19, 2008 7:04 PM To: gnupg-users at gnupg.org Subject: Re: Corporate use of gnupg On Fri, Feb 15, 2008 at 07:00:12PM -0800, Texaskilt wrote: > > I guess what we are wanting is for every mail user to have their own > public/private key. This way they can encrypt their own email on the > corporate system. > > In addition, every email would also be encrypted using the "corporate key" > that would be in the hands of a select few (supposedly). > > For example, the sales force can send encrypted mail to each other, > but when a salesperson leaves the company, the Email Admin can > retreive and decrypt the email so that the salesperson's replacement > can pick up their accounts without too much disruption. > > Looks like this is ADK. Is there any way to do this on gpg? Yes. Put "encrypt-to (the-adk-key)" in everyone's gpg.conf. Of course, they could turn around and take it right out again. Unless you have pretty tight control over the environment, ADKs or encrypt-tos are not foolproof (and that applies to both PGP and GPG). As I said before, note that this isn't safe because of the crypto math. It's "safe" because you can fire people who don't do it. David _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. ----------------------------------------------------------------------------------------------------------------------- From maury.markowitz at gmail.com Thu Feb 21 16:25:50 2008 From: maury.markowitz at gmail.com (Maury Markowitz) Date: Thu, 21 Feb 2008 10:25:50 -0500 Subject: Still no luck on the passphrase Message-ID: <5bdbc9050802210725x239a9a30r5764991eccc6ba9d@mail.gmail.com> Ok, I have done everything I can think of. I have used the original keyfiles, I've exported/imported the keyfiles, I've typed in every possible variation of the passphrase I can think of, and it still doesn't work. Is there a way to simply remove the passphrase. Yes I know this is bad, but it's better than "doesn't work at all". Maury From vedaal at hush.com Thu Feb 21 20:20:56 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Thu, 21 Feb 2008 14:20:56 -0500 Subject: Moving from PGP to GPG Message-ID: <20080221192056.97A5915803D@mailserver6.hushmail.com> Maury Markowitz maury.markowitz at gmail.com wrote on Wed Feb 20 15:34:19 CET 2008 >gpg: Invalid passphrase; please try again ... >Uhhh, no, it's NOT invalid. And this is where I am stuck. try this: gpg -h and see if IDEA comes up on this list of algorithms installed if not, there is your answer, and try putting this into your gpg.conf : load-extension o:\utilities\idea.dll and try again here is a pgp2.x v3 test key and encrypted test file you can try on your system (using gnupg 1.4.8 the key imported and the file decrypted without problems) -----BEGIN PGP PRIVATE KEY BLOCK----- Comment: passphrase: v3tk lQOgA0e9bGAAAAEIAMpOKN7kzyelNivx8CHwnySaEilyY5LAcZTUbenaMHexKjOr VbI5jxuB52XxFg4Tj+fDZCwHJicKyQTdtbFsVtoFQeR89cKYq5VgkLTtfCvX5uEb Pl7NuM99yyWSpMgqtcLM7jgxw51Q5GNcUT0VIqqklYwC7+zSnkInBqbK0+eXHYxA U0M60i3HVKg/a3ac2PNkcV4fXO5IXqeBzFEaDuok8fiYWrRqBboNSs4i4LTxzY92 frJokXATZ8FMhlwsOR8CksMuH6diemqPvjjO/fjL43Hfg22weeB59JUkgwfiUygJ OWLVsK+bl8Vq9t+t5RoWDU4iJZ75kmkht+O6QTEABREBtF4CZpNlcUAH+Vda0EAz rUn6XSVYSzOqssKfwWMOS9a8djjTTDHE3XxbttTETEtUsmBVUoOGBpFpYvcnnCMu 1RuNstssKqXj/zeiOfE3LrB4IKTiqBPbTW1qeTD4y+NOygxQYP4d0AiukQQR1BSa M3BYAmqy1qcFVZECwZW6ZFzUNogDFg3Py+lhMhBQPSWesoIP77JNpDuAs1OCjeoq txag6/oSYR2/Xo/uJ9lZnS/1uWsQLUqPczOZQYQVXWMjaZYvFB9DtkUhKG0QX6JU wQshGnOtZ4f/7WmDDS41uscdh0ViWH/y83fpUR2s6jWJgbaWVmUkRi8TU06jHiio QmDUV3BnxRpR4b8EALTvvudB32wc3NVWjigP/010zSTMtthFaLgMNkZ2C31puVcW +eN8oRBOBPldwqVUxjpwbX8r77QmK8CoNi+y3bHLnpaipYT3t4it4vMmuhLIoNZU cAEHLtuvNIxgMoFVzg6EAR3/Ztiux2VOQQt3laA7ReEW8oDvjBh2H9xgOh8GBACQ q91sZMW3C/kdmVCbSoh8m6gFJuQPKlsD9GZvQlyIpw6Ikpz6WHKo1H5GOhNW7u5t iZkgjv3tpWLZt+1pCxiPu3vghx4RtPl53/WErWGOSAKujxTZV9Ciohf1w3R/AQdu aVloeyyWtGMkPPOHfERAKdP/rn6ZtJXQjrYlgM/I5QQA66wtmvadgOie96qONwWT 1HxsJBGZCmELuXggi4KwMYcq+e2slzIKOqg+gLjuuH29m7u850tTGQ+U1AUza5ya V+aoiGOrF9PLSOucqHyL1bTd9eZiph4NAUN6tF/JxGFd6YZzd1E6yNLVPZe/BNAH iPOOcHicWf3k13Df/z9IVI08D7QZdjN0ayA8djN0ZXN0a2V5QGtleS50ZXN0Pg== =2sNe -----END PGP PRIVATE KEY BLOCK----- -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: Acts of Kindness better the World, and protect the Soul mQENA0e9bGAAAAEIAMpOKN7kzyelNivx8CHwnySaEilyY5LAcZTUbenaMHexKjOr VbI5jxuB52XxFg4Tj+fDZCwHJicKyQTdtbFsVtoFQeR89cKYq5VgkLTtfCvX5uEb Pl7NuM99yyWSpMgqtcLM7jgxw51Q5GNcUT0VIqqklYwC7+zSnkInBqbK0+eXHYxA U0M60i3HVKg/a3ac2PNkcV4fXO5IXqeBzFEaDuok8fiYWrRqBboNSs4i4LTxzY92 frJokXATZ8FMhlwsOR8CksMuH6diemqPvjjO/fjL43Hfg22weeB59JUkgwfiUygJ OWLVsK+bl8Vq9t+t5RoWDU4iJZ75kmkht+O6QTEABRG0GXYzdGsgPHYzdGVzdGtl eUBrZXkudGVzdD6JARUDBRBHvWySkmkht+O6QTEBAQKbCAC46+enKkHpfoY77bZU A+5TU+r4wku6AJBXwPMdTC86LWoEUgMREAnaVd5ynGwIVrzCWp8DGjkS/Q4hxw0M 9j/0Rr5v+0OBUxOVKsgidQ/+94qKTfJ/FUfOV7KKynnAmJWgvTMW1Zu660gPKFAi i85mkCo3UHGIgex/7QpaEaSWXHlKawFfdpfffCS1+30iS4EK4SPuq9jiSSNnuEWT h9XJId9V91k2vCfrpIE2+Zp91g5wMlaeo0yadbH/0EDqQt7DXXocu7VciChj/pp/ lBbaHFUYe9nlWu5VyujeHPfYUWEIizrtqiAdtS7/Qr/kyPYK9e5zuyoF/TeGF9cS LvKQ =8kdc -----END PGP PUBLIC KEY BLOCK----- here is the encrypted test file: -----BEGIN PGP MESSAGE----- Version: PGP 2.6.3ia-multi06 Comment: Acts of Kindness better the World, and protect the Soul hQEMA5JpIbfjukExAQf/SoERbJzcLXNKrtSbN/ZMOFNVJKoyXlS+Zad1Y9D6AwqA 5NibmB+gkCcoqd4JgX0Ygrudbqrs6jsoz0x9X71CE1Eqf4HCtuH5Xbbq4/cGaRTd UfOT7hqEhFOJIm8ua+loQeQjqCy58e4EQUdH/AeQACFrHej4mbvaYduNIlGYQUNN vYgv5ieEU3JPx9Vv4H9FyO97dKQ/efhHbPX27/30cSOP/l8tnCMnk3A6o3ucVy1m ZfpN/deyd4ssAQmgyqLqIB8Sc4TP4PVxeKndB193XdFa7In2125vU5jpgDUobvZQ gwWWhyDj6DXvUMW8szXh/D3I7q3g3LfHX70U1MzOaqYAAAApNrgEfjTRpiVngme7 hs879RjyLO6RTOWF93NghzAd3gVP2at7SXwghx4= =Lw8Y -----END PGP MESSAGE----- vedaal any ads or links below this message are added by hushmail without -- Victim of medical malpractice? Click here to find an expert lawyer to help pursue your case. http://tagline.hushmail.com/fc/Ioyw6h4fOjqm6kDIHuVA7jnC29olmuAuVy98XLZAodshJhpfRDYkeL/ my endorsement or awareness of the nature of the link From maury.markowitz at gmail.com Thu Feb 21 21:03:53 2008 From: maury.markowitz at gmail.com (Maury Markowitz) Date: Thu, 21 Feb 2008 15:03:53 -0500 Subject: Moving from PGP to GPG In-Reply-To: <47BC7721.7000801@tx.rr.com> References: <5bdbc9050802200634i4a1f1df9r8a0301b87c4f5382@mail.gmail.com> <47BC7721.7000801@tx.rr.com> Message-ID: <5bdbc9050802211203s4789baa1lb89f3f837439feb3@mail.gmail.com> On Wed, Feb 20, 2008 at 1:53 PM, John Clizbe wrote: > For the passphrase issue: the times I've seen this, it is usually due to the > passphrase having characters that don't map into the command line code-page. Wait, is there a length limit? Maury From nikola.lecic at anthesphoria.net Fri Feb 22 04:37:19 2008 From: nikola.lecic at anthesphoria.net (Nikola =?UTF-8?B?TGXEjWnEhw==?=) Date: Fri, 22 Feb 2008 04:37:19 +0100 Subject: Orphaned secret subkeys In-Reply-To: <1203603117.995.14.camel@dell.sinux.seb> References: <20080131023710.2061a1d8@anthesphoria.net> <20080220232239.59fe2a61@anthesphoria.net> <1203603117.995.14.camel@dell.sinux.seb> Message-ID: <20080222043719.10a46cb9@anthesphoria.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Thu, 21 Feb 2008 15:11:57 +0100 Sebastien Chassot wrote: > On Wed, 2008-02-20 at 23:22 +0100, Nikola Le?i? wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: RIPEMD160 > > > > On Thu, 31 Jan 2008 02:37:10 +0100 > > Nikola Le?i? wrote: > > > > > I wasn't aware that one had to 'save' a key immediately after > > > deleting a subkey (using delkey) in order to replace that subkey > > > with a new one (using addkey). Now I have this situation: > > > > Hi again, > > > > It seems that not so many mails remain unanswered on this list... So > > please let me know if I should report my question with more details > > or clarify something. > > Hi, > > You just have to toggle to secret keyring, select key (> key 4) and > run delkey. You'd be asked if you realy want delete a secret subkey. Sebastien, thank you for the reply. That's exactly why I asked: I can't do this. :-) It seems that GnuPG always wants me to return to the public ring: %gpg --edit-key 7B063EAA [...] Secret key is available. [...] Command> toggle sec 2048R/7B063EAA created: 2008-01-30 expires: never ssb 1024R/35E8152C created: 2008-01-30 expires: never ssb 2048R/AE444AB1 created: 2008-01-30 expires: never ssb 1024g/FA352C19 created: 2008-01-30 expires: never <--- orphan ssb 1024R/44EDC121 created: 2008-01-30 expires: never <--- orphan ssb 2048R/C0AD5BE4 created: 2008-01-30 expires: never Command> key 4 ... ssb* 1024R/44EDC121 created: 2008-01-30 expires: never ... Command> delkey Please use the command "toggle" first. Command> > That's what you did in public keyring but there is two keyring one > public and one secret. You could have run "gpg --delete-keys" and "gpg > --delete-secret-keys" too. I understood that delete{,-secret}-keys can't delete subkeys. - -- Nikola Le?i? = ?????? ????? fingerprint : FEF3 66AF C90E EDC3 D878 7CDC 956D F4AB A377 1C9B ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iQCVAwUBR75DfvzDP9K2CKGYAQMSKQP/bfExJd9RSzyC3cJlgbQ3im23+6Mj5UMz 7Dp5NWcEO+o6+162gdaNebqOPyK5+kDcdR+34Sbx8X+w1Xb9waVzBdRa/wS1QEdE 2YP/0bs+2DAcOUZL8O+3pfRKidMkXcCuHiUp/6A8//DfNH08+KIp4yETICvCe/wg 1uJTFWY3US4= =/epJ -----END PGP SIGNATURE----- From sinux at fsfe.org Fri Feb 22 10:06:15 2008 From: sinux at fsfe.org (Sebastien Chassot) Date: Fri, 22 Feb 2008 10:06:15 +0100 Subject: Orphaned secret subkeys In-Reply-To: <20080222043719.10a46cb9@anthesphoria.net> References: <20080131023710.2061a1d8@anthesphoria.net> <20080220232239.59fe2a61@anthesphoria.net> <1203603117.995.14.camel@dell.sinux.seb> <20080222043719.10a46cb9@anthesphoria.net> Message-ID: <1203671175.1000.20.camel@dell.sinux.seb> On Fri, 2008-02-22 at 04:37 +0100, Nikola Le?i? wrote: > Sebastien, thank you for the reply. > > That's exactly why I asked: I can't do this. :-) It seems that GnuPG > always wants me to return to the public ring: > OK, I misunderstood your question. > %gpg --edit-key 7B063EAA > [...] > Secret key is available. > > [...] > Command> toggle > > sec 2048R/7B063EAA created: 2008-01-30 expires: never > ssb 1024R/35E8152C created: 2008-01-30 expires: never > ssb 2048R/AE444AB1 created: 2008-01-30 expires: never > ssb 1024g/FA352C19 created: 2008-01-30 expires: never <--- orphan > ssb 1024R/44EDC121 created: 2008-01-30 expires: never <--- orphan > ssb 2048R/C0AD5BE4 created: 2008-01-30 expires: never > > Command> key 4 > ... > ssb* 1024R/44EDC121 created: 2008-01-30 expires: never > ... > Command> delkey > Please use the command "toggle" first. > > Command> Have you try to recreate and re-import your full public keyring and delete your secret subkey first? It's just an idea to solve your problem but I can't help you find out an explanation. From kloecker at kde.org Fri Feb 22 21:58:32 2008 From: kloecker at kde.org (Ingo =?iso-8859-15?q?Kl=F6cker?=) Date: Fri, 22 Feb 2008 21:58:32 +0100 Subject: Moving from PGP to GPG In-Reply-To: <5bdbc9050802211203s4789baa1lb89f3f837439feb3@mail.gmail.com> References: <5bdbc9050802200634i4a1f1df9r8a0301b87c4f5382@mail.gmail.com> <47BC7721.7000801@tx.rr.com> <5bdbc9050802211203s4789baa1lb89f3f837439feb3@mail.gmail.com> Message-ID: <200802222158.32747@erwin.ingo-kloecker.de> On Thursday 21 February 2008, Maury Markowitz wrote: > On Wed, Feb 20, 2008 at 1:53 PM, John Clizbe wrote: > > For the passphrase issue: the times I've seen this, it is usually > > due to the passphrase having characters that don't map into the > > command line code-page. > > Wait, is there a length limit? Sure, but it's several thousand characters and therefore shouldn't be a problem. Anyway, that's not what John meant. What John meant is that the passphrase maybe contains characters that the command line does not accept, e.g. in latin1 locale you cannot enter the Euro symbol ? because the latin1 character set does not contain the Euro symbol. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part. URL: From dirk.traulsen at lypso.de Mon Feb 25 09:59:36 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Mon, 25 Feb 2008 09:59:36 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <20080208202301.GB17716@jabberwocky.com> References: <1202501241.1029.22.camel@dell.sinux.seb>, <20080208202301.GB17716@jabberwocky.com> Message-ID: <47C29188.11367.2369B52A@dirk.traulsen.lypso.de> Am 8 Feb 2008 um 15:23 hat David Shaw geschrieben: > On Fri, Feb 08, 2008 at 09:07:21PM +0100, Sebastien Chassot wrote: > > Hi, > > > > I can't find how list who's a file encrypted for ? I've encrypt several > > files with different recipients, but I don't remember which. > > Just run 'gpg' on the file, and don't give a passphrase. It prints > all the possible recipients. No, not really. gpg asks three times for the password for each recipient one after the other. If you are the third recipient, you have to give 6 times a wrong password until you can finally input the correct one. This gets real fun when there are ten recipients... It would be nice, if 1. gpg would take the password and test it automatically with all recipients keys. 1a. If there would be a hit, fine. 1b. If there was no hit, print a list of all recipient keys and give two more chances for a correct password. 2. there would be a command --recipient-keys which would just list all recipient keys of an encrypted file, so I could see in advance whether my key is one of them. Dirk From sinux at fsfe.org Mon Feb 25 14:29:43 2008 From: sinux at fsfe.org (Sebastien Chassot) Date: Mon, 25 Feb 2008 14:29:43 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <47C29188.11367.2369B52A@dirk.traulsen.lypso.de> References: <1202501241.1029.22.camel@dell.sinux.seb> , <20080208202301.GB17716@jabberwocky.com> <47C29188.11367.2369B52A@dirk.traulsen.lypso.de> Message-ID: <1203946183.1007.22.camel@dell.sinux.seb> On Mon, 2008-02-25 at 09:59 +0100, Dirk Traulsen wrote: > If you are the third recipient, you have to give 6 times a wrong > password until you can finally input the correct one. This gets real > fun when there are ten recipients... > > It would be nice, if > 1. gpg would take the password and test it automatically with all > recipients keys. > 1a. If there would be a hit, fine. > 1b. If there was no hit, print a list of all recipient keys and give > two more chances for a correct password. > 2. there would be a command --recipient-keys which would just list all > recipient keys of an encrypted file, so I could see in advance whether > my key is one of them. > I thought it wasn't any command for security reason, but I agree it seems a basic functionality is missing. Maybe a command giving complete information on a file would be useful too. I mean a signed file and an encrypted file have both .gpg extension and are hard to distinguish, aren't they ? Or the --verify command could be more verbose and list recipient's keys ? $ gpg --verify encrypted_file.gpg gpg: verify signatures failed: unexpected data $ gpg --verify signed_file.gpg gpg: Signature made ... gpg: Good signature from ... From sithtracy at yahoo.com Mon Feb 25 17:01:46 2008 From: sithtracy at yahoo.com (Tracy D. Bossong) Date: Mon, 25 Feb 2008 08:01:46 -0800 (PST) Subject: How know who is a file encrypted for ? Message-ID: <562221.63256.qm@web56706.mail.re3.yahoo.com> gpg --list-packets should give you a clue.... ----- Original Message ---- From: Sebastien Chassot To: Dirk Traulsen Cc: GnuPG mailing list Sent: Monday, February 25, 2008 7:29:43 AM Subject: Re: How know who is a file encrypted for ? On Mon, 2008-02-25 at 09:59 +0100, Dirk Traulsen wrote: > If you are the third recipient, you have to give 6 times a wrong > password until you can finally input the correct one. This gets real > fun when there are ten recipients... > > It would be nice, if > 1. gpg would take the password and test it automatically with all > recipients keys. > 1a. If there would be a hit, fine. > 1b. If there was no hit, print a list of all recipient keys and give > two more chances for a correct password. > 2. there would be a command --recipient-keys which would just list all > recipient keys of an encrypted file, so I could see in advance whether > my key is one of them. > I thought it wasn't any command for security reason, but I agree it seems a basic functionality is missing. Maybe a command giving complete information on a file would be useful too. I mean a signed file and an encrypted file have both .gpg extension and are hard to distinguish, aren't they ? Or the --verify command could be more verbose and list recipient's keys ? $ gpg --verify encrypted_file.gpg gpg: verify signatures failed: unexpected data $ gpg --verify signed_file.gpg gpg: Signature made ... gpg: Good signature from ... _______________________________________________ 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 sinux at fsfe.org Mon Feb 25 18:32:00 2008 From: sinux at fsfe.org (Sebastien Chassot) Date: Mon, 25 Feb 2008 18:32:00 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <562221.63256.qm@web56706.mail.re3.yahoo.com> References: <562221.63256.qm@web56706.mail.re3.yahoo.com> Message-ID: <1203960720.2006.11.camel@dell.sinux.seb> On Mon, 2008-02-25 at 08:01 -0800, Tracy D. Bossong wrote: > gpg --list-packets should give you a clue.... > Yes true! I'm not use using it cos it's only mentioned in man page and not in help (and I don't rtfm enough ;) From andog at gmx.net Mon Feb 25 18:41:19 2008 From: andog at gmx.net (Andreas Grassl) Date: Mon, 25 Feb 2008 18:41:19 +0100 Subject: SCM SCR 201 PCMCIA or TI PCIxx12 smartcard reader Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, does anybody know if the Microsystems SCM SCR 201 PCMCIA cardreader is supported on Linux with the standard-approach? found at ebay for example with the id 160211050548. Or does anybody know how to get working the Texas Instruments PCIxx12 GemCore based SmartCard controller of a HPNC6400? My system is Ubuntu Gutsy and I own a fsfe-card. thanks a lot greetings ando - -- /"\ \ / ASCII Ribbon X against HTML email / \ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQCVAwUBR8L9vSxC7ZRV6mG1AQLXlwP/Wmjx7oY0S2DQrbLcSoEHDJ3jVumiw3wG nfXh0RkiItxlTmHI0fctadv2XcqLveia3SjHGOTFzYL8p7c6TvOztCk0AvLlwId3 yNPGDdfUTJ3853+6chtP+QdeuSgH/CBU/LFXc2TiwxzPdm/0xE2Rpjo5uG7BCPMt qxDqdGBBpZI= =PzcU -----END PGP SIGNATURE----- From dirk.traulsen at lypso.de Mon Feb 25 19:27:56 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Mon, 25 Feb 2008 19:27:56 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <562221.63256.qm@web56706.mail.re3.yahoo.com> References: <562221.63256.qm@web56706.mail.re3.yahoo.com> Message-ID: <47C316BC.25436.257207FC@dirk.traulsen.lypso.de> Am 25 Feb 2008 um 8:01 hat Tracy D. Bossong geschrieben: > gpg --list-packets should give you a clue.... No, it does not! does the same as . The only difference is that gpg gives additional packet information before asking the passphrases three times for each recipient. So the described problem for an encrypted file with several recipients stays the same. ===================================== C:\>gpg --list-packets file.gpg :pubkey enc packet: version 3, algo 16, keyid F2A47460E192093D data: [4095 bits] data: [4095 bits] You need a passphrase to unlock the secret key for user: "Dirk Traulsen (dtl-2) " 4096-bit ELG-E key, ID E192093D, created 2005-10-21 (main key ID CDDB9911) Please enter the passphrase: ===================================== Dirk Traulsen From sithtracy at yahoo.com Mon Feb 25 21:54:26 2008 From: sithtracy at yahoo.com (Tracy D. Bossong) Date: Mon, 25 Feb 2008 12:54:26 -0800 (PST) Subject: How know who is a file encrypted for ? Message-ID: <241012.46021.qm@web56707.mail.re3.yahoo.com> gpg --list-packets --list-only but clearly you identified yourself as a recipient because you were prompted for a passphrase. ----- Original Message ---- From: Dirk Traulsen To: Cc: GnuPG mailing list Sent: Monday, February 25, 2008 12:27:56 PM Subject: Re: How know who is a file encrypted for ? Am 25 Feb 2008 um 8:01 hat Tracy D. Bossong geschrieben: > gpg --list-packets should give you a clue.... No, it does not! does the same as . The only difference is that gpg gives additional packet information before asking the passphrases three times for each recipient. So the described problem for an encrypted file with several recipients stays the same. ===================================== C:\>gpg --list-packets file.gpg :pubkey enc packet: version 3, algo 16, keyid F2A47460E192093D data: [4095 bits] data: [4095 bits] You need a passphrase to unlock the secret key for user: "Dirk Traulsen (dtl-2) " 4096-bit ELG-E key, ID E192093D, created 2005-10-21 (main key ID CDDB9911) Please enter the passphrase: ===================================== Dirk Traulsen _______________________________________________ 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 michael at vorlon.ping.de Mon Feb 25 23:35:55 2008 From: michael at vorlon.ping.de (Michael Bienia) Date: Mon, 25 Feb 2008 23:35:55 +0100 Subject: "Bad signature" when calling "check" in the edit-key menu: what happened to my public key? Message-ID: <20080225223555.GA29625@vorlon.ping.de> Hello, I see a strange situation when I try to edit my key: 1.) When I call "gpg2 --edit-key 0x968BD587" I see several lines of "gpg: moving a key signature to the correct place" 2.) When I call then "check" in the edit-key menu, I get a line saying "218 signatures not checked due to errors" and many duplicate lines with a "[Bad signature]" at the end, e.g.: sig%3 AAE3C5A0 2006-05-28 [Bad signature] sig%3 AAE3C5A0 2006-05-28 [Bad signature] sig%3 3E60B7DA 2007-03-11 [Bad signature] sig%3 3E60B7DA 2007-03-11 [Bad signature] sig% C5D34D05 2007-02-25 [Bad signature] sig% C5D34D05 2007-02-25 [Bad signature] 3.) After calling "clean" everything seems to be fine till the next key refresh when the errors comes back (and over 200 new signatures). So it looks like the "error" already propagated to the key servers, but doesn't seem to cause any harm (yet and as far as I can tell). But I would like to know what happened to my key. Any ideas? gpg2 is gpg (GnuPG) 2.0.8, the Debian package from unstable compiled on Ubuntu hardy. But I see the same behaviour with gpg 1.4.6. TIA, Michael From lists at thehurley.com Mon Feb 25 23:46:10 2008 From: lists at thehurley.com (Craig Hurley) Date: Mon, 25 Feb 2008 22:46:10 +0000 Subject: w32 client installer - silent install? Message-ID: <47C34532.4040403@thehurley.com> Hello, I've downloaded the windows command line client, version 1.4.8, from here: ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.8.exe ... I'm wondering are there any command line options for the installer? I'm specifically trying to install gpg silently on multiple computers via a startup script. I've tried: "gnupg-w32cli-1.4.8.exe /q" "gnupg-w32cli-1.4.8.exe /quiet" "gnupg-w32cli-1.4.8.exe /silent" "gnupg-w32cli-1.4.8.exe /?" "gnupg-w32cli-1.4.8.exe --help" "gnupg-w32cli-1.4.8.exe -h" ... each simply kicks off the visual installer prompting for user input. Regards, Craig. From dirk.traulsen at lypso.de Tue Feb 26 08:48:57 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Tue, 26 Feb 2008 08:48:57 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <241012.46021.qm@web56707.mail.re3.yahoo.com> References: <241012.46021.qm@web56707.mail.re3.yahoo.com> Message-ID: <47C3D279.12850.284F6283@dirk.traulsen.lypso.de> The two wishes I listed for gpg were: 1. If there are several recipients, test the given passphrase automatically for all secret keys in your keyring, so that you don't have to give for example 9 times a wrong one if you are recipient number four, which you even don't know beforehand. 2. A command which lists the recipients of an encrypted file. The first proposal is much more interesting as it would remedy a nuisance if you regularly work with files with several recipients. I really don't see a possible security problem here. Passphrases are to decrypt symmetrically the secret keys, nothing else. So we are only talking about secret keys in the keyring where a. all keys belong to me or b. some keys do not belong to me in a common keyring. In case a. there is no problem, I just give the first asked passphrase. But in case b, where it is the nuisance I described, you could only be unsure whether someone could guess your password. This is a completely different problem but has nothing to do with my proposal as now gpg also asks you three times to give a passphrase for these keys. You see, nothing changes securitywise. What I would like: gpg encrypted_file.gpg -> output nice list of the recipients with UIDs (ideally with indication, which one is in the secret keyring) -> ask for passphrase if at least one is in the secret keyring, otherwise tell that you can't decrypt the file -> test each secret key in the secret keyring with the passphrase -> if there was a hit, tell so and decrypt -> if not, give two more chances For the second wish Tracy D. Bossong mentioned > gpg --list-packets --list-only as a solution, which goes at least a bit in the right direction as it lists all the keyids. Interestingly it lists nicely the keys for which there is no secret key in our keyring, like David Shaws in this example. ============================================ C:\>gpg --list-packets --list-only file.gpg :pubkey enc packet: version 3, algo 16, keyid 79F51929AC2E2384 data: [4096 bits] data: [4096 bits] :pubkey enc packet: version 3, algo 16, keyid E3B52841743DD3E2 data: [4096 bits] data: [4093 bits] :pubkey enc packet: version 3, algo 16, keyid AE2827D11643B926 data: [2047 bits] data: [2046 bits] :pubkey enc packet: version 3, algo 16, keyid 9166EB1E0B9DCED2 data: [4095 bits] data: [4096 bits] :encrypted data packet: length: 81 mdc_method: 2 gpg: verschl?sselt mit 2048-Bit ELG-E Schl?ssel, ID 1643B926, erzeugt 2002-01-28 "David M. Shaw " C:\> ============================================ What I proposed with --recipient-keys is an output of a nice list of all the recipient keys like the last one here. And why not by the way even highlight for which one you have the secret key in the keyring? Dirk PS: Tracy, you seem to have a serious problem with your citing of other mails. You are citing them one word per line. To be sure that it is no artefact on my side, I checked the archives. See http://marc.info/?l=gnupg-users&m=120397363028142 and compare to below. There is definitely something wrong on your side. > ----- Original Message ---- > From: Dirk Traulsen > To: > Cc: GnuPG mailing list > Sent: Monday, February 25, 2008 12:27:56 PM > Subject: Re: How know who is a file encrypted for ? > > > Am > 25 > Feb > 2008 > um > 8:01 > hat > Tracy > D. > Bossong > geschrieben: > > > > gpg > --list-packets > should > give > you > a > clue.... > > No, > it > does > not! > --list-packets > file.gpg> > does > the > same > as > file.gpg>. > The > only > difference > is > that > gpg > gives > additional > packet > information > before > asking > the > passphrases > three > times > for > each > recipient. (...) I stop copying here. This should be enough to show the problem. From wk at gnupg.org Tue Feb 26 09:10:09 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Feb 2008 09:10:09 +0100 Subject: w32 client installer - silent install? In-Reply-To: <47C34532.4040403@thehurley.com> (Craig Hurley's message of "Mon, 25 Feb 2008 22:46:10 +0000") References: <47C34532.4040403@thehurley.com> Message-ID: <87mypof89q.fsf@wheatstone.g10code.de> On Mon, 25 Feb 2008 23:46, lists at thehurley.com said: > ... I'm wondering are there any command line options for the installer? Sorry, no. However the installer we use with gpg4win now features a few options. See the excerpt below for details. IIRC, this is available in the current gpg4win (1.1.3); checkout the README file. Salam-Shalom, Werner 4. Installer Options ==================== The default installation path can be speficied with the /D=PATH option, which must be last on the command line. The installer supports the options /S for unattended installation, and the option /C=INIFILE to specify an .ini file which should contain exactly one section "[gpg4win]". This section contains various installer settings and absolute file paths to configuration files that should be preinstalled. Most options just set a different default value. Excetions are documented below. Here is an example file which shows all possible keys: [gpg4win] ; Installer settings. Do not define or leave empty for defaults. inst_gnupg2 = false inst_gpgol = true inst_gpgex = true inst_gpa = true inst_winpt = true inst_gpgee = true inst_claws_mail = false inst_novice_manual_en = true inst_novice_manual_de = true inst_advanced_manual_de = true ; Where to install short-cuts. inst_start_menu = true inst_desktop = false inst_quick_launch_bar = false ; Contrary to other settings in this file, the start menu folder ; setting here will override the user selection at installation ; time. inst_start_menu_folder = GnuPG for Windows ; Additional configuration files to install. gpg.conf = D:\config\gpg-site.conf gpg-agent.conf = D:\config\gpg-agent-site.conf trustlist.txt = D:\config\trustlist-site.txt dirmngr.conf = D:\config\dirmngr-site.conf dirmngr_ldapserver.conf = D:\config\dirmngr_ldapserver-site.conf scdaemon.conf = D:\config\scdaemon-site.txt gpa.conf = D:\config\gpa-site.conf An example command for unattended installation could look like this: gpg4win.exe /S /C=C:\TEMP\gpg4win.ini /D=D:\Programme\Gpg4win -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From email at sven-radde.de Tue Feb 26 09:40:28 2008 From: email at sven-radde.de (Sven Radde) Date: Tue, 26 Feb 2008 09:40:28 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <47C3D279.12850.284F6283@dirk.traulsen.lypso.de> References: <241012.46021.qm@web56707.mail.re3.yahoo.com> <47C3D279.12850.284F6283@dirk.traulsen.lypso.de> Message-ID: <47C3D07C.2050000@sven-radde.de> Hi! Dirk Traulsen schrieb: > b. some keys do not belong to me in a common keyring. I am really not sure whether that is a good idea at all. Granting other people (write!) access to my secret keyring would be a troubling thought, even though I am not currently aware of any practical exploits. I do not know your threat model but I cannot imagine many benefits for such a setup. cu, Sven From dirk.traulsen at lypso.de Tue Feb 26 10:49:16 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Tue, 26 Feb 2008 10:49:16 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <47C3D07C.2050000@sven-radde.de> References: <241012.46021.qm@web56707.mail.re3.yahoo.com>, <47C3D279.12850.284F6283@dirk.traulsen.lypso.de>, <47C3D07C.2050000@sven-radde.de> Message-ID: <47C3EEAC.12097.28BD88A1@dirk.traulsen.lypso.de> Am 26 Feb 2008 um 9:40 hat Sven Radde geschrieben: > Hi! > > Dirk Traulsen schrieb: > > b. some keys do not belong to me in a common keyring. > > I am really not sure whether that is a good idea at all. Granting other > people (write!) access to my secret keyring would be a troubling > thought, even though I am not currently aware of any practical > exploits. > > I do not know your threat model but I cannot imagine many benefits for > such a setup. You are completely right that this is nothing for a maximum security usage, not the scenario one would like to have and not what I have at home. But think of one computer which is used together by several people in a working group or a shared flat. As the computer itself is physically reachable to several people you have no other chance as to trust these people not to mess with the computer. In these cases where there is no high security possible, you don't really get more security by using different keyrings. Dirk From vedaal at hush.com Tue Feb 26 15:55:22 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Tue, 26 Feb 2008 09:55:22 -0500 Subject: How know who is a file encrypted for ? Message-ID: <20080226145522.C600015803D@mailserver6.hushmail.com> >Date: Tue, 26 Feb 2008 08:48:57 +0100 >From: "Dirk Traulsen" >Subject: Re: How know who is a file encrypted for ? >1. If there are several recipients, test the given passphrase >automatically for all secret keys in your keyring, so that you >don't >have to give for example 9 times a wrong one if you are recipient >number four, which you even don't know beforehand. it isn't necessary to enter the passphrase at all just press repeatedly until you reach the recipient you want (you'll still need 9 'enter's for your example ;-) but hardly such a tedious task) >2. A command which lists the recipients of an encrypted file. or maybe an upgrade of gpg list packets, to include the recipient listing the way pgpdump does pgpdump immediately lists all the keyid's a message is encrypted to, and does so in the same order of recipients, as gnupg uses to ask for the passphrase here is a sample message encrypted to multiple keys: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.5 (MingW32) Comment: encrypted to 5 recipients hQEMA33EJ0r5AVSWAQf/VLQ6Olu6blS14quefUC14MFPkNhBrtrb9BjZZhlf7UPQ n4KAbfCOMjyKsmQMidraUGbLVfvzOh74blBOvy56MmqI9nAwc6abA+pHx6NUPxL+ HCu4s8NAxkebJkdNDwKLUG3NEUFLkh1Z31ItzpePQl8rpE7/BTkffr2HwRid5AZg r5OPcbky5r6WFdlcg/wzR8v593TaEkR5XcCMUuR3wBbXVeTuMVhJkxOF46G4aJ7+ Jcf9PUWMD2rGuUPrThpa608ueje0wsq4LLDeFPLS1905vq2IuTvY7djaANLHay8T fUUENU+Dr75P/SlaKJ26bX2hhD/GnojdKIVY80A564UBDAOjBsN7SVyhWwEH/RNu QBpgqjIToFJPTRB8ZWo+V5KKQUrR9sNK0gR16TRnAhovpUVmlPPfW/VsSO86Crz4 RQ9elc330hwdW6sgcyAoVxFO57rcvnr7gyXIki/20r2cZHKEytA0j4NlIS1iERpo vPoPQmuWuKujmM975goLKXp0/4FuqnD9W3WzjHxRtMq/+/MkEUIW1q8WWzlPoFIq nuuDS/b1MsdsrTDiQLGqzJoDijtAZ2OCot5LB5jYlhiAAG12InCD2y7s56huj95c +4HRpB7xwA7QIiA0LtIgMTaGO7C8B6joZWe8rt0HlqQVjdXic9zcUhAFNXDrqShz nqwSFcVrbht/kUIcATCFAQ4D2RmnrvDnSUgQA/0a7o1am71UgJu22opIrz1x9Iag 94hBct+j8iR7H8EuMctwdfFxVVH+Dn3cOvYDkbjOLIY8zU1wyjdW6AqvVoRQ4aws NPdAqp811stDM41PNa4Uo5hCX/Pf3426eepjYTWLqOMQBSQAU9S1KtIAdKq8TfFg ABvSTPINkTDcR7Q83AQA6MYMmlK5JvbspAkRQnpygIe43d2Wxx9E7zejVkYRNvai iIDO4g4YG48x+AS2JHsuwm+XOY28SCqpJihHlnsZCP1F9+eFH1KGfMsGPZKZijpf yOIUCliXVWsoi2eKQAhRUp76LR94pN2pGF+K2WrOM7hbSTBr+zVhdjagYRhu4MGF AQwDndLzwHVskd4BB/4qMQ7ClUo6YS6J7aiC50VK9HR5voik4PznLYhrrHpaow0R 85/Gprwr1RS0muk9upFZFX6SDZw/PB72rjgQV2Lb7AV0htuuivmn3Q6vnxWNMd1e jhk/bMfxtRIR+AVezMbGzLbslBOyW9lmT9z6n7JcIP47ZYLiZ3/jdm/4/DbUhSIj N3D/E9EHpkHo/OnCHE+HpPqbC8jWQGNmN2aUURlPpfVgpChDB1XUeOu8t0UkNOxK 6M3auZM6GA7a5lDiGxMVxtYmvCrAwyj98zknhRB6lGigl+jmHBi67CJei+85v2Ee SpQxdsFLgTyiz7RWC8HIKp/MFbPQOCVLFtQRKvAi0loB/GI8tmITfTYRHyZEp0vZ IKnWsKyerAefPBwqZcmDHOUOboayfxbnc0TYElxyzWbL8tsVfJPT5utQG+15W+CF aJoLiVGt3JnWgch44ePEkqo+y1n9f4CKNzs= =Md62 -----END PGP MESSAGE----- here is the pgpdump web interface: http://www.pgpdump.net/ and here is the pgpdump home site and links for sourcecode: http://www.mew.org/~kazu/proj/pgpdump/ vedaal any ads or links below this message are added by hushmail without my endorsement or awareness of the nature of the link -- Save hundreds on getting a Web Design Degree. Click here. http://tagline.hushmail.com/fc/Ioyw6h4fMueeWAGklrZP73ctJCCuFleiu0xJwUnBcDXi24RgBh6I4f/ From bahamut at digital-signal.net Tue Feb 26 17:00:37 2008 From: bahamut at digital-signal.net (Andrew Berg) Date: Tue, 26 Feb 2008 10:00:37 -0600 Subject: Corporate use of gnupg In-Reply-To: <47BB83A0.10505@sixdemonbag.org> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <002b01c872fa$98998ed0$0302a8c0@Nautilus> <20080219174956.GB16013@jabberwocky.com> <47BB83A0.10505@sixdemonbag.org> Message-ID: <47C437A5.8020808@digital-signal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Robert J. Hansen wrote: | The last time I talked to a patent lawyer about software (I had a nifty thing I wanted to implement and needed to make sure I wasn't walking into a patent lawsuit), I paid my $200/hr and got this bit of professional advice: "in today's software market, patents are used a lot more to keep other people out than to bring money in." Well, /I/ could've told you that. Don't tell me you never figured that out on your own. David Shaw wrote: | Yes. Put "encrypt-to (the-adk-key)" in everyone's gpg.conf. | | Of course, they could turn around and take it right out again. Unless | you have pretty tight control over the environment, ADKs or | encrypt-tos are not foolproof (and that applies to both PGP and GPG). Why can't they take away write privileges of gpg.conf (and the gpg executables for that matter) from normal users? AFAIK, that would be pretty simple (at least on a *nix system). Or did I overlook something important? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAwAGBQJHxDelAAoJEPiOA0Bgp4/LlfEH/Ap9Y7JiLtpFOs2U2FvqYVu5 xhZCy0Fo5SumAP7+OWA/lvZ1SU/zFCrSF2k/k+BZmnQtgh0h+lt3l78t1cR+tk+Z PkJPkPce0QbJ+lDl5OZNNkT8J166FVcm0UVdkTBkg/vBBcnn17k/gZAptV6sZg6A 95CnCxCxQCLhshCP/WhjrahM/CbG/cVx8nEU99TysC+Bt2a/8YuXd/HUAvhcoh6I RNbVGTmcHh8BZKp7tLbnhIpubBuLNscjssKCTos898JJ/tBSrTCZLMfNmNKP5Gtw OqzAkWj1wJ99VWZaWMOejeGE22U+ccSePeUIrojZ5NLDhlzUTUmaZghamlgLlFk= =zC7/ -----END PGP SIGNATURE----- From yalla at fsfe.org Tue Feb 26 17:07:59 2008 From: yalla at fsfe.org (Alexander W. Janssen) Date: Tue, 26 Feb 2008 17:07:59 +0100 Subject: Corporate use of gnupg In-Reply-To: <47C437A5.8020808@digital-signal.net> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <002b01c872fa$98998ed0$0302a8c0@Nautilus> <20080219174956.GB16013@jabberwocky.com> <47BB83A0.10505@sixdemonbag.org> <47C437A5.8020808@digital-signal.net> Message-ID: <47C4395F.4060407@fsfe.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Berg wrote: > Why can't they take away write privileges of gpg.conf (and the gpg > executables for that matter) from normal users? AFAIK, that would be > pretty simple (at least on a *nix system). You'd need to take away write-rights from the directory where gpg.conf resides - but that also would prevent the user of filling his or her keyring. All those files are in ~/.gnupg after all... You could probably put up all files in different directories and tell gnupg to use the files from certain locations. Or chown() the gnupg.conf to some other user. Not sure if gpg will read the file then though. Alex. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iQCVAwUBR8Q5XRYlVVSQ3uFxAQKBOwQAwPSSQEejvXoOcNOlKQpMXNR8sc59R/xc Wys10rqzf1SljK+vSj95hOc06yQOh0ox0vwqoGjVPPtDbmHJDroN3Juunnrk6DwY AaIsXHn8ea2/snAn8mMXdXQzNqDqVKFE7Um4OJXLcDDVXjD2V+GXrFFVmOKaxgCB Qv2mJi+InEE= =7iFo -----END PGP SIGNATURE----- From lists at thehurley.com Tue Feb 26 18:02:10 2008 From: lists at thehurley.com (Craig Hurley) Date: Tue, 26 Feb 2008 17:02:10 +0000 Subject: w32 client installer - silent install? In-Reply-To: <87mypof89q.fsf@wheatstone.g10code.de> References: <47C34532.4040403@thehurley.com> <87mypof89q.fsf@wheatstone.g10code.de> Message-ID: <47C44612.5000906@thehurley.com> On 26/02/2008 08:10, Werner Koch wrote: > Sorry, no. However the installer we use with gpg4win now features a few > options. See the excerpt below for details. IIRC, this is available in > the current gpg4win (1.1.3); checkout the README file. Thanks for that. It looks like gpg4win, version 1.1.3, using gpg 1.4.7; the available version of gpg is 1.4.8 (the updates are listed below). Should I be worried about not using the latest version of gpg? Regards, Craig. What's New [1.4.8] =========== * Changed the license to GPLv3. * Improved detection of keyrings specified multiple times. * Changes to better cope with broken keyservers. * Minor bug fixes. * The new OpenPGP standard is now complete, and has been published as RFC-4880. The GnuPG --openpgp mode (note this is not the default) has been updated to match the new standard. The --rfc2440 option can be used to return to the older RFC-2440 behavior. The main differences between the two are "--enable-dsa2 --no-rfc2440-text --escape-from-lines --require-cross-certification". * By default (i.e. --gnupg mode), --require-cross-certification is now on. --rfc2440-text and --force-v3-sigs are now off. * Allow encryption using legacy Elgamal sign+encrypt keys if option --rfc2440 is used. * Fixed the auto creation of the key stub for smartcards. * Fixed a rare bug in decryption using the OpenPGP card. * Fix RFC-4880 typo in the SHA-224 hash prefix. Old SHA-224 signatures will continue to work. From rjh at sixdemonbag.org Tue Feb 26 18:22:07 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 26 Feb 2008 11:22:07 -0600 Subject: Corporate use of gnupg In-Reply-To: <47C437A5.8020808@digital-signal.net> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <002b01c872fa$98998ed0$0302a8c0@Nautilus> <20080219174956.GB16013@jabberwocky.com> <47BB83A0.10505@sixdemonbag.org> <47C437A5.8020808@digital-signal.net> Message-ID: <47C44ABF.3010905@sixdemonbag.org> Andrew Berg wrote: > Well, /I/ could've told you that. Don't tell me you never figured that > out on your own. Unless your day job involves being intimately involved in IP transactions (not just writing code), you could have _speculated_ on that. There's a big difference between what you believe to be true, what you think to be true, what you know to be true, and what you can prove to be true. When dealing with actual dollars and cents, it pays off in the long run to pay the money required to get opinions from people who can prove the correctness of their assertions. This is true whether you're talking about information security, law, medicine, or just about anything else. From bahamut at digital-signal.net Tue Feb 26 19:15:22 2008 From: bahamut at digital-signal.net (Andrew Berg) Date: Tue, 26 Feb 2008 12:15:22 -0600 Subject: Corporate use of gnupg In-Reply-To: <47C44ABF.3010905@sixdemonbag.org> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <002b01c872fa$98998ed0$0302a8c0@Nautilus> <20080219174956.GB16013@jabberwocky.com> <47BB83A0.10505@sixdemonbag.org> <47C437A5.8020808@digital-signal.net> <47C44ABF.3010905@sixdemonbag.org> Message-ID: <47C4573A.6050205@digital-signal.net> Robert J. Hansen wrote: > Andrew Berg wrote: > >> Well, /I/ could've told you that. Don't tell me you never figured that >> out on your own. >> > Unless your day job involves being intimately involved in IP > transactions (not just writing code), you could have _speculated_ on > that. Although I would not bet my life on that, I don't agree that "speculated" is the right word. I have a bit more confidence it in it than that. > There's a big difference between what you believe to be true, > what you think to be true, what you know to be true, and what you can > prove to be true. > Agreed. > When dealing with actual dollars and cents, it pays off in the long run > to pay the money required to get opinions from people who can prove the > correctness of their assertions. This is true whether you're talking > about information security, law, medicine, or just about anything else. I would agree that when there are real, serious negative consequences involved, one cannot always afford to rely on assumptions, assertions, etc.. From wk at gnupg.org Tue Feb 26 19:44:57 2008 From: wk at gnupg.org (Werner Koch) Date: Tue, 26 Feb 2008 19:44:57 +0100 Subject: w32 client installer - silent install? In-Reply-To: <47C44612.5000906@thehurley.com> (Craig Hurley's message of "Tue, 26 Feb 2008 17:02:10 +0000") References: <47C34532.4040403@thehurley.com> <87mypof89q.fsf@wheatstone.g10code.de> <47C44612.5000906@thehurley.com> Message-ID: <87r6ez8sly.fsf@wheatstone.g10code.de> On Tue, 26 Feb 2008 18:02, lists at thehurley.com said: > Should I be worried about not using the latest version of gpg? No. Unless you are bitten by one of the bugs fixed in 1.4.8. There are no security issues. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From yalla at fsfe.org Tue Feb 26 18:42:35 2008 From: yalla at fsfe.org (Alexander W. Janssen) Date: Tue, 26 Feb 2008 18:42:35 +0100 Subject: Corporate use of gnupg In-Reply-To: <47C4441C.2070303@digital-signal.net> References: <15312177.post@talk.nabble.com> <20080210195726.GC12706@jabberwocky.com> <15514362.post@talk.nabble.com> <002b01c872fa$98998ed0$0302a8c0@Nautilus> <20080219174956.GB16013@jabberwocky.com> <47BB83A0.10505@sixdemonbag.org> <47C437A5.8020808@digital-signal.net> <47C4395F.4060407@fsfe.org> <47C4441C.2070303@digital-signal.net> Message-ID: <47C44F8B.1000801@fsfe.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Berg wrote: > Alexander W. Janssen wrote: >> Or chown() the gnupg.conf to some other user. Not sure if gpg will read >> the file then though. > If the user has read access (and gpg is being run with that user's > privileges of course), why wouldn't it? I don't know :-) I didn't try it and it might be some security-feature... Like "if the effective UID doesn't match the owner of ~/.gnupg/gnupg.conf" don't start". But as I said: Didn't try it. Was just thinking of possibilities. Alex. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iQCVAwUBR8RPiRYlVVSQ3uFxAQKafgQAg9sDv7XsUrrAwZVk8KpTO3QP3kaxdHim rFe/kCuFRKQBoIlnW09YRnmGkBqjTMobleGwBd1x/Ylkp6Ksgp/OkOoSNooN8mfp ixPF8943QydV5ku6ffrPkJBJAaWOVvSBpcfJJpTSB7rBMXsW7KoY8khoQWv1lvfg Pcl4bM8EoCI= =q1Uh -----END PGP SIGNATURE----- From dirk.traulsen at lypso.de Wed Feb 27 10:00:25 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Wed, 27 Feb 2008 10:00:25 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <20080226145522.C600015803D@mailserver6.hushmail.com> References: <20080226145522.C600015803D@mailserver6.hushmail.com> Message-ID: <47C534B9.7390.2DB72BD7@dirk.traulsen.lypso.de> Am 26 Feb 2008 um 9:55 hat vedaal at hush.com geschrieben: > > Am 26 Feb 2008 um 8:48 hat Dirk.Traulsen at lypso.de geschrieben: > > > >1. If there are several recipients, test the given passphrase > >automatically for all secret keys in your keyring, so that you don't > >have to give for example 9 times a wrong one if you are recipient > >number four, which you even don't know beforehand. > > it isn't necessary to enter the passphrase at all just press > repeatedly until you reach the recipient you want (you'll still need 9 > 'enter's for your example ;-) but hardly such a tedious task) You don't believe me to enter 9 times a complete passphrase, do you? You are right, that it is possible to live with it, but why not implement something more comfortable if it doesn't lower the security level? > >2. A command which lists the recipients of an encrypted file. > > or maybe an upgrade of gpg list packets, to include the recipient > listing the way pgpdump does > > pgpdump immediately lists all the keyid's a message is encrypted to, > and does so in the same order of recipients, as gnupg uses to ask > for the passphrase What I meant, was something like this mockup: ============== C:\>gpg --recipient-keys ENCRYPTED_FILE.gpg gpg: file ENCRYPTED_FILE.gpg was encrypted to the following keys: gpg: encrypted with 2048-bit ELG-E key, ID 1643B926, created 2002-01-28 "David M. Shaw " gpg: encrypted with 4096-bit ELG-E key, ID E192093D, created 2005-10-21 "Dirk Traulsen (dtl-2) " gpg: secret key with ID E192093D in keyring gpg: encrypted with 2048-bit RSA key, ID 85306D25, created 2000-09-05 "vedaal nistar " gpg: encrypted with RSA key, ID 710ACD97 gpg: encrypted with RSA key, ID 01B0C12D C:\> ============== As you can easily see, there are 5 recipients: 3 in public keyring with 1 secret key in secret keyring, 2 not in keyring This is the result, I get from your example: ============ PGPdump Results Old: Public-Key Encrypted Session Key Packet(tag 1)(268 bytes) New version(3) Key ID - 0x7DC4274AF9015496 Pub alg - RSA Encrypt or Sign(pub 1) RSA m^e mod n(2047 bits) - ... -> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02 Old: Public-Key Encrypted Session Key Packet(tag 1)(268 bytes) New version(3) Key ID - 0xA306C37B495CA15B Pub alg - RSA Encrypt or Sign(pub 1) RSA m^e mod n(2045 bits) - ... -> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02 (...) ============== While pgpdump gives an really interesting output, it does not deliver what I asked for: A nicely formated list of the recipients of an encrypted file. Dirk From sinux at fsfe.org Wed Feb 27 10:44:41 2008 From: sinux at fsfe.org (Sebastien Chassot) Date: Wed, 27 Feb 2008 10:44:41 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <47C534B9.7390.2DB72BD7@dirk.traulsen.lypso.de> References: <20080226145522.C600015803D@mailserver6.hushmail.com> <47C534B9.7390.2DB72BD7@dirk.traulsen.lypso.de> Message-ID: <1204105481.999.26.camel@dell.sinux.seb> On Wed, 2008-02-27 at 10:00 +0100, Dirk Traulsen wrote: > You don't believe me to enter 9 times a complete passphrase, do you? > You are right, that it is possible to live with it, but why not > implement something more comfortable if it doesn't lower the security > level? > > > While pgpdump gives an really interesting output, it does not deliver > what I asked for: > A nicely formated list of the recipients of an encrypted file. > I agree, normal users may want user friendly output and developers want full debugging output. There is two need and now only full (heavy) output is available. Obviously users can make it with sed and awk but if there do so they are developers and like verbose output ;) From vedaal at hush.com Wed Feb 27 15:51:05 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Wed, 27 Feb 2008 09:51:05 -0500 Subject: How know who is a file encrypted for ? Message-ID: <20080227145106.16CC615803D@mailserver6.hushmail.com> Dirk Traulsen dirk.traulsen at lypso.de wrote on Wed Feb 27 10:00:25 CET 2008 >You don't believe me to enter 9 times a complete passphrase, do you? i agree with you completely that it would be a major annoyance to have to enter a complete passphrase, even 3 times, and certainly would be very annoying to enter it 9 times, my point was that you don't need to enter the *complete* passphrase at all, or even 'any' part of it, all you have to do is press the 'enter' key without typing *anything* pressing the 'enter' key 9 times quickly, is something i can live with without bothering the developers (they were nice enough to include the option of being able to see the passphrase as it is typed in, after i requested it), [belated THANKS !!! ;-) ] >What I meant, was something like this mockup: ============== >C:\>gpg --recipient-keys ENCRYPTED_FILE.gpg >gpg: file ENCRYPTED_FILE.gpg was encrypted to the following keys: i agree, and would welcome this as well, also agree that the pgpdump provides extra distracting information, when all one is interested in, is finding out who the encrypted recipients are only brought up pgpdump as a useful solution until this could be done, (it lets you see how many times you need to press 'enter' to get to your key) and also, that since it is open source, it might be easier for the developers look at it and add a modified patch to have gnupg do the 'gpg --recipient-keys' option as you suggested (btw, i made a mistake in my example, it was encrypted to 4 keys instead of 5, i forgot i turned of my 'encrypt to default key' option ;-( ) vedaal any ads or links below this message are added by hushmail without -- Click to get a free auto insurance quotes from top companies. http://tagline.hushmail.com/fc/Ioyw6h4d8EHyLkuT6PZ33RrS131T3H2ZH6Fus2c3hJ5Yj08REzU9VV/ my endorsement or awareness of the nature of the link From dirk.traulsen at lypso.de Wed Feb 27 18:55:28 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Wed, 27 Feb 2008 18:55:28 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <20080227145106.16CC615803D@mailserver6.hushmail.com> References: <20080227145106.16CC615803D@mailserver6.hushmail.com> Message-ID: <47C5B220.19076.2FA10758@dirk.traulsen.lypso.de> Am 27 Feb 2008 um 9:51 hat vedaal at hush.com geschrieben: > Dirk Traulsen dirk.traulsen at lypso.de > wrote on Wed Feb 27 10:00:25 CET 2008 > > >You don't believe me to enter 9 times a complete passphrase, do > you? > > i agree with you completely that it would be a major annoyance to > have to enter a complete passphrase, even 3 times, > and certainly would be very annoying to enter it 9 times, > > my point was that you don't need to enter the *complete* passphrase > at all, or even 'any' part of it, > > all you have to do is press the 'enter' key without typing > *anything* Oh God! You REALLY thought I am so stupid that I type in complete passphrases 9 times. I cannot believe it. I first thought you made fun on me. Do I really sound like a complete moron here? 1. I thought, it was self-evident that one just hits to go through the questions, so I didn't mention it. 2. And to repeat myself: The examples I described for wish number one, where not MY scenarios I LIKE to have at home! There I'm in control of the computer and I can setup everything logical and secure. But when you are NOT in control of the computer you are supposed to work with and you experience a scenario like I described, then you just have to live with it. (Which might be a bit more comfortable, that's all.) On to the obviously more realistic wish number 2: --recipient-keys > >What I meant, was something like this mockup: > ============== > >C:\>gpg --recipient-keys ENCRYPTED_FILE.gpg > >gpg: file ENCRYPTED_FILE.gpg was encrypted to the following keys: > > > i agree, and would welcome this as well, Thanks. So at least three people think it would be a good addition. Dirk From vedaal at hush.com Wed Feb 27 18:00:59 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Wed, 27 Feb 2008 12:00:59 -0500 Subject: How know who is a file encrypted for ? Message-ID: <20080227170100.3C1DA15803D@mailserver6.hushmail.com> vedaal at hush.com vedaal at hush.com wrote o Wed Feb 27 15:51:05 CET 2008 >What I meant, was something like this mockup: ============== >C:\>gpg --recipient-keys ENCRYPTED_FILE.gpg >gpg: file ENCRYPTED_FILE.gpg was encrypted to the following keys: actually, gnupg already does this when decrypting, but only after the passphrases are entered incorrectly for each key in the example i posted, here is the gnupg output after intentionally giving the wrong passphrases for each of the keys: gpg: Invalid passphrase; please try again ... You need a passphrase to unlock the secret key for user: "cccc1 " 2048-bit RSA key, ID 756C91DE, created 2005-12-01 :encrypted data packet: length: 90 mdc_method: 2 gpg: encrypted with 2048-bit RSA key, ID 756C91DE, created 2005-12- 01 "cccc1 " gpg: public key decryption failed: bad passphrase gpg: encrypted with 1024-bit ELG-E key, ID F0E74948, created 2002- 01-15 "boo " gpg: public key decryption failed: bad passphrase gpg: encrypted with 2048-bit RSA key, ID 495CA15B, created 2005-12- 01 "bbbb1 " gpg: public key decryption failed: bad passphrase gpg: encrypted with 2048-bit RSA key, ID F9015496, created 2005-12- 01 "aaaa1 " gpg: public key decryption failed: bad passphrase gpg: decryption failed: secret key not available c:\gnupg> so, a simple workaround to see which keys a message is encrypted to, is to just type: gpg filename and press the 'enter' key quickly and repeatedly until gnupg gives the 'failed decryption' message, and lists all the keys (also not too hard to live with ... ;-) ) vedaal any ads or links below this message are added by hushmail without my endorsement or awareness of the nature of the link -- Need cash? Click to get a cash advance. http://tagline.hushmail.com/fc/Ioyw6h4dP5JPpivsACr8uRGuNoIGIPHVi2hu11IoWuXXcqfw85CjFt/ From dshaw at jabberwocky.com Wed Feb 27 19:23:34 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 27 Feb 2008 13:23:34 -0500 Subject: How know who is a file encrypted for ? In-Reply-To: <47C5B220.19076.2FA10758@dirk.traulsen.lypso.de> References: <20080227145106.16CC615803D@mailserver6.hushmail.com> <47C5B220.19076.2FA10758@dirk.traulsen.lypso.de> Message-ID: <20080227182334.GA24626@jabberwocky.com> On Wed, Feb 27, 2008 at 06:55:28PM +0100, Dirk Traulsen wrote: > > >What I meant, was something like this mockup: > > ============== > > >C:\>gpg --recipient-keys ENCRYPTED_FILE.gpg > > >gpg: file ENCRYPTED_FILE.gpg was encrypted to the following keys: > > > > > > i agree, and would welcome this as well, > > Thanks. > So at least three people think it would be a good addition. Why? I'm serious - what is the use case here? How often do people need to list all recipients of a file? By the way: gpg --no-default-keyring --secret-keyring /dev/null the-file.gpg David From lists at thehurley.com Wed Feb 27 19:27:31 2008 From: lists at thehurley.com (Craig Hurley) Date: Wed, 27 Feb 2008 18:27:31 +0000 Subject: w32 client installer - silent install? In-Reply-To: <87mypof89q.fsf@wheatstone.g10code.de> References: <47C34532.4040403@thehurley.com> <87mypof89q.fsf@wheatstone.g10code.de> Message-ID: <47C5AB93.6090809@thehurley.com> On 26/02/2008 08:10, Werner Koch wrote: > > [gpg4win] > ; Installer settings. Do not define or leave empty for defaults. > inst_gnupg2 = false > inst_gpgol = true > inst_gpgex = true > inst_gpa = true > inst_winpt = true > inst_gpgee = true > inst_claws_mail = false > inst_novice_manual_en = true > inst_novice_manual_de = true > inst_advanced_manual_de = true Hello, Thank you for this, I've got the scripted install working. I just have a couple more queries... I've tried installing using "inst_gnupg2" set to true and then false; it didn't seem to make a difference. What is the "inst_gnupg2" setting? Also, what is the "inst_gpgex" setting for? Many thanks, Craig. From wk at gnupg.org Wed Feb 27 19:47:43 2008 From: wk at gnupg.org (Werner Koch) Date: Wed, 27 Feb 2008 19:47:43 +0100 Subject: Sorting the recipeint keys (was: How know who is a file encrypted for ?) In-Reply-To: <20080227145106.16CC615803D@mailserver6.hushmail.com> (vedaal@hush.com's message of "Wed, 27 Feb 2008 09:51:05 -0500") References: <20080227145106.16CC615803D@mailserver6.hushmail.com> Message-ID: <87lk562q40.fsf@wheatstone.g10code.de> On Wed, 27 Feb 2008 15:51, vedaal at hush.com said: > pressing the 'enter' key 9 times quickly, is something i can live > with without bothering the developers Well, I sometimes receive mails encrypted to 20 or so keys and some of them use the wild card keyid (-R) feature. Now, this is not a problem if you have just one or two secret keys but with 30 secret keys it is a major annoyance because all of them need to be trial decrypted which takes a long time and requires to enter many passphrases. Eventually gpg sees my own key and can now decrypt it. The solution to this is pretty clear, we need to read all public key encrypted packets first and sort them so that own keys come first followed by other keys and finally by the wild card keys. This also allows us to order the trial decryption to minimize smart card changes. I have not implement this because obviously I have not yet suffered enough from that problem. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From vedaal at hush.com Wed Feb 27 21:31:57 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Wed, 27 Feb 2008 15:31:57 -0500 Subject: How know who is a file encrypted for ? Message-ID: <20080227203157.CD03DD0102@mailserver10.hushmail.com> David Shaw dshaw at jabberwocky.com wrote on Wed Feb 27 19:23:34 CET 2008 : >By the way: > gpg --no-default-keyring --secret-keyring /dev/null the-file.gpg ..............................................^^^^^^^^........... what is the correct command on 'windows' ? TIA, vedaal any ads or links below this message are added by hushmail without my endorsement or awareness of the nature of the link -- Save big on a huge selection of discount auto parts. Click now! http://tagline.hushmail.com/fc/Ioyw6h4eju29Wdh6ZQ7gb864RUMIeiLzQ3G92VUIgkleWNXUrxkIyj/ From lists at thehurley.com Wed Feb 27 22:02:22 2008 From: lists at thehurley.com (Craig Hurley) Date: Wed, 27 Feb 2008 21:02:22 +0000 Subject: w32 client installer - silent install? In-Reply-To: <47C5AB93.6090809@thehurley.com> References: <47C34532.4040403@thehurley.com> <87mypof89q.fsf@wheatstone.g10code.de> <47C5AB93.6090809@thehurley.com> Message-ID: <47C5CFDE.7080309@thehurley.com> Initially, I replied straight back to Werner (by mistake). He already responded with the answer... "inst_gnupg2" and "inst_gpgex" are for use in the forthcoming release of gpg4win. Regards, Craig. From JPClizbe at tx.rr.com Wed Feb 27 22:17:01 2008 From: JPClizbe at tx.rr.com (John Clizbe) Date: Wed, 27 Feb 2008 15:17:01 -0600 Subject: How know who is a file encrypted for ? In-Reply-To: <20080227203157.CD03DD0102@mailserver10.hushmail.com> References: <20080227203157.CD03DD0102@mailserver10.hushmail.com> Message-ID: <47C5D34D.2060407@tx.rr.com> vedaal at hush.com wrote: > David Shaw dshaw at jabberwocky.com > wrote on Wed Feb 27 19:23:34 CET 2008 : > >>By the way: >> gpg --no-default-keyring --secret-keyring /dev/null the-file.gpg > > what is the correct command on Windows ? gpg --no-default-keyring --secret-keyring nul the-file.gpg or if you prefer NUL: (case is insignificant) -- John P. Clizbe Inet: JPClizbe (a) tx DAWT rr DAHT con Ginger Bear Networks hkp://keyserver.gingerbear.net "Be who you are and say what you feel because those who mind don't matter and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 658 bytes Desc: OpenPGP digital signature URL: From freeyourmind251 at hotmail.com Fri Feb 22 07:30:00 2008 From: freeyourmind251 at hotmail.com (chenkai) Date: Fri, 22 Feb 2008 06:30:00 +0000 Subject: IS GNU2.0 still support on OPENVMS? Message-ID: I heard GNU 1.4.7 support OPENVMS and some other popular Operation System. what is the difference in the newest version in this part? thx a lot Daniel freeyourmind251 at hotmail.com _________________________________________________________________ MSN????????????????????? http://im.live.cn/emoticons/?ID=18 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragmore at gmail.com Mon Feb 25 16:13:37 2008 From: dragmore at gmail.com (Dragmore) Date: Mon, 25 Feb 2008 16:13:37 +0100 Subject: "--passphrase-file" issues Message-ID: Hi. I have a question regarding some automation options in Gnupg. Im using Gnupg 2.0.4 running on OpenSuse 10.3 32bit. Each 3rd day i get 5-10 new .gpg files that i need to automatically decrypt using a known passphrase using the following command line: gpg --decrypt-files --no-mdc-warning -q --allow-multiple-messages $(find . -name '*.gpg') When i add "--passphrase-file" /root/pass.txt i still get the passphrase dialogbox up. PS! Im running the gpg command as root user so there shouldnt be security issue.. If any one has a tip or a hint to what to do i would be most greatfull Best Regards TEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From mt at martintoft.dk Wed Feb 27 20:06:57 2008 From: mt at martintoft.dk (Martin Toft) Date: Wed, 27 Feb 2008 20:06:57 +0100 Subject: ISO-8859-1 mails getting marked as UTF-8 Message-ID: <20080227190657.GA11763@puffy.obsd.dk> Hi, I use GnuPG together with mutt on Debian Etch. I prefer to use ISO-8859-1 and have these lines in my .muttrc to accomplish that: set charset="iso-8859-1" set config_charset="iso-8859-1" set send_charset="iso-8859-1" When sending a mail without using GnuPG (by selecting "clear" in mutt's PGP menu), the above configuration results in the following content type in the mail's header: Content-Type: text/plain; charset=iso-8859-1 However, when signing the mail using GnuPG, the content type changes: Content-Type: text/plain; charset=utf-8; x-action=pgp-signed The body of the mail is also converted to UTF-8. My Danish characters (??????) end up being displayed incorrect at the receiver, as mutt still inserts the following line in the header: Content-Transfer-Encoding: 8bit I have tried a lot of things to avoid the conversion to UTF-8, unfortunately without luck: - Using the mutt and GnuPG packages that come with Debian Etch (mutt 1.5.13 and GnuPG 1.4.6). - Compiling my own versions of mutt and GnuPG (./configure without any options other than --prefix, mutt 1.5.17, GnuPG 1.4.8). - Invoking gpg with "--charset iso-8859-1". - Invoking gpg with "--display-charset iso-8859-1". - Having "charset iso-8859-1" in ~/.gnupg/gpg.conf. - Exporting LC_ALL=en_DK before starting mutt. - Exporting LC_ALL=en_DK.iso88591 before starting mutt. - Invoking gpg with "LC_ALL=en_DK gpg ...". - Invoking gpg with "LC_ALL=en_DK.iso88591 gpg ...". - Searched Google (mostly without luck). - Searched the gnupg-users at gnupg.org archive (on marc.info, completely without luck). I have run out of ideas. What else can I try? Can you spot something wrong in what I have tried so far? Please CC me when replying, as I'm not subscribed to the list. I have attached my locale configuration and most of my .muttrc (the GnuPG relevant part) inline. Thanks in advance. Martin Attachments: 1. locale configuration: $ locale -a C en_DK en_DK.iso88591 POSIX $ locale LANG=en_DK LC_CTYPE="en_DK" LC_NUMERIC="en_DK" LC_TIME="en_DK" LC_COLLATE="en_DK" LC_MONETARY="en_DK" LC_MESSAGES="en_DK" LC_PAPER="en_DK" LC_NAME="en_DK" LC_ADDRESS="en_DK" LC_TELEPHONE="en_DK" LC_MEASUREMENT="en_DK" LC_IDENTIFICATION="en_DK" LC_ALL= 2. My .muttrc (the GnuPG relevant part): [...] #stolen from http://codesorcery.net/old/mutt/mutt-gnupg-howto set pgp_decode_command="gpg %?p?--passphrase-fd 0? --no-verbose --batch --output - %f" set pgp_verify_command="gpg --no-verbose --batch --output - --verify %s %f" set pgp_decrypt_command="gpg --passphrase-fd 0 --no-verbose --batch --output - %f" set pgp_sign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f" set pgp_clearsign_command="gpg --no-verbose --batch --output - --passphrase-fd 0 --armor --textmode --clearsign %?a?-u %a? %f" set pgp_encrypt_only_command="pgpewrap gpg --batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust --encrypt-to 0xC0589D9E -- -r %r -- %f" set pgp_encrypt_sign_command="pgpewrap gpg --passphrase-fd 0 --batch --quiet --no-verbose --textmode --output - --encrypt --sign %?a?-u %a? --armor --always-trust --encrypt-to 0xC0589D9E -- -r %r -- %f" set pgp_import_command="gpg --no-verbose --import -v %f" set pgp_export_command="gpg --no-verbose --export --armor %r" set pgp_verify_key_command="gpg --no-verbose --batch --fingerprint --check-sigs %r" set pgp_list_pubring_command="gpg --no-verbose --batch --with-colons --list-keys %r" set pgp_list_secring_command="gpg --no-verbose --batch --with-colons --list-secret-keys %r" set pgp_autosign=yes set pgp_sign_as=0xC0589D9E set pgp_replyencrypt=yes set pgp_timeout=1800 set pgp_good_sign="^gpg: Good signature from" set pgp_create_traditional=yes [...] From vedaal at hush.com Wed Feb 27 23:29:49 2008 From: vedaal at hush.com (vedaal at hush.com) Date: Wed, 27 Feb 2008 17:29:49 -0500 Subject: How know who is a file encrypted for ? Message-ID: <20080227222950.136ACD0102@mailserver10.hushmail.com> On Wed, 27 Feb 2008 16:17:01 -0500 John Clizbe wrote: >>>By the way: >>> gpg --no-default-keyring --secret-keyring /dev/null the- >file.gpg >> >> what is the correct command on Windows ? > >gpg --no-default-keyring --secret-keyring nul the-file.gpg i can't get it to work :-(( i get the same gpg output as when trying to decrypt any file gpg lists whatever public keys are not in my keyring, and then asks me for a passphrase for the first key in my secret ring, and then, if that one is wrong, goes onto the next one, and only, if the passphrases are wrong for all the keys, then gpg lists all the keys the message was encrypted to vedaal any ads or links below this message are added by hushmail without my endorsement or awareness of the nature of the link -- Compete with the big boys. Click here to find products to benefit your business. http://tagline.hushmail.com/fc/Ioyw6h4eDJdZDQq9RXV2uE440Pzoe8316d8SBZLT9HkGZ3OLjFffVl/ From mkallas at schokokeks.org Wed Feb 27 23:11:43 2008 From: mkallas at schokokeks.org (Michael Kesper) Date: Wed, 27 Feb 2008 23:11:43 +0100 Subject: ISO-8859-1 mails getting marked as UTF-8 In-Reply-To: <20080227190657.GA11763@puffy.obsd.dk> References: <20080227190657.GA11763@puffy.obsd.dk> Message-ID: <20080227221143.GG3922@localhost> * Martin Toft [2008-02-27 20:06:57 +0100]: > I use GnuPG together with mutt on Debian Etch. I prefer to use > ISO-8859-1 Short question: Why? ISO-8859-1 is a hack and even so common alphabets like cyrillic break it. So, if you want to stay sane, switch to UTF-8. My 0,02 EUR Michael -- Free Software Foundation Europe (FSFE) [] (http://fsfeurope.org) Join the Fellowship of FSFE! [][][] (http://fsfe.org/join) Your donation powers our work! [] (http://fsfeurope.org/donate) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature URL: From richih.mailinglist at gmail.com Thu Feb 28 01:38:11 2008 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 28 Feb 2008 01:38:11 +0100 Subject: Signing people with only one form of ID? Message-ID: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> Hi all, after creating a new key and getting back into 'serious' gpg usage, I attended a key signing party where the overwhelming portion of people had only one form of ID with them. It seems that most people assign the highest trust level to others who have presented only one form of ID. Personally, I tend towards only granting that to people who showed me two seperate pieces of ID. I know I am free to do whatever I want, but I am looking for feedback and, perhaps, consensus from the community. Best regards, Richard From rjh at sixdemonbag.org Thu Feb 28 03:36:44 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 27 Feb 2008 20:36:44 -0600 Subject: Signing people with only one form of ID? In-Reply-To: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> Message-ID: <47C61E3C.3050009@sixdemonbag.org> Richard Hartmann wrote: > It seems that most people assign the highest trust level to others > who have presented only one form of ID. Personally, I tend towards > only granting that to people who showed me two seperate pieces > of ID. It may be helpful for you to think about things in terms of not just how many identity documents are present, but the relative difficulty in forging identity documents, as well as your ability to spot forgeries. E.g., a university ID card is pretty easy to forge. You also probably don't know what Wayne State University's ID card looks like, so if someone presents it to you, you have no way of knowing whether it's on the up and up or not. Compare that to a passport. You might already have a passport. Even if you don't, it's pretty easy to find out what a passport looks like, what sort of paper is used in it, what security features are present. You can thus have a lot more confidence in someone's identity if they present you with a passport than if they present you with, say, a university ID card. From rjh at sixdemonbag.org Thu Feb 28 03:45:50 2008 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 27 Feb 2008 20:45:50 -0600 Subject: Signing people with only one form of ID? In-Reply-To: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> Message-ID: <47C6205E.2000200@sixdemonbag.org> Another couple of thoughts-- > I know I am free to do whatever I want, but I am looking for > feedback and, perhaps, consensus from the community. If I recall correctly, OpenPGP explicitly has six different certification levels (in the range 0-5), but it does not specify any semantic meaning to each level. They make recommendations, but those recommendations are not really binding. To muddy the waters further, many OpenPGP implementations either fail to support certification-level distinctions, or make you jump through hoops in order to do it. Those hoops are often error-prone. E.g., GnuPG. GnuPG's default certification level is a 3. If I see a signature on someone's key, I know absolutely nothing. Maybe it's a simple persona-level cert, in which case they should have certified it with a 0 but they just forgot to set the cert level. Maybe it's a "I have his DNA and fingerprints on file with me and I asked the FBI to check him out", in which case they should have certified it as a 5 but they just forgot to set the cert level. Etc., etc. Because of these three factors--no semantic meaning associated with certification levels, some OpenPGP implementations not supporting the distinctions, and many implementations making it easy to forget that such distinctions exist--my default policy is to treat all signatures as unchecked persona-level IDs unless I know the signer personally and know they have a signature policy. From dshaw at jabberwocky.com Thu Feb 28 03:51:28 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 27 Feb 2008 21:51:28 -0500 Subject: Signing people with only one form of ID? In-Reply-To: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> Message-ID: <20080228025128.GA26111@jabberwocky.com> On Thu, Feb 28, 2008 at 01:38:11AM +0100, Richard Hartmann wrote: > Hi all, > > after creating a new key and getting back into 'serious' gpg usage, > I attended a key signing party where the overwhelming portion of > people had only one form of ID with them. > > It seems that most people assign the highest trust level to others > who have presented only one form of ID. Personally, I tend towards > only granting that to people who showed me two seperate pieces > of ID. Perhaps more important than the number of IDs, is the quality of IDs. A cheap generic photo ID from the local gym is practically worthless. A passport or drivers license is usually good. I wouldn't go crazy here: keep in mind that the web of trust is designed for people who don't have the ability to prove that a passport or license is real. This is one of the reasons that more than one signature is needed to make a key fully valid. All that the web of trust asks is that you do your best. David From dshaw at jabberwocky.com Thu Feb 28 04:09:03 2008 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 27 Feb 2008 22:09:03 -0500 Subject: Signing people with only one form of ID? In-Reply-To: <47C6205E.2000200@sixdemonbag.org> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <47C6205E.2000200@sixdemonbag.org> Message-ID: <20080228030903.GA26047@jabberwocky.com> On Wed, Feb 27, 2008 at 08:45:50PM -0600, Robert J. Hansen wrote: > Another couple of thoughts-- > >> I know I am free to do whatever I want, but I am looking for >> feedback and, perhaps, consensus from the community. > > If I recall correctly, OpenPGP explicitly has six different certification > levels (in the range 0-5), but it does not specify any semantic meaning to > each level. They make recommendations, but those recommendations are not > really binding. 4 levels: 0-3, inclusive. They are not binding (can't be, given the design), but meaning is specified. The meaning, however, is relative to the signer. That is, my #2 is not necessarily the same as someone elses #2. > To muddy the waters further, many OpenPGP implementations either fail to > support certification-level distinctions, or make you jump through hoops in > order to do it. Those hoops are often error-prone. I know of no OpenPGP implementation that truly supports certification level distinctions. All of them, including GPG, treat a signature as a signature, regardless of the level. GPG does have a way to say "don't accept anything less than level (X)" (which defaults to 2), but once a signature has been accepted, it's the same as any other signature. > E.g., GnuPG. GnuPG's default certification level is a 3. The default is 0. 0 makes no claim at all, which is the safest default. The levels (for general knowledge) are: 0 = I'm not telling you ("generic") 1 = I didn't check at all ("persona") 2 = I checked a little bit ("casual") 3 = I checked a lot ("positive") There is a lot more verbiage on the 4 types in RFC-4880, but it basically boils down to what I said above. > If I see a signature on someone's key, I know absolutely nothing. > Maybe it's a simple persona-level cert, in which case they should > have certified it with a 0 but they just forgot to set the cert > level. Maybe it's a "I have his DNA and fingerprints on file with > me and I asked the FBI to check him out", in which case they should > have certified it as a 5 but they just forgot to set the cert level. > Etc., etc. Some people include a policy URL in the certification to tell a recipient just what was done. This has its own advantages and disadvantages, but is really a comment as well, as no program parses and acts on the information. The bottom line is that you can sign with a signature level if you like, but (barring persona signatures) it only makes a marginal difference in practice. David From brian at briansmith.org Thu Feb 28 04:43:23 2008 From: brian at briansmith.org (Brian Smith) Date: Wed, 27 Feb 2008 19:43:23 -0800 Subject: Signing people with only one form of ID? In-Reply-To: <47C6205E.2000200@sixdemonbag.org> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <47C6205E.2000200@sixdemonbag.org> Message-ID: <001d01c879bc$127fff50$6401a8c0@T60> Robert J. Hansen wrote: > Because of these three factors--no semantic meaning > associated with certification levels, some OpenPGP > implementations not supporting the distinctions, and many > implementations making it easy to forget that such > distinctions exist--my default policy is to treat all > signatures as unchecked persona-level IDs unless I know the > signer personally and know they have a signature policy. Even that strict policy is hardly sensible, but it is better than the policies that are often promoted. I don't see how a keysigning party works. Anybody that participates by showing ID is reducing their personal privacy by divulging their personal information. Furthermore, caring around such ID is much more likely to create a security problem (if it is lost or stolen) than anything GPG can prevent. Finally, we give up a lot of personal security when we give our personal information to governments to get our government-issued IDs, which I think is a big mistake. Especially, when I was staying in Thailand, I saw firsthand how governments (Thai, American, and every other one) use ID controls to repress people they don't like. Anybody that insists on government-issued ID for authentication is doing the world a disservice. For all those reasons, I am willing to sign anybody's keys at any level without any authentication, using as many different signatures as they require. And, I will do so with a set of keys that are not linked to my (online or real-life) identity, so they cannot be blacklisted. Actually, I would like to create a network of people with the same key-signing policy. In doing so, I think it will be easy to demonstrate why the current implementation of the web-of-trust via keysigining is inadequate, especially when such a network of people participate in keysigning parties to promote the authority of their own (bogus) signatures. In an ideal world, the fact that I am disclosing this information in advance should mean that mobody will sign my PGP key at any keysigning party. I don't know how many I will be able to attend, but I will attempt to get as many as signatures as I can, alternatively using my birth name and a name of my own choosing (possibly copied from somebody with a coincidentally similar appearance). It will be interesting to see how many people will give me a level 5 classification with an identity that can be traced back directly to this message. - Brian From email at sven-radde.de Thu Feb 28 07:22:50 2008 From: email at sven-radde.de (Sven Radde) Date: Thu, 28 Feb 2008 07:22:50 +0100 Subject: Signing people with only one form of ID? In-Reply-To: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> Message-ID: <1204179770.6277.28.camel@carbon> Hi! Am Donnerstag, den 28.02.2008, 01:38 +0100 schrieb Richard Hartmann: > after creating a new key and getting back into 'serious' gpg usage, > I attended a key signing party where the overwhelming portion of > people had only one form of ID with them. What do you define as "form of ID"? Being german, I am really baffled by this question... I have only one personal identity card and it is really sufficient to prove my identity to anyone. I could bring along my traveller's passport but that one is issued by the same authority based on the same data. What else would count as "form of ID"? Credit card? Credit card with picture? Library card? A bonus card from the german railway with picture? I am sure that I could come up with about a dozen such pieces of "ID" with a wrong name on it (and, if applicable, my picture). cu, Sven From wk at gnupg.org Thu Feb 28 09:17:59 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Feb 2008 09:17:59 +0100 Subject: ISO-8859-1 mails getting marked as UTF-8 In-Reply-To: <20080227190657.GA11763@puffy.obsd.dk> (Martin Toft's message of "Wed, 27 Feb 2008 20:06:57 +0100") References: <20080227190657.GA11763@puffy.obsd.dk> Message-ID: <87d4qhijew.fsf@wheatstone.g10code.de> On Wed, 27 Feb 2008 20:06, mt at martintoft.dk said: > When sending a mail without using GnuPG (by selecting "clear" in mutt's > PGP menu), the above configuration results in the following content type That is your problem. Clearsigned PGP messages are not well defined. OpenPGP says that all is UTF-8 and there is no clean way to change that. Yes there is the Charset armor header but that one is not supported by GnuPG because it is a kludge not required since 15 years or so (since MIME). Please use PGP/MIME and the semantics of your message are well defined. > - Invoking gpg with "--charset iso-8859-1". > - Invoking gpg with "--display-charset iso-8859-1". The option --charset (and its alias --display-charset) is used only for meta data (user IDs, notations) and has no effect on the actual encrypted or signed data. We won't do anything in GnuPG about this. The Mutt folks discussed these issues for many years. There suggestion will probably also be: Use PGP/MIME. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From dirk.traulsen at lypso.de Thu Feb 28 08:59:18 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Thu, 28 Feb 2008 08:59:18 +0100 Subject: Sorting the recipeint keys (was: How know who is a file encrypted for ?) In-Reply-To: <87lk562q40.fsf@wheatstone.g10code.de> References: <20080227145106.16CC615803D@mailserver6.hushmail.com>, <87lk562q40.fsf@wheatstone.g10code.de> Message-ID: <47C677E6.6492.32A59535@dirk.traulsen.lypso.de> Am 27 Feb 2008 um 19:47 hat Werner Koch geschrieben: > The solution to this is pretty clear, we need to read all public key > encrypted packets first and sort them so that own keys come first > followed by other keys and finally by the wild card keys. This also > allows us to order the trial decryption to minimize smart card > changes. > > I have not implement this because obviously I have not yet suffered > enough from that problem. Werner, please do it. Making decryption clearly more comfortable is a good thing and the better if you personally have a benefit of it. Dirk From dirk.traulsen at lypso.de Thu Feb 28 09:33:30 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Thu, 28 Feb 2008 09:33:30 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <20080227182334.GA24626@jabberwocky.com> References: <20080227145106.16CC615803D@mailserver6.hushmail.com>, <47C5B220.19076.2FA10758@dirk.traulsen.lypso.de>, <20080227182334.GA24626@jabberwocky.com> Message-ID: <47C67FEA.31792.32C4E439@dirk.traulsen.lypso.de> Am 27 Feb 2008 um 13:23 hat David Shaw geschrieben: > On Wed, Feb 27, 2008 at 06:55:28PM +0100, Dirk Traulsen wrote: > > > >What I meant, was something like this mockup: > > > ============== > > > >C:\>gpg --recipient-keys ENCRYPTED_FILE.gpg > > > >gpg: file ENCRYPTED_FILE.gpg was encrypted to the following keys: > > > > > > > > > i agree, and would welcome this as well, > > > > Thanks. > > So at least three people think it would be a good addition. > > Why? > > I'm serious - what is the use case here? How often do people need to > list all recipients of a file? I want to list just some use cases, where you only need the recipients and not the encrypted file content. I'm sure there are many more. 1. control Your coworker encrypted an important file and you want to control whether it has the correct set of recipient keys before sending or archiving it. 2. curiosity You want to know who else is getting the information in the file because he is also able to decrypt the file (I know about hidden- recipient.) 3. finding You don't remember the exact name of the file. But you know it was encrypted to XYZ also. 4. sorting You want to sort the encrypted files in an archive depending on the recipients. > By the way: > gpg --no-default-keyring --secret-keyring /dev/null the-file.gpg Cool. This is an interesting possibility to nearly get what I asked for, but not very user friendly. I now have this excellent tip from you, but I think it would be nice to have a clearly named command which people can find in the manual. --list-recipients would be an excellent name, I think. Ideally additionally in a --with-colons format for easier scripting. Dirk From wk at gnupg.org Thu Feb 28 09:31:06 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Feb 2008 09:31:06 +0100 Subject: Signing people with only one form of ID? In-Reply-To: <1204179770.6277.28.camel@carbon> (Sven Radde's message of "Thu, 28 Feb 2008 07:22:50 +0100") References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <1204179770.6277.28.camel@carbon> Message-ID: <878x15iit1.fsf@wheatstone.g10code.de> On Thu, 28 Feb 2008 07:22, email at sven-radde.de said: > prove my identity to anyone. I could bring along my traveller's passport BTW, I suggest to add the day of birth to the UID. As soon as everyone in the world needs to carry an RFID bugged passport around we can do key signing much more efficient by just passing along a reader. No long and troublesome key signing parties anymore and there is a better chance to still get some food at the social event. ;-) Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From muewi at acm.org Thu Feb 28 10:04:29 2008 From: muewi at acm.org (Wilhelm =?iso-8859-1?Q?M=FCller?=) Date: Thu, 28 Feb 2008 10:04:29 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <20080227182334.GA24626@jabberwocky.com> References: <20080227182334.GA24626@jabberwocky.com> Message-ID: <18374.31005.873861.495172@gargle.gargle.HOWL> >>>>> On Wed, 27 Feb 2008 13:23:34 -0500, David Shaw said: David> On Wed, Feb 27, 2008 at 06:55:28PM +0100, Dirk Traulsen wrote: [...] >> > >C:\>gpg --recipient-keys ENCRYPTED_FILE.gpg [...] >> So at least three people think it would be a good addition. David> Why? David> I'm serious - what is the use case here? How often do people need to David> list all recipients of a file? I agree with David, especially since the desired feature is already present, though somewhat hidden: gpg --list-only --verbose encrypted_file.gpg (Btw: It's in the manual...) Wilhelm -- There are 10 types of people in the world: Those who understand binary, and those who don't. -- **************************************** fixed pitch fonts! ** Wilhelm M?ller muewi at acm.org (o_ (o_ (o_ //\ 1024D/2048g 5E6E CF83 B15E C7ED 1A31 (/)_ (/)_ V_/_ F9435BF6 E9F3 F509 FD7B F943 5BF6 ? N.Smith From veronatif at free.fr Thu Feb 28 10:54:39 2008 From: veronatif at free.fr (Alain Bench) Date: Thu, 28 Feb 2008 10:54:39 +0100 (CET) Subject: ISO-8859-1 mails getting marked as UTF-8 In-Reply-To: <20080227190657.GA11763@puffy.obsd.dk> References: <20080227190657.GA11763@puffy.obsd.dk> Message-ID: <20080228095439.GA16214@free.fr> Hello Martin, On Wednesday, February 27, 2008 at 20:06:57 +0100, Martin Toft wrote: > I use GnuPG together with mutt on Debian Etch. I prefer to use > ISO-8859-1 and have these lines in my .muttrc to accomplish that: First of all, your Mutt charset setup is quite suboptimal. Discussing it would be off-topic here, but you could find infos in the Mutt wiki, and some guidance on the mutt-users mailing list. > when signing the mail using GnuPG, the content type changes: >| Content-Type: text/plain; charset=utf-8; x-action=pgp-signed Mutt forces traditional PGP mails to be sent in either "us-ascii" or "utf-8", period. $send_charset is ignored. That is done on purpose, to follow some standards, and is not overridable. However, as you noticed, this poses interoperability problems with some other mailers. So Tamotsu Takahashi wrote a Mutt patch permitting to read and write traditional inline PGP mails containing any charset. It picks the best adapted first necessary and sufficient charset in the $send_charset list (just like for non-signed mails). Apply his latest patch-1.5.*.tamo.pgp_charsethack.1, and set $pgp_charsethack=yes. You'll be able to send inline signed Latin-1. > - Invoking gpg with "--charset iso-8859-1". > - Invoking gpg with "--display-charset iso-8859-1". > - Having "charset iso-8859-1" in ~/.gnupg/gpg.conf. Don't hardcode any given charset. Let GnuPG free to automatically derive the right charset from your current locale. LANG=en_DK implies the Latin-1 charset, so all is well. And if one day you switch locales, GnuPG will immediatly follow, and continue to display things right. Bye! Alain. -- Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as - subscribe ^list at ddress$ if you are subscribed and don't want courtesy copy. - lists ^list at ddress$ if you are not subscribed or want a courtesy copy. From dirk.traulsen at lypso.de Thu Feb 28 13:11:55 2008 From: dirk.traulsen at lypso.de (Dirk Traulsen) Date: Thu, 28 Feb 2008 13:11:55 +0100 Subject: How know who is a file encrypted for ? In-Reply-To: <18374.31005.873861.495172@gargle.gargle.HOWL> References: <20080227182334.GA24626@jabberwocky.com>, <18374.31005.873861.495172@gargle.gargle.HOWL> Message-ID: <47C6B31B.13977.338CDC6C@dirk.traulsen.lypso.de> Am 28 Feb 2008 um 10:04 hat Wilhelm M?ller geschrieben: > >>>>> On Wed, 27 Feb 2008 13:23:34 -0500, David Shaw > said: > > David> Why? > > David> I'm serious - what is the use case here? How often do > David> people need to list all recipients of a file? > > I agree with David, David didn't say he doesn't want this new command, but asked seriously for some use cases. > especially since the desired feature is already present, though > somewhat hidden: > > gpg --list-only --verbose encrypted_file.gpg It kind of partially works. With --verbose it at least mentions your own subkeys, but still doesn't print the uids or the primary keyid. No nice consistent output and a 'somewhat hidden' command. If you prefer not changing anything then Davids tip is much better. Dirk From ale at pcartwright.com Thu Feb 28 13:17:42 2008 From: ale at pcartwright.com (Paul Cartwright) Date: Thu, 28 Feb 2008 07:17:42 -0500 Subject: Signing people with only one form of ID? In-Reply-To: <20080228025128.GA26111@jabberwocky.com> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <20080228025128.GA26111@jabberwocky.com> Message-ID: <200802280717.42937.ale@pcartwright.com> On Wed February 27 2008, David Shaw wrote: > I wouldn't go crazy here: keep in mind that the web of trust is > designed for people who don't have the ability to prove that a > passport or license is real. ?This is one of the reasons that more > than one signature is needed to make a key fully valid. ?All that the > web of trust asks is that you do your best. I never made it to a formal key signing, all I did was look up biglumber: http://biglumber.com/x/web and found someone who would be in my area. We met, I showed him my ID, we talked a bit, and he signed my key. He lives in Switzerland and I live in Athens,Ga, USA. If I wantyed to drive 80 miles to Atlanta, I could probably find a number of people to sign my key, but this way I got to meet someone from another country! -- Paul Cartwright Registered Linux user # 367800 Registered Ubuntu User #12459 From veronatif at free.fr Thu Feb 28 13:43:05 2008 From: veronatif at free.fr (Alain Bench) Date: Thu, 28 Feb 2008 13:43:05 +0100 (CET) Subject: ISO-8859-1 mails getting marked as UTF-8 In-Reply-To: <87d4qhijew.fsf@wheatstone.g10code.de> References: <20080227190657.GA11763@puffy.obsd.dk> <87d4qhijew.fsf@wheatstone.g10code.de> Message-ID: <20080228124305.GA26572@free.fr> Hello Werner, On Thursday, February 28, 2008 at 9:17:59 +0100, Werner Koch wrote: > Yes there is the Charset armor header but that one is not supported by > GnuPG because it is a kludge not required since 15 years or so (since > MIME). A charsethacked Mutt can make use of this Charset armor header, if it exists. Or make use of a MIME charset label, if it exists. Or assume UTF-8 otherwise. Mutt then converts accordingly the text to the display. This doesn't impact signature verification, which is done before the conversion. And when sending, Mutt sets the MIME charset label, as a hint for the recipient. This scheme is not half as robust as PGP/MIME, of course. But in practice works rather well in cooperation with various other mailers. Comparing it with traditional PGP in the straight Mutt (forcing UTF-8) is not crystal clear: One will fail in some cases where the other works, and the contrary. The balance seems in favour of the charsethack, though. The standard hurts interoperability, unfortunately. > Please use PGP/MIME and the semantics of your message are well > defined. If the recipient's mailer supports PGP/MIME, this is of course a way better solution than any form of traditional inline PGP. All charsets are then cleanly usable, without any hack or guesswork. Bye! Alain. -- set honor_followup_to=yes in muttrc is the default value, and makes your list replies go where the original author wanted them to go: Only to the list, or with a private copy. From wk at gnupg.org Thu Feb 28 15:37:37 2008 From: wk at gnupg.org (Werner Koch) Date: Thu, 28 Feb 2008 15:37:37 +0100 Subject: ISO-8859-1 mails getting marked as UTF-8 In-Reply-To: <20080228124305.GA26572@free.fr> (Alain Bench's message of "Thu, 28 Feb 2008 13:43:05 +0100 (CET)") References: <20080227190657.GA11763@puffy.obsd.dk> <87d4qhijew.fsf@wheatstone.g10code.de> <20080228124305.GA26572@free.fr> Message-ID: <87ir09du4u.fsf@wheatstone.g10code.de> On Thu, 28 Feb 2008 13:43, veronatif at free.fr said: > If the recipient's mailer supports PGP/MIME, this is of course a way > better solution than any form of traditional inline PGP. All charsets > are then cleanly usable, without any hack or guesswork. >From the major MUAs only Outlook has problems with PGP/MIME. However, the GpgOL included in gpg4win 1.1.3 works well although with some deficies in the user interface. The forthcoming version of GpgOL (as available in SVN) features a far better integration and also sends PGP/MIME. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From david at miradoiro.com Thu Feb 28 16:19:32 2008 From: david at miradoiro.com (=?iso-8859-1?Q?David_Pic=F3n_=C1lvarez?=) Date: Thu, 28 Feb 2008 16:19:32 +0100 Subject: ISO-8859-1 mails getting marked as UTF-8 References: <20080227190657.GA11763@puffy.obsd.dk><87d4qhijew.fsf@wheatstone.g10code.de><20080228124305.GA26572@free.fr> <87ir09du4u.fsf@wheatstone.g10code.de> Message-ID: <000901c87a1d$527e5370$0302a8c0@Nautilus> > From the major MUAs only Outlook has problems with PGP/MIME. However, > the GpgOL included in gpg4win 1.1.3 works well although with some > deficies in the user interface. The forthcoming version of GpgOL (as > available in SVN) features a far better integration and also sends > PGP/MIME. Correct me if I'm wrong, but GPGOL as currently existing cannot deal with PGP/MIME, right? --David. From jmoore3rd at bellsouth.net Thu Feb 28 16:37:46 2008 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Thu, 28 Feb 2008 10:37:46 -0500 Subject: Certification signatures on subkeys In-Reply-To: <20080130211400.GA8836@riva.ucam.org> References: <20080130154426.GA8107@roadrunner.rdu.rpath.com> <20080130184610.GA15357@jabberwocky.com> <20080130211400.GA8836@riva.ucam.org> Message-ID: <47C6D54A.5070504@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Colin Watson wrote: > In other words, it looks like any time I go through an --edit-key / > --send-keys / --recv-keys cycle (however extended), I'm going to grow > six new signatures on my key. Could GnuPG be fixed to check for > duplicates before it moves signatures? The delsig UI is going to be > extremely tedious for getting rid of these and of course won't affect > the keyservers. What happens when You run --clean on the Key? This should remove all Signatures except for the most recent. :-\ JOHN ;) Timestamp: Thursday 28 Feb 2008, 10:37 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9-svn4691: (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: https://www.gswot.org Comment: Homepage: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJHxtVIAAoJEBCGy9eAtCsPt6IH+weif5jFOLfim++PH9BLu8IO yjdrVTMcjXoyXiDEGlvFCiTZwr4GQ7RSJazFkqktZavSMHlJpkombJB7y8f0gl6E 2+eRMfndQI3B9iTy3s2LLDmmWKbMITuvTtwzMZxxUw8oLNZz9fUa66agIyx9bJRF ZDbb9gCxRqQOEThn5b3pjBEMeewPZWZgJzkZrdxPfvUJwwK2pFC2dgfNoBoZc56c Om2+yTHxeWS6b4pZbqfTcNoOOpXzZL3wy/ug8xIkz2Q04wYjfGDKEuKHhTDsvjXX BQGsfbZe5JWY4UBxiIyo++Fbi/WqjdHW7BxnyPxtQlZ89ZBKHQM9FKO5ZmvA0V8= =R56x -----END PGP SIGNATURE----- From pschoenb at gmx.de Thu Feb 28 16:32:20 2008 From: pschoenb at gmx.de (Patrick Schoenbach) Date: Thu, 28 Feb 2008 16:32:20 +0100 Subject: Problem with compiling gpg-2.0.8 Message-ID: <1o678jc11675n$.10hr37k6ieon4$.dlg@40tude.net> Hi, I am trying to compile gpg-2.0.8 on Linux (x64). I updated all dependency libs, but when compiling gpg, I get: make[2]: Entering directory `/root/gnupg-2.0.8/g10' gcc -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -o gpg2 gpg.o server.o build-packet.o compress.o compress-bz2.o free-packet.o getkey.o keydb.o keyring.o seskey.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o progress.o misc.o openfile.o keyid.o parse-packet.o cpr.o plaintext.o sig-check.o keylist.o pkglue.o pkclist.o skclist.o pubkey-enc.o passphrase.o seckey-cert.o encr-data.o cipher.o encode.o sign.o verify.o revoke.o decrypt.o keyedit.o dearmor.o import.o export.o trustdb.o tdbdump.o tdbio.o delkey.o keygen.o helptext.o keyserver.o photoid.o call-agent.o card-util.o exec.o ../common/libcommon.a ../jnlib/libjnlib.a ../gl/libgnu.a ../common/libgpgrl.a -lz -lbz2 -lresolv -lreadline -lgcrypt -L/lib64 -lgpg-error -lassuan -lgpg-error server.o: In function `close_message_fd': /root/gnupg-2.0.8/g10/server.c:58: undefined reference to `assuan_sock_close' collect2: ld returned 1 exit status make[2]: *** [gpg2] Error 1 What could be wrong? -- Regards, Patrick From gnupg at ethen.de Thu Feb 28 18:52:05 2008 From: gnupg at ethen.de (gnupg at ethen.de) Date: Thu, 28 Feb 2008 18:52:05 +0100 Subject: Problem with compiling gpg-2.0.8 In-Reply-To: <1o678jc11675n$.10hr37k6ieon4$.dlg@40tude.net> References: <1o678jc11675n$.10hr37k6ieon4$.dlg@40tude.net> Message-ID: <200802281852.05489.gnupg@ethen.de> > /root/gnupg-2.0.8/g10/server.c:58: undefined reference to > `assuan_sock_close' > collect2: ld returned 1 exit status > make[2]: *** [gpg2] Error 1 > > What could be wrong? Do you have the current libassuan-config in your PATH? More than one version of libassunan installed and both in lib-dirs that are used to compile/link? From atom at smasher.org Thu Feb 28 09:52:22 2008 From: atom at smasher.org (Atom Smasher) Date: Thu, 28 Feb 2008 21:52:22 +1300 (NZDT) Subject: Signing people with only one form of ID? In-Reply-To: <47C61E3C.3050009@sixdemonbag.org> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <47C61E3C.3050009@sixdemonbag.org> Message-ID: <20080228085225.88895.qmail@smasher.org> On Wed, 27 Feb 2008, Robert J. Hansen wrote: > Compare that to a passport. You might already have a passport. Even if > you don't, it's pretty easy to find out what a passport looks like, what > sort of paper is used in it, what security features are present. ================== ever seen a turkish passport? the real ones look like bad fakes. i'm sure that's not the only country that issues fake looking passports. personally, the only way i'd issue a level 3 signature on a key is if i know the person in some capacity. if i just meet someone at a keysigning party the best they could hope for is a level 2 signature. -- ...atom ________________________ http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 ------------------------------------------------- "A people that values its privileges above its principles soon loses both." -- Dwight D. Eisenhower From pschoenb at gmx.de Thu Feb 28 23:28:19 2008 From: pschoenb at gmx.de (Patrick Schoenbach) Date: Thu, 28 Feb 2008 23:28:19 +0100 Subject: Problem with compiling gpg-2.0.8 References: <1o678jc11675n$.10hr37k6ieon4$.dlg@40tude.net> <200802281852.05489.gnupg__31343.9157595441$1204226237$gmane$org@ethen.de> Message-ID: On Thu, 28 Feb 2008 18:52:05 +0100, gnupg at ethen.de wrote: > More than one version of libassunan installed and both in lib-dirs that are > used to compile/link? This was the problem. Works now. Thanks. -- Regards, Patrick From richih.mailinglist at gmail.com Fri Feb 29 10:20:10 2008 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Feb 2008 10:20:10 +0100 Subject: Signing people with only one form of ID? In-Reply-To: <47C61E3C.3050009@sixdemonbag.org> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <47C61E3C.3050009@sixdemonbag.org> Message-ID: <2d460de70802290120j3fd3bf0ne81dffe90d1ec47c@mail.gmail.com> On Thu, Feb 28, 2008 at 3:36 AM, Robert J. Hansen wrote: > It may be helpful for you to think about things in terms of not just how > many identity documents are present, but the relative difficulty in > forging identity documents, as well as your ability to spot forgeries. Living in the EU, the only forms of ID I got to see were government-issued. Of course, not all of them are officially an ID card, like the German dirver's licence, but a German driver's licence has more security features than a few passports I have seen. > E.g., a university ID card is pretty easy to forge. You also probably > don't know what Wayne State University's ID card looks like, so if > someone presents it to you, you have no way of knowing whether it's on > the up and up or not. I noted which IDs are of the laminated, bazillion-checks kind of type and which were mere paper. Of the two paper IDs, one was an old German passport of a person I have known for quite some time, the other was a German passport for children under 16. I know and remeber these, but while I will sign the first, I did not yet decide on the second. Of course, I did not have a full list of reference ID cards for all major countries with me, but I _did_ try and remember if a Greek passport from guy one matches the Greek passport of gal two. > Compare that to a passport. You might already have a passport. Even if > you don't, it's pretty easy to find out what a passport looks like, what > sort of paper is used in it, what security features are present. You > can thus have a lot more confidence in someone's identity if they > present you with a passport than if they present you with, say, a > university ID card. I would never sign anyone with only a university ID unless I knew them for years. Richard From richih.mailinglist at gmail.com Fri Feb 29 10:22:33 2008 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Feb 2008 10:22:33 +0100 Subject: Signing people with only one form of ID? In-Reply-To: <47C6205E.2000200@sixdemonbag.org> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <47C6205E.2000200@sixdemonbag.org> Message-ID: <2d460de70802290122l173b0ee3l6241e22fc26c262a@mail.gmail.com> On Thu, Feb 28, 2008 at 3:45 AM, Robert J. Hansen wrote: > Because of these three factors--no semantic meaning associated with > certification levels, some OpenPGP implementations not supporting the > distinctions, and many implementations making it easy to forget that > such distinctions exist--my default policy is to treat all signatures as > unchecked persona-level IDs unless I know the signer personally and know > they have a signature policy. Good point, I will ask & note that in my signature, in the future. Richard From richih.mailinglist at gmail.com Fri Feb 29 10:26:38 2008 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Feb 2008 10:26:38 +0100 Subject: Signing people with only one form of ID? In-Reply-To: <20080228025128.GA26111@jabberwocky.com> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <20080228025128.GA26111@jabberwocky.com> Message-ID: <2d460de70802290126gcceb6b2s339dbfda67b7e455@mail.gmail.com> On Thu, Feb 28, 2008 at 3:51 AM, David Shaw wrote: > I wouldn't go crazy here: keep in mind that the web of trust is > designed for people who don't have the ability to prove that a > passport or license is real. This is one of the reasons that more > than one signature is needed to make a key fully valid. All that the > web of trust asks is that you do your best. Yes and no. While a web of trust may look just like a huge interconnected graph, it actually is a directed graph and the only root node you care about is your own. So while it is true that you can't do too much about a guy who is ten hops away from you, you can try and make connections to nodes near to you as good and detailed as possible. Richard From richih.mailinglist at gmail.com Fri Feb 29 10:34:41 2008 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Feb 2008 10:34:41 +0100 Subject: Signing people with only one form of ID? In-Reply-To: <20080228030903.GA26047@jabberwocky.com> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <47C6205E.2000200@sixdemonbag.org> <20080228030903.GA26047@jabberwocky.com> Message-ID: <2d460de70802290134m5e99295u4f371680290e268@mail.gmail.com> On Thu, Feb 28, 2008 at 4:09 AM, David Shaw wrote: > Some people include a policy URL in the certification to tell a > recipient just what was done. This has its own advantages and > disadvantages, but is really a comment as well, as no program parses > and acts on the information. 5.2.3.13. and 5.2.3.20. of RFC 4880 look very promising. Even if no one else cares about them, I will probably try and implement them. > The bottom line is that you can sign with a signature level if you > like, but (barring persona signatures) it only makes a marginal > difference in practice. While that is a problem, you can do your best to make the local situation the best you can possibly make it. Richard From richih.mailinglist at gmail.com Fri Feb 29 10:52:44 2008 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Feb 2008 10:52:44 +0100 Subject: Signing people with only one form of ID? In-Reply-To: <1204179770.6277.28.camel@carbon> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <1204179770.6277.28.camel@carbon> Message-ID: <2d460de70802290152t4bd2a3ear4899c5600d0e9578@mail.gmail.com> On Thu, Feb 28, 2008 at 7:22 AM, Sven Radde wrote: > Being german, I am really baffled by this question... > I have only one personal identity card and it is really sufficient to > prove my identity to anyone. I could bring along my traveller's passport > but that one is issued by the same authority based on the same data. It is not (all) about the authority who issued it. Two are harder to forge than one (unless you have direct access within the authority, of course). > What else would count as "form of ID"? Credit card? Credit card with > picture? Library card? A bonus card from the german railway with > picture? I am sure that I could come up with about a dozen such pieces > of "ID" with a wrong name on it (and, if applicable, my picture). Basically, the only thing I would accept is state-issued unless I know that there is an actual replacement system in a specific country that is _better_. If in doubt, don't sign. Richard From richih.mailinglist at gmail.com Fri Feb 29 10:54:14 2008 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Feb 2008 10:54:14 +0100 Subject: Signing people with only one form of ID? In-Reply-To: <20080228085225.88895.qmail@smasher.org> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <47C61E3C.3050009@sixdemonbag.org> <20080228085225.88895.qmail@smasher.org> Message-ID: <2d460de70802290154w3035a202uef16e19e73748000@mail.gmail.com> On Thu, Feb 28, 2008 at 9:52 AM, Atom Smasher wrote: > personally, the only way i'd issue a level 3 signature on a key is if i > know the person in some capacity. if i just meet someone at a keysigning > party the best they could hope for is a level 2 signature. That is probably a good idea, yes. Will need to ponder. Richard From richih.mailinglist at gmail.com Fri Feb 29 10:49:13 2008 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Fri, 29 Feb 2008 10:49:13 +0100 Subject: Signing people with only one form of ID? In-Reply-To: <001d01c879bc$127fff50$6401a8c0@T60> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com> <47C6205E.2000200@sixdemonbag.org> <001d01c879bc$127fff50$6401a8c0@T60> Message-ID: <2d460de70802290149g51f8f0d2l2be7b76abb72c6fa@mail.gmail.com> On Thu, Feb 28, 2008 at 4:43 AM, Brian Smith wrote: > I don't see how a keysigning party works. Anybody that participates by > showing ID is reducing their personal privacy by divulging their > personal information. The basic assumption is that a key signing is good and that you actually gain something from it. If the other guy were to start copying my ID, he would not get far. > Furthermore, caring around such ID is much more > likely to create a security problem (if it is lost or stolen) than > anything GPG can prevent. Finally, we give up a lot of personal security > when we give our personal information to governments to get our > government-issued IDs, which I think is a big mistake. In some countries, you simply have to carry it on you, end of story. You might as well enjoy the few benefits. > Especially, when > I was staying in Thailand, I saw firsthand how governments (Thai, > American, and every other one) use ID controls to repress people they > don't like. Anybody that insists on government-issued ID for > authentication is doing the world a disservice. In the US, they are just using credit cards and the ability to block money on your account for their own use in stead of ID. This is basically an ID with electronic traceability (people _know_ you were in X, renting a car. And they can look it all up in a central location). > For all those reasons, I am willing to sign anybody's keys at any level > without any authentication, using as many different signatures as they > require. And, I will do so with a set of keys that are not linked to my > (online or real-life) identity, so they cannot be blacklisted. Actually, > I would like to create a network of people with the same key-signing > policy. I would like you to do that as well. Please keep that out of what others _try_ to make at good as possible. > In doing so, I think it will be easy to demonstrate why the > current implementation of the web-of-trust via keysigining is > inadequate, especially when such a network of people participate in > keysigning parties to promote the authority of their own (bogus) > signatures. While living in a perfect world is, of course, perfect (for exactly one person) I would rather try and change what I can and until such a point, do the things that I can do to make the best of actual reality. I just hope those people stay as far away from my personal nodes as possible. > In an ideal world, the fact that I am disclosing this information in > advance should mean that mobody will sign my PGP key at any keysigning > party. WIth a name of Brian Smith, this is easily feasible.. > I don't know how many I will be able to attend, but I will > attempt to get as many as signatures as I can, alternatively using my > birth name and a name of my own choosing (possibly copied from somebody > with a coincidentally similar appearance). This will give you only identities of people who look like you, which is also possible in the real world. The only thing you are proving is the need for better ID for the sake of 'added security'. Gee, thanks ;) > It will be interesting to see > how many people will give me a level 5 classification with an identity > that can be traced back directly to this message. I doubt you include the unique message ID of this mail in your key. Else, this is just a snug comment with no actual warning value to anyone. Richard From wk at gnupg.org Fri Feb 29 17:25:02 2008 From: wk at gnupg.org (Werner Koch) Date: Fri, 29 Feb 2008 17:25:02 +0100 Subject: ISO-8859-1 mails getting marked as UTF-8 In-Reply-To: <000901c87a1d$527e5370$0302a8c0@Nautilus> ("David =?utf-8?Q?P?= =?utf-8?Q?ic=C3=B3n=09=C3=81lvarez=22's?= message of "Thu, 28 Feb 2008 16:19:32 +0100") References: <20080227190657.GA11763@puffy.obsd.dk> <87d4qhijew.fsf@wheatstone.g10code.de> <20080228124305.GA26572@free.fr> <87ir09du4u.fsf@wheatstone.g10code.de> <000901c87a1d$527e5370$0302a8c0@Nautilus> Message-ID: <871w6vafxd.fsf@wheatstone.g10code.de> On Thu, 28 Feb 2008 16:19, david at miradoiro.com said: > Correct me if I'm wrong, but GPGOL as currently existing cannot deal > with PGP/MIME, right? It can decrypt and verify PGP/MIME but tehre a couple of minor problems. In fact we use a complete MIME parser here. The latest GpgOL incarnation does it far better and is abale to also send PGP/MIME. Not yet released; you need to build it from SVN (see http://www.gpg4win.org) Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From brian at briansmith.org Fri Feb 29 18:40:27 2008 From: brian at briansmith.org (Brian Smith) Date: Fri, 29 Feb 2008 09:40:27 -0800 Subject: Signing people with only one form of ID? In-Reply-To: <2d460de70802290149g51f8f0d2l2be7b76abb72c6fa@mail.gmail.com> References: <2d460de70802271638x6153a5f0w4bb9a355bf1c9889@mail.gmail.com><47C6205E.2000200@sixdemonbag.org><001d01c879bc$127fff50$6401a8c0@T60> <2d460de70802290149g51f8f0d2l2be7b76abb72c6fa@mail.gmail.com> Message-ID: <005401c87afa$2db309e0$6401a8c0@T60> Richard Hartmann wrote: > > I don't see how a keysigning party works. Anybody that > > participates by showing ID is reducing their personal > > privacy by divulging their personal information. > > The basic assumption is that a key signing is good and that > you actually gain something from it. That is the assumption that I am challenging. > In some countries, you simply have to carry it on you, end of > story. You might as well enjoy the few benefits. > In the US, they are just using credit cards and the ability > to block money on your account for their own use in stead of > ID. This is basically an ID with electronic traceability > (people _know_ you were in X, renting a car. > And they can look it all up in a central location). These are things I want to help change. > > In doing so, I think it will be easy to demonstrate why > > the current implementation of the web-of-trust via keysigining > > is inadequate, especially [with] such a network of people > > participate in keysigning parties to promote the authority of > > their own (bogus) signatures. > > While living in a perfect world is, of course, perfect (for > exactly one person) I would rather try and change what I can > and until such a point, do the things that I can do to make > the best of actual reality. > > I just hope those people stay as far away from my personal > nodes as possible. There's got to be some mechanism that doesn't require (as much) hope, and which doesn't require the loss of anonymity, at least for common uses of PGP like personal email. > > I don't know how many I will be able to attend, but I will > > attempt to get as many as signatures as I can, alternatively > > using my birth name and a name of my own choosing (possibly > > copied from somebody with a coincidentally similar appearance). > > This will give you only identities of people who look like > you, which is also possible in the real world. The only thing > you are proving is the need for better ID for the sake of > 'added security'. Gee, thanks ;) Would better IDs really help? It has got to be hard for a person to say "I don't trust you or your ID, I'm not going to sign your key." - Brian From maury.markowitz at gmail.com Fri Feb 29 21:10:47 2008 From: maury.markowitz at gmail.com (Maury Markowitz) Date: Fri, 29 Feb 2008 15:10:47 -0500 Subject: _almost_ working, now a command line question... Message-ID: <5bdbc9050802291210yb9333ccr4d86c867ba1b5e96@mail.gmail.com> So after finally deciding to trust that gpg was giving me an accurate error, and that the passphrase really was wrong, I spend the last week scaring up someone within the labyrinths that could actually change the key to the one that we know works. Presto! Working file. Lesson learned: You CAN simply copy binary key files from pgp to gpg, which is really nice. All that's left now is to fully automate this, and my Windows CMD noobishness is an issue. Here's my command line: O:\Utilities>echo o:\apricing\pass.txt | o:\utilities\gpg --homedir o:\utilities \ --passphrase-fd 0 --load-extension o:\utilities\idea.dll -o "o:\apricing\morga n_cds_20080229.txt" -d "o:\apricing\24476.txt.pgp" And here are the results (slightly trimmed to protect the innocent): Reading passphrase from file descriptor 0 You need a passphrase to unlock the secret key for user: "Polar Securities Inc " 2048-bit ELG-E key, ID 3E396FC9, created 2000-10-27 (main key ID F0ED5CDC) gpg: encrypted with 2048-bit ELG-E key, [snip] gpg: public key decryption failed: bad passphrase pass.txt absolutely has the right key in it. I tried both | and >, the later did nothing at all (which I guess makes sense). Anything obvious here? Maury From steve at srevilak.net Fri Feb 29 23:45:55 2008 From: steve at srevilak.net (Steve Revilak) Date: Fri, 29 Feb 2008 17:45:55 -0500 (EST) Subject: _almost_ working, now a command line question... In-Reply-To: <5bdbc9050802291210yb9333ccr4d86c867ba1b5e96@mail.gmail.com> References: <5bdbc9050802291210yb9333ccr4d86c867ba1b5e96@mail.gmail.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > From: Maury Markowitz > Date: Fri, 29 Feb 2008 15:10:47 -0500 > Subject: _almost_ working, now a command line question... > All that's left now is to fully automate this, and my Windows CMD > noobishness is an issue. Here's my command line: > > O:\Utilities>echo o:\apricing\pass.txt | o:\utilities\gpg --homedir o:\utilities > \ --passphrase-fd 0 --load-extension o:\utilities\idea.dll -o "o:\apricing\morga > n_cds_20080229.txt" -d "o:\apricing\24476.txt.pgp" > > And here are the results (slightly trimmed to protect the innocent): > > Reading passphrase from file descriptor 0 > > You need a passphrase to unlock the secret key for > user: "Polar Securities Inc " > 2048-bit ELG-E key, ID 3E396FC9, created 2000-10-27 (main key ID F0ED5CDC) > > gpg: encrypted with 2048-bit ELG-E key, [snip] > gpg: public key decryption failed: bad passphrase > > pass.txt absolutely has the right key in it. I tried both | and >, the > later did nothing at all (which I guess makes sense). Doesn't echo o:\apricing\pass.txt produce output of "o:\apricing\pass.txt"? You might have better luck redirecting gpg's standard input from pass.txt, like this: o:\utilities\gpg --homedir o:\utilities \ --passphrase-fd 0 \ --load-extension o:\utilities\idea.dll \ -o "o:\apricing\morgan_cds_20080229.txt" \ -d "o:\apricing\24476.txt.pgp" < o:\apricing\pass.txt Also, be careful of extra whitespace in pass.txt. Steve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (Darwin) iEYEARECAAYFAkfIiyYACgkQX7YJI4BuyDQf0QCg2AUA0Bd/o6h7mI1RF4gswPYT /uwAoLJGeBhHn62VHZA1LhCHhkIeVbPn =oJI2 -----END PGP SIGNATURE----- From mt at martintoft.dk Thu Feb 28 22:12:31 2008 From: mt at martintoft.dk (Martin Toft) Date: Thu, 28 Feb 2008 22:12:31 +0100 Subject: ISO-8859-1 mails getting marked as UTF-8 In-Reply-To: <87ir09du4u.fsf@wheatstone.g10code.de> References: <20080227190657.GA11763@puffy.obsd.dk> <87d4qhijew.fsf@wheatstone.g10code.de> <20080228124305.GA26572@free.fr> <87ir09du4u.fsf@wheatstone.g10code.de> Message-ID: <20080228211231.GG3759@puffy.obsd.dk> On Thu, Feb 28, 2008 at 03:37:37PM +0100, Werner Koch wrote: > On Thu, 28 Feb 2008 13:43, veronatif at free.fr said: > > If the recipient's mailer supports PGP/MIME, this is of course a way > > better solution than any form of traditional inline PGP. All > > charsets are then cleanly usable, without any hack or guesswork. > > From the major MUAs only Outlook has problems with PGP/MIME. However, > the GpgOL included in gpg4win 1.1.3 works well although with some > deficies in the user interface. The forthcoming version of GpgOL (as > available in SVN) features a far better integration and also sends > PGP/MIME. Thank you very much for the elaborate explanations. I see now that my decision to switch from PGP/MIME to inline signing a while ago caused the problem. I'll switch back to PGP/MIME and ignore recipients running Outlook. I don't want to spend my time working around shortcomings in crap software. Thanks again. Martin