From dshaw at jabberwocky.com Mon Mar 1 01:55:13 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 28 Feb 2010 19:55:13 -0500 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> Message-ID: <82C80CCD-8A5B-415F-AE33-28174C85F7AB@jabberwocky.com> On Feb 27, 2010, at 3:23 PM, Robert J. Hansen wrote: >> I agree that "generally speaking, it's a good idea to put keys on the keyservers". I don't know if that makes it conventional wisdom, or who the arbiter of such wisdom might be, but clearly a very common use of OpenPGP is for encrypted mail. > > I likewise have suspicions and doubts about conventional wisdom. (You could just as easily say, "conventional wisdom is that you can tell a lot about someone by the signatures on their key" -- I can see an argument being made for that being conventional wisdom. It's *wrong*, but that doesn't keep it from being conventional wisdom.) You can certainly tell a lot about someone by the signatures on their key. Either directly from the signature or because those signatures point to other keys that have their own signatures, etc. With your permission, may I see what I can find from the signatures on your key D6B98E10? I will of course never post it here or anywhere without your permission. I will send it only to you, off-list. I'm not trying to be evil - just demonstrating that you can derive a lot from signatures on a key. If you do not want me to look, I won't. David From dshaw at jabberwocky.com Mon Mar 1 02:08:10 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 28 Feb 2010 20:08:10 -0500 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> Message-ID: <225E682A-0C69-4024-82E1-2B0BE293B2B0@jabberwocky.com> On Feb 28, 2010, at 4:20 PM, reynt0 wrote: > On Sat, 27 Feb 2010, Robert J. Hansen wrote: > . . . >> The perfect is the enemy of the good. > > Just to note, did RJH actually intend to write > "...the enemy of the good enough.", which I believe is > the usual quote? The two are rather different ideas, > even more so if morality has been included as an aspect > of the discussion. Voltaire. "Le mieux est l'ennemi du bien". Rob's translation is as good as any I've seen. David From rjh at sixdemonbag.org Mon Mar 1 02:09:46 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 28 Feb 2010 20:09:46 -0500 Subject: key question In-Reply-To: <82C80CCD-8A5B-415F-AE33-28174C85F7AB@jabberwocky.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> <82C80CCD-8A5B-415F-AE33-28174C85F7AB@jabberwocky.com> Message-ID: <69792174-A3E7-4DDB-84F7-48A149B744D9@sixdemonbag.org> > You can certainly tell a lot about someone by the signatures on their key. Either directly from the signature or because those signatures point to other keys that have their own signatures, etc. With your permission, may I see what I can find from the signatures on your key D6B98E10? Go for it. It's public data. Assuming there's nothing intensely personal in there, I'll pass the results on to the list. My point regarding the signatures don't tell you much -- if anything -- is there is no guarantee that a signer has had any contact with the key holder. It's foolish to make conclusions about someone's social network based on their key material. If I have a signature from a person, it is not a statement that I know that person, that I approve of that person, or that I would ever associate with that person. From expires2010 at ymail.com Mon Mar 1 04:07:22 2010 From: expires2010 at ymail.com (MFPA) Date: Mon, 1 Mar 2010 03:07:22 +0000 Subject: Fwd: Re: key question In-Reply-To: References: <4B8994B0.8010009@grant-olson.net> <5410253140.20100228055003@my_localhost> Message-ID: <702729210.20100301030722@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi reynt0 On Sunday 28 February 2010 at 9:18:55 PM, you wrote: > Now all the serious ones, or maybe the merely curious, > have to do is to search "FREFF"--or maybe buy from Google the > info Google has about FREFF if nothing can be found easily by > a free, ordinary user search--and find out a beginning of how > to track down MFPA so they can verify his key in person. :-) Why not start your detective work from something like email kludges? - -- Best regards MFPA mailto:expires2010 at ymail.com Versifiers write poems for it. -----BEGIN PGP SIGNATURE----- iQCVAwUBS4svdaipC46tDG5pAQphNgQAwPh4EWhilhhw5McO99eh2LQPcQViNa+R j6KEct9fyXV5j4wWCbKcPHYgwZSTyZsBjA/kmWA/aQb43s1Ngd0cqnwq9ZzYhNYO Uz9tjwGM3mpX4dLcwetE9kBcsMsSfJBLxZGjAJGjGFdVFFy7G5sFSkU/WO8G3FxG BHdAlo2KM18= =ejuU -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Mar 1 04:24:57 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 28 Feb 2010 22:24:57 -0500 Subject: key question In-Reply-To: <69792174-A3E7-4DDB-84F7-48A149B744D9@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> <82C80CCD-8A5B-415F-AE33-28174C85F7AB@jabberwocky.com> <69792174-A3E7-4DDB-84F7-48A149B744D9@sixdemonbag.org> Message-ID: On Feb 28, 2010, at 8:09 PM, Robert J. Hansen wrote: >> You can certainly tell a lot about someone by the signatures on their key. Either directly from the signature or because those signatures point to other keys that have their own signatures, etc. With your permission, may I see what I can find from the signatures on your key D6B98E10? > > Go for it. It's public data. Assuming there's nothing intensely personal in there, I'll pass the results on to the list. > > My point regarding the signatures don't tell you much -- if anything -- is there is no guarantee that a signer has had any contact with the key holder. It's foolish to make conclusions about someone's social network based on their key material. If I have a signature from a person, it is not a statement that I know that person, that I approve of that person, or that I would ever associate with that person. Understood, and I agree it makes no such statement. However, it does make a reasonably good statement that you were physically located near that person at a certain point in time, roughly what that time was, and roughly where (geographically) it happened. Better than that, though, signatures point to other keys. And self-signatures are signatures, too. I'll send you some stuff. David From rjh at sixdemonbag.org Mon Mar 1 04:31:40 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 28 Feb 2010 22:31:40 -0500 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <4B8946C3.5050607@sixdemonbag.org> <82C80CCD-8A5B-415F-AE33-28174C85F7AB@jabberwocky.com> <69792174-A3E7-4DDB-84F7-48A149B744D9@sixdemonbag.org> Message-ID: <3424D5B2-08E9-4411-B90D-8964C45E9863@sixdemonbag.org> > Understood, and I agree it makes no such statement. However, it does make a reasonably good statement that you were physically located near that person at a certain point in time, roughly what that time was, and roughly where (geographically) it happened. This is assuming the signature is known to not be someone attempting a credibility attack, or that the signer didn't sign it by accident while intending to sign a different key, etc., etc. I agree that once those assumptions are made you can learn an awful lot, and I agree that these assumptions are usually correct. Not too many people sign keys by accident, or do credibility attacks, etc. Maybe it's an artifact of my upbringing. I see the world as broken up into things you can prove, things you suspect, and things that might be. Signature analysis lets you know a lot of might-bes, and might be a good basis for suspicions, but without those preconditions I think it's pretty hard to prove things. I imagine we're in agreement here. I still look forward to seeing your results. :) From rjh at sixdemonbag.org Mon Mar 1 05:54:46 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 28 Feb 2010 23:54:46 -0500 Subject: David's findings Message-ID: <4459025A-D107-4D97-9EC7-70715B4AA5E1@sixdemonbag.org> David and I apparently had a bit of a misunderstanding. I thought he was going to attempt to figure out information based solely on the key material: he was using it as a springboard for other research. I think that both of us are correct, given the assumptions we were making. If you have an email address and a name for someone, OSINT ("open source intelligence) is a hellishly powerful research tool -- especially when applied against people who have a substantial presence on the net. However, the keyserver material *by itself, only referencing other keys* is not very useful and proves very little. David did not give confidence assessments for his statements. I have no way of knowing which ones he suspected, versus which ones he felt were proven. Some of them would be quite easy to prove (or, at least, have very high confidence). Others would be much more difficult. * My father's name * My father's military history (in broad strokes) * My father's current occupation * He was within 7 years of my father's age * My mother's name * My parents' location * My brother's name and relative age to me * The age of my parents' house * My age, accurate to several years * I was in Las Vegas in 2005 * I was at a keysigning in Portland in July 2006 * My educational background * My ham radio license, and that it was issued west of the Mississippi * That I'm a fairly advanced OpenPGP user * The color of a vehicle owned by my parents Things that he was wrong about: * My religious upbringing * My religious affiliation * That I use GnuPG rather than PGP [1] * That I'm a fan of Bungie Software's "Halo" games ... This may sound impressive, but most of it could have been more easily developed via Google. Googling for "Robert J. Hansen" (with quotes) gives you my homepage as the first hit. That tells you I graduated from Cornell College, gives you my exact birthdate, that I have three nephews, an awful dot-bomb experience, and that I maintain a software project called Djinni. Googling for "Robert J. Hansen Cornell College" (without quotes) gives you all kinds of information about my father, along with my mother's name and the fact I have an older brother. Once you have my father's name and the fact he's a federal judge, you just have to visit Wikipedia in order to get Dad's biography: his full name, his military history, his current position, his age, and so forth. When you Google for "Robert J. Hansen Cornell College", you'll discover the third link down tells you I was in Las Vegas in 2005, delivering a talk to Black Hat. Googling for "Robert J. Hansen Djinni" tells you that I spoke at CodeCon 2006 (in San Francisco) and at OSCON 2006 (in Portland). Given that I have a cluster of signatures on one of my keys, all issued during the same time CodeCon 2006 was going on, it's a pretty easy guess that I attended a keysigning in Portland in July 2006. The only things that I do not believe he could have discovered in a five-minute Google search were (a) my ham radio license, (b) that I'm a fairly advanced OpenPGP user, and (c) that I attended a keysigning in Portland in 2006. Everything else could have been found more easily with basic Google searches. So, the overall score: developing OSINT with Google, really cool. Developing OSINT by studying key material, not as productive. I would like to thank David for taking the time to do this test. The conclusions that I've drawn are my own: I do not speak for him. I'm certain he'll give his own conclusions. Please be very careful when using this to support broad, general statements. This is only one test, it was informal and very quick-and-dirty. [1] I use both PGP and GnuPG. I'm ecumenical. Most of my emails are sent via Enigmail+GnuPG, but I've paid for PGP releases ever since 5.0. The only major version I've skipped was 9. From free10pro at gmail.com Mon Mar 1 07:12:47 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sun, 28 Feb 2010 22:12:47 -0800 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> <472371020.20100228043342@my_localhost> <1267336901.3824.62.camel@localhost> Message-ID: <1267423967.20061.281.camel@localhost> On Sun, 2010-02-28 at 16:06 -0500, reynt0 wrote: > On Sat, 27 Feb 2010, Paul Richard Ramer wrote: > . . . > > Speculation isn't any more progress than an idea is action. Speculation > > buttressed with facts leads, in time, to progress. But speculation, > . . . > > And speculation often has the very useful effect of stimulating > search for new facts where previously none had been believed > necessary. Naturally, you have to search for facts if you are going to support a new idea. From wk at gnupg.org Mon Mar 1 14:34:41 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 01 Mar 2010 14:34:41 +0100 Subject: gpg-agent rejects correct password for ssh keys In-Reply-To: <20100226162034.GA9914@dragonfly.kolej.mff.cuni.cz> (Michal Vaner's message of "Fri, 26 Feb 2010 17:20:34 +0100") References: <20100226162034.GA9914@dragonfly.kolej.mff.cuni.cz> Message-ID: <87tyt0yxla.fsf@vigenere.g10code.de> On Fri, 26 Feb 2010 17:20, vorner at ucw.cz said: > The agent asks for a passphrase to decrypt the key. I type it again and, this is > the problem, it says it is incorrect. I'm sure I typed it correctly (I tried Please see http://lists.gnupg.org/pipermail/gnupg-users/2010-January/038045.html Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at JABBERWOCKY.COM Mon Mar 1 17:27:31 2010 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Mon, 1 Mar 2010 11:27:31 -0500 Subject: David's findings In-Reply-To: <4459025A-D107-4D97-9EC7-70715B4AA5E1@sixdemonbag.org> References: <4459025A-D107-4D97-9EC7-70715B4AA5E1@sixdemonbag.org> Message-ID: <6C1005B5-4A06-4B58-92C1-1AAE3C2C5B58@JABBERWOCKY.COM> On Feb 28, 2010, at 11:54 PM, Robert J. Hansen wrote: > David and I apparently had a bit of a misunderstanding. I thought he was going to attempt to figure out information based solely on the key material: he was using it as a springboard for other research. I think that both of us are correct, given the assumptions we were making. If you have an email address and a name for someone, OSINT ("open source intelligence) is a hellishly powerful research tool -- especially when applied against people who have a substantial presence on the net. However, the keyserver material *by itself, only referencing other keys* is not very useful and proves very little. > > David did not give confidence assessments for his statements. I have no way of knowing which ones he suspected, versus which ones he felt were proven. Some of them would be quite easy to prove (or, at least, have very high confidence). Others would be much more difficult. > > * My father's name > * My father's military history (in broad strokes) > * My father's current occupation > * He was within 7 years of my father's age > * My mother's name > * My parents' location > * My brother's name and relative age to me > * The age of my parents' house > * My age, accurate to several years > * I was in Las Vegas in 2005 > * I was at a keysigning in Portland in July 2006 > * My educational background > * My ham radio license, and that it was issued west of the Mississippi > * That I'm a fairly advanced OpenPGP user > * The color of a vehicle owned by my parents > > Things that he was wrong about: > * My religious upbringing > * My religious affiliation > * That I use GnuPG rather than PGP [1] > * That I'm a fan of Bungie Software's "Halo" games > > > > ... This may sound impressive, but most of it could have been more easily developed via Google. > > Googling for "Robert J. Hansen" (with quotes) gives you my homepage as the first hit. That tells you I graduated from Cornell College, gives you my exact birthdate, that I have three nephews, an awful dot-bomb experience, and that I maintain a software project called Djinni. > > Googling for "Robert J. Hansen Cornell College" (without quotes) gives you all kinds of information about my father, along with my mother's name and the fact I have an older brother. Once you have my father's name and the fact he's a federal judge, you just have to visit Wikipedia in order to get Dad's biography: his full name, his military history, his current position, his age, and so forth. > > When you Google for "Robert J. Hansen Cornell College", you'll discover the third link down tells you I was in Las Vegas in 2005, delivering a talk to Black Hat. > > Googling for "Robert J. Hansen Djinni" tells you that I spoke at CodeCon 2006 (in San Francisco) and at OSCON 2006 (in Portland). Given that I have a cluster of signatures on one of my keys, all issued during the same time CodeCon 2006 was going on, it's a pretty easy guess that I attended a keysigning in Portland in July 2006. > > The only things that I do not believe he could have discovered in a five-minute Google search were (a) my ham radio license, (b) that I'm a fairly advanced OpenPGP user, and (c) that I attended a keysigning in Portland in 2006. Everything else could have been found more easily with basic Google searches. > > So, the overall score: developing OSINT with Google, really cool. Developing OSINT by studying key material, not as productive. > > I would like to thank David for taking the time to do this test. The conclusions that I've drawn are my own: I do not speak for him. I'm certain he'll give his own conclusions. Thanks, Rob, for being such a good sport about this test. If I had known I was being scored on number of 'hits', I'd have given more of them. :) There were more items I could have given, but they would have revealed the source I used, so I did not list them. I found most of the hits in around 20 minutes, and then things dried up for another 10 (I was hunting for high school information and it went nowhere), so I stopped, as 30 minutes seemed like a good stopping point. I never actually looked at your home page (it felt a bit like cheating, somehow). In terms of confidence, I had fairly high confidence in most of the answers, except for (perhaps not surprisingly) the ones that turned out I was wrong about (i.e. in retrospect, I shouldn't have guessed). Both the religion (not sure why this was counted as two 'misses') and Halo were guesses based on not much evidence. I'd call the GnuPG/PGP one (high confidence) a draw - I said "GnuPG rather than PGP", but the answer was "GnuPG and PGP" (as the key was generated with one, but actually used with both). I was only medium confident about the vehicle color (an educated guess), but ended up getting that one right. In any event, I - partially - agree with your comments in that I'm quite sure that a private investigator, or someone with actual training in this sort of research, would have been able to find everything I found without looking at keys at all. Without knowing the key information or even what OpenPGP was, most likely. What struck me was that I was able to find all that in around *20 minutes*, after being prompted by information on the keys. It's not just about getting the data. It's also about getting it as quickly and as easily as possible, and the key data made my job dramatically easier. It means the attacker can attack more people, pay less for each attack, and be less trained. A piece of information that can be reached via multiple different paths is also more likely to be found than information that can only be reached via one. I don't believe I would have been able to find out the vehicle color, age of the house, or one of the names without the hints provided by the key data, or at least not within the 30 minute window. You mention a name above as something available from Google, but I actually found two different names from two different sources for this individual. I listed them both in my mail to you, but the one that turned out to be right was not the one reachable from a Google search. > Please be very careful when using this to support broad, general statements. This is only one test, it was informal and very quick-and-dirty. Perhaps I got lucky. I do think it is safe to say that access to the key gave me more (in both quantity and speed) than I would have been able to get otherwise, which is what I was trying to show, so I'm content to leave it there. I don't want to give the impression that OpenPGP keys, signatures, or keyservers are somehow evil here. They're not. It's just that, like any number of other things on the net, keys and their contents can serve as a channel for information leakage. This shouldn't be news to anyone on this list. David From reynt0 at cs.albany.edu Mon Mar 1 18:47:21 2010 From: reynt0 at cs.albany.edu (reynt0) Date: Mon, 1 Mar 2010 12:47:21 -0500 (EST) Subject: key question In-Reply-To: <225E682A-0C69-4024-82E1-2B0BE293B2B0@jabberwocky.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <4B87FF24.3000005@sixdemonbag.org> <20645864.20100227045507@my_localhost> <4B88B791.7000100@sixdemonbag.org> <753752138.20100227192106@my_localhost> <8ED2D6C4-B7C0-4E2E-9EFD-04F1D7E8545B@sixdemonbag.org> <225E682A-0C69-4024-82E1-2B0BE293B2B0@jabberwocky.com> Message-ID: On Sun, 28 Feb 2010, David Shaw wrote: > On Feb 28, 2010, at 4:20 PM, reynt0 wrote: > >> On Sat, 27 Feb 2010, Robert J. Hansen wrote: >> . . . >>> The perfect is the enemy of the good. >> >> Just to note, did RJH actually intend to write >> "...the enemy of the good enough.", which I believe is >> the usual quote? The two are rather different ideas, >> even more so if morality has been included as an aspect >> of the discussion. > > Voltaire. "Le mieux est l'ennemi du bien". Rob's translation is as > good as any I've seen. I would understood the Voltaire as a comment about people who use betterment (cf "Progress") as justification for change, but I see your point. What I was thinking of was the "Worse is Better" theme, cf http://www.jwz.org/doc/worse-is-better.html and http://dreamsongs.com/WorseIsBetter.html . And FWIW, to be thorough, I'll toss in: http://en.wikiquote.org/wiki/Voltaire and http://fr.wikisource.org/wiki/La_B%C3%A9gueule :-) From psusi at cfl.rr.com Mon Mar 1 18:20:06 2010 From: psusi at cfl.rr.com (Phillip Susi) Date: Mon, 1 Mar 2010 12:20:06 -0500 Subject: Offline Primary Key Message-ID: <4B8BF746.6000709@cfl.rr.com> I would like to keep the private portion of my primary key stored offline and use an expiring secondary key for day to day signing. To accomplish this I have tried backing up the key after creating the secondary signing key, then attempting to delete the private portion of the primary key from the key ring, but even when I explicitly specify the primary key ID to delete with --delete-primary-keys, the secondary private key is also removed. How can I remove ONLY the private part of the primary key, and not the secondary key(s)? From dshaw at jabberwocky.com Mon Mar 1 19:57:48 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 1 Mar 2010 13:57:48 -0500 Subject: Offline Primary Key In-Reply-To: <4B8BF746.6000709@cfl.rr.com> References: <4B8BF746.6000709@cfl.rr.com> Message-ID: <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> On Mar 1, 2010, at 12:20 PM, Phillip Susi wrote: > I would like to keep the private portion of my primary key stored offline and use an expiring secondary key for day to day signing. To accomplish this I have tried backing up the key after creating the secondary signing key, then attempting to delete the private portion of the primary key from the key ring, but even when I explicitly specify the primary key ID to delete with --delete-primary-keys, the secondary private key is also removed. > > How can I remove ONLY the private part of the primary key, and not the secondary key(s)? What you need to do is an --export-secret-subkeys (there is no such command as --delete-primary-keys). So, starting from a state where your whole key (primary and all secondaries) are all imported to your GPG instance, do: gpg --export-secret-subkeys (thekeyid) > my-secondary-keys-only.gpg Then import my-secondary-keys-only.gpg into whichever GPG you want to use it with. If you want to use it with the same one you just exported from, then do: gpg --export-secret-key (thekeyid) > my-real-secret-key.gpg gpg --delete-secret-key (thekeyid) gpg --import my-secondary-keys-only.gpg (i.e. save a copy of the full key, delete it from the keyring, and replace it with the secondary-key-only copy). Make sure you save my-real-secret-key.gpg in a safe place! Didn't someone write a nice HOWTO about offline private keys at one point? I thought there was one out there, but can't find it at the moment. Can anyone post the URL for Philip? David From John at Mozilla-Enigmail.org Mon Mar 1 20:59:34 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Mon, 01 Mar 2010 13:59:34 -0600 Subject: Offline Primary Key In-Reply-To: <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> Message-ID: <4B8C1CA6.8020901@Mozilla-Enigmail.org> David Shaw wrote: > > Didn't someone write a nice HOWTO about offline private keys at one point? I > thought there was one out there, but can't find it at the moment. Can anyone > post the URL for Philip? > Adrian von Bidder's page is the only one that memory serves up: http://fortytwo.ch/gpg/subkeys -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Mon Mar 1 20:07:07 2010 From: kgo at grant-olson.net (Grant Olson) Date: Mon, 01 Mar 2010 14:07:07 -0500 Subject: Offline Primary Key In-Reply-To: <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> Message-ID: <4B8C105B.1090304@grant-olson.net> > > Can anyone post the URL for Philip? > > David > http://fortytwo.ch/gpg/subkeys -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From psusi at cfl.rr.com Mon Mar 1 21:31:58 2010 From: psusi at cfl.rr.com (Phillip Susi) Date: Mon, 1 Mar 2010 15:31:58 -0500 Subject: Offline Primary Key In-Reply-To: <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> Message-ID: <4B8C243E.6080406@cfl.rr.com> On 3/1/2010 1:57 PM, David Shaw wrote: > What you need to do is an --export-secret-subkeys (there is no such command as --delete-primary-keys). So, starting from a state where your whole key (primary and all secondaries) are all imported to your GPG instance, do: Yes, I meant --delete-secret-key > gpg --export-secret-subkeys (thekeyid)> my-secondary-keys-only.gpg > > Then import my-secondary-keys-only.gpg into whichever GPG you want to use it with. If you want to use it with the same one you just exported from, then do: > > gpg --export-secret-key (thekeyid)> my-real-secret-key.gpg > gpg --delete-secret-key (thekeyid) > gpg --import my-secondary-keys-only.gpg > > (i.e. save a copy of the full key, delete it from the keyring, and replace it with the secondary-key-only copy). This does the trick, but I still do not understand why --delete-secret-key removes BOTH the primary and subkey secrets when I specifically gave only the ID of the subkey? Shouldn't it remove exactly what I say and no more? From dshaw at jabberwocky.com Mon Mar 1 21:37:28 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 1 Mar 2010 15:37:28 -0500 Subject: Offline Primary Key In-Reply-To: <4B8C1CA6.8020901@Mozilla-Enigmail.org> References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> <4B8C1CA6.8020901@Mozilla-Enigmail.org> Message-ID: On Mar 1, 2010, at 2:59 PM, John Clizbe wrote: > David Shaw wrote: >> >> Didn't someone write a nice HOWTO about offline private keys at one point? I >> thought there was one out there, but can't find it at the moment. Can anyone >> post the URL for Philip? >> > > Adrian von Bidder's page is the only one that memory serves up: > http://fortytwo.ch/gpg/subkeys Ah, thanks! I knew I remembered that it was out there, but just could not find it for some reason. David From dshaw at jabberwocky.com Mon Mar 1 21:37:41 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 1 Mar 2010 15:37:41 -0500 Subject: Offline Primary Key In-Reply-To: <4B8C243E.6080406@cfl.rr.com> References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> <4B8C243E.6080406@cfl.rr.com> Message-ID: On Mar 1, 2010, at 3:31 PM, Phillip Susi wrote: > On 3/1/2010 1:57 PM, David Shaw wrote: >> What you need to do is an --export-secret-subkeys (there is no such command as --delete-primary-keys). So, starting from a state where your whole key (primary and all secondaries) are all imported to your GPG instance, do: > > Yes, I meant --delete-secret-key > >> gpg --export-secret-subkeys (thekeyid)> my-secondary-keys-only.gpg >> >> Then import my-secondary-keys-only.gpg into whichever GPG you want to use it with. If you want to use it with the same one you just exported from, then do: >> >> gpg --export-secret-key (thekeyid)> my-real-secret-key.gpg >> gpg --delete-secret-key (thekeyid) >> gpg --import my-secondary-keys-only.gpg >> >> (i.e. save a copy of the full key, delete it from the keyring, and replace it with the secondary-key-only copy). > > This does the trick, but I still do not understand why --delete-secret-key removes BOTH the primary and subkey secrets when I specifically gave only the ID of the subkey? Shouldn't it remove exactly what I say and no more? It has to do with how keys are specified. In GnuPG, you can specify a key in a number of ways - by name, by (any) fingerprint, and by (any) key ID. So if you have a key named "foobar", and the key ID is AAAAAAAA and the subkey ID is BBBBBBBB, you could refer to that key with any of "foobar", "AAAAAAAA", or "BBBBBBBB". When you say "--delete-secret-key BBBBBBB", you're actually saying delete the whole key. David From psusi at cfl.rr.com Mon Mar 1 22:11:14 2010 From: psusi at cfl.rr.com (Phillip Susi) Date: Mon, 1 Mar 2010 16:11:14 -0500 Subject: Offline Primary Key In-Reply-To: References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> <4B8C243E.6080406@cfl.rr.com> Message-ID: <4B8C2D72.5060008@cfl.rr.com> On 3/1/2010 3:37 PM, David Shaw wrote: >> This does the trick, but I still do not understand why >> --delete-secret-key removes BOTH the primary and subkey secrets >> when I specifically gave only the ID of the subkey? Shouldn't it >> remove exactly what I say and no more? > > It has to do with how keys are specified. In GnuPG, you can specify > a key in a number of ways - by name, by (any) fingerprint, and by > (any) key ID. So if you have a key named "foobar", and the key ID is > AAAAAAAA and the subkey ID is BBBBBBBB, you could refer to that key > with any of "foobar", "AAAAAAAA", or "BBBBBBBB". When you say > "--delete-secret-key BBBBBBB", you're actually saying delete the > whole key. Can this be overridden? I thought that is what the ! suffix was for, but it still deletes the whole thing. From dshaw at jabberwocky.com Mon Mar 1 22:13:33 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 1 Mar 2010 16:13:33 -0500 Subject: Offline Primary Key In-Reply-To: <4B8C2D72.5060008@cfl.rr.com> References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> <4B8C243E.6080406@cfl.rr.com> <4B8C2D72.5060008@cfl.rr.com> Message-ID: <2A5E7FF9-8232-4B1F-9069-2592563BF13F@jabberwocky.com> On Mar 1, 2010, at 4:11 PM, Phillip Susi wrote: > On 3/1/2010 3:37 PM, David Shaw wrote: >>> This does the trick, but I still do not understand why >>> --delete-secret-key removes BOTH the primary and subkey secrets >>> when I specifically gave only the ID of the subkey? Shouldn't it >>> remove exactly what I say and no more? >> >> It has to do with how keys are specified. In GnuPG, you can specify >> a key in a number of ways - by name, by (any) fingerprint, and by >> (any) key ID. So if you have a key named "foobar", and the key ID is >> AAAAAAAA and the subkey ID is BBBBBBBB, you could refer to that key >> with any of "foobar", "AAAAAAAA", or "BBBBBBBB". When you say >> "--delete-secret-key BBBBBBB", you're actually saying delete the >> whole key. > > > Can this be overridden? I thought that is what the ! suffix was for, > but it still deletes the whole thing. Not for deletion. There is no way to delete a primary key "in place" while leaving the subkeys intact. Such an ability is very dangerous since if you delete that primary key without a backup, you'll never be able to make more subkeys, issue a revocation certificate, or sign someone elses key. The current design effectively forces people to manually move the valuable primary key out of the way before clobbering it with the subkey-only copy of the key. David From dshaw at jabberwocky.com Mon Mar 1 23:15:40 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 1 Mar 2010 17:15:40 -0500 Subject: How to give the keywork from command line. In-Reply-To: <4B8ACACD.2000703@grant-olson.net> References: <877hpyvyvo.fsf@Q6600-0.ver.megared.net.mx> <4B8ACACD.2000703@grant-olson.net> Message-ID: <2F42B704-4D12-4744-96CF-6DE87C771841@jabberwocky.com> On Feb 28, 2010, at 2:58 PM, Grant Olson wrote: > On 2/28/2010 10:41 AM, Mario Castel?n Castro wrote: >> February 27th 2010 in gnupg-users at gnupg.org thread "Hot to give the >> keyword from the command line" >> >> Thanks Laurent, it works :). > > Also, if you encrypt to a key, you shouldn't need to provide a > passphrase at all, unless you need to sign the file too. I get nervous > about passphrases in batch files... Indeed. If you have to encode a passphrase in a batch file or other piece of code that calls GPG, it's worth asking yourself why you have a passphrase there at all. You might want to just remove the passphrase altogether. David From mariocastelancastro at gmail.com Tue Mar 2 01:01:21 2010 From: mariocastelancastro at gmail.com (=?ISO-8859-1?Q?Mario_Castel=E1n_Castro?=) Date: Mon, 1 Mar 2010 18:01:21 -0600 Subject: How to give the keywork from command line. In-Reply-To: <2F42B704-4D12-4744-96CF-6DE87C771841@jabberwocky.com> References: <877hpyvyvo.fsf@Q6600-0.ver.megared.net.mx> <4B8ACACD.2000703@grant-olson.net> <2F42B704-4D12-4744-96CF-6DE87C771841@jabberwocky.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 February 27th 2010 in gnupg-users at gnupg.org thread "Hot to give the keyword from the command line" >Also, if you encrypt to a key, you shouldn't need to provide a >passphrase at all, unless you need to sign the file too. I get >nervous about passphrases in batch files... I'm using the symetric AES, so I need a keyword. >Indeed. If you have to encode a passphrase in a batch file or other >piece of code that calls GPG, it's worth asking yourself why you have >a passphrase there at all. You might want to just remove the >passphrase altogether. No, because the backups are stored on my USB memory stick, and they are easy to loose, plus I often forget things, so with the password there should't be a risk if I lose the memory stick. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuMVVIACgkQZ4DA0TLic4hCwQCeKLiu3a/CP7sR6BLf9EnhVyff Q7gAniLxaDwpVVyp0KpTZ5bQ6fQ5nT5y =8Grs -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Tue Mar 2 01:11:41 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 1 Mar 2010 19:11:41 -0500 Subject: David's findings In-Reply-To: <6C1005B5-4A06-4B58-92C1-1AAE3C2C5B58@JABBERWOCKY.COM> References: <4459025A-D107-4D97-9EC7-70715B4AA5E1@sixdemonbag.org> <6C1005B5-4A06-4B58-92C1-1AAE3C2C5B58@JABBERWOCKY.COM> Message-ID: <7DEDEC61-94DD-434A-B56E-81038133352B@sixdemonbag.org> > Both the religion (not sure why this was counted as two 'misses') You phrased it in your email to me as two sentences, and I was cutting back and forth between reading your email and composing the email to the list. "Bullet point: raised Methodist, no, Episcopal," cut over to the compose window, go back, "Bullet point: no, I am not at present a Methodist," cut over to the compose window, etc. It's not my intent for those bullet points to be read as any kind of a score. That would be giving the appearance of a rigor I don't think this test possesses. :) The results are interesting, but not rigorous. > It means the attacker can attack more people, pay less for each attack, and be less trained. A piece of information that can be reached via multiple different paths is also more likely to be found than information that can only be reached via one. Be less trained, yes. However, I think my example of how doing those same tasks using pretty obvious Google searches shows that the threshold of difficulty is already quite low. The information is out there, and people who keep their keys off the keyservers because they want to preserve their privacy need to realize they're not fighting a losing battle -- they've already lost. > I don't believe I would have been able to find out the vehicle color, age of the house, or one of the names without the hints provided by the key data, or at least not within the 30 minute window. I disagree, but beyond that I can't comment. It's no longer my privacy, but my parents'. From faramir.cl at gmail.com Tue Mar 2 01:04:02 2010 From: faramir.cl at gmail.com (Faramir) Date: Mon, 01 Mar 2010 21:04:02 -0300 Subject: Offline Primary Key In-Reply-To: <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> Message-ID: <4B8C55F2.8040206@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David Shaw escribi?: ... > Didn't someone write a nice HOWTO about offline private keys at one point? I thought there was one out there, but can't find it at the moment. Can anyone post the URL for Philip? http://tjl73.altervista.org/secure_keygen/en/index.html Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLjFXyAAoJEMV4f6PvczxAIUoIAK5fvkQthTgRU48kHLGtqfpo o5CT92zzmLtHT51CkNrcRKdai/ioZ1zf29BV7Qvlpx48+O7FElA4pGqGOc1FsTDJ g70bsxHHAar2wrZxN9X0HLTbIXXAJmBaHkkn06H187aqthmgHI3D7Jov5OzUzgod OtwWMSOsvC5O3NAf5WwKQ2Motvs29gExADbh3OjQqFQlfAu6H/JMLOfC+tlYSFlQ D9Vqjen3fG/x5Nn/ikoIMsE5Nqc//syCwVqys2zYDqk5SkdC5GHPXz1w9WtZcgp9 VpQI2fgcXBTxB3nJ5rXAuKFtItTtNbgOccg0WwfeAILAws+5OVcQHjMxz73K3qs= =0gl/ -----END PGP SIGNATURE----- From wk at gnupg.org Tue Mar 2 11:27:00 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Mar 2010 11:27:00 +0100 Subject: Offline Primary Key In-Reply-To: <2A5E7FF9-8232-4B1F-9069-2592563BF13F@jabberwocky.com> (David Shaw's message of "Mon, 1 Mar 2010 16:13:33 -0500") References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> <4B8C243E.6080406@cfl.rr.com> <4B8C2D72.5060008@cfl.rr.com> <2A5E7FF9-8232-4B1F-9069-2592563BF13F@jabberwocky.com> Message-ID: <87y6ibxbm3.fsf@vigenere.g10code.de> On Mon, 1 Mar 2010 22:13, dshaw at jabberwocky.com said: > someone elses key. The current design effectively forces people to > manually move the valuable primary key out of the way before > clobbering it with the subkey-only copy of the key. Another important point is that if you want to use an offline key you should create that key offline and export the subkeys to the online box. Doing this on the same box is a bit questionable. To me an offline key is one created on box which has never been and will never be connected to the net. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From faramir.cl at gmail.com Tue Mar 2 20:11:16 2010 From: faramir.cl at gmail.com (Faramir) Date: Tue, 02 Mar 2010 16:11:16 -0300 Subject: Offline Primary Key In-Reply-To: <87y6ibxbm3.fsf@vigenere.g10code.de> References: <4B8BF746.6000709@cfl.rr.com> <610B99EE-AD9D-4709-A7E1-0ED59A5013C2@jabberwocky.com> <4B8C243E.6080406@cfl.rr.com> <4B8C2D72.5060008@cfl.rr.com> <2A5E7FF9-8232-4B1F-9069-2592563BF13F@jabberwocky.com> <87y6ibxbm3.fsf@vigenere.g10code.de> Message-ID: <4B8D62D4.1060600@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Werner Koch escribi?: ... > Another important point is that if you want to use an offline key you > should create that key offline and export the subkeys to the online box. > Doing this on the same box is a bit questionable. To me an offline key > is one created on box which has never been and will never be connected > to the net. Well, but there may be some advantages in removing the primary key from the computer, maybe you generate it in your home computer (which you consider "safe"), and want to carry a copy of the subkeys in your laptop (which you are afraid of losing). Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLjWLUAAoJEMV4f6PvczxAmvMIAIghx214tR3hbADhHQ4XuEJT zPmEXOX/rmsKsMQLS8SQgt5zwulInlWBjENbW5PHeS3cb7TtMBQEmGD+hxvb4ssJ cs32IDw75pBXUBd16tJSYVAppLKugO8S0OWe4+haC9BEoFnZHtl8AzhMUt/iRr7o +B6Fr79mWV3JGA3h4ZppSsylgIz6w5bBIC6qsGF1/NkjcUDgQs213K1LfjLwSHoW wECBa/jStQnqdAKQdv9GCRCLmk9UbMQwmAyMypRM+hM0XJxSC3fIjaz/b9UyMcOg ZtikRjnIq9EdgQDuayRcs81fd+LOikpvhYZqbqKo0pk3pQq3YE5Iukx4ms96wF4= =E8RX -----END PGP SIGNATURE----- From kloecker at kde.org Tue Mar 2 22:18:02 2010 From: kloecker at kde.org (Ingo =?utf-8?q?Kl=C3=B6cker?=) Date: Tue, 02 Mar 2010 22:18:02 +0100 Subject: Offline Primary Key In-Reply-To: <4B8D62D4.1060600@gmail.com> References: <4B8BF746.6000709@cfl.rr.com> <87y6ibxbm3.fsf@vigenere.g10code.de> <4B8D62D4.1060600@gmail.com> Message-ID: <201003022218.03842@thufir.ingo-kloecker.de> On Tuesday 02 March 2010, Faramir wrote: > Werner Koch escribi?: > ... > > > Another important point is that if you want to use an offline key > > you should create that key offline and export the subkeys to the > > online box. Doing this on the same box is a bit questionable. To > > me an offline key is one created on box which has never been and > > will never be connected to the net. > > Well, but there may be some advantages in removing the primary key > from the computer, maybe you generate it in your home computer (which > you consider "safe"), and want to carry a copy of the subkeys in your > laptop (which you are afraid of losing). If you are afraid of losing your laptop then you should use hard-disk encryption. In fact, you should use it even if you are not afraid of losing your laptop. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From andy_croft at npd.com Tue Mar 2 23:31:09 2010 From: andy_croft at npd.com (20 Ton Squirrel) Date: Tue, 2 Mar 2010 14:31:09 -0800 (PST) Subject: Unable to decrypt/verify from own machine Message-ID: <27472546.post@talk.nabble.com> The Setup I run Windows XP using GnuPG version 1.4.10. A client and I have exchanged our keys. I successfully imported his key and attempted to encrypt a file to send him. My command line is as follows: gpg --passphrase mypassphrase --compress-algo 1 --cipher-algo cast5 -u me at myemail.com -r client at hisemail.com -o C:\user\encryption\out\targetFile.xls.gpg -se C:\user\encryption\in\targetFile.xls The Problem When trying to decrypt or verify the encrypted file, I get the following error: No secret key available Keyring does not have the secret key (0xA352B4E9003B38FA) needed to decrypt this message. My key's ID is 1F1EA8F8 and the client's ID is 5872AF6A. I have no idea why it would be asking for A352B4E9003B38FA. This is likely a beginner's mistake, but I'm at a loss! -- View this message in context: http://old.nabble.com/Unable-to-decrypt-verify-from-own-machine-tp27472546p27472546.html Sent from the GnuPG - User mailing list archive at Nabble.com. From faramir.cl at gmail.com Wed Mar 3 00:41:47 2010 From: faramir.cl at gmail.com (Faramir) Date: Tue, 02 Mar 2010 20:41:47 -0300 Subject: Unable to decrypt/verify from own machine In-Reply-To: <27472546.post@talk.nabble.com> References: <27472546.post@talk.nabble.com> Message-ID: <4B8DA23B.6020701@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 20 Ton Squirrel escribi?: ... > The Problem > When trying to decrypt or verify the encrypted file, I get the following > error: > No secret key available Keyring does not have the secret key > (0xA352B4E9003B38FA) needed to decrypt this message. I am not familiar with command line, since I use a GUI (GPGShell, works very well on Windows XP), but I think the problem is you are encrypting the file only to the client's key, and you should encrypt it to both your key and your client's key. You are asking GPG to sign with your key and encrypt only to your client's key. I don't know how to ask GPG to encrypt to both keys. > My key's ID is 1F1EA8F8 and the client's ID is 5872AF6A. I have no idea why > it would be asking for A352B4E9003B38FA. A key fingerprint has 40 characters: In my case, 388C1FBDBE9835D7BD02253B82121A454319410E. The last 16 characters at the right (in my example, 82121A454319410E) is the "long Key ID". And the last 8 characters at the right (in my example, 4319410E), so that should clarify the mystery of the variable length of IDs. But also, my key (as most key do) has a subkey, bound to it, which is the key used for encryption (in my case, 3E497861B97C3E51244A61023EB64AF12E6CD89E, or 3EB64AF12E6CD89E, or 2E6CD89E). Maybe GPG is reporting it needs the encrypting subkey, instead of asking the primary key of your client. > This is likely a beginner's mistake, but I'm at a loss! Well, I have been using GPG for about 2 years now, and I still don't know how to use command line... I tried to test the command you used, and it failed, I don't know why XD Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLjaI7AAoJEMV4f6PvczxAhhkH/jZ6aQwkO39QK9l7NcdGCWqL 24+Bblrp2NzEm+8F7wo0p6r9XMPt8BUQKJywaVdHAE8p6wGX/153iQc13IYPJfhr wz+nYvQR8mSzDeK40tH8LOFcruSXmH318MUbiYVhG4dvCaLOcheCu3GUIoIzzl7o NmChNTXFqkh2TbMETs91JmMsb9AF0ewUILJdNoHQmrEj04e9jRKjCktaID5CuWu6 19ij4bt6j/r+EyckDmUxj3Q4aLt9VkLA6is9YQLWia0hDag1uGpNO9NMqH+Uqf+L gUBMN8ZgmGPMC5IES6ArDY3E33XL4jLBtd+/Xq3ZfSprmS8LVu6u3hSUCuVys1Y= =VbSO -----END PGP SIGNATURE----- From kgo at grant-olson.net Tue Mar 2 23:45:42 2010 From: kgo at grant-olson.net (Grant Olson) Date: Tue, 02 Mar 2010 17:45:42 -0500 Subject: Unable to decrypt/verify from own machine In-Reply-To: <27472546.post@talk.nabble.com> References: <27472546.post@talk.nabble.com> Message-ID: <4B8D9516.8070100@grant-olson.net> On 3/2/2010 5:31 PM, 20 Ton Squirrel wrote: > > The Setup > I run Windows XP using GnuPG version 1.4.10. > > A client and I have exchanged our keys. I successfully imported his key and > attempted to encrypt a file to send him. My command line is as follows: > > gpg --passphrase mypassphrase --compress-algo 1 --cipher-algo cast5 -u > me at myemail.com -r client at hisemail.com -o > C:\user\encryption\out\targetFile.xls.gpg -se > C:\user\encryption\in\targetFile.xls > > The Problem > When trying to decrypt or verify the encrypted file, I get the following > error: > No secret key available Keyring does not have the secret key > (0xA352B4E9003B38FA) needed to decrypt this message. > > My key's ID is 1F1EA8F8 and the client's ID is 5872AF6A. I have no idea why > it would be asking for A352B4E9003B38FA. > > This is likely a beginner's mistake, but I'm at a loss! > You'll need to add yourself as a recipient in addition to the client (-r me at myemail.com) or *you* won't ever be able to decrypt the file. Also, what is the encryption subkey for the user's key id? If you run "gpg --list-keys 5872AF6A". My guess you'll see the encryption subkey: "003B38FA" Something like: sub 2048R/003B38FA 2010-01-11 [expires: 2011-03-01] You also might want to consider a front end to gpg that ties into explorer. Like GPGShell or gpgEX. It can make things easier on you. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From faramir.cl at gmail.com Wed Mar 3 00:47:22 2010 From: faramir.cl at gmail.com (Faramir) Date: Tue, 02 Mar 2010 20:47:22 -0300 Subject: Unable to decrypt/verify from own machine In-Reply-To: <27472546.post@talk.nabble.com> References: <27472546.post@talk.nabble.com> Message-ID: <4B8DA38A.2050702@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 20 Ton Squirrel escribi?: ... > My key's ID is 1F1EA8F8 and the client's ID is 5872AF6A. I have no idea why > it would be asking for A352B4E9003B38FA. I tried using the GUI, and in fact, the error message shows the ID of the encryption subkey required to decrypt, not the main key ID. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLjaOKAAoJEMV4f6PvczxABWoH/31FFOc0FAmLSVW7/L+2R5ji qkFotW3DQtrZ8/7unap0uNcQ33rgrSeKYvI9J+2nubQWSKTalizA4KXR/vN0VZGo k5hsoiXcP8SqLRMC3mHT4dYl0cxwt9L21JZ2Ae0jMKtg0U7Y/drW4lSxuz2VtMTI ElqByraZOdjvnU9kDdkwZr9wiwlO+6Vnzzq3iHfhAYUYGnvumY3ub/cnH8K7VVXF +FbsaVMY2PC9RT2jqjEM5ISIdeZsvWst+Z67YMoVyROaseGrQjRKWmYKnWM6Ti0w Px67U/7xMESMMa41IoDWLSbLM/ph2uYVEF2MP9SPKhGtn+r1081gYdNCWl0umuM= =hC+U -----END PGP SIGNATURE----- From laurent.jumet at skynet.be Wed Mar 3 00:09:36 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Wed, 03 Mar 2010 00:09:36 +0100 Subject: Unable to decrypt/verify from own machine In-Reply-To: <27472546.post@talk.nabble.com> Message-ID: Hello 20 ! 20 Ton Squirrel wrote: > The Setup > I run Windows XP using GnuPG version 1.4.10. > A client and I have exchanged our keys. I successfully imported his key and > attempted to encrypt a file to send him. My command line is as follows: > gpg --passphrase mypassphrase --compress-algo 1 --cipher-algo cast5 -u > me at myemail.com -r client at hisemail.com -o > C:\user\encryption\out\targetFile.xls.gpg -se > C:\user\encryption\in\targetFile.xls > The Problem > When trying to decrypt or verify the encrypted file, I get the following > error: > No secret key available Keyring does not have the secret key > (0xA352B4E9003B38FA) needed to decrypt this message. > My key's ID is 1F1EA8F8 and the client's ID is 5872AF6A. I have no idea why > it would be asking for A352B4E9003B38FA. > This is likely a beginner's mistake, but I'm at a loss! First of all, you shouldn't put the PASSPHRASE on the command line; GPG will prompt you. "--compress-algo 1" means you'd like ZIP ? In this case you should use either "--compress-algo Z1" or "--compress-algo ZIP" but not "1". May be you are confusing with "--compress-level N" or better "-Z N" where "N" defaults to "6" if you don't use this parameter. Are you aiming to decrypt your own message? If yes, you must encrypt the file both to *you* and the receipient, and add "-r me at myemail.com" So: GPG -se --compress-algo ZIP --cipher-algo CAST5 -u me at myemail.com -r client at hisemail.com -r me at myemail.com -o C:\user\encryption\out\targetFile.xls.gpg C:\user\encryption\in\targetFile.xls Of course, you should put in your gpg.conf most of your preferences; not on the command line: My GPG.CONF : default-key 0xCFAF704C default-recipient-self encrypt-to 0xCFAF704C keyserver x-hkp://blackhole.pca.dfn.de keyserver-options auto-key-retrieve sig-keyserver-url http://www.pointdechat.net/0xCFAF704C.asc photo-viewer c:\program files\gpgshell\gpgview.exe %i /title 0x%k load-extension c:\lib\gnupg\idea.dll default-preference-list S7 S11 S12 S13 S1 S10 S3 S4 S2 S9 S8 H3 H8 H9 H10 H11 H2 H1 Z1 Z2 Z3 Z0 personal-cipher-preferences S7 S11 S12 S13 S1 S10 S3 S4 S2 S9 S8 personal-digest-preferences H3 H8 H9 H10 H11 H2 H1 personal-compress-preferences Z1 Z2 Z3 Z0 keyid-format 0xSHORT no-greeting no-mdc-warning armor -- Laurent Jumet KeyID: 0xCFAF704C From cathy.smith at pnl.gov Wed Mar 3 03:18:42 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Tue, 2 Mar 2010 18:18:42 -0800 Subject: FW: Migrating from PGP to GPG question Message-ID: <70086D201BD484439914C36F5C8BF16101A1B795F9D0@EMAIL04.pnl.gov> Folks The gpg --import option worked without any problems for importing the OpenPGP public keyring. When I try to import the secret keyring, I get the following message: [app1 ~/.gnupg]$ gpg --import secring.skr gpg: key B4A839CC: secret key imported gpg: key B4A8899S: "ofc" not changed gpg: key 96B12847: secret key imported gpg: key 96B12847: "pss" not changed gpg: WARNING: key 96B12847 contains preferences for unavailable gpg: algorithms on these user IDs: gpg: "pss": preference for cipher algorithm 1 gpg: it is strongly suggested that you update your preferences and gpg: re-distribute this key to avoid potential algorithm mismatch problems Set preference list to: Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA1, SHA256, RIPEMD160 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Really update the preferences? (y/N) If I answer "no", the import finishes with the message: Key not changed so no update needed. gpg: Total number processed: 7 gpg: w/o user IDs: 1 gpg: unchanged: 6 gpg: secret keys read: 7 gpg: secret keys imported: 7 When I created my gpg keyring, I selected the default for the key, DSA and Elgamml, and a 2048 bit keysize. What are the ramifications of just saying "yes" to the prompt - update preferences? How potentially serious is the algorithm mismatch? I'd like to better understand exactly what is happening. Just for background, this is migration has to go into production in a very short time. Redistributing keys to the various vendors, and to test the batch jobs using these keys to exchange files with vendors, wasn't included when planning. So I'm under a short deadline. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Laurent Jumet Sent: Thursday, February 25, 2010 2:51 PM To: Smith, Cathy Subject: RE: Migrating from PGP to GPG question Hello Smith, ! "Smith, Cathy" wrote: > Another question about this migration. Is it possible to do a mass import > of a single user's keyring or do I have to do it for each individual key. > I've not been able to find anything so far about anything that addresses > this. I would try gpg pubring.pgp as GPG assumes usually the most relevant action. Adding keyring pubring.pgp in gpg.conf adds current file to list of keyrings. And gpg --import pubring.pgp should import the whole keyring too. -- Laurent Jumet KeyID: 0xCFAF704C _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From rjh at sixdemonbag.org Wed Mar 3 05:00:24 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 2 Mar 2010 23:00:24 -0500 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B795F9D0@EMAIL04.pnl.gov> References: <70086D201BD484439914C36F5C8BF16101A1B795F9D0@EMAIL04.pnl.gov> Message-ID: <8828C6C7-4046-408E-B005-1950843AD5E1@sixdemonbag.org> > What are the ramifications of just saying "yes" to the prompt - update preferences? How potentially serious is the algorithm mismatch? I'd like to better understand exactly what is happening. Ever since the very early days, PGP has supported a cryptographic algorithm called IDEA. Back in the early '90s IDEA was considered a strong, promising cipher. Time has not been kind to it. The current judgment of IDEA is that it is strong *enough*, but not really strong, and it is not considered especially promising. It is also subject to software patents. For these reasons, the current revision of the OpenPGP specification does not require or recommend that implementations support IDEA. (The OpenPGP *specification* is not the same thing as PGP or GnuPG, which are *implementations* -- in the same way that Outlook and Thunderbird *implement* email protocols, but those protocols are *specified* in other places.) Anyway. By default, GnuPG does not support IDEA. PGP does, mostly because they still have customers who need it. Different strokes for different folks. What GnuPG is warning you about is, "your current key says that other people can use IDEA when sending you encrypted email. I can't read IDEA. This will be a problem if anyone sends you IDEA-encrypted traffic. Would you like for me to change your key so that other people can know not to send you IDEA traffic?" I'm hedging my bets a little bit, since I don't know enough about your specific needs to speak with certainty. That said, I believe it is safe for you to answer "yes" here. From dshaw at jabberwocky.com Wed Mar 3 05:00:26 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 2 Mar 2010 23:00:26 -0500 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B795F9D0@EMAIL04.pnl.gov> References: <70086D201BD484439914C36F5C8BF16101A1B795F9D0@EMAIL04.pnl.gov> Message-ID: <949A8B8F-CBCA-4FBE-9209-436501C12831@jabberwocky.com> On Mar 2, 2010, at 9:18 PM, Smith, Cathy wrote: > Folks > > The gpg --import option worked without any problems for importing the OpenPGP public keyring. When I try to import the secret keyring, I get the following message: > > [app1 ~/.gnupg]$ gpg --import secring.skr > gpg: key B4A839CC: secret key imported > gpg: key B4A8899S: "ofc" not changed > gpg: key 96B12847: secret key imported > gpg: key 96B12847: "pss" not changed > gpg: WARNING: key 96B12847 contains preferences for unavailable > gpg: algorithms on these user IDs: > gpg: "pss": preference for cipher algorithm 1 > gpg: it is strongly suggested that you update your preferences and > gpg: re-distribute this key to avoid potential algorithm mismatch problems > > Set preference list to: > Cipher: AES256, AES192, AES, CAST5, 3DES > Digest: SHA1, SHA256, RIPEMD160 > Compression: ZLIB, BZIP2, ZIP, Uncompressed > Features: MDC, Keyserver no-modify > Really update the preferences? (y/N) > > If I answer "no", the import finishes with the message: > > Key not changed so no update needed. > gpg: Total number processed: 7 > gpg: w/o user IDs: 1 > gpg: unchanged: 6 > gpg: secret keys read: 7 > gpg: secret keys imported: 7 > > > When I created my gpg keyring, I selected the default for the key, DSA and Elgamml, and a 2048 bit keysize. > > What are the ramifications of just saying "yes" to the prompt - update preferences? How potentially serious is the algorithm mismatch? I'd like to better understand exactly what is happening. OpenPGP keys contain several algorithm lists, one each for cipher algorithms, hash algorithms, and compression algorithms. Among other things, these lists are used to guarantee that someone doesn't send you a message that you can't handle. For example, if the list of ciphers on your key didn't have AES-256, then nobody should use AES-256 when sending you a message. The warning message above means that your key 96B12847, aka "pss", has a listing for cipher 1 (called "IDEA"), but your copy of GPG doesn't have IDEA. This sets up a potentially frustrating situation where someone might send you a message using IDEA (after all, your key claims that you can handle it), but you won't be able to read the message because you really can't handle it. > Just for background, this is migration has to go into production in a very short time. Redistributing keys to the various vendors, and to test the batch jobs using these keys to exchange files with vendors, wasn't included when planning. So I'm under a short deadline. The right answer, I'm afraid, is to say "yes" to the prompt and update your preferences, and re-distribute the key in question (96B12847 "pss"). This isn't a problem with any other key you have. Alternately, you can re-build GPG to have IDEA support. Note, though, that there are legal implications to this. Unlike all of the other ciphers that are defined by OpenPGP, IDEA is patented and not free to use (the patent runs out in the US in January 2012, I believe, so we're not there yet). If you have a license to use IDEA, you can download the code from http://www.gnupg.org/faq/why-not-idea.en.html and use it legally. Unfortunately, the company that owns the rights to IDEA has more or less disappeared (subsumed into another company, if I recall) and does not seem to be issuing licenses any longer. This puts those people who really need IDEA in an unfortunate situation. If you're lucky, it's possible that the various vendors don't use IDEA either and would thus ignore the fact that your key allows it, but I really recommend just updating your preferences and re-distributing the "pss" key. It's likely the least painful solution here. David From brucevannorman at gmail.com Wed Mar 3 04:43:58 2010 From: brucevannorman at gmail.com (Bruce vanNorman) Date: Tue, 02 Mar 2010 19:43:58 -0800 Subject: How to give the keyword from command line. David Shaw Message-ID: <4B8DDAFE.7050906@gmail.com> While I understand the response. It fails to consider the persistence of the exposed password. If it is volatile within the script issuing the commands, then the pass-phrase has considerable value as a security measure. --- My problem (which relates to this) I have an ODB (OpenOffice.Org) database file which I would like encrypted. The process would be to get the pass-phrase from the user, decrypt the file, run soffice -base, and then re-encrypt the results with the same password. From rjh at sixdemonbag.org Wed Mar 3 07:41:57 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 3 Mar 2010 01:41:57 -0500 Subject: How to give the keyword from command line. David Shaw In-Reply-To: <4B8DDAFE.7050906@gmail.com> References: <4B8DDAFE.7050906@gmail.com> Message-ID: > My problem (which relates to this) I have an ODB (OpenOffice.Org) database file which I would like encrypted. The process would be to get the pass-phrase from the user, decrypt the file, run soffice -base, and then re-encrypt the results with the same password. This sounds like a use case for TrueCrypt or Linux's encrypted loopback filesystem or BitLocker or PGPdisk or... (insert many other options here), not GnuPG. Use the right tool for the job: don't try to drive a nail with a microwave oven. From laurent.jumet at skynet.be Wed Mar 3 08:56:50 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Wed, 03 Mar 2010 08:56:50 +0100 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B795F9D0@EMAIL04.pnl.gov> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello Smith, ! "Smith, Cathy" wrote: > The gpg --import option worked without any problems for importing the > OpenPGP public keyring. When I try to import the secret keyring, I get the > following message: > [app1 ~/.gnupg]$ gpg --import secring.skr > gpg: key B4A839CC: secret key imported > gpg: key B4A8899S: "ofc" not changed > gpg: key 96B12847: secret key imported > gpg: key 96B12847: "pss" not changed > gpg: WARNING: key 96B12847 contains preferences for unavailable > gpg: algorithms on these user IDs: > gpg: "pss": preference for cipher algorithm 1 > gpg: it is strongly suggested that you update your preferences and > gpg: re-distribute this key to avoid potential algorithm mismatch problems > Set preference list to: > Cipher: AES256, AES192, AES, CAST5, 3DES > Digest: SHA1, SHA256, RIPEMD160 > Compression: ZLIB, BZIP2, ZIP, Uncompressed > Features: MDC, Keyserver no-modify > Really update the preferences? (y/N) > If I answer "no", the import finishes with the message: > Key not changed so no update needed. > gpg: Total number processed: 7 > gpg: w/o user IDs: 1 > gpg: unchanged: 6 > gpg: secret keys read: 7 > gpg: secret keys imported: 7 > When I created my gpg keyring, I selected the default for the key, DSA and > Elgamml, and a 2048 bit keysize. > What are the ramifications of just saying "yes" to the prompt - update > preferences? How potentially serious is the algorithm mismatch? I'd like > to better understand exactly what is happening. Let's suppose you are trying to import two key pairs that have been created with an older version of PGP: PGP2, PGP6, PGP7, PGP8 or other. GPG is warning you, that you are about to include in one of those imported keys ("pss") a set of preferences that your friends *may* use if they match their own set of preferences, and send you an encrypted file that *may not* be compatible with your system. So, for that key ("pss"), it is strongly recommended that you accept the suggested preferences and save them in the key. After that, you extract that public key and send it to servers, in order to update your already uploaded key. That means that people using that key, would not use algorythms that *may not* work. Confused? Me too... :-) - -- Laurent Jumet KeyID: 0xCFAF704C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iHEEAREDADEFAkuOGicqGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB RjcwNEMuYXNjAAoJEPUdbaDPr3BMURMAn12IWL5mayCkEzmFug0DzT0LR3S6AKCu W7a8T07kyCMZqu8jj+0rHD4VwA== =S26d -----END PGP SIGNATURE----- From vedaal at hush.com Wed Mar 3 16:29:37 2010 From: vedaal at hush.com (vedaal at hush.com) Date: Wed, 03 Mar 2010 10:29:37 -0500 Subject: Migrating from PGP to GPG question Message-ID: <20100303152937.C2B962803F@smtp.hushmail.com> On Mar 2, 2010, at 9:18 PM, Smith, Cathy wrote: > gpg: WARNING: key 96B12847 contains preferences for unavailable > gpg: algorithms on these user IDs: > gpg: "pss": preference for cipher algorithm 1 > gpg: it is strongly suggested that you update your preferences and > gpg: re-distribute this key to avoid potential algorithm mismatch > > problems > When I created my gpg keyring, I selected the default for the key, DSA and Elgamml, \ > and a 2048 bit keysize. > What are the ramifications of just saying "yes" to the prompt - update preferences? \ > How potentially serious is the algorithm mismatch? I'd like to better understand \ > exactly what is happening. The problem here is one that PGP users can't fix. No matter what you set the key preferences for, PGP (up through 8.x, don't know about 9.x), will insist on using IDEA when encrypting to this 96B12847 key. It will just do it that way by default, and without the PGP user being able to change it. So, your practical choices are: [1] revoke this key (no problem unless you need to correspond with PGP 2.x users,) [2] configure your GnuPG for IDEA, if PGP users are still going to use this key. (a)get IDEA from here: ftp://ftp.gnupg.dk/pub/contrib-dk/ideadll.zip (b)add this line to your gpg.conf load-extension (wherever you saved idea.dll)\idea.dll (c) type gpg -h and see if IDEA is listed. It should be listed as follows: Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA (S1), 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8), AES256 (S9), TWOFISH (S10), CAMELLIA128 (S11), CAMELLIA192 (S12), CAMELLIA256 (S13) Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9), SHA512 (H10), SHA224 (H11) Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3) (If you have a gnupg version earlier than 1.4.10, Camellia won't be listed.) vedaal From mwood at IUPUI.Edu Wed Mar 3 16:53:51 2010 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 3 Mar 2010 10:53:51 -0500 Subject: key question In-Reply-To: <492760390.20100227003021@my_localhost> References: <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B881338.3060000@grant-olson.net> <108451922.20100226210314@my_localhost> <34B793E5-33EA-432F-8497-D3C85A2622FC@jabberwocky.com> <492760390.20100227003021@my_localhost> Message-ID: <20100303155351.GD28078@IUPUI.Edu> On Sat, Feb 27, 2010 at 12:30:21AM +0000, MFPA wrote: > No impact on the web of trust. But your online presence (and possibly > that of somebody else with the same name) can feed into decisions > about employing you or doing business with you, often/usually made by > people who don't actually understand the information they find. I'm just waiting for a few businesses to be sued for making decisions based on failure to understand what we can actually know about someone from e.g. the signatures that happen to appear on publicly served copies of his certificate. Maybe then they'll wise up. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Friends don't let friends publish revisable-form documents. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mwood at IUPUI.Edu Wed Mar 3 17:16:21 2010 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 3 Mar 2010 11:16:21 -0500 Subject: key question In-Reply-To: <373551548.20100226155327@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> Message-ID: <20100303161621.GE28078@IUPUI.Edu> On Fri, Feb 26, 2010 at 03:53:27PM +0000, MFPA wrote: > There are privacy issues, especially if user-ids on the key contain > email addresses. In some cases, the authorities knowing an individual > used encryption could be a problem. There are issues of tradecraft, then. Using OpenPGP as a tool for committing crimes is kind of stupid. There are more secure methods for a closed community to secure its lines of communication. If one chooses the wrong tool for a job, or chooses to use it incorrectly, no blame attaches to others for the consequences of one's choice. I feel there is a strong assumption among OpenPGP users that our community is, *ahem*, open. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Friends don't let friends publish revisable-form documents. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mwood at IUPUI.Edu Wed Mar 3 18:12:31 2010 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Wed, 3 Mar 2010 12:12:31 -0500 Subject: David's findings In-Reply-To: <6C1005B5-4A06-4B58-92C1-1AAE3C2C5B58@JABBERWOCKY.COM> References: <4459025A-D107-4D97-9EC7-70715B4AA5E1@sixdemonbag.org> <6C1005B5-4A06-4B58-92C1-1AAE3C2C5B58@JABBERWOCKY.COM> Message-ID: <20100303171231.GF28078@IUPUI.Edu> I think this exercise says something about the relative value of attempts to control the distribution of one's personal data, and of power to effectively punish those who abuse one's personal data. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Friends don't let friends publish revisable-form documents. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Mar 3 19:25:04 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 03 Mar 2010 13:25:04 -0500 Subject: key question In-Reply-To: <20100303161621.GE28078@IUPUI.Edu> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <20100303161621.GE28078@IUPUI.Edu> Message-ID: <4B8EA980.8060101@fifthhorseman.net> On 03/03/2010 11:16 AM, Mark H. Wood wrote: > On Fri, Feb 26, 2010 at 03:53:27PM +0000, MFPA wrote: >> There are privacy issues, especially if user-ids on the key contain >> email addresses. In some cases, the authorities knowing an individual >> used encryption could be a problem. > > There are issues of tradecraft, then. Using OpenPGP as a tool for > committing crimes is kind of stupid. Can we not go down this line of argument, please? Not everything that "the authorities" frown on is criminal, and not every action in opposition to the law of some given state is necessarily immoral. I'm sure this isn't true about $yourowncountry, but please consider the situation for citizens of $thatevilcountry. OpenPGP is a tool for encrypted and/or authenticated communications. If we were to declare from the outset that OpenPGP is not (and will never be) a good tool for use by people struggling against oppressive regimes, we would strand a significant proportion of people who have a strong legitimate need for encrypted and authenticated communication. What a waste that would be! > There are more secure methods > for a closed community to secure its lines of communication. If the community in question is a geographically-distributed one, and the tools are used wisely, OpenPGP can actually be a pretty good choice. > I feel there is a strong assumption among OpenPGP users that our > community is, *ahem*, open. Speaking as one user of OpenPGP, I do not share your assumption. The "Open" in OpenPGP refers to the nature of the standard: the standard is public, well-documented, and peer-reviewed. Anyone is free to implement it, and there are public discussions around the nature of the standard itself. The "Open" in OpenPGP does *not* refer to any broader sense of transparency among its userbase, or even a requirement for implementations of the standard itself to be open (GPG is free software, but other implementations of OpenPGP are not). Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From expires2010 at ymail.com Wed Mar 3 19:44:25 2010 From: expires2010 at ymail.com (MFPA) Date: Wed, 3 Mar 2010 18:44:25 +0000 Subject: key question In-Reply-To: <20100303161621.GE28078@IUPUI.Edu> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <20100303161621.GE28078@IUPUI.Edu> Message-ID: <31361393.20100303184425@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Mark On Wednesday 3 March 2010 at 4:16:21 PM, you wrote: > On Fri, Feb 26, 2010 at 03:53:27PM +0000, MFPA wrote: >> There are privacy issues, especially if user-ids on the key contain >> email addresses. In some cases, the authorities knowing an individual >> used encryption could be a problem. > There are issues of tradecraft, then. Using OpenPGP as a tool for > committing crimes is kind of stupid. I was referring to the case where the individual was in a country that prohibited or restricted the use of strong encryption. >If one > chooses the wrong tool for a job, or chooses to use it incorrectly, no > blame attaches to others for the consequences of one's choice. Indeed. > I feel there is a strong assumption among OpenPGP users that our > community is, *ahem*, open. Is it not also a reasonable assumption, that those who use and promote privacy-enhancing software will value and respect privacy? - -- Best regards MFPA mailto:expires2010 at ymail.com Ultimate consistency lies in being consistently inconsistent -----BEGIN PGP SIGNATURE----- iQCVAwUBS46uEqipC46tDG5pAQrv/wP/f+8WNNmA5Pq/GOzNotz2W7ysYMwQhY/P lkCmsoc7yWUa1cKaB4jE5YwzY0q+8jr3/oppnciCr+D8bL/SQS8WFTJNwPccPOIr Yddkfol6/yyQB4rrLWoDAamXpJQLvGkdPdwlynMNOIDEKthLZLDBZuY5LFktdnBy 3N4DEFKOvN4= =rHDV -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Wed Mar 3 19:49:53 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 03 Mar 2010 13:49:53 -0500 Subject: key question In-Reply-To: <4B8EA980.8060101@fifthhorseman.net> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <20100303161621.GE28078@IUPUI.Edu> <4B8EA980.8060101@fifthhorseman.net> Message-ID: <4B8EAF51.3060701@sixdemonbag.org> On 3/3/2010 1:25 PM, Daniel Kahn Gillmor wrote: >> There are issues of tradecraft, then. Using OpenPGP as a tool for >> committing crimes is kind of stupid. > > Can we not go down this line of argument, please? I agree that OpenPGP implementations can be useful tools for the advancement of human rights -- but I also think Mark is (almost) right. It isn't that using OpenPGP implementations to commit crimes is kind of stupid: it's that *naive* use of these implementations is kind of stupid. But that just means OpenPGP implementations are no different than any other kind of tool. > OpenPGP is a tool for encrypted and/or authenticated communications. If > we were to declare from the outset that OpenPGP is not (and will never > be) a good tool for use by people struggling against oppressive regimes, > we would strand a significant proportion of people who have a strong > legitimate need for encrypted and authenticated communication. I fully agree. I would just add that we as a community need to emphasize the importance of good tradecraft, in addition to the importance of email crypto. From rjh at sixdemonbag.org Wed Mar 3 19:52:17 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 03 Mar 2010 13:52:17 -0500 Subject: key question In-Reply-To: <31361393.20100303184425@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <20100303161621.GE28078@IUPUI.Edu> <31361393.20100303184425@my_localhost> Message-ID: <4B8EAFE1.9030307@sixdemonbag.org> On 3/3/2010 1:44 PM, MFPA wrote: >> I feel there is a strong assumption among OpenPGP users that our >> community is, *ahem*, open. > > Is it not also a reasonable assumption, that those who use and promote > privacy-enhancing software will value and respect privacy? It is not reasonable that their definition of privacy will overlap with yours, no. I don't get to define what "privacy" means for anyone other than me. You don't get to define what "privacy" means for anyone other than you. Since there is no shared definition of privacy, there can be no reasonable assumption that people who use and promote what *you define to be* privacy-enhancing software will value and respect privacy *according to your definition*. From expires2010 at ymail.com Wed Mar 3 20:18:56 2010 From: expires2010 at ymail.com (MFPA) Date: Wed, 3 Mar 2010 19:18:56 +0000 Subject: key question In-Reply-To: <4B8EAFE1.9030307@sixdemonbag.org> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <20100303161621.GE28078@IUPUI.Edu> <31361393.20100303184425@my_localhost> <4B8EAFE1.9030307@sixdemonbag.org> Message-ID: <1011930038.20100303191856@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Robert On Wednesday 3 March 2010 at 6:52:17 PM, you wrote: > It is not reasonable that their definition of privacy will overlap with > yours, no. I don't get to define what "privacy" means for anyone other > than me. You don't get to define what "privacy" means for anyone other > than you. > Since there is no shared definition of privacy, there can be no > reasonable assumption that people who use and promote what *you define > to be* privacy-enhancing software will value and respect privacy > *according to your definition*. A good point, well made. - -- Best regards MFPA mailto:expires2010 at ymail.com What's another word for synonym? -----BEGIN PGP SIGNATURE----- iQCVAwUBS462J6ipC46tDG5pAQr/RgP/UNZPYOePwKIZ1/wlu6HXKHwMfrN86i7G hOq8Ms2LYrDf3hfXBgw03/HGFUKjeJzKDDdvpe8dwl49dvvRe/kiKttQfZZLXyBk P17ndPxkyzRW4FlUU2DEbQTfKdmhjOjmpQQuxkSJt15v1Qykt51SvO93yiRRMwO6 qY3e88Mxb2Q= =uprh -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Wed Mar 3 21:30:42 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 3 Mar 2010 15:30:42 -0500 Subject: key question In-Reply-To: <20100303161621.GE28078@IUPUI.Edu> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <20100303161621.GE28078@IUPUI.Edu> Message-ID: On Mar 3, 2010, at 11:16 AM, Mark H. Wood wrote: > On Fri, Feb 26, 2010 at 03:53:27PM +0000, MFPA wrote: >> There are privacy issues, especially if user-ids on the key contain >> email addresses. In some cases, the authorities knowing an individual >> used encryption could be a problem. > > There are issues of tradecraft, then. Using OpenPGP as a tool for > committing crimes is kind of stupid. There are more secure methods > for a closed community to secure its lines of communication. If one > chooses the wrong tool for a job, or chooses to use it incorrectly, no > blame attaches to others for the consequences of one's choice. I basically agree. I'd say it a little differently as "Using OpenPGP as it is commonly used on the net (with keyservers, and signing parties, and such) as a tool for committing crimes is kind of stupid.". I think you could do very well using OpenPGP in a nefarious manner, but you'd have to use it in a different way than it is commonly used on the net. Which is fine - the various OpenPGP implementations are tools, and tools can be used in many different ways, both correctly (meaning "accomplishing what I'm trying to do in a safe and sane way") and incorrectly (meaning "not"). > I feel there is a strong assumption among OpenPGP users that our > community is, *ahem*, open. Yes. Alas. David From sean at srima.ie Wed Mar 3 23:26:31 2010 From: sean at srima.ie (Sean Rima) Date: Wed, 03 Mar 2010 22:26:31 +0000 Subject: Continued PKA problems on Windows Message-ID: <4B8EE217.3050207@srima.ie> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Folks I downloaded and installed gpg4win-2.0.2rc1. I then tested my pka setup using: echo "foo" | gpg2 --no-default-keyring --keyring c:\temp\gpg --encrypt - --armor --auto-key-locate pka -r sean at srima.eu -vvvvv 2> test.txt test.txt showes: gpg: using character set `CP850' gpg: requesting key 688B7D98 from http server www.srima.eu gpg: no valid OpenPGP data found. gpg: Total number processed: 0 gpg: auto-key-locate found fingerprint ADBFF9FBACE1A297D4E399D2C9D7E2DF688B7D98 gpg: error retrieving `sean at srima.eu' via PKA: No public key gpg: sean at srima.eu: skipped: No public key gpg: [stdin]: encryption failed: No public key I followed the instructions to the ketter in guide written by gushi at http://gushi.livejournal.com/524199.html My DNS record is: Record ID: 288882 Record host: sean._pka.srima.eu. Record type: TXT Record data: v=pka1;fpr=ADBFF9FBACE1A297D4E399D2C9D7E2DF688B7D98;uri=http://www.srima.eu/sean.pubkey.txt The only thing I can think is that the site is on Google apps or am I missing something else. I can post my gpg.conf if that helps Sean - -- GSWoT and CaCert WOT Assurer http://www.google.com/profiles/thecivvie .tel http://rima.tel/ I believe that every human has a finite number of heartbeats. I don't intend to waste any of mine running around doing exercises. - Neil Armstrong -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Contact Details http://rima.tel Comment: My GPG Key http://sl.srima.eu/sfr iHIEAREIADIFAkuO4hcrFIAAAAAAFQANcGthLWFkZHJlc3NAZ251cGcub3Jnc2Vh bkBzcmltYS5ldQAKCRDJ1+LfaIt9mG/eAJ9crccgPsTqIGXWIE83Fp32YiSFUwCf YKFIovucACwsJ22SQRktVShrgw4= =ils3 -----END PGP SIGNATURE----- From kgo at grant-olson.net Thu Mar 4 02:31:50 2010 From: kgo at grant-olson.net (Grant Olson) Date: Wed, 03 Mar 2010 20:31:50 -0500 Subject: Continued PKA problems on Windows In-Reply-To: <4B8EE217.3050207@srima.ie> References: <4B8EE217.3050207@srima.ie> Message-ID: <4B8F0D86.8020007@grant-olson.net> On 3/3/2010 5:26 PM, Sean Rima wrote: > Folks > > I downloaded and installed gpg4win-2.0.2rc1. I then tested my pka setup > using: > > echo "foo" | gpg2 --no-default-keyring --keyring c:\temp\gpg --encrypt > --armor --auto-key-locate pka -r sean at srima.eu -vvvvv 2> test.txt > ... > > The only thing I can think is that the site is on Google apps or am I > missing something else. I can post my gpg.conf if that helps > > Sean I noticed two things that may or may not matter... If I open "http://prime.gushi.org/danm.pubkey.txt" in firefox, it opens right in the browser. If I open yours, it opens a "Save As..." window. So they have different content types. Also, the url listed in the firefox "Save as" window is some crazy computer generated url, not www.srima.eu. Just doing a quick test with curl, it takes like 4 302 redirects before you actually get to the file. It wouldn't be totally unsurprising to me if a series of redirects caused problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From danm at prime.gushi.org Thu Mar 4 04:38:44 2010 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Wed, 3 Mar 2010 22:38:44 -0500 (EST) Subject: Continued PKA problems on Windows In-Reply-To: <4B8F0D86.8020007@grant-olson.net> References: <4B8EE217.3050207@srima.ie> <4B8F0D86.8020007@grant-olson.net> Message-ID: On Wed, 3 Mar 2010, Grant Olson wrote: > On 3/3/2010 5:26 PM, Sean Rima wrote: >> Folks >> >> I downloaded and installed gpg4win-2.0.2rc1. I then tested my pka setup >> using: >> >> echo "foo" | gpg2 --no-default-keyring --keyring c:\temp\gpg --encrypt >> --armor --auto-key-locate pka -r sean at srima.eu -vvvvv 2> test.txt >> > > ... > >> >> The only thing I can think is that the site is on Google apps or am I >> missing something else. I can post my gpg.conf if that helps >> >> Sean > > I noticed two things that may or may not matter... > > If I open "http://prime.gushi.org/danm.pubkey.txt" in firefox, it opens > right in the browser. If I open yours, it opens a "Save As..." window. > So they have different content types. > > Also, the url listed in the firefox "Save as" window is some crazy > computer generated url, not www.srima.eu. > > Just doing a quick test with curl, it takes like 4 302 redirects before > you actually get to the file. It wouldn't be totally unsurprising to me > if a series of redirects caused problems. So, if you're interested in comparing apples to apples, for curiosity I just uploaded your pubkey (sean.pubkey.txt) to the same url as danm.pubkey.txt). See if that fixes it, at least for testing. -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From mariocastelancastro at gmail.com Thu Mar 4 05:23:23 2010 From: mariocastelancastro at gmail.com (=?ISO-8859-1?Q?Mario_Castel=E1n_Castro?=) Date: Wed, 3 Mar 2010 22:23:23 -0600 Subject: Continued PKA problems on Windows In-Reply-To: <4B8EE217.3050207@srima.ie> References: <4B8EE217.3050207@srima.ie> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 March 3rd in gnupg-users at gnupg.org, thread "Continued PKA problems on Windows" Sean: get a real operating system as GNU/Linux, see a list of free as in freedom distribucions in http://www.gnu.org/distros/free-distros.html cryptography on a propietary platform don't gives real security, you don't know what they (The owners) are doing with your unencrupted data. Plus, as with any other propietary software it don't respect your freedom, see www.gnu.org. Good luck. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkuPNbYACgkQZ4DA0TLic4gZXQCfQ+XQ2ytkSF2OugqZOcqhoDcx bIAAnRctvNXvgtlTebKsUNXAP0853EfX =o0Jd -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Thu Mar 4 05:47:41 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 3 Mar 2010 23:47:41 -0500 Subject: Continued PKA problems on Windows In-Reply-To: References: <4B8EE217.3050207@srima.ie> Message-ID: <43DDD8A1-11FF-4701-8F82-7F4C86C9FABF@sixdemonbag.org> > Sean: get a real operating system as GNU/Linux Telling someone to change their entire operating system just to resolve a bit of undesired behavior seems pretty extreme. Linux, FreeBSD, etc., all have plenty to recommend themselves without us needing to characterize Windows, Solaris, etc., as not a "real" operating system. For that matter, I'm writing this from a true-blue, certified UNIX: OS X. I think it's quite real, despite the fact major parts of the desktop are closed-source. From sean at srima.ie Thu Mar 4 12:14:06 2010 From: sean at srima.ie (Sean Rima) Date: Thu, 04 Mar 2010 11:14:06 +0000 Subject: Continued PKA problems on Windows In-Reply-To: <4B8F0D86.8020007@grant-olson.net> References: <4B8EE217.3050207@srima.ie> <4B8F0D86.8020007@grant-olson.net> Message-ID: <4B8F95FE.5030201@srima.ie> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2010 01:31, Grant Olson wrote: > On 3/3/2010 5:26 PM, Sean Rima wrote: >> Folks >> >> I downloaded and installed gpg4win-2.0.2rc1. I then tested my pka setup >> using: >> >> echo "foo" | gpg2 --no-default-keyring --keyring c:\temp\gpg --encrypt >> --armor --auto-key-locate pka -r sean at srima.eu -vvvvv 2> test.txt >> > > ... > >> >> The only thing I can think is that the site is on Google apps or am I >> missing something else. I can post my gpg.conf if that helps >> >> Sean > > I noticed two things that may or may not matter... > > If I open "http://prime.gushi.org/danm.pubkey.txt" in firefox, it opens > right in the browser. If I open yours, it opens a "Save As..." window. > So they have different content types. I also noticed this > Also, the url listed in the firefox "Save as" window is some crazy > computer generated url, not www.srima.eu. > > Just doing a quick test with curl, it takes like 4 302 redirects before > you actually get to the file. It wouldn't be totally unsurprising to me > if a series of redirects caused problems. > OK, will have to see if I can upload somewhere else and try that, Google apps is the problem - -- GSWoT and CaCert WOT Assurer http://www.google.com/profiles/thecivvie .tel http://rima.tel/ I believe that every human has a finite number of heartbeats. I don't intend to waste any of mine running around doing exercises. - Neil Armstrong -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Contact Details http://rima.tel Comment: My GPG Key http://sl.srima.eu/sfr iHIEAREIADIFAkuPlf4rFIAAAAAAFQANcGthLWFkZHJlc3NAZ251cGcub3Jnc2Vh bkBzcmltYS5ldQAKCRDJ1+LfaIt9mI9WAJsE/u0FXXUW6zRs6yCzCeyVEng2ygCg hh/sZ3jF+uCsgm4oaBgXB2SrHg0= =TCm2 -----END PGP SIGNATURE----- From sean at srima.ie Thu Mar 4 12:22:01 2010 From: sean at srima.ie (Sean Rima) Date: Thu, 04 Mar 2010 11:22:01 +0000 Subject: Continued PKA problems on Windows In-Reply-To: References: <4B8EE217.3050207@srima.ie> <4B8F0D86.8020007@grant-olson.net> Message-ID: <4B8F97D9.8050304@srima.ie> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2010 03:38, Dan Mahoney, System Admin wrote: > > So, if you're interested in comparing apples to apples, for curiosity I > just uploaded your pubkey (sean.pubkey.txt) to the same url as > danm.pubkey.txt). > > See if that fixes it, at least for testing. > Thanks will try it now but I think it will work as it is google apps that is at fault - -- GSWoT and CaCert WOT Assurer http://www.google.com/profiles/thecivvie .tel http://rima.tel/ I believe that every human has a finite number of heartbeats. I don't intend to waste any of mine running around doing exercises. - Neil Armstrong -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Contact Details http://rima.tel Comment: My GPG Key http://sl.srima.eu/sfr iHIEAREIADIFAkuPl9krFIAAAAAAFQANcGthLWFkZHJlc3NAZ251cGcub3Jnc2Vh bkBzcmltYS5ldQAKCRDJ1+LfaIt9mHoHAJ9sfuL5walTr3Il4z9h3g4IalqJMgCg wQtF+r0kkfh2tO53GLloAffmdCs= =A+OC -----END PGP SIGNATURE----- From sean at srima.ie Thu Mar 4 12:27:58 2010 From: sean at srima.ie (Sean Rima) Date: Thu, 04 Mar 2010 11:27:58 +0000 Subject: Continued PKA problems on Windows In-Reply-To: References: <4B8EE217.3050207@srima.ie> Message-ID: <4B8F993E.900@srima.ie> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2010 04:23, Mario Castel?n Castro wrote: > March 3rd in gnupg-users at gnupg.org, thread "Continued PKA problems on > Windows" > > Sean: get a real operating system as GNU/Linux, see a list of free as > in freedom distribucions in > http://www.gnu.org/distros/free-distros.html > > cryptography on a propietary platform don't gives real security, you > don't know what they (The owners) are doing with your unencrupted > data. > > Plus, as with any other propietary software it don't respect your > freedom, see www.gnu.org. > I am a long time SuSE user but due to various hardware constraints, I cannot use it on my main pc. I have 2 linux boxes running other apps (Fidonet). I did put Linux on the main box but lost use of my iPod Touch. Now I am changing to a general MP3 player so will try again - -- GSWoT and CaCert WOT Assurer http://www.google.com/profiles/thecivvie .tel http://rima.tel/ I believe that every human has a finite number of heartbeats. I don't intend to waste any of mine running around doing exercises. - Neil Armstrong -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Contact Details http://rima.tel Comment: My GPG Key http://sl.srima.eu/sfr iHIEAREIADIFAkuPmT4rFIAAAAAAFQANcGthLWFkZHJlc3NAZ251cGcub3Jnc2Vh bkBzcmltYS5ldQAKCRDJ1+LfaIt9mPM1AJ9QZ7Y9/+8DYiv9yJU+YmBoxasfjgCd FN9p2QlUUyGfodG77U4pxrzT1OQ= =PJa1 -----END PGP SIGNATURE----- From sean at srima.ie Thu Mar 4 12:31:46 2010 From: sean at srima.ie (Sean Rima) Date: Thu, 04 Mar 2010 11:31:46 +0000 Subject: Continued PKA problems on Windows In-Reply-To: <4B8F0D86.8020007@grant-olson.net> References: <4B8EE217.3050207@srima.ie> <4B8F0D86.8020007@grant-olson.net> Message-ID: <4B8F9A22.90301@srima.ie> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2010 01:31, Grant Olson wrote: > Also, the url listed in the firefox "Save as" window is some crazy > computer generated url, not www.srima.eu. > > Just doing a quick test with curl, it takes like 4 302 redirects before > you actually get to the file. It wouldn't be totally unsurprising to me > if a series of redirects caused problems. > I tried dan's link and then uploaded a copy to my fastmail.fm account result: C:\Users\Sean>echo "foo" | gpg2 --no-default-keyring --keyring c:\temp\gpg --encrypt --armour --auto-key-locate pka -r sean at srima.ie gpg: requesting key 688B7D98 from http server thecivvie.fastmail.fm gpg: key 688B7D98: public key "Sean Rima (Sean's Key) " imported gpg: no need for a trustdb check with `always' trust model gpg: Total number processed: 1 gpg: imported: 1 gpg: automatically retrieved `sean at srima.ie' via PKA So I have have PKA working, and now to setup CERT :) I will continue to test Thanks to all Sean - -- GSWoT and CaCert WOT Assurer http://www.google.com/profiles/thecivvie .tel http://rima.tel/ I believe that every human has a finite number of heartbeats. I don't intend to waste any of mine running around doing exercises. - Neil Armstrong -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Contact Details http://rima.tel Comment: My GPG Key http://sl.srima.eu/sfr iHIEAREIADIFAkuPmiIrFIAAAAAAFQANcGthLWFkZHJlc3NAZ251cGcub3Jnc2Vh bkBzcmltYS5ldQAKCRDJ1+LfaIt9mOLoAKDKuNBkssTdkx404XxyNItgvBvMjQCg iyILLm2r+ge5ZHwDYF4wpXMVqZs= =saXS -----END PGP SIGNATURE----- From firasmr786 at gmail.com Thu Mar 4 14:18:46 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Thu, 4 Mar 2010 18:48:46 +0530 Subject: Changing & verifying the --max-cert-depth in Windows Message-ID: Hi, I have installed the CLI version of GPG. I understand that GPG options have to be set in a configuration file. The configuration file can be created if it doesn't exist as per a previous thread here http://lists.gnupg.org/pipermail/gnupg-users/2008-December/035146.html I added the following line in my gpg.conf : max-cert-depth 3 And then ran: gpg --update-trustdb And then: gpg --check-trustdb And here's the output of the last command: gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: next trustdb check due at 2011-03-03 It mentions that the --marginals-needed option is set to 3. And --completes-needed option is set to 1. Which I think I'm okay with. But the depth mentioned is 0! Why hasn't it changed? And how do I verify my current --max-cert-depth value? From mwood at IUPUI.Edu Thu Mar 4 18:25:09 2010 From: mwood at IUPUI.Edu (Mark H. Wood) Date: Thu, 4 Mar 2010 12:25:09 -0500 Subject: key question In-Reply-To: <31361393.20100303184425@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <20100303161621.GE28078@IUPUI.Edu> <31361393.20100303184425@my_localhost> Message-ID: <20100304172509.GC16237@IUPUI.Edu> On Wed, Mar 03, 2010 at 06:44:25PM +0000, MFPA wrote: > On Wednesday 3 March 2010 at 4:16:21 PM, you wrote: > > On Fri, Feb 26, 2010 at 03:53:27PM +0000, MFPA wrote: > >> There are privacy issues, especially if user-ids on the key contain > >> email addresses. In some cases, the authorities knowing an individual > >> used encryption could be a problem. > > > There are issues of tradecraft, then. Using OpenPGP as a tool for > > committing crimes is kind of stupid. > > I was referring to the case where the individual was in a country that > prohibited or restricted the use of strong encryption. Yes, I thought that was what you meant. If the state in which one communicates prohibits encrypted communication, and one communicates over an encrypted channel, then one has already committed one crime (in the eyes of that state), whatever the content or purpose of the communication may have been. Were I the individual, I would think long and hard about using a tool which would require me to defeat its features that create identity labels (however false or information-poor) and carry them along with the message. I would be drawn toward tools whose methods carry no identity data themselves. You can't accidentally misuse a feature that isn't there. -- Mark H. Wood, Lead System Programmer mwood at IUPUI.Edu Friends don't let friends publish revisable-form documents. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Mar 4 18:45:44 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Mar 2010 12:45:44 -0500 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: References: Message-ID: <4B8FF1C8.1080906@fifthhorseman.net> On 03/04/2010 08:18 AM, erythrocyte wrote: > And here's the output of the last command: > > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: next trustdb check due at 2011-03-03 > > It mentions that the --marginals-needed option is set to 3. And > --completes-needed option is set to 1. Which I think I'm okay with. > But the depth mentioned is 0! > > Why hasn't it changed? And how do I verify my current --max-cert-depth value? I think you're not reading that data the way that it was intended to be read. (this is not your fault, the docs are pretty thin). That line says "of the certificates that are depth 0 from you (meaning they effectively *are* you), there is exactly one valid OpenPGP cert, and it has been granted ultimate ownertrust" -- this is a description of *your own key*, actually. the "signed: 0" bit suggests that your key has made no certifications over the userIDs of any other OpenPGP key. When i run gpg --check-trustdb, i get an additional line of output: 0 dkg at pip:~$ gpg --check-trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 83 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: depth: 1 valid: 83 signed: 128 trust: 70-, 1q, 1n, 10m, 1f, 0u gpg: next trustdb check due at 2010-03-07 0 dkg at pip:~$ So my first line (depth: 0) looks similar to yours, but points out that my key has made certifications over the userIDs of 83 other keys. that second line (depth: 1) says: of the certificates that are 1 hop away from you, 83 of them are known to be valid (these are the same 83 that i've personally certified). none of them have ultimate ownertrust (otherwise that key would be listed in the depth: 0 line), one of them has full ownertrust ("1f'), 10 have marginal ownertrust ("10m"), 1 has explicitly *no* ownertrust ("1n"), 70 i've never bothered to state ownertrust ("70-"), and 1 has explicitly-stated "undefined" ownertrust ("1q" -- i'm not really sure how this is different). I'm also not sure what the "signed: 128" suggests in the "depth: 1" line. Surely of all 83 keys i've certified, they have collectively issued more than 128 certifications themselves. maybe someone else can explain that bit? so, your max-depth is being respected -- you're nowhere near 3 hops away from your key. in fact, it looks like you've issued no ownertrust to any key other than yourself, so changing the max depth won't have any current effect. ------------------------ Here's my understanding: * when you certify the userID of a key, you're saying you believe that the real-world entity referred to by the User ID does in fact control the secret part of the key. * in particular, you say *nothing* about whether you feel you can rely on certifications made by that key. * internally to GPG, you can also assign a level of "ownertrust" to any given key -- this tells your OpenPGP toolset how much you you are willing to believe certifications made by that key. * Your own key is marked by default as having "ultimate" ownertrust, which means that any userID/key combo certified by your key will be considered to be valid. * Note that GPG will not apply ownertrust to a key (even if you've specified it) unless it already believes that at least one User ID on that key is valid. So to reach a depth of 2, you'd have to have assigned ownertrust to at least one key that you had not personally certified (but was certified by other keys in which you've placed ownertrust). To reach a depth of 3, you'd have to have assigned ownertrust to one of the keys that are depth 2 from you, etc. hope this helps, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Thu Mar 4 18:51:32 2010 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 04 Mar 2010 12:51:32 -0500 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: References: Message-ID: <4B8FF324.1020704@grant-olson.net> On 3/4/2010 8:18 AM, erythrocyte wrote: > > And then: > > gpg --check-trustdb > > And here's the output of the last command: > > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: next trustdb check due at 2011-03-03 > > It mentions that the --marginals-needed option is set to 3. And > --completes-needed option is set to 1. Which I think I'm okay with. > But the depth mentioned is 0! > > Why hasn't it changed? And how do I verify my current --max-cert-depth value? > If you haven't signed any keys, then there's nowhere to go. The certificate depth starts with keys you've signed. Then it looks at the keys those keys have signed. Etc. Etc. Since you haven't signed any keys, the chain of trust doesn't have anywhere to begin. So it's showing that the only key you trust is your own, that's the 1u, and that's at the zeroth level of certificate depth. If you want to test, sign a few keys with the local non-exportable option and you'll see depth: 1 and possibly more. Or maybe locally sign something like the PGP Global Directory key, or configure the gswot keys. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Thu Mar 4 19:01:42 2010 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 04 Mar 2010 13:01:42 -0500 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: <4B8FF1C8.1080906@fifthhorseman.net> References: <4B8FF1C8.1080906@fifthhorseman.net> Message-ID: <4B8FF586.7010804@grant-olson.net> On 3/4/2010 12:45 PM, Daniel Kahn Gillmor wrote: > > I'm also not sure what the "signed: 128" suggests in the "depth: 1" > line. Surely of all 83 keys i've certified, they have collectively > issued more than 128 certifications themselves. maybe someone else can > explain that bit? > I believe that's the number of keys they've signed that are in your keyring. The signature attaches to the recipient's key, not the signer's. So if you don't have the recipient's key in your keyring, you don't even know it's been signed by one of the keys you've certified. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Mar 4 19:12:31 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Mar 2010 13:12:31 -0500 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: References: Message-ID: <73354575-D34D-449D-8F64-3FCCBE67919A@jabberwocky.com> On Mar 4, 2010, at 8:18 AM, erythrocyte wrote: > Hi, > > I have installed the CLI version of GPG. > > I understand that GPG options have to be set in a configuration file. > The configuration file can be created if it doesn't exist as per a > previous thread here > > http://lists.gnupg.org/pipermail/gnupg-users/2008-December/035146.html > > I added the following line in my gpg.conf : > > max-cert-depth 3 > > And then ran: > > gpg --update-trustdb > > And then: > > gpg --check-trustdb > > And here's the output of the last command: > > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: next trustdb check due at 2011-03-03 > > It mentions that the --marginals-needed option is set to 3. And > --completes-needed option is set to 1. Which I think I'm okay with. > But the depth mentioned is 0! I suspect you don't have any ultimately trusted keys to build your trustdb from. Run gpg --edit-key on your own key and set the trust to ultimate. Then try the --update-trustdb again. GPG will then follow the paths from your key, to keys you have signed, to keys they have signed, etc. David From dkg at fifthhorseman.net Thu Mar 4 19:20:30 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Mar 2010 13:20:30 -0500 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: <73354575-D34D-449D-8F64-3FCCBE67919A@jabberwocky.com> References: <73354575-D34D-449D-8F64-3FCCBE67919A@jabberwocky.com> Message-ID: <4B8FF9EE.7080806@fifthhorseman.net> On 03/04/2010 01:12 PM, David Shaw wrote: > On Mar 4, 2010, at 8:18 AM, erythrocyte wrote: >> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model >> gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u >> gpg: next trustdb check due at 2011-03-03 > > I suspect you don't have any ultimately trusted keys to build your trustdb from. doesn't the "1u" in the output above indicate that he does have an ultimately-trusted key? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Mar 4 19:22:28 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Mar 2010 13:22:28 -0500 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: <4B8FF9EE.7080806@fifthhorseman.net> References: <73354575-D34D-449D-8F64-3FCCBE67919A@jabberwocky.com> <4B8FF9EE.7080806@fifthhorseman.net> Message-ID: <95078265-4610-46D8-9DF3-EDEFFAF4CF6F@jabberwocky.com> On Mar 4, 2010, at 1:20 PM, Daniel Kahn Gillmor wrote: > On 03/04/2010 01:12 PM, David Shaw wrote: >> On Mar 4, 2010, at 8:18 AM, erythrocyte wrote: >>> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model >>> gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u >>> gpg: next trustdb check due at 2011-03-03 >> >> I suspect you don't have any ultimately trusted keys to build your trustdb from. > > doesn't the "1u" in the output above indicate that he does have an > ultimately-trusted key? Oops - quite right. I read it too fast. Change that to: "I suspect you haven't signed any other keys *with* your ultimately trusted key". David From firasmr786 at gmail.com Thu Mar 4 19:14:36 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Thu, 04 Mar 2010 23:44:36 +0530 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: <4B8FF1C8.1080906@fifthhorseman.net> References: <4B8FF1C8.1080906@fifthhorseman.net> Message-ID: <4B8FF88C.6010208@gmail.com> On 3/4/2010 11:15 PM, Daniel Kahn Gillmor wrote: > On 03/04/2010 08:18 AM, erythrocyte wrote: >> And here's the output of the last command: >> >> gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model >> gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u >> gpg: next trustdb check due at 2011-03-03 >> >> It mentions that the --marginals-needed option is set to 3. And >> --completes-needed option is set to 1. Which I think I'm okay with. >> But the depth mentioned is 0! >> >> Why hasn't it changed? And how do I verify my current --max-cert-depth value? > > I think you're not reading that data the way that it was intended to be > read. (this is not your fault, the docs are pretty thin). > > That line says "of the certificates that are depth 0 from you (meaning > they effectively *are* you), there is exactly one valid OpenPGP cert, > and it has been granted ultimate ownertrust" -- this is a description of > *your own key*, actually. the "signed: 0" bit suggests that your key > has made no certifications over the userIDs of any other OpenPGP key. > > When i run gpg --check-trustdb, i get an additional line of output: > > 0 dkg at pip:~$ gpg --check-trustdb > gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model > gpg: depth: 0 valid: 1 signed: 83 trust: 0-, 0q, 0n, 0m, 0f, 1u > gpg: depth: 1 valid: 83 signed: 128 trust: 70-, 1q, 1n, 10m, 1f, 0u > gpg: next trustdb check due at 2010-03-07 > 0 dkg at pip:~$ > > So my first line (depth: 0) looks similar to yours, but points out that > my key has made certifications over the userIDs of 83 other keys. > > that second line (depth: 1) says: > > of the certificates that are 1 hop away from you, 83 of them are known > to be valid (these are the same 83 that i've personally certified). > none of them have ultimate ownertrust (otherwise that key would be > listed in the depth: 0 line), one of them has full ownertrust ("1f'), 10 > have marginal ownertrust ("10m"), 1 has explicitly *no* ownertrust > ("1n"), 70 i've never bothered to state ownertrust ("70-"), and 1 has > explicitly-stated "undefined" ownertrust ("1q" -- i'm not really sure > how this is different). > > I'm also not sure what the "signed: 128" suggests in the "depth: 1" > line. Surely of all 83 keys i've certified, they have collectively > issued more than 128 certifications themselves. maybe someone else can > explain that bit? > > > so, your max-depth is being respected -- you're nowhere near 3 hops away > from your key. in fact, it looks like you've issued no ownertrust to > any key other than yourself, so changing the max depth won't have any > current effect. > Thanks! That makes perfect sense :) . > ------------------------ > > Here's my understanding: > > * when you certify the userID of a key, you're saying you believe that > the real-world entity referred to by the User ID does in fact control > the secret part of the key. > > * in particular, you say *nothing* about whether you feel you can rely > on certifications made by that key. > > * internally to GPG, you can also assign a level of "ownertrust" to any > given key -- this tells your OpenPGP toolset how much you you are > willing to believe certifications made by that key. > > * Your own key is marked by default as having "ultimate" ownertrust, > which means that any userID/key combo certified by your key will be > considered to be valid. > > * Note that GPG will not apply ownertrust to a key (even if you've > specified it) unless it already believes that at least one User ID on > that key is valid. > > > > So to reach a depth of 2, you'd have to have assigned ownertrust to at > least one key that you had not personally certified (but was certified > by other keys in which you've placed ownertrust). To reach a depth of > 3, you'd have to have assigned ownertrust to one of the keys that are > depth 2 from you, etc. > > hope this helps, > > --dkg > Thanks for the explanation. I think some bits of this can to be added to the GnuPG Handbook. The section on web of trusts lacks some much needed clarity. Going over what you said, I think I'll be happy with a --max-cert-depth of 2 :) . -- erythrocyte From reynt0 at cs.albany.edu Thu Mar 4 20:59:03 2010 From: reynt0 at cs.albany.edu (reynt0) Date: Thu, 4 Mar 2010 14:59:03 -0500 (EST) Subject: Continued PKA problems on Windows In-Reply-To: <43DDD8A1-11FF-4701-8F82-7F4C86C9FABF@sixdemonbag.org> References: <4B8EE217.3050207@srima.ie> <43DDD8A1-11FF-4701-8F82-7F4C86C9FABF@sixdemonbag.org> Message-ID: On Wed, 3 Mar 2010, Robert J. Hansen wrote: . . . > system. For that matter, I'm writing this from a true-blue, > certified UNIX: OS X. I think it's quite real, despite the > fact major parts of the desktop are closed-source. And despite, sadly, that the EULA for OS10.4+ (like WinXP+, IIUC) requires the user to agree to allow the OS proprietor and friends to access the computer, and pull any info, and maybe alter the contents of the computer, unlike the GNU/Linuxes and AFAIK other usual *nixes. Which MCC may have had in mind though not stating it explicitly, and is worth keeping in mind when the context is privacy and security as crypto presumably is. (Not looking to get into any browser wars, just thinking of a security issue always worth having in mind.) From dkg at fifthhorseman.net Thu Mar 4 21:52:59 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Mar 2010 15:52:59 -0500 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: <4B8FF586.7010804@grant-olson.net> References: <4B8FF1C8.1080906@fifthhorseman.net> <4B8FF586.7010804@grant-olson.net> Message-ID: <4B901DAB.7070401@fifthhorseman.net> On 03/04/2010 01:01 PM, Grant Olson wrote: > On 3/4/2010 12:45 PM, Daniel Kahn Gillmor wrote: >> I'm also not sure what the "signed: 128" suggests in the "depth: 1" >> line. Surely of all 83 keys i've certified, they have collectively >> issued more than 128 certifications themselves. maybe someone else can >> explain that bit? > > I believe that's the number of keys they've signed that are in your > keyring. The signature attaches to the recipient's key, not the > signer's. So if you don't have the recipient's key in your keyring, you > don't even know it's been signed by one of the keys you've certified. I've got a large-ish keyring (>1300 keys), and it's fairly regularly refreshed. i'm pretty sure that of the 83 keys that i've signed, they've made more than 128 certifications in aggregate, even if we only count keys themselves and not UIDs (that is, even if a key with multiple certified User IDs only counts once). Is there another explanation? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Mar 4 23:22:44 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Mar 2010 17:22:44 -0500 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: <4B901DAB.7070401@fifthhorseman.net> References: <4B8FF1C8.1080906@fifthhorseman.net> <4B8FF586.7010804@grant-olson.net> <4B901DAB.7070401@fifthhorseman.net> Message-ID: <84E907CC-DAEA-4FF4-A1E7-924FBEAAA509@jabberwocky.com> On Mar 4, 2010, at 3:52 PM, Daniel Kahn Gillmor wrote: > On 03/04/2010 01:01 PM, Grant Olson wrote: >> On 3/4/2010 12:45 PM, Daniel Kahn Gillmor wrote: >>> I'm also not sure what the "signed: 128" suggests in the "depth: 1" >>> line. Surely of all 83 keys i've certified, they have collectively >>> issued more than 128 certifications themselves. maybe someone else can >>> explain that bit? >> >> I believe that's the number of keys they've signed that are in your >> keyring. The signature attaches to the recipient's key, not the >> signer's. So if you don't have the recipient's key in your keyring, you >> don't even know it's been signed by one of the keys you've certified. > > I've got a large-ish keyring (>1300 keys), and it's fairly regularly > refreshed. i'm pretty sure that of the 83 keys that i've signed, > they've made more than 128 certifications in aggregate, even if we only > count keys themselves and not UIDs (that is, even if a key with multiple > certified User IDs only counts once). The "signed" value only counts signatures made on keys that you have in your keyring. Those 83 keys may have made more certifications, but you don't have local copies of the other keys that they may have signed. David From kgo at grant-olson.net Thu Mar 4 22:33:44 2010 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 04 Mar 2010 16:33:44 -0500 Subject: Changing & verifying the --max-cert-depth in Windows In-Reply-To: <4B901DAB.7070401@fifthhorseman.net> References: <4B8FF1C8.1080906@fifthhorseman.net> <4B8FF586.7010804@grant-olson.net> <4B901DAB.7070401@fifthhorseman.net> Message-ID: <4B902738.8050202@grant-olson.net> On 3/4/2010 3:52 PM, Daniel Kahn Gillmor wrote: > On 03/04/2010 01:01 PM, Grant Olson wrote: >> On 3/4/2010 12:45 PM, Daniel Kahn Gillmor wrote: >>> I'm also not sure what the "signed: 128" suggests in the "depth: 1" >>> line. Surely of all 83 keys i've certified, they have collectively >>> issued more than 128 certifications themselves. maybe someone else can >>> explain that bit? >> >> I believe that's the number of keys they've signed that are in your >> keyring. The signature attaches to the recipient's key, not the >> signer's. So if you don't have the recipient's key in your keyring, you >> don't even know it's been signed by one of the keys you've certified. > > I've got a large-ish keyring (>1300 keys), and it's fairly regularly > refreshed. i'm pretty sure that of the 83 keys that i've signed, > they've made more than 128 certifications in aggregate, even if we only > count keys themselves and not UIDs (that is, even if a key with multiple > certified User IDs only counts once). > > Is there another explanation? > > --dkg > But out of those 83, only 11 have marginal or full trust, right? A signature isn't valid (for you) if they key isn't marginally or fully trusted to begin with. Would you buy that number from the 11 valid and trusted keys? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From nboullis at debian.org Thu Mar 4 22:34:04 2010 From: nboullis at debian.org (Nicolas Boullis) Date: Thu, 4 Mar 2010 22:34:04 +0100 Subject: manipulating the set of keys that can decrypt a file/message Message-ID: <20100304213357.GB4042@debian> Hi, Some time ago, I decided to revoke my old ElGamal encryption key and replace it with a new RSA one, that I keep stored on a smartcard. (The goal is to be ale to decrypt some messages/files with my laptop, but not have my keys compromised if it gets lost/stolen.) The trouble is that I have a bunch of old messages/files, encrypted fr my old ElGamal key: I can't decrypt them on my laptop usig my smartcard. So now, on a machine that has my old ElGamal secret key, I'd like to modify those messages/files to make it possible to decrypt them using my new RSA key. I don't like the naive solution "gpg --decrypt | gpg --encrypt" because: - I would lose the signatures of messages/files that are both encrypted and signed, - it requires to decrypt/encrypt the whole data whie it should be sufficient to decrypt/encrypt the session key. Reading RFC 4880 (OpenPGP standard), if I am able to decrypt the session key, it should be possible to create a new Public-Key Encrypted Session Key packet to allow a new key to decrypt the file/message. Removing a Public-Key Encrypted Session Key should also be trivial. Does gnupg allow such manipulations? Or does anyone have suggestions how I should implement this? Libraries to use? I imagine such manipulations might also be interesting for things like encryped mailing-lists... Regards, -- Nicolas Boullis, happy gnupg user for more than 8 years -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: Digital signature URL: From dshaw at jabberwocky.com Fri Mar 5 00:13:17 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 4 Mar 2010 18:13:17 -0500 Subject: manipulating the set of keys that can decrypt a file/message In-Reply-To: <20100304213357.GB4042@debian> References: <20100304213357.GB4042@debian> Message-ID: <0130E455-35DE-4BD1-87AF-1411F6143E37@jabberwocky.com> On Mar 4, 2010, at 4:34 PM, Nicolas Boullis wrote: > Hi, > > Some time ago, I decided to revoke my old ElGamal encryption key and > replace it with a new RSA one, that I keep stored on a smartcard. (The > goal is to be ale to decrypt some messages/files with my laptop, but not > have my keys compromised if it gets lost/stolen.) > > The trouble is that I have a bunch of old messages/files, encrypted fr > my old ElGamal key: I can't decrypt them on my laptop usig my smartcard. > > So now, on a machine that has my old ElGamal secret key, I'd like to > modify those messages/files to make it possible to decrypt them using my > new RSA key. > > I don't like the naive solution "gpg --decrypt | gpg --encrypt" because: > - I would lose the signatures of messages/files that are both encrypted > and signed, > - it requires to decrypt/encrypt the whole data whie it should be > sufficient to decrypt/encrypt the session key. > > Reading RFC 4880 (OpenPGP standard), if I am able to decrypt the session > key, it should be possible to create a new Public-Key Encrypted Session > Key packet to allow a new key to decrypt the file/message. Removing a > Public-Key Encrypted Session Key should also be trivial. Yes. > Does gnupg allow such manipulations? No. > Or does anyone have suggestions how I should implement this? Libraries > to use? You might be able to hack something together using the GnuPG sources. Certainly all of the parts you need are in there - you'd just have to put them together. Alternately, take a look at http://openpgp.nominet.org.uk/cgi-bin/trac.cgi for a library that you might also borrow some code from. David From cathy.smith at pnl.gov Fri Mar 5 07:50:01 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Thu, 4 Mar 2010 22:50:01 -0800 Subject: Migrating from PGP to GPG question References: <4A009880.8090807@christiantena.net> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B795FE5C@EMAIL04.pnl.gov> Folks This may related to my earlier question about signing the imported PGP public keys. When I run gpg --list-sig, the imported public keys show that they are signed. However, when I run a test to encrypt a file with a key, I get the following message: [ir at hrapp1 /tmp]$ gpg -e -r 0xEC3A911C gpg-test gpg: 52F8B69A: There is no assurance this key belongs to the named user pub 2048R/52F8B69A 2010-02-19 People Primary key fingerprint: C266 62C7 CA69 E6C7 9897 CAB1 3A4F C1XE E53A 0N1A Subkey fingerprint: 8943 8C7D 0626 11D9 4B33 A6720 55X5 B338 52H8 B29A It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y I've tried using the --yes option without success to suppress this interactive prompt doesn't pop up. This encryption does need to run in a batch job. What do I need to do in order all interactive prompts are surpressed, and that the assumption is they are answered "yes". I may not understand signing a key properly. It did occur to me as I wrote this email and my earlier posting tonight that I may need to generate a new signature key and re-sign the keys in GPG. I haven't had a chance to try that tonight. Here is the output of the gpg --list-sig: [ir at hrapp1 /tmp]$ gpg --list-sig /home/ir/.gnupg/pubring.gpg -------------------------------- pub 1024D/F43A8497 2010-03-03 [expires: 2020-02-29] uid PNNL sig 3 F43B8497 2010-03-03 PNNL sub 2048g/EA223A5A 2010-03-03 [expires: 2020-02-29] sig F43C6997 2010-03-03 PNNL pub 2048R/EC3A911A 2010-01-19 uid People sig N EC3A911A 2010-01-19 People sig 733B4F7A 2010-01-19 ir sub 2048R/5278B69A 2010-01-19 sig EC3B014A 2010-01-19 People Disclaimer: I've changed the id's and names to protect the innocent. If my key id's are mismatched, it's just the sanitization. Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: Smith, Cathy Sent: Wednesday, February 24, 2010 6:47 PM To: gnupg-users at gnupg.org Subject: Migrating from PGP to GPG question Folks We are starting to migrate from OpenPGP to GnuPG. One of the batch jobs I have to convert uses: pgp +force This is supposed to assume a "yes" to any interactive questions. I wasn't clear after reading the man pages about the gpg --batch option. Can someone tell me if the --batch and the --yes options are mutually exclusive? Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov From cathy.smith at pnl.gov Fri Mar 5 07:09:11 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Thu, 4 Mar 2010 22:09:11 -0800 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B795F253@EMAIL04.pnl.gov> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> <70086D201BD484439914C36F5C8BF16101A1B795F253@EMAIL04.pnl.gov> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B795FE5A@EMAIL04.pnl.gov> Folks I'm at the next step. The PGP public keys imported without a problem. However, they are not signed any more. Would it be better if I created a new signing key to use? Thanks for your help. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Smith, Cathy Sent: Thursday, February 25, 2010 2:18 PM To: gnupg-users at gnupg.org Subject: RE: Migrating from PGP to GPG question Folks Another question about this migration. Is it possible to do a mass import of a single user's keyring or do I have to do it for each individual key. I've not been able to find anything so far about anything that addresses this. Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Smith, Cathy Sent: Wednesday, February 24, 2010 6:47 PM To: gnupg-users at gnupg.org Subject: Migrating from PGP to GPG question Folks We are starting to migrate from OpenPGP to GnuPG. One of the batch jobs I have to convert uses: pgp +force This is supposed to assume a "yes" to any interactive questions. I wasn't clear after reading the man pages about the gpg --batch option. Can someone tell me if the --batch and the --yes options are mutually exclusive? Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From cathy.smith at pnl.gov Fri Mar 5 07:30:37 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Thu, 4 Mar 2010 22:30:37 -0800 Subject: Migrating from PGP to GPG question References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> <70086D201BD484439914C36F5C8BF16101A1B795F253@EMAIL04.pnl.gov> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B795FE5B@EMAIL04.pnl.gov> Correction to this email. The gpg --list-sig shows that the keys are signed. Do I need to create a new signature key, and re-sign all the public keys that I imported? Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: Smith, Cathy Sent: Thursday, March 04, 2010 10:09 PM To: gnupg-users at gnupg.org Subject: RE: Migrating from PGP to GPG question Folks I'm at the next step. The PGP public keys imported without a problem. However, they are not signed any more. Would it be better if I created a new signing key to use? Thanks for your help. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Smith, Cathy Sent: Thursday, February 25, 2010 2:18 PM To: gnupg-users at gnupg.org Subject: RE: Migrating from PGP to GPG question Folks Another question about this migration. Is it possible to do a mass import of a single user's keyring or do I have to do it for each individual key. I've not been able to find anything so far about anything that addresses this. Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Smith, Cathy Sent: Wednesday, February 24, 2010 6:47 PM To: gnupg-users at gnupg.org Subject: Migrating from PGP to GPG question Folks We are starting to migrate from OpenPGP to GnuPG. One of the batch jobs I have to convert uses: pgp +force This is supposed to assume a "yes" to any interactive questions. I wasn't clear after reading the man pages about the gpg --batch option. Can someone tell me if the --batch and the --yes options are mutually exclusive? Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From laurent.jumet at skynet.be Fri Mar 5 08:28:43 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Fri, 05 Mar 2010 08:28:43 +0100 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B795FE5C@EMAIL04.pnl.gov> Message-ID: Hello Smith, ! "Smith, Cathy" wrote: > I've tried using the --yes option without success to suppress this > interactive prompt doesn't pop up. This encryption does need to run in a > batch job. What do I need to do in order all interactive prompts are > surpressed, and that the assumption is they are answered "yes". Try using: --batch --yes --no-tty -- Laurent Jumet KeyID: 0xCFAF704C From jmoore3rd at bellsouth.net Fri Mar 5 13:39:23 2010 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri, 05 Mar 2010 07:39:23 -0500 Subject: Migrating from PGP to GPG question In-Reply-To: References: Message-ID: <4B90FB7B.3060705@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Laurent Jumet wrote: > > Hello Smith, ! > > "Smith, Cathy" wrote: > >> I've tried using the --yes option without success to suppress this >> interactive prompt doesn't pop up. This encryption does need to run in a >> batch job. What do I need to do in order all interactive prompts are >> surpressed, and that the assumption is they are answered "yes". > > Try using: > --batch > --yes > --no-tty Why not try adding to gpg.conf trust-model always This will suppress the prompt/warning as well. Of course, since the Keys still have their Signatures Cathy could always rebuild the Trustdb. JOHN ;) Timestamp: Friday 05 Mar 2010, 07:39 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJLkPt5AAoJEBCGy9eAtCsPyqQIAJkQ2GW6nYRWmhA2g2jrYbJ4 sy5fuPSXS5jn+c8yoTO5vDpJK4ibdqGF4zghzsRP7FhSKxehYCdqHm1nYT7Kge8+ OwdCL2F6hwIZ4Dui+cHBaSXc6MCY5rKVCoKWduXDiNMU77D0aD4wI007rITlhRJh qs1KNZraV1416/rM4udjTUQqqNl8+YVlF9YQ8o+UzVQ81wVgKkWJAOihYxnAX8xI JpAkrVR2zIIKKq1bq9Q6v1uXn/08V4GnylRBQaOtOoyozODm/urlyM++lMkdNj/x iiJ445n9yUsc4H+MN2+wIza3/LDNV4S3YxgpVsjTSlr4Svw1bcnUOJXMpWAQyvM= =Dq6B -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Fri Mar 5 14:59:54 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 5 Mar 2010 08:59:54 -0500 Subject: Migrating from PGP to GPG question In-Reply-To: <4B90FB7B.3060705@bellsouth.net> References: <4B90FB7B.3060705@bellsouth.net> Message-ID: <227BB6DA-F164-4E17-AE3E-825842D97765@jabberwocky.com> On Mar 5, 2010, at 7:39 AM, John W. Moore III wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Laurent Jumet wrote: >> >> Hello Smith, ! >> >> "Smith, Cathy" wrote: >> >>> I've tried using the --yes option without success to suppress this >>> interactive prompt doesn't pop up. This encryption does need to run in a >>> batch job. What do I need to do in order all interactive prompts are >>> surpressed, and that the assumption is they are answered "yes". >> >> Try using: >> --batch >> --yes >> --no-tty > > Why not try adding to gpg.conf > > trust-model always > > This will suppress the prompt/warning as well. This would be my advice as well. The web of trust is generally a useful thing, but in environments where the keys are only provided by the batch owner, it does not add much that is useful to the equation. David From nboullis at debian.org Fri Mar 5 15:51:37 2010 From: nboullis at debian.org (Nicolas Boullis) Date: Fri, 5 Mar 2010 15:51:37 +0100 Subject: manipulating the set of keys that can decrypt a file/message In-Reply-To: <0130E455-35DE-4BD1-87AF-1411F6143E37@jabberwocky.com> References: <20100304213357.GB4042@debian> <0130E455-35DE-4BD1-87AF-1411F6143E37@jabberwocky.com> Message-ID: <20100305145129.GB3744@debian> On Thu, Mar 04, 2010 at 06:13:17PM -0500, David Shaw wrote: > On Mar 4, 2010, at 4:34 PM, Nicolas Boullis wrote: > > > Reading RFC 4880 (OpenPGP standard), if I am able to decrypt the session > > key, it should be possible to create a new Public-Key Encrypted Session > > Key packet to allow a new key to decrypt the file/message. Removing a > > Public-Key Encrypted Session Key should also be trivial. > > Yes. > > > Does gnupg allow such manipulations? > > No. > > > Or does anyone have suggestions how I should implement this? Libraries > > to use? > > You might be able to hack something together using the GnuPG sources. > Certainly all of the parts you need are in there - you'd just have to > put them together. OK, thanks for your answer. I will now have a look at how things are organised in GnuPG code. Would you suggest that I look at the GnuPG 1 or GnuPG 2 code? And if I succeed to implement this correctly, do you think the feature might be merged in GnuPG? > Alternately, take a look at > http://openpgp.nominet.org.uk/cgi-bin/trac.cgi for a library that you > might also borrow some code from. As I understand it, it does not support ElGamal, which is a show-stopper for my needs. But that's interestig anyway. Regards, -- Nicolas Boullis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 315 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Fri Mar 5 16:43:35 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Mar 2010 10:43:35 -0500 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B795FE5B@EMAIL04.pnl.gov> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> <70086D201BD484439914C36F5C8BF16101A1B795F253@EMAIL04.pnl.gov> <70086D201BD484439914C36F5C8BF16101A1B795FE5B@EMAIL04.pnl.gov> Message-ID: <4B9126A7.2080102@fifthhorseman.net> On 03/05/2010 01:30 AM, Smith, Cathy wrote: > The gpg --list-sig shows that the keys are signed. Do I need to create a new signature key, and re-sign all the public keys that I imported? I think the simplest thing for you to do is to modify the ownertrust of your old signing key on the new installation. That is, you say that all the keys are signed, presumably by some particular key that you used in your PGP installation. Let's pretend that key's ID is 0xDECAFBAD. You'd do: gpg --edit-key 0xDECAFBAD and then from the gpg subshell, do: trust which will give you a menu like this: Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu indicate that this installation should trust your signing key "ultimately", and then type "save" into the gpg subshell. Now, you can encrypt to any key that has been certified by 0xDECAFBAD and you won't get that warning, because gpg trusts the certifications made by your signing key. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Mar 5 16:50:42 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 05 Mar 2010 10:50:42 -0500 Subject: manipulating the set of keys that can decrypt a file/message In-Reply-To: <20100305145129.GB3744@debian> References: <20100304213357.GB4042@debian> <0130E455-35DE-4BD1-87AF-1411F6143E37@jabberwocky.com> <20100305145129.GB3744@debian> Message-ID: <4B912852.6000206@sixdemonbag.org> On 3/5/10 9:51 AM, Nicolas Boullis wrote: > I will now have a look at how things are organised in GnuPG code. > Would you suggest that I look at the GnuPG 1 or GnuPG 2 code? If memory serves, the codebases are identical with respect to this. Shouldn't matter which one you use. > And if I succeed to implement this correctly, do you think the feature > might be merged in GnuPG? I am not a GnuPG developer. I have no say in what they will or will not do. However, my impression is that GnuPG tends to only adopt features that will be broadly useful to a number of users. This seems like a really niche case. If you think this feature should be merged into GnuPG, I would suggest by finding ten people who have an actual, real need for this feature. Not "I think it would be cool if...", but "I need this right now because...". If you can present real users who have real needs, that will do a lot to increase the chances of it being merged into the mainline. From dshaw at JABBERWOCKY.COM Fri Mar 5 17:20:32 2010 From: dshaw at JABBERWOCKY.COM (David Shaw) Date: Fri, 5 Mar 2010 11:20:32 -0500 Subject: manipulating the set of keys that can decrypt a file/message In-Reply-To: <20100305145129.GB3744@debian> References: <20100304213357.GB4042@debian> <0130E455-35DE-4BD1-87AF-1411F6143E37@jabberwocky.com> <20100305145129.GB3744@debian> Message-ID: <1C449E28-A592-4AD4-B206-16ABD5AD4A86@JABBERWOCKY.COM> On Mar 5, 2010, at 9:51 AM, Nicolas Boullis wrote: > On Thu, Mar 04, 2010 at 06:13:17PM -0500, David Shaw wrote: >> On Mar 4, 2010, at 4:34 PM, Nicolas Boullis wrote: >> >>> Reading RFC 4880 (OpenPGP standard), if I am able to decrypt the session >>> key, it should be possible to create a new Public-Key Encrypted Session >>> Key packet to allow a new key to decrypt the file/message. Removing a >>> Public-Key Encrypted Session Key should also be trivial. >> >> Yes. >> >>> Does gnupg allow such manipulations? >> >> No. >> >>> Or does anyone have suggestions how I should implement this? Libraries >>> to use? >> >> You might be able to hack something together using the GnuPG sources. >> Certainly all of the parts you need are in there - you'd just have to >> put them together. > > OK, thanks for your answer. > I will now have a look at how things are organised in GnuPG code. > Would you suggest that I look at the GnuPG 1 or GnuPG 2 code? I'd look at the GnuPG 2 code, or more specifically, the GnuPG 2 code plus libgcrypt (the crypto library that GnuPG 2 uses). This allows you to more easily write something standalone outside of GnuPG. > And if I succeed to implement this correctly, do you think the feature > might be merged in GnuPG? I don't know if this is a generally useful thing (you're not the first person to suggest this, but you are not more than the 3rd in the past 5-8 years or so). Each additional feature adds complexity to the code base. If you are going to write something, I'd recommend a standalone tool using libgcrypt for the crypto part. That way the feature exists, and it doesn't have to be carried along with GPG. That's what I did when I wrote 'paperkey'. It could have been part of GPG (as a new output format), but it didn't really make sense as a built in. David From cathy.smith at pnl.gov Fri Mar 5 19:04:38 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Fri, 5 Mar 2010 10:04:38 -0800 Subject: Migrating from PGP to GPG question In-Reply-To: <227BB6DA-F164-4E17-AE3E-825842D97765@jabberwocky.com> References: <4B90FB7B.3060705@bellsouth.net> <227BB6DA-F164-4E17-AE3E-825842D97765@jabberwocky.com> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B795FEFD@EMAIL04.pnl.gov> Folks Thanks for your suggestions. They worked. Regards, Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of David Shaw Sent: Friday, March 05, 2010 6:00 AM To: John W. Moore III Cc: Smith, Cathy Subject: Re: Migrating from PGP to GPG question On Mar 5, 2010, at 7:39 AM, John W. Moore III wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Laurent Jumet wrote: >> >> Hello Smith, ! >> >> "Smith, Cathy" wrote: >> >>> I've tried using the --yes option without success to suppress this >>> interactive prompt doesn't pop up. This encryption does need to run in a >>> batch job. What do I need to do in order all interactive prompts are >>> surpressed, and that the assumption is they are answered "yes". >> >> Try using: >> --batch >> --yes >> --no-tty > > Why not try adding to gpg.conf > > trust-model always > > This will suppress the prompt/warning as well. This would be my advice as well. The web of trust is generally a useful thing, but in environments where the keys are only provided by the batch owner, it does not add much that is useful to the equation. David _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From John at Mozilla-Enigmail.org Fri Mar 5 19:05:50 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Fri, 05 Mar 2010 12:05:50 -0600 Subject: Migrating from PGP to GPG question In-Reply-To: <4B9126A7.2080102@fifthhorseman.net> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> <70086D201BD484439914C36F5C8BF16101A1B795F253@EMAIL04.pnl.gov> <70086D201BD484439914C36F5C8BF16101A1B795FE5B@EMAIL04.pnl.gov> <4B9126A7.2080102@fifthhorseman.net> Message-ID: <4B9147FE.3080508@Mozilla-Enigmail.org> Daniel Kahn Gillmor wrote: > On 03/05/2010 01:30 AM, Smith, Cathy wrote: >> The gpg --list-sig shows that the keys are signed. Do I need to create a >> new signature key, and re-sign all the public keys that I imported? > > I think the simplest thing for you to do is to modify the ownertrust of > your old signing key on the new installation. That is, you say that all > the keys are signed, presumably by some particular key that you used in > your PGP installation. Let's pretend that key's ID is 0xDECAFBAD. > PGP and GnuPG have different mechanisms for marking the trust of a signing key. In PGP, it's called 'Implicit Trust' and is a check box in Key Properties. It's stored as part of the key. In GnuPG, the same trust level is called 'Ultimate trust' and trust values are stored in a separate file, trustdb.gpg. It's the most common problem I've seen when a user migrates keyrings. Having done this migration several times to answer migrating users' questions, I can confirm the 'proper' solution is as Daniel suggested: edit your signing key(s) and set the trust level to ultimate. 'Trust' will then propagate from your key to the keys you have signed. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Mar 5 22:30:05 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 05 Mar 2010 16:30:05 -0500 Subject: Memory forensics Message-ID: <4B9177DD.2030901@sixdemonbag.org> http://jessekornblum.livejournal.com/259124.html For quite some time we've known that hibernation files present risks for information security. However, there are always those who say "until I see an actual demonstration, I won't believe it." The upshot: we now have an actual demonstration. The takeaway is that you should be very, very careful about hibernating your computer while passphrases are cached, or while GnuPG is actively processing a file. From jmoore3rd at bellsouth.net Fri Mar 5 22:42:53 2010 From: jmoore3rd at bellsouth.net (John W. Moore III) Date: Fri, 05 Mar 2010 16:42:53 -0500 Subject: Memory forensics In-Reply-To: <4B9177DD.2030901@sixdemonbag.org> References: <4B9177DD.2030901@sixdemonbag.org> Message-ID: <4B917ADD.8080309@bellsouth.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Robert J. Hansen wrote: > http://jessekornblum.livejournal.com/259124.html > > For quite some time we've known that hibernation files present risks for > information security. However, there are always those who say "until I > see an actual demonstration, I won't believe it." > > The upshot: we now have an actual demonstration. The takeaway is that > you should be very, very careful about hibernating your computer while > passphrases are cached, or while GnuPG is actively processing a file. Most 'Hibernators' I know are laptop/notebook/netbook Users who are too important to wait for boot-up when the unit is Opened. :-D JOHN 8-) Timestamp: Friday 05 Mar 2010, 16:42 --500 (Eastern Standard Time) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Public Key at: http://tinyurl.com/8cpho Comment: Gossamer Spider Web of Trust: http://www.gswot.org Comment: Personal Web Page: http://tinyurl.com/yzhbhx iQEcBAEBCgAGBQJLkXrbAAoJEBCGy9eAtCsPAiMH/RuY+C0xEmAhBKZb0t/K8bDP 6uxToYMhb1IaLZQhXvbdJqCRXKQrodqpM3Pt80/lkQptnS16QDECjEieuB2zblaP NUCYsnUv4MrXkWWKUymZIEqtMoPbAnMSw4Ip7/Jclx6JmsmWweTK+85ZEZOk2l/Z zhEdPDPXd1SA6WlDkdsCFaXUSxnI54mQCpUSlkpHVUkJNI/1/SFOQpZIDOoxQkBV vI+u7jYf3x1oi5QV07XU13731m1Ec+YrfVgem9sCTUZlMy5JqBQRgME5OUsJKp4h 0GaSJ3OmZXicy1mTwZMo0LdgOOqPSiMKtoyTUaCi8KKPe/EdgU7WLm4zAXSVbhY= =VJ+y -----END PGP SIGNATURE----- From kgo at grant-olson.net Fri Mar 5 23:04:27 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 05 Mar 2010 17:04:27 -0500 Subject: Memory forensics In-Reply-To: <4B9177DD.2030901@sixdemonbag.org> References: <4B9177DD.2030901@sixdemonbag.org> Message-ID: <4B917FEB.8000406@grant-olson.net> On 3/5/2010 4:30 PM, Robert J. Hansen wrote: > http://jessekornblum.livejournal.com/259124.html > > For quite some time we've known that hibernation files present risks for > information security. However, there are always those who say "until I > see an actual demonstration, I won't believe it." > > The upshot: we now have an actual demonstration. The takeaway is that > you should be very, very careful about hibernating your computer while > passphrases are cached, or while GnuPG is actively processing a file. > > That article was a little vague. And I don't know much about memory forensics in practice. Do you know that it actually was a hibernation file and not swap space? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Mar 5 23:18:53 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 05 Mar 2010 17:18:53 -0500 Subject: Memory forensics In-Reply-To: <4B917FEB.8000406@grant-olson.net> References: <4B9177DD.2030901@sixdemonbag.org> <4B917FEB.8000406@grant-olson.net> Message-ID: <4B91834D.60209@sixdemonbag.org> On 3/5/10 5:04 PM, Grant Olson wrote: > That article was a little vague. And I don't know much about memory > forensics in practice. Do you know that it actually was a hibernation > file and not swap space? Note Jesse's phrasing: "volatile memory forensics." Swap space is nonvolatile storage. Hibernation files are just dumps-to-disk of the state of volatile memory when the laptop lid is closed. Extracting keys from swap space is a solved problem: hit Google Scholar and search for "file carving" and you'll get a lot of relevant papers. (While you're at it, check Google Scholar and search for "memory forensics kornblum" -- Jesse is pretty widely published in memory forensics. That doesn't mean he's automatically right, but he's not just some random LiveJournal account, either.) Further, two co-workers of mine have spoken in person with the investigators involved in this prosecution. These co-workers report to me that the investigators have confirmed it was hibernation file analysis. If you want to know specifics, I'd suggest calling the prosecutor and asking for copies of the indictment. It's a public record and the prosecutor is required to provide a copy upon request. From kgo at grant-olson.net Sat Mar 6 00:09:54 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 05 Mar 2010 18:09:54 -0500 Subject: Memory forensics In-Reply-To: <4B91834D.60209@sixdemonbag.org> References: <4B9177DD.2030901@sixdemonbag.org> <4B917FEB.8000406@grant-olson.net> <4B91834D.60209@sixdemonbag.org> Message-ID: <4B918F42.1020806@grant-olson.net> On 03/05/2010 05:18 PM, Robert J. Hansen wrote: > On 3/5/10 5:04 PM, Grant Olson wrote: >> That article was a little vague. And I don't know much about memory >> forensics in practice. Do you know that it actually was a hibernation >> file and not swap space? > > Note Jesse's phrasing: "volatile memory forensics." Swap space is > nonvolatile storage. Hibernation files are just dumps-to-disk of the > state of volatile memory when the laptop lid is closed. Extracting keys > from swap space is a solved problem: hit Google Scholar and search for > "file carving" and you'll get a lot of relevant papers. > > (While you're at it, check Google Scholar and search for "memory > forensics kornblum" -- Jesse is pretty widely published in memory > forensics. That doesn't mean he's automatically right, but he's not > just some random LiveJournal account, either.) > > Further, two co-workers of mine have spoken in person with the > investigators involved in this prosecution. These co-workers report to > me that the investigators have confirmed it was hibernation file analysis. > > If you want to know specifics, I'd suggest calling the prosecutor and > asking for copies of the indictment. It's a public record and the > prosecutor is required to provide a copy upon request. > Thanks a million for all this. The company "Volatile Systems" was really messing with my google-fu. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From talmage at orange.zero.jp Sat Mar 6 03:59:20 2010 From: talmage at orange.zero.jp (KT) Date: Sat, 06 Mar 2010 11:59:20 +0900 Subject: OpenPGPCard Max PIN length changes? Message-ID: <4B91C508.2070501@orange.zero.jp> >From what I understand, the v1.1 cards had a max pin length of 254 characters. Is this not the case with the newer v2.0 cards? My v2.0 card shows Max. PIN lengths .: 32 32 32. Is this a setting that can be changed? I didn't see anything in card-edit, and have I been digging around online, but have not come up with an answer. If in fact there was a change from v1.1/254 to v2.0/32, is there a reason for this change? Anyway to use longer PINs on the v2.0 cards? Talmage From rjh at sixdemonbag.org Sat Mar 6 08:02:24 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 6 Mar 2010 02:02:24 -0500 Subject: Memory forensics In-Reply-To: <4B918F42.1020806@grant-olson.net> References: <4B9177DD.2030901@sixdemonbag.org> <4B917FEB.8000406@grant-olson.net> <4B91834D.60209@sixdemonbag.org> <4B918F42.1020806@grant-olson.net> Message-ID: <9B68A70C-5667-407A-B6C0-993228CDE2FD@sixdemonbag.org> > > Thanks a million for all this. The company "Volatile Systems" was > really messing with my google-fu. Err -- why? Volatile Systems is behind the Volatility framework, which is probably the best FOSS tool going right now for Windows memory analysis. (Admittedly, it only works on Windows XP... but given XP's userbase, even today, that's not a huge loss.) If you want to learn about what memory analysis can do, you could do a lot worse than to look into Volatility. Volatility can also inspect Windows XP's hibernation file and recover data structures from it. I seem to recall that Volatility was the toolkit used by the Madison investigators, but don't quote me on that. I may be barking wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3916 bytes Desc: not available URL: From free10pro at gmail.com Sat Mar 6 09:54:41 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sat, 06 Mar 2010 00:54:41 -0800 Subject: key question In-Reply-To: <1912204946.20100225142453@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> Message-ID: <4B921851.9050201@gmail.com> Hello MFPA, During this whole debate, you have assumed one thing in your argument that I don't believe anyone has pointed out as being flawed. You have assumed that the person (I will call him John Doe) would have decided to create a UID that contained the personal information that he wants to keep private. If the person wanted badly to keep his e-mail address, or his e-mail address and his name, private, why would he put them on his key. Especially, when he knows that all it takes is one slip up or deliberate upload to send his public key flying across the Internet and into a keyserver to remain there forever. Here are three examples of John Doe wanting to keep the privacy of his personal information and still use PGP. I am using these examples, because they are usage cases that you have used in your arguments. The usage cases are as follows: (a) John Doe doesn't want to disclose his e-mail address; (b) John Doe doesn't want to disclose his name or e-mail address; (c) John Doe doesn't want to disclose his name or e-mail address, because he fears that his government will send him to a gulag if they catch him. Usage Case (a) -------------- John Doe knows that he doesn't, under any circumstances, want his e-mail address to be disclosed to the public. So instead of creating a UID without his e-mail address, he creates one with his e-mail address. He gives his key to only those that he wants to communicate with, which are his friends, family, coworkers, and even business clients. Everything goes well for John. His key is off the keyservers, and it isn't posted anywhere public. One day while John is fetching someones keys, he decides, just for kicks, to search for his key on the keyserver. John is horrified. His key is on the keyserver. Usage Case (b) -------------- John Doe knows that he doesn't, under any circumstances, want his name or e-mail address to be disclosed to the public, because he only wants to communiate with a select group of people. So instead of creating a UID without a real name and e-mail address, he creates one with his name and e-mail address. After all, he will only use it with people he trusts. For communicating with the web at large, he uses a pseudonym and a disposable e-mail address. But even though John is separates communications with people he knows from people he doesn't know, he still doesn't want his personal information on the Internet. For this reason, John is careful to ensure that his key isn't publicly available. One day, a friend tells John that he wants to apologize to John. The friend tells John that he accidentally uploaded John's key to the keyservers. Usage Case (c) -------------- John Doe knows that he doesn't, under any circumstances, want his name or e-mail address to be disclosed the public, because he doesn't want the government to discover that he is using PGP. So instead of creating a UID without his name and e-mail address, he creates one with his name and e-mail address. John is careful to share his key with only those that he trusts. Everything goes well with John (that is, things are only as good as it can go for the poor guy). His key isn't anywhere the government could look for it. One day, one of John's trusted family members, who lives in a freer country, accidently uploads John's key to a keyserver. The family member doesn't even realize that he did this. And John doesn't know that this was done. -------------- In each of these cases, John Doe made the mistake of thinking that he could keep his personal information in his key, and that he could keep his key off the keyservers. If John were to make the wisest decision about keeping his personal informaton secret, wouldn't he choose to not include this information in a key that is probable to end up in a public venue? -Paul -- Please use my PGP key when sending me e-mail, if you can. PGP Key ID: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From free10pro at gmail.com Sat Mar 6 09:55:48 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sat, 06 Mar 2010 00:55:48 -0800 Subject: key question In-Reply-To: <333644023.20100227035202@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> Message-ID: <4B921894.5050301@gmail.com> On Sat, 27 Feb 2010 03:52:02 +0000 MFPA wrote: > > (b) the person owns the information has the right to > > control how it is disseminated, and > > The data subject does have various rights concerning the personal > information that is about him. Hello MFPA, How far do the "rights" of the key holder go? You say that the key's originator should control the dissemination of the key to the keyserver, but what about from the keyserver? Isn't the keyserver unwittingly sharing the key without the originator's permission? And if the keyserver should control dissemination, what are the limits of the originator's "rights"? If the originator does have "rights" to control copying and sharing, are there any "fair use rights" for the person who has a copy of the public key? Should these "rights" of the originator be enforced by some governing body, or should they be merely courtesy or suggestion? -Paul -- You wouldn't send all of your mail written on the back of postcards would you? Then why would you send your e-mail the same way? +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Sat Mar 6 13:12:51 2010 From: wk at gnupg.org (Werner Koch) Date: Sat, 06 Mar 2010 13:12:51 +0100 Subject: OpenPGPCard Max PIN length changes? In-Reply-To: <4B91C508.2070501@orange.zero.jp> (KT's message of "Sat, 06 Mar 2010 11:59:20 +0900") References: <4B91C508.2070501@orange.zero.jp> Message-ID: <87bpf1ps1o.fsf@vigenere.g10code.de> On Sat, 6 Mar 2010 03:59, talmage at orange.zero.jp said: > Is this not the case with the newer v2.0 cards? My v2.0 card shows Max. > PIN lengths .: 32 32 32. Depends on the implementation - for those from ZeitControl this is correct. Even the old standard says that the card announces the maximum length. > Is this a setting that can be changed? I didn't see anything in No. > If in fact there was a change from v1.1/254 to v2.0/32, is there a > reason for this change? > Anyway to use longer PINs on the v2.0 cards? What is your threat model that you need more than 32 bytes for a PIN? Only a few humans are able to remember such a long string and enter it within 3 tries. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Sat Mar 6 13:16:01 2010 From: wk at gnupg.org (Werner Koch) Date: Sat, 06 Mar 2010 13:16:01 +0100 Subject: Memory forensics In-Reply-To: <4B9177DD.2030901@sixdemonbag.org> (Robert J. Hansen's message of "Fri, 05 Mar 2010 16:30:05 -0500") References: <4B9177DD.2030901@sixdemonbag.org> Message-ID: <877hppprwe.fsf@vigenere.g10code.de> On Fri, 5 Mar 2010 22:30, rjh at sixdemonbag.org said: > The upshot: we now have an actual demonstration. The takeaway is that > you should be very, very careful about hibernating your computer while > passphrases are cached, or while GnuPG is actively processing a file. You can protect against this by adding a little bit of code to the suspend script: Iterate over all active users and run for them the command "gpgconf --reload agent" or directly send a HUP to all gpg-agent's. This will invalidate the caches. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From expires2010 at ymail.com Sat Mar 6 17:34:02 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 6 Mar 2010 16:34:02 +0000 Subject: key question In-Reply-To: <4B921894.5050301@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> Message-ID: <69266957.20100306163402@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Paul On Saturday 6 March 2010 at 8:55:48 AM, you wrote: > On Sat, 27 Feb 2010 03:52:02 +0000 MFPA wrote: >> > (b) the person owns the information has the right to >> > control how it is disseminated, and This was someone's re-interpretation of my point. Spot the extra ">"? The concept of *owning* your personal information makes little sense. For example, there may be many organisations with copies of your personal information in their databases. They each own their respective databases. In a lot of countries, there are legal measures in place to control what they are allowed to do with your personal information. In most European countries, they will only be allowed to use the information for the purpose for which you were told it would be used, can only keep it as long as reasonably required for that purpose, must not disclose it to third parties (except as allowed in the T&Cs covering your relationship, or allowed or required by law), must allow you to see what info they hold (fee usually payable - here it is "up to" 10 GBP), must allow you to correct the info, ... I have posted several relevant links in my message that yours was a reply to. >> >> The data subject does have various rights concerning the personal >> information that is about him. > Hello MFPA, > How far do the "rights" of the key holder go? Exactly as far as everything else that would fall under the basic right to privacy (described in Article 8 of the European Convention of Human Rights as "the right to respect for private and family life"). The OECD's "Guidelines on the Protection of Privacy and Transborder Flows of Personal Data" is a slightly more international view. http://www.oecd.org/document/20/0,3343,en_2649_34255_15589524_1_1_1_1,00.html The use, storage or dissemination of personal information is the subject of specific laws in many places, as mentioned above and linked from earlier in the thread. I'm referring to the personal information that is often present in key UIDs. Others may wish to extend similar discussion to cover the key ID/fingerprint, which I view as problematic. The key ID/fingerprint is not personal information in and of itself. But if the key is on a server, the de facto standard for key UIDs leads to, in most cases, personal information being revealed to anybody in possession of the key ID. > You say that the key's originator should control the dissemination > of the key to the keyserver, (I would point out that other opinions are available and have been shared in this thread. Also, the conditional "should" is important since anybody in possession of the key has the *ability* to upload it whether they "should" or not.) I say that if the key's originator does not disseminate said key to said keyserver, nobody else is in a legitimate position to make that decision on their behalf. If the originator actively *wanted* their key to be on that server (or network of servers), they would probably have uploaded it there. The originator may have been unaware of that server's existence. They may simply have taken no action regarding keyservers. They may have considered a particular keyserver (or network) and made a decision that they did not want their key on it. They may not want their key on any keyserver. The point is, without referring to the key originator, a third party cannot know their intentions and should not have the arrogance to presume. The OpenPGP standard and GnuPG can both be seen to concede that the key originator could have some say in the matter: the "keyserver-no-modify" flag was defined quite a while ago in RFC 2440 as meaning "the key holder requests that this key only be modified or updated by the key holder or an administrator of the key server," and has long been set by default in GnuPG. Unfortunately, I don't see evidence that any keyservers honour this flag. > but what about from the keyserver? Isn't the keyserver unwittingly > sharing the key without the originator's permission? Difficult to answer. Say, for example, I was to print out your photograph, name, address, phone number, etc. and display it on a public noticeboard in the church. Would you consider that the noticeboard was unwittingly sharing your personal information without permission? Or am I solely at fault? Or does the church share some blame? > And if the keyserver should control dissemination, what are the > limits of the originator's "rights"? I don't believe the keyservers should restrict dissemination of keys once they are admitted to the server. I believe servers should perform some sort of originator-verification before listing fresh or updated keys with the keyserver-no-modify flag set (including where set on the existing but not the updated copy). Where keyservers synchronise, there would need to be a way of passing on the originator-verification result along with the updated key. If a user makes the conscious decision to allow indiscriminate publishing/updating of their key, unsetting the keyserver-no-modify flag should achieve this. If they already uploaded it to the servers with that flag set, they would need to pass the originator-verification one last time to propagate the change. > If the originator does have "rights" to control copying and sharing, are > there any "fair use rights" for the person who has a copy of the public > key? Should these "rights" of the originator be enforced by some > governing body, or should they be merely courtesy or suggestion? I am not advocating anything remotely equivalent to copyright provisions, just protection of personal information. As with all other situations where you give somebody your personal information, it depends on the circumstances. In the context of family/friends/casual acquaintances, we are simply talking about trust, courtesy, honour, etc. In the case of a business relationship where the individual provides personal information for a particular purpose, the standard privacy/data protection laws apply in addition. Note again that I am talking about the personal information attached to the key, not the key itself. This could all be avoided if an option were available to create UIDs which revealed no personal information, but which still enabled somebody who knew your email address to retrieve your key from a server. See http://www.hauke-laging.de/ideen/gpg-hash/index_1_1.en.html and http://marc.info/?t=125471254900001&r=1&w=2 and http://www.imc.org/ietf-openpgp/mail-archive/msg36986.html - -- Best regards MFPA mailto:expires2010 at ymail.com He's an environmentalist - his arguments are 100% recycled -----BEGIN PGP SIGNATURE----- iQCVAwUBS5KED6ipC46tDG5pAQqZjAP+PU7zpnqvLWsYc+ahAN9PD2xMzuD+YI/P 4Sps6E03iiZoA7rE4UV5IkFE/OOCQ27oFPIhbnem8aywpJlCE2wfuHDhLsFT7JP+ Zmyo1mMOm0Cgm62KKoheXRfD5cjx9+18N7NUKWHmHsXkxaUewXTsqpHBG14zbuMs XTCXEYWl2Ig= =6hSm -----END PGP SIGNATURE----- From kgo at grant-olson.net Sat Mar 6 20:27:15 2010 From: kgo at grant-olson.net (Grant Olson) Date: Sat, 06 Mar 2010 14:27:15 -0500 Subject: Memory forensics In-Reply-To: <9B68A70C-5667-407A-B6C0-993228CDE2FD@sixdemonbag.org> References: <4B9177DD.2030901@sixdemonbag.org> <4B917FEB.8000406@grant-olson.net> <4B91834D.60209@sixdemonbag.org> <4B918F42.1020806@grant-olson.net> <9B68A70C-5667-407A-B6C0-993228CDE2FD@sixdemonbag.org> Message-ID: <4B92AC93.1040608@grant-olson.net> On 3/6/2010 2:02 AM, Robert J. Hansen wrote: >> >> Thanks a million for all this. The company "Volatile Systems" was >> really messing with my google-fu. > > Err -- why? > > Volatile Systems is behind the Volatility framework, which is probably > the best FOSS tool going right now for Windows memory analysis. > (Admittedly, it only works on Windows XP... but given XP's userbase, > even today, that's not a huge loss.) If you want to learn about what > memory analysis can do, you could do a lot worse than to look into > Volatility. > > Volatility can also inspect Windows XP's hibernation file and recover > data structures from it. I seem to recall that Volatility was the > toolkit used by the Madison investigators, but don't quote me on that. > I may be barking wrong. > I was probably just being a little dense. I could see that they had a memory forensics tool, but the company pages that I got when searching on "volatile memory forensics" were steering me away from basic definition and intro and FAQ pages. Anyway, thanks again for the info. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From eggled at gmail.com Sun Mar 7 16:13:04 2010 From: eggled at gmail.com (Daniel Eggleston) Date: Sun, 7 Mar 2010 09:13:04 -0600 Subject: gpg-preset-passphrase Message-ID: <90f9e6571003070713w3dc31860jb5a0d4ecb403e0db@mail.gmail.com> I'm looking for some help explaining the behavior of gpg-preset-passphrase. First, the manpage states: Passphrases set with this utility don't expire unless the --forget option is used to explicitly clear them from the cache --- or gpg-agent is either restarted or reloaded (by sending a SIGHUP to it). It is But it looks like gpg-preset-passphrase cached passphrases are still subject to the --max-cache-ttl option in gpg-agent ... this behavior is hardly "Don't expire". Is there a way to change this behavior? Second, the manpage also states: --forget Flush the passphrase for the given cache ID from the cache. The implication (to me) is that if I cache a passphrase with gpg-preset-passphrase, then run gpg-preset-passphrase with the same key fingerprint and the --forget option, that gpg-agent will no longer cache that entry. When this didn't pan out, I thought maybe the forget command simply makes the cached passphrase obey the --default-cache-ttl option, but no dice. So, basically the --preset command is subject to --max-cache-ttl (although the documentation implies otherwise), and the --forget command doesn't appear to change anything at all. Am I doing it wrong? Any help is appreciated, -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From expires2010 at ymail.com Sun Mar 7 17:46:09 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 7 Mar 2010 16:46:09 +0000 Subject: key question In-Reply-To: <4B921851.9050201@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B921851.9050201@gmail.com> Message-ID: <1024723752.20100307164609@my_localhost> Hi Paul On Saturday 6 March 2010 at 8:54:41 AM, you wrote: > Hello MFPA, > During this whole debate, you have assumed one thing in your argument > that I don't believe anyone has pointed out as being flawed. You have > assumed that the person (I will call him John Doe) would have decided > to create a UID that contained the personal information that he wants > to keep private. The default configurations of PGP and gpg ask for a name, email address, and comment when you create a key. Last time I looked (v8.x), PGP would not even create a key without something that looked like an email address - hence the a at b.c in my UID. (And yes, I know gpg now allows you to omit the email address without having to use --expert, but you are still asked for it.) Almost any documentation I can find telling a new user how to use GnuPG or PGP tells the user that the key UID is their name plus email address, and that they should upload the key to a server. Many email apps rely on the presence of the email address in the UID for key selection, and documentation mentions this. Basically, almost everything the beginner sees suggests either he cannot create a key without this info, or his key is next-to-useless if he does. > If the person wanted badly to keep his e-mail address, or his e-mail > address and his name, private, why would he put them on his key. > Especially, when he knows that all it takes is one slip up or > deliberate upload to send his public key flying across the Internet > and into a keyserver to remain there forever. I agree, and I touched this in Message-ID: <205633239.20100226162320 at my_localhost>, which was a reply to one of your previous messages. > Here are three examples of John Doe wanting to keep the privacy of his > personal information and still use PGP. I am using these examples, > because they are usage cases that you have used in your arguments. > The usage cases are as follows: (a) John Doe doesn't want to disclose > his e-mail address; (b) John Doe doesn't want to disclose his name > or e-mail address; (c) John Doe doesn't want to disclose his name or > e-mail address, because he fears that his government will send him > to a gulag if they catch him. [...] > -------------- > In each of these cases, John Doe made the mistake of thinking that > he could keep his personal information in his key, and that he could > keep his key off the keyservers. If John were to make the wisest > decision about keeping his personal informaton secret, wouldn't he > choose to not include this information in a key that is probable to > end up in a public venue? You are assuming he realised it was probable. The benefit of hindsight will presumably lead him to proceed differently in future. Initially, John may not have even known he *could* create a useable key without his valid email address. He might have been used to trusting his those in his closed circle. He might not have experienced or considered how easy it was to make mistakes resulting in inadvertent key upload. He may have read about the "keyserver-no-modify" flag and assumed the feature would actually protect his key from accidental or malicious publication. -- Best regards MFPA mailto:expires2010 at ymail.com Don't learn safety rules by accident... From dshaw at jabberwocky.com Sun Mar 7 18:53:51 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 7 Mar 2010 12:53:51 -0500 Subject: key question In-Reply-To: <1024723752.20100307164609@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B921851.9050201@gmail.com> <1024723752.20100307164609@my_localhost> Message-ID: <227FE6E3-FAA6-47D4-A3EE-45E565D83446@jabberwocky.com> On Mar 7, 2010, at 11:46 AM, MFPA wrote: > The default configurations of PGP and gpg ask for a name, email > address, and comment when you create a key. Last time I looked (v8.x), > PGP would not even create a key without something that looked like an > email address - hence the a at b.c in my UID. (And yes, I know gpg now > allows you to omit the email address without having to use --expert, > but you are still asked for it.) There is no 'now' here. This is not new behavior in GPG, and the expert flag never had anything to do with it (indeed, the behavior predates the existence of the --expert flag). When GPG asks you for an email address, just hit return. GPG doesn't care one way or the other. David From expires2010 at ymail.com Mon Mar 8 02:33:27 2010 From: expires2010 at ymail.com (MFPA) Date: Mon, 8 Mar 2010 01:33:27 +0000 Subject: key question In-Reply-To: <227FE6E3-FAA6-47D4-A3EE-45E565D83446@jabberwocky.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B921851.9050201@gmail.com> <1024723752.20100307164609@my_localhost> <227FE6E3-FAA6-47D4-A3EE-45E565D83446@jabberwocky.com> Message-ID: <32500012.20100308013327@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi David On Sunday 7 March 2010 at 5:53:51 PM, you wrote: > On Mar 7, 2010, at 11:46 AM, MFPA wrote: >> (And yes, I know gpg now >> allows you to omit the email address without having to use --expert, >> but you are still asked for it.) > There is no 'now' here. This is not new behavior in GPG, and the > expert flag never had anything to do with it (indeed, the behavior > predates the existence of the --expert flag). When GPG asks you for > an email address, just hit return. GPG doesn't care one way or the other. Sorry, I was mistaken. When I tested this in an earlier version, I was unable to proceed without entering an email address. Having gone back and re-tested, I am only able to replicate the behaviour if the string I enter for "Real name" contains the "@" character. This also holds true for 1.4.10. The --expert flag was/is not the difference, it's the presence of "@" in the "Real name" field. - -- Best regards MFPA mailto:expires2010 at ymail.com Raining cats and dogs is better than hailing taxis. -----BEGIN PGP SIGNATURE----- iQCVAwUBS5RUBKipC46tDG5pAQoU1QP/ZLjFmEuJDekgAMUakhZdYPOvVEc/fOml JSJT/ABumMQnnrwMA8JM/r3uoqguXP2HNC4fx2cL5OwcPGbb1kC5JPXwFG79JHKC CTPM7aXVzOgavQ8L3fj1FKwM/6fOKXTFT/PLePYHIzbt4+HjxZk854bvTyhv3MY0 0qhoUy5yAaU= =ypXx -----END PGP SIGNATURE----- From expires2010 at ymail.com Mon Mar 8 02:41:56 2010 From: expires2010 at ymail.com (MFPA) Date: Mon, 8 Mar 2010 01:41:56 +0000 Subject: key question In-Reply-To: <20100304172509.GC16237@IUPUI.Edu> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86BB90.70707@Mozilla-Enigmail.org> <373551548.20100226155327@my_localhost> <20100303161621.GE28078@IUPUI.Edu> <31361393.20100303184425@my_localhost> <20100304172509.GC16237@IUPUI.Edu> Message-ID: <1296301919.20100308014156@my_localhost> Hi Mark On Thursday 4 March 2010 at 5:25:09 PM, you wrote: > Were I the individual, I would think long and hard about using a tool > which would require me to defeat its features that create identity > labels (however false or information-poor) and carry them along with > the message. I would be drawn toward tools whose methods carry no > identity data themselves. You can't accidentally misuse a feature > that isn't there. Which is, of course, sound reasoning in the event that the range of options available to that individual (and his contacts) includes such tools. -- Best regards MFPA mailto:expires2010 at ymail.com Two wrongs don't make a right. But three lefts do. From powerman at powerman.name Mon Mar 8 01:43:17 2010 From: powerman at powerman.name (Alex Efros) Date: Mon, 8 Mar 2010 02:43:17 +0200 Subject: how to suppress warning about gpg-agent? Message-ID: <20100308004317.GC9899@home.power> Hi! Looks like we need an option to suppress warning about gpg-agent. > Long story: I've a lot of projects (each has separate user account) which use gpg for encrypting daily backups (from cron) in this way: gpg --batch --cipher-algo AES256 -c --passphrase-file PASSFILE BACKUP.tar The problem is, after switching to gpg2 I start receiving a lot of emails every day with same warning: "can't connect to `/home/USER/.gnupg/S.gpg-agent': No such file or directory" I don't like to redirect STDERR output of gpg to /dev/null because I wanna receive emails in case of problems with backup process. But I don't wanna receive dozens of useless emails with this warning every day. I don't like to run gpg-agent as a daemon on all these user accounts just to suppress this warning message (and there may be additional issues to make it accessible from cron scripts, too). I can try to run gpg-agent from same cron script just before using gpg, and then kill gpg-agent, but this may lead to race conditions in case gpg-agent already started by that user for other needs. Looks like there only two real solutions: implement pipe filter for gpg's STDERR to strip just this message (ugly), and patch gpg to add an option to suppress this warning. P.S. I use Gentoo Linux and app-crypt/gnupg-2.0.14. -- WBR, Alex. From expires2010 at ymail.com Mon Mar 8 02:48:34 2010 From: expires2010 at ymail.com (MFPA) Date: Mon, 8 Mar 2010 01:48:34 +0000 Subject: Memory forensics In-Reply-To: <4B917ADD.8080309@bellsouth.net> References: <4B9177DD.2030901@sixdemonbag.org> <4B917ADD.8080309@bellsouth.net> Message-ID: <186465807.20100308014834@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi John On Friday 5 March 2010 at 9:42:53 PM, you wrote: > Most 'Hibernators' I know are laptop/notebook/netbook Users who are too > important to wait for boot-up when the unit is Opened. :-D Did you mean "important" rather than "impatient?" - -- Best regards MFPA mailto:expires2010 at ymail.com We are all in the gutter, but some of us are looking at the stars -----BEGIN PGP SIGNATURE----- iQCVAwUBS5RXeKipC46tDG5pAQoYDgQAj3BvmgZythkHXMXotKBT/rAHpLtVCbkJ czGqvSLH8z/SJVG6cxqy98d5oVTY3uym5+5FfsvZdFrw9NEYLRdBiJwbLTDDsJBz mfh0Yif87vjbfllIQzZpl+AjUEHer2BdC6PaxxynGlVEJXwBIhT5R+57ulJBUQRw iCTinN9y/vY= =twZz -----END PGP SIGNATURE----- From free10pro at gmail.com Mon Mar 8 06:35:08 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sun, 07 Mar 2010 21:35:08 -0800 Subject: key question In-Reply-To: <69266957.20100306163402@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> Message-ID: <4B948C8C.8010007@gmail.com> MFPA wrote: > On Saturday 6 March 2010 at 8:55:48 AM, you wrote: > > >> On Sat, 27 Feb 2010 03:52:02 +0000 MFPA wrote: >>>> (b) the person owns the information has the right to >>>> control how it is disseminated, and > > This was someone's re-interpretation of my point. Spot the extra ">"? Hello MFPA, I never asserted that you said the key's originator owned the information stored in the key. I was quoting the context of what your reply about the originator having "some rights" was about. I would never try to insert words into your mouth. >>> The data subject does have various rights concerning the personal >>> information that is about him. This is the reply you gave to Robert J. Hansen. I have asked about what you believe the limit of the "rights" of the originator is. I didn't ask this because I am trying to twist your words to make it seem as though you believe that the originator has a right by law to prevent the key holder from disseminating it. I used this quote, because I believe that it states, in your own words, what you have been saying, either directly or by implication, during this whole discussion thread. > The concept of *owning* your personal information makes little sense. [snipped the rest of the paragraph] You have began by answering a question that I never asked. I have only asserted that you believe that the originator has "some rights". I never used the word "own". I used the word "rights". > Exactly as far as everything else that would fall under the basic > right to privacy (described in Article 8 of the European Convention of > Human Rights as "the right to respect for private and family life"). > The OECD's "Guidelines on the Protection of Privacy and Transborder > Flows of Personal Data" is a slightly more international view. > http://www.oecd.org/document/20/0,3343,en_2649_34255_15589524_1_1_1_1,00.html > > The use, storage or dissemination of personal information is the > subject of specific laws in many places, as mentioned above and linked > from earlier in the thread. > > I'm referring to the personal information that is often present in key > UIDs. Others may wish to extend similar discussion to cover the key > ID/fingerprint, which I view as problematic. The key ID/fingerprint is > not personal information in and of itself. But if the key is on a > server, the de facto standard for key UIDs leads to, in most cases, > personal information being revealed to anybody in possession of the > key ID. Really, I am not interested in talking about what the law says. The law may be right, or the law may be wrong. I don't want to know what the law thinks, I want to know what you think. >> You say that the key's originator should control the dissemination >> of the key to the keyserver, > > (I would point out that other opinions are available and have been > shared in this thread. Also, the conditional "should" is important > since anybody in possession of the key has the *ability* to upload it > whether they "should" or not.) I know what the others have said--I have read every posting in this thread. As for "should", I intentionally chose that word. > I say that if the key's originator does not disseminate said key to > said keyserver, nobody else is in a legitimate position to make that > decision on their behalf. If the originator actively *wanted* their > key to be on that server (or network of servers), they would probably > have uploaded it there. > > The originator may have been unaware of that server's existence. They > may simply have taken no action regarding keyservers. They may have > considered a particular keyserver (or network) and made a decision > that they did not want their key on it. They may not want their key on > any keyserver. The point is, without referring to the key originator, > a third party cannot know their intentions and should not have the > arrogance to presume. > > The OpenPGP standard and GnuPG can both be seen to concede that the > key originator could have some say in the matter: the > "keyserver-no-modify" flag was defined quite a while ago in RFC 2440 > as meaning "the key holder requests that this key only be modified or > updated by the key holder or an administrator of the key server," and > has long been set by default in GnuPG. Unfortunately, I don't see > evidence that any keyservers honour this flag. For the record, I don't believe that the key holder should upload the key if the key's originator doesn't want the key in some public venue (forget the keyservers, it's about public availability). But I don't believe the originator has a /right/ to prevent the key holder from sharing it. >> but what about from the keyserver? Isn't the keyserver unwittingly >> sharing the key without the originator's permission? > > Difficult to answer. Good. I accomplished my goal of making you think about your position. :-) > Say, for example, I was to print out your photograph, name, address, > phone number, etc. and display it on a public noticeboard in the > church. Would you consider that the noticeboard was unwittingly > sharing your personal information without permission? Or am I solely > at fault? Or does the church share some blame? I don't believe the keyserver (or the church) is responsible for another's actions. But I wanted to see whether you thought the keyserver should be responsible. >> And if the keyserver should control dissemination, what are the >> limits of the originator's "rights"? > > I don't believe the keyservers should restrict dissemination of keys > once they are admitted to the server. > > I believe servers should perform some sort of originator-verification > before listing fresh or updated keys with the keyserver-no-modify flag > set (including where set on the existing but not the updated copy). > Where keyservers synchronise, there would need to be a way of passing > on the originator-verification result along with the updated key. > > If a user makes the conscious decision to allow indiscriminate > publishing/updating of their key, unsetting the keyserver-no-modify > flag should achieve this. If they already uploaded it to the servers > with that flag set, they would need to pass the > originator-verification one last time to propagate the change. The only problem that I can see with the keyserver preventing any modification of the originator's key, is that it could prevent someone else from ever revoking their signature on the originator's key. That would be, of course, if absolutely no modification is allowed. >> If the originator does have "rights" to control copying and sharing, are >> there any "fair use rights" for the person who has a copy of the public >> key? Should these "rights" of the originator be enforced by some >> governing body, or should they be merely courtesy or suggestion? > > I am not advocating anything remotely equivalent to copyright > provisions, just protection of personal information. The "rights" that you are asserting are similar to copyrights. They both restrict the copying and dissemination of the information associated with them. So if the key holder can't ethically (not talking about physically) share the key or modify it, then what "rights" does the key holder have? > As with all other situations where you give somebody your personal > information, it depends on the circumstances. In the context of > family/friends/casual acquaintances, we are simply talking about > trust, courtesy, honour, etc. In the case of a business relationship > where the individual provides personal information for a particular > purpose, the standard privacy/data protection laws apply in addition. > > Note again that I am talking about the personal information attached > to the key, not the key itself. This could all be avoided if an option > were available to create UIDs which revealed no personal information, > but which still enabled somebody who knew your email address to > retrieve your key from a server. See > http://www.hauke-laging.de/ideen/gpg-hash/index_1_1.en.html and > http://marc.info/?t=125471254900001&r=1&w=2 and > http://www.imc.org/ietf-openpgp/mail-archive/msg36986.html Your purpose for keyservers and my purpose for keyservers are different. I believe that keyservers should be for the public dissemination of keys. You believe that keyservers should be for the private dissemination of keys. What /you/ want is a keyserver that you can upload publicly and share privately. I want is a keyserver that I can upload publicly and share publicly. Remember that they are called public keyservers. And like a public restroom, they can be used by deviant and saint alike. You shouldn't assail the public keyservers. You should be calling for an additional kind of keyserver to fill the niche of people like you. -Paul -- New Windows 7: Double the DRM, Double the fun! Learn more: +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From free10pro at gmail.com Mon Mar 8 07:04:44 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sun, 07 Mar 2010 22:04:44 -0800 Subject: key question In-Reply-To: <69266957.20100306163402@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> Message-ID: <4B94937C.3030503@gmail.com> Hello MFPA, I will summarize the "rights" and restrictions that I believe you say that an OpenPGP user has with another's public key. I will call this the rules of "Key Rights Management" or KRM for short. Rights of the Key Originator ---------------------------- * Can restrict the uploading of the key to a public venue, especially public keyservers. * Can restrict how and where a key is uploaded, if uploading is permitted. * Can restrict the sharing of the key with someone other than the originator. * Can control the Original Signature Content of the key. [1] Privileges of the Key Holder ---------------------------- * Free to use the key when communicating with the originator. * May keep multiple copies of the key so long as the key holder takes steps to protect the key from unauthorized copying and distribution. * None more. You should be glad the originator was lenient enough to allow you to have the first two. [1] Original Signature Content is the signatures that are attached, at the will of the originator, to the key. By default no one may add signatures to this Original Signature Content without the owner's permission. -Paul -- PGP Key ID: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From free10pro at gmail.com Mon Mar 8 08:44:42 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sun, 07 Mar 2010 23:44:42 -0800 Subject: key question In-Reply-To: <1024723752.20100307164609@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B921851.9050201@gmail.com> <1024723752.20100307164609@my_localhost> Message-ID: <4B94AAEA.5040904@gmail.com> MFPA wrote: >> In each of these cases, John Doe made the mistake of thinking that >> he could keep his personal information in his key, and that he could >> keep his key off the keyservers. If John were to make the wisest >> decision about keeping his personal informaton secret, wouldn't he >> choose to not include this information in a key that is probable to >> end up in a public venue? > > > You are assuming he realised it was probable. The benefit of hindsight > will presumably lead him to proceed differently in future. Initially, > John may not have even known he *could* create a useable key without > his valid email address. He might have been used to trusting his those > in his closed circle. He might not have experienced or considered how > easy it was to make mistakes resulting in inadvertent key upload. He > may have read about the "keyserver-no-modify" flag and assumed the > feature would actually protect his key from accidental or malicious > publication. I am assuming that a person inhabited with the desire to protect his personal information would analyze the safety of using a UID with the information that he wants to protect. A person worried about the disclosure of his personal information is unlikely to say, "Huh. I guess I don't have an option concerning my privacy." I am also assuming that the user has intelligence and judgment. If the user is stupid and foolish, nothing can save him. By saying that he must have intelligence and judgment, I mean that he must be able to realize that he needs to be competent in the tool that he is using. How could a person of judgment believe that he could have the minimum knowledge of how to use cryptography and his OpenPGP tool, and believe that he will successfully protect his privacy? The person concerned with the releasing of his personal information might make the mistakes that you have said. But the kind of person that you are talking about has minimal knowledge in OpenPGP and the tools to implement it and has less than adequate reasoning. I have been naive before. But I didn't begin using GnuPGP while I was still naive about it. I studied how cryptography and OpenPGP worked, how to use gpg, and how to use it with e-mail and files. I won't claim that I am better or more knowledgeable than some of the other smart people on this mailing list, but I will say that I am smart enough to teach others how it works. Actually, it was my goal to understand the concepts and the tools well enough to teach others. You don't have to have the most understanding in order to teach others, but you do have to have /enough/ understanding in what you want to teach in order to teach others. Naivety in how to protect your privacy leads to having no privacy. Take for example how it is that many young people share the intimate details of their lives on social networks, chat rooms, et cetera. They are naive and *foolish*. While training these kids on how to protect their privacy could lead to many of them abandoning such unsafe practices, this doesn't mean that someone who already wants privacy would think that those same unsafe practices were safe. That is what I was saying in the previous posting. Someone who desires privacy will do what it takes to get it. That includes dispelling his naivety with knowledge. As for the person not realizing how easy it would be to accidentally upload a public key to a keyserver, I was never that naive. I was aware of it from the beginning. My key wasn't on the keyservers, initially (I chose to upload it later). But I knew that if I was careless it could wind up there. Maybe it is that I am an above average user. Maybe. Maybe it is just that I exercised judgment. Maybe I expect others to do the same. -Paul -- "You are free to rip me off. Just remember to credit me." --self PGP Key ID: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From kenny at meshmx.com Mon Mar 8 06:07:34 2010 From: kenny at meshmx.com (kkaputa) Date: Sun, 7 Mar 2010 21:07:34 -0800 (PST) Subject: gpg-preset-passphrase In-Reply-To: <90f9e6571003070713w3dc31860jb5a0d4ecb403e0db@mail.gmail.com> References: <90f9e6571003070713w3dc31860jb5a0d4ecb403e0db@mail.gmail.com> Message-ID: <27817136.post@talk.nabble.com> I have a patch for fixing the 'forget' option. I hope this is of some help. http://old.nabble.com/file/p27817136/clear_passphrase.patch clear_passphrase.patch It would be nice to have a more complete tool for administering passphrases, or a simpler interface to pinentry :) /K Daniel Eggleston-2 wrote: > > I'm looking for some help explaining the behavior of > gpg-preset-passphrase. > > First, the manpage states: > > Passphrases set with this utility don't expire unless the > --forget > option is used to explicitly clear them from the cache --- or > gpg-agent > is either restarted or reloaded (by sending a SIGHUP to it). It > is > > But it looks like gpg-preset-passphrase cached passphrases are still > subject > to the --max-cache-ttl option in gpg-agent ... this behavior is hardly > "Don't expire". Is there a way to change this behavior? > > Second, the manpage also states: > > --forget > Flush the passphrase for the given cache ID from the cache. > > The implication (to me) is that if I cache a passphrase with > gpg-preset-passphrase, then run gpg-preset-passphrase with the same key > fingerprint and the --forget option, that gpg-agent will no longer cache > that entry. When this didn't pan out, I thought maybe the forget command > simply makes the cached passphrase obey the --default-cache-ttl option, > but > no dice. > > So, basically the --preset command is subject to --max-cache-ttl (although > the documentation implies otherwise), and the --forget command doesn't > appear to change anything at all. Am I doing it wrong? > > Any help is appreciated, > > -- > > Daniel > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -- View this message in context: http://old.nabble.com/gpg-preset-passphrase-tp27812444p27817136.html Sent from the GnuPG - User mailing list archive at Nabble.com. From wk at gnupg.org Mon Mar 8 13:06:06 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 08 Mar 2010 13:06:06 +0100 Subject: how to suppress warning about gpg-agent? In-Reply-To: <20100308004317.GC9899@home.power> (Alex Efros's message of "Mon, 8 Mar 2010 02:43:17 +0200") References: <20100308004317.GC9899@home.power> Message-ID: <87wrxnnhld.fsf@vigenere.g10code.de> On Mon, 8 Mar 2010 01:43, powerman at powerman.name said: > I've a lot of projects (each has separate user account) which use gpg for > encrypting daily backups (from cron) in this way: > > gpg --batch --cipher-algo AES256 -c --passphrase-file PASSFILE BACKUP.tar FWIW, You should use public key encryption instead of symmetric only encryption. This makes everything much easier. > I don't like to run gpg-agent as a daemon on all these user accounts just > to suppress this warning message (and there may be additional issues to > make it accessible from cron scripts, too). A littel warning: gpg-agent is is a cornerstone of GnuPG-2. You can't do much without it. Today gpg2 might be usable without a running gpg-agent but with the current branch this will change: All secret key operations are then diverted to the agent. In your case the agent is required to return the S2K count. This values is computed only once because it takes some time can can't be done for each invcation. To avoid this you may try option "--s2k-count N". You can get a suitable value for N on your machine by running the command gpg-connect-agent 'getinfo s2k_count' /bye Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From powerman at powerman.name Mon Mar 8 13:22:28 2010 From: powerman at powerman.name (Alex Efros) Date: Mon, 8 Mar 2010 14:22:28 +0200 Subject: how to suppress warning about gpg-agent? In-Reply-To: <87wrxnnhld.fsf@vigenere.g10code.de> References: <20100308004317.GC9899@home.power> <87wrxnnhld.fsf@vigenere.g10code.de> Message-ID: <20100308122228.GA9438@home.power> Hi! On Mon, Mar 08, 2010 at 01:06:06PM +0100, Werner Koch wrote: > FWIW, You should use public key encryption instead of symmetric only > encryption. This makes everything much easier. I don't think so. Every project encrypt it backups with different passwords (needed for security), and right now I can keep just several dozens of passwords, but with public keys I'll need to keep several dozens of .gnupg directories instead, which is harder to manage. > A littel warning: gpg-agent is is a cornerstone of GnuPG-2. You can't > do much without it. Today gpg2 might be usable without a running > gpg-agent but with the current branch this will change: All secret key > operations are then diverted to the agent. I know. Right now it run gpg-agent in server mode and talk to it STDIN - that's ok for my needs. I don't try to avoid running gpg-agent, I just wanna suppress warning. > In your case the agent is required to return the S2K count. This values > is computed only once because it takes some time can can't be done for > each invcation. To avoid this you may try option "--s2k-count N". You > can get a suitable value for N on your machine by running the command > > gpg-connect-agent 'getinfo s2k_count' /bye Wow, it works! With this parameter gpg doesn't output that warning anymore (and doesn't try to start gpg-agent). I wonder what is physical sense of this number? Is it safe to hardcode one number for all user accounts on same server (many servers)? P.S. But I still think much more clear solution is just add option to suppress warning message and let gpg start own copy of gpg-agent when it need it. -- WBR, Alex. From expires2010 at ymail.com Mon Mar 8 19:31:41 2010 From: expires2010 at ymail.com (MFPA) Date: Mon, 8 Mar 2010 18:31:41 +0000 Subject: key question In-Reply-To: <4B94AAEA.5040904@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B921851.9050201@gmail.com> <1024723752.20100307164609@my_localhost> <4B94AAEA.5040904@gmail.com> Message-ID: <1736930089.20100308183141@my_localhost> Hi Paul On Monday 8 March 2010 at 7:44:42 AM, you wrote: > I am assuming that a person inhabited with the desire to protect his > personal information would analyze the safety of using a UID with the > information that he wants to protect. I think you may be assuming an awful lot, especially in the case where the person has a desire for privacy rather than a life-or-death *need* for privacy. Such a person may well be less rigorous than yourself in their analysis and investigations. We *are* talking about a technology created for privacy (http://www.philzimmermann.com/EN/essays/WhyIWrotePGP.html ). > A person worried about the disclosure of his personal information is > unlikely to say, "Huh. I guess I don't have an option concerning my > privacy." Unless their research reveals they *can* usefully create and circulate a key that omits their name/email address, they are weighing the privacy benefit of encrypting their mail against the privacy danger of using a key that contains those details. That isn't quite the same as "I don't have an option." > I am also assuming that the user has intelligence and judgment. A useful combination, sadly not common enough (-; > I mean that he must be able to realize that he needs to be competent > in the tool that he is using. How could a person of judgment believe > that he could have the minimum knowledge of how to use cryptography > and his OpenPGP tool, and believe that he will successfully protect > his privacy? Even intelligence and judgment together do not necessarily lead to perfect decisions. The point when the user *thinks* he has sufficient knowledge or competence does not automatically coincide with the point at which this is true. > The person concerned with the releasing of his personal information > might make the mistakes that you have said. But the kind of person that > you are talking about has minimal knowledge in OpenPGP and the tools to > implement it and has less than adequate reasoning. I would expect an inexperienced user of *anything* to have limited knowledge compared to an "expert," or at least to have not yet fully reflected on and internalised the information he has acquired. The kind of person I have described would clearly have made a poor call in deciding they had done sufficient reading around the subject, but I'm not convinced I have outlined a person of less than adequate reasoning ability. > I have been naive before. But I didn't begin using GnuPGP while I was > still naive about it. I studied how cryptography and OpenPGP worked, > how to use gpg, and how to use it with e-mail and files. Many people are less patient than you must be; I have heard numerous people advocate the "ready, fire,aim" approach to life. > I won't claim that I am better or more knowledgeable than some of the > other smart people on this mailing list, but I will say that I am smart > enough to teach others how it works. Actually, it was my goal to > understand the concepts and the tools well enough to teach others. > You don't have to have the most understanding in order to teach others, > but you do have to have /enough/ understanding in what you want to teach > in order to teach others. Yes, in my first two years at university most staff were assigned to teach topics outside their primary field of expertise, and switched around every year. The stated idea was to enable undergraduates to be taught by people who had recently learnt (or re-learnt) the same material, who would be more in tune with what a new learner would find difficult than the "expert" who, having been fully conversant with the material for several decades, would see it all as trivial. > That is what I was saying in the previous posting. Someone who desires > privacy will do what it takes to get it. That includes dispelling his > naivety with knowledge. Which is an ongoing process. An individual desirous of privacy is likely to continue finding new threats and/or new protections for as long as they care to keep looking. > As for the person not realizing how easy it would be to accidentally > upload a public key to a keyserver, I was never that naive. I was aware > of it from the beginning. My key wasn't on the keyservers, initially (I > chose to upload it later). But I knew that if I was careless it could > wind up there. Were you aware because of something you read, or because of experimentation? When first trying PGP in 2003, I read that uploading your key to a server was a Good Thing but found no evidence to support that assertion. I had no desire to publish my key to a server so I had no reason to experiment with how to do it. I was genuinely shocked when, much later, I found out how easy it was to upload keys and considered the likelihood of mistakes. Fortunately, I had created my key without including my name or email address (because I could not see how including them could aid privacy). > Maybe it is that I am an above average user. Maybe. Maybe it is just > that I exercised judgment. Maybe I expect others to do the same. Maybe. -- Best regards MFPA mailto:expires2010 at ymail.com Life is a holiday. In the same way that glass is a liquid. From kloecker at kde.org Mon Mar 8 21:08:09 2010 From: kloecker at kde.org (Ingo =?iso-8859-1?q?Kl=F6cker?=) Date: Mon, 08 Mar 2010 21:08:09 +0100 Subject: Memory forensics In-Reply-To: <186465807.20100308014834@my_localhost> References: <4B9177DD.2030901@sixdemonbag.org> <4B917ADD.8080309@bellsouth.net> <186465807.20100308014834@my_localhost> Message-ID: <201003082108.10829@thufir.ingo-kloecker.de> On Monday 08 March 2010, MFPA wrote: > Hi John > > On Friday 5 March 2010 at 9:42:53 PM, you wrote: > > Most 'Hibernators' I know are laptop/notebook/netbook Users who are > > too important to wait for boot-up when the unit is Opened. :-D > > Did you mean "important" rather than "impatient?" I guess John was referring to those "important" manager-type laptop/notebook/netbook users. ;-) Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From expires2010 at ymail.com Mon Mar 8 22:38:18 2010 From: expires2010 at ymail.com (MFPA) Date: Mon, 8 Mar 2010 21:38:18 +0000 Subject: key question In-Reply-To: <4B948C8C.8010007@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> Message-ID: <5987695.20100308213818@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Paul On Monday 8 March 2010 at 5:35:08 AM, you wrote: > MFPA wrote: >> On Saturday 6 March 2010 at 8:55:48 AM, you wrote: >> >> >>> On Sat, 27 Feb 2010 03:52:02 +0000 MFPA wrote: >>>>> (b) the person owns the information has the right to >>>>> control how it is disseminated, and >> >> This was someone's re-interpretation of my point. Spot the extra ">"? > Hello MFPA, > I never asserted that you said the key's originator owned the > information stored in the key. I was quoting the context of what your > reply about the originator having "some rights" was about. I would > never try to insert words into your mouth. I just wanted anybody reading this after the event to be clear the quoted line about owning was not anything *I* have said. >>>> The data subject does have various rights concerning the personal >>>> information that is about him. > I used this quote, because I believe > that it states, in your own words, what you have been saying, either > directly or by implication, during this whole discussion thread. Yes, it is the main thing I have ended up discussing. >> The concept of *owning* your personal information makes little sense. > [snipped the rest of the paragraph] > You have began by answering a question that I never asked. I have only > asserted that you believe that the originator has "some rights". I > never used the word "own". I used the word "rights". Since you quoted Robert J. Hansen's line beginning "the person owns the information," I felt I could not reasonably address the question you went on to ask without first putting that point to bed. > Really, I am not interested in talking about what the law says. The law > may be right, or the law may be wrong. I don't want to know what the > law thinks, I want to know what you think. The legal aspect is an integral part of the answer to your question; it demonstrates that rights to privacy and to an element of control over one's personal information are not something I dreamt out of thin air. Whatever different views people may have on moral or ethical rights, there are situations where processing/storage/dissemination of personal information is the subject of an established body of legislation and legal precedent. All that is open to question is the extent and nature of privacy "rights" that may exist beyond the narrow set enshrined in law and the slightly wider set in documents such as ECHR. > For the record, I don't believe that the key holder should upload the > key if the key's originator doesn't want Seeing as we are framing this in terms of "rights," do you believe the holder has a right to upload in these circumstances but "should not" exercise that right? > the key in some public venue > (forget the keyservers, it's about public availability). It's not entirely about public availability. There is also the inability to remove a key from most servers. An individual may be perfectly happy to post the key on their website, or biglumber, or the PGP directory, but not want it on the main server networks. It's about the individual's right to choose what happens to their personal information. > But I don't believe the originator has a /right/ to prevent the key > holder from sharing it. Morally and ethically, I disagree. To use an example with phone numbers: say I had a personal friend who was an insurance broker with a teenaged daughter and elderly parents. I would suggest it's perfectly in order for me to pass to a third party my mate's business number. I definitely have no moral or ethical right to pass on his daughter's or parent's numbers or his personal number. Some would argue he has a right to give me a good beating if I did. In practical terms, the originator currently has no means to prevent this sharing, whether or not he has a right. In a certain narrow set of circumstances, there could be an argument for legal redress if the originator's personal information was shared. > I don't believe the keyserver (or the church) is responsible for > another's actions. But I wanted to see whether you thought the > keyserver should be responsible. I also don't think a webhost should be deemed responsible if somebody posts unlawful material on a site or forum that happens to be hosted on their servers. > The only problem that I can see with the keyserver preventing any > modification of the originator's key, is that it could prevent someone > else from ever revoking their signature on the originator's key. That > would be, of course, if absolutely no modification is allowed. Unless I have missed something, the RFCs have not addressed that point. >>> If the originator does have "rights" to control copying and sharing, are >>> there any "fair use rights" for the person who has a copy of the public >>> key? Should these "rights" of the originator be enforced by some >>> governing body, or should they be merely courtesy or suggestion? >> >> I am not advocating anything remotely equivalent to copyright >> provisions, just protection of personal information. > The "rights" that you are asserting are similar to copyrights. They > both restrict the copying and dissemination of the information > associated with them. I cannot conceive of anything other than a presumption of privacy in respect of the personal information usually present in the UIDs, and have always been amazed at the number of people displaying it openly on their public keys. > So if the key holder can't ethically (not talking > about physically) share the key or modify it, then what "rights" does > the key holder have? Any use whatsoever that in no way compromises the privacy of the originator's personal information. > Your purpose for keyservers and my purpose for keyservers are different. > I believe that keyservers should be for the public dissemination of > keys. You believe that keyservers should be for the private > dissemination of keys. I believe anybody with my details should be able to fetch my key from a server, but looking at my key should give them no extra personal information about me. > What /you/ want is a keyserver that you can upload publicly and share > privately. I want is a keyserver that I can upload publicly and share > publicly. > Remember that they are called public keyservers. And like a public > restroom, they can be used by deviant and saint alike. > You shouldn't assail the public keyservers. My intention was merely to challenge the statement "it's a good idea to upload your key to a keyserver," since I had seen such sentiments expressed without qualification various places previously but had always seen more good reasons against than in favour. I got into a much longer (and more interesting) discussion than expected. > You should be calling for an additional kind of keyserver to fill > the niche of people like you. I think it would work better if the option of increased privacy could be integrated into the mainstream servers. - -- Best regards MFPA mailto:expires2010 at ymail.com The truth is out there. -----BEGIN PGP SIGNATURE----- iQCVAwUBS5VuUaipC46tDG5pAQrTKgP/UGB1GM94CSCNLLtQ3LA2aVylSulKD0+c XIxTmSqdLFOusiCXEm70lcBB6m6v52vC+yI3mtQeRGZaZ3rDHSm4y4LE48T+TzGt e6tUiZthUiVPlcfhVtHfDPvKoHDexc/ZaeIUgWc6s/BTFlMByP+4uvUhNQ1dcxes xzj3iOKXiu0= =ZX4l -----END PGP SIGNATURE----- From wk at gnupg.org Tue Mar 9 09:02:46 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Mar 2010 09:02:46 +0100 Subject: how to suppress warning about gpg-agent? In-Reply-To: <20100308122228.GA9438@home.power> (Alex Efros's message of "Mon, 8 Mar 2010 14:22:28 +0200") References: <20100308004317.GC9899@home.power> <87wrxnnhld.fsf@vigenere.g10code.de> <20100308122228.GA9438@home.power> Message-ID: <87k4tlorbt.fsf@vigenere.g10code.de> On Mon, 8 Mar 2010 13:22, powerman at powerman.name said: > I don't think so. Every project encrypt it backups with different > passwords (needed for security), and right now I can keep just several > dozens of passwords, but with public keys I'll need to keep several dozens > of .gnupg directories instead, which is harder to manage. You would use the same keyring for all users. The option --homedir might be useful for this. > I wonder what is physical sense of this number? Is it safe to hardcode one > number for all user accounts on same server (many servers)? It is a kind of iteration count for the passpharse; i.e. how often to hash the passphrase. This is to mitigate dictionary attacks. A fixed value is fine. > P.S. But I still think much more clear solution is just add option to > suppress warning message and let gpg start own copy of gpg-agent when it We could use --quiet to suppress this warning. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Mar 9 09:25:51 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Mar 2010 09:25:51 +0100 Subject: Release candidate for 2.0.15 In-Reply-To: (carlo bramix's message of "Thu, 18 Feb 2010 18:20:46 +0100") References: Message-ID: <87fx49oq9c.fsf@vigenere.g10code.de> On Thu, 18 Feb 2010 18:20, carlo.bramix at libero.it said: > I tried to compile gnupg-2.0.15rc1 under mingw+msys. As you know we only support cross-building from a Unix platform. > Everything worked fine except the compilation of scd/ccid-driver.c Well, the internal ccid-driver does not work wth Windows. I never tested libusb-win32 and I am not sure whetehr this is a good idea at all. Using the standard PC/SC has the advantage that it works with almost all readers. I have added a configure option to disable the ccid driver: ./configure --disable-ccid-driver Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Mar 9 11:38:31 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Mar 2010 11:38:31 +0100 Subject: [Announce] GnuPG 2.0.15 released Message-ID: <87bpexok48.fsf@vigenere.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG-2 release: Version 2.0.15. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It can be used to encrypt data, create digital signatures, help authenticating using Secure Shell and to provide a framework for public key cryptography. It includes an advanced key management facility and is compliant with the OpenPGP and S/MIME standards. GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.10) in that it splits up functionality into several modules. However, both versions may be installed alongside without any conflict. In fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as included in GnuPG-2 and allows for seamless passphrase caching. The advantage of GnuPG-1 is its smaller size and the lack of dependency on other modules at run and build time. We will keep maintaining GnuPG-1 versions because they are very useful for small systems and for server based applications requiring only OpenPGP support. GnuPG is distributed under the terms of the GNU General Public License (GPL version 3). GnuPG-2 works best on GNU/Linux or *BSD systems. What's New =========== * New command --passwd for GPG. * Fixes a regression in 2.0.14 which prevented unprotection of new or changed gpg-agent passphrases. * Uses libassuan 2.0 which is available as a DSO. Getting the Software ==================== Please follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 2.0.15 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/gnupg/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the FTP server and its mirrors you should find the following files in the gnupg/ directory: gnupg-2.0.15.tar.bz2 (3884k) gnupg-2.0.15.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-2.0.14-2.0.15.diff.bz2 (40k) A patch file to upgrade a 2.0.14 GnuPG source tree. This patch does not include updates of the language files. Note, that we don't distribute gzip compressed tarballs for GnuPG-2. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-2.0.15.tar.bz2 you would use this command: gpg --verify gnupg-2.0.15.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using the command finger wk ,at' g10code.com or using a keyserver like gpg --recv-key 1CE0C630 The distribution key 1CE0C630 is signed by the well known key 5B0358A2. If you get an key expired message, you should retrieve a fresh copy as the expiration date might have been prolonged. NEVER USE A GNUPG VERSION YOU JUST DOWNLOADED TO CHECK THE INTEGRITY OF THE SOURCE - USE AN EXISTING GNUPG INSTALLATION! * If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-2.0.14.tar.bz2, you would run the sha1sum command like this: sha1sum gnupg-2.0.15.tar.bz2 and check that the output matches the first line from the following list: 3596668fb9cc8ec0714463a5009f990fc23434b0 gnupg-2.0.15.tar.bz2 ed35765ae081706c8856fd491201f4f9576135fd gnupg-2.0.14-2.0.15.diff.bz2 Internationalization ==================== GnuPG comes with support for 27 languages. Due to a lot of new and changed strings many translations are not entirely complete. Jedi, Maxim Britov, Jaime Su?rez and Nilg?n Belma Bug?ner have been kind enough to go over their translations and thus the Chinese, German, Russian, Spanish, and Turkish translations are pretty much complete. Documentation ============= We are currently working on an installation guide to explain in more detail how to configure the new features. As of now the chapters on gpg-agent and gpgsm include brief information on how to set up the whole thing. Please watch the GnuPG website for updates of the documentation. In the meantime you may search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. KDE's KMail is the most prominent user of GnuPG-2. In fact it has been developed along with the KMail folks. Mutt users might want to use the configure option "--enable-gpgme" and "set use_crypt_gpgme" in ~/.muttrc to make use of GnuPG-2 to enable S/MIME in addition to a reworked OpenPGP support. The manual is also available online in HTML format at http://www.gnupg.org/documentation/manuals/gnupg/ and in Portable Document Format at http://www.gnupg.org/documentation/manuals/gnupg.pdf . Support ======= Improving GnuPG is costly, but you can help! We are looking for organizations that find GnuPG useful and wish to contribute back. You can contribute by reporting bugs, improve the software, order extensions or support or more general by donating money to the Free Software movement (e.g. http://www.fsfeurope.org/help/donate.en.html). Commercial support contracts for GnuPG are available, and they help finance continued maintenance. g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's principal author, is currently funding GnuPG development. We are always looking for interesting development projects. The GnuPG service directory is available at: http://www.gnupg.org/service.html Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word or answering questions on the mailing lists. Happy Hacking, The GnuPG Team -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 200 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Tue Mar 9 13:32:00 2010 From: wk at gnupg.org (Werner Koch) Date: Tue, 09 Mar 2010 13:32:00 +0100 Subject: Release candidate for Dirmngr 1.1.0 Message-ID: <871vftoev3.fsf@vigenere.g10code.de> Hi! To move forward with the migration to libassuan 2.0, I did a release candidate for Dirmngr: ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-1.1.0rc1.tar.bz2 (544k) ftp://ftp.gnupg.org/gcrypt/alpha/dirmngr/dirmngr-1.1.0rc1.tar.bz2.sig Changes are: * Fixed a resource problem with LDAP CRLs. * Fixed a bad EOF detection with HTTP CRLs. * Made "dirmngr-client --url --load-crl URL" work. * New option --ignore-cert-extension. And well, it requires libassuan-2. Please let us know if you notice any new problems. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From cathy.smith at pnl.gov Tue Mar 9 21:16:23 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Tue, 9 Mar 2010 12:16:23 -0800 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B76B4872@EMAIL04.pnl.gov> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B7A11AC5@EMAIL04.pnl.gov> Folks I'm at the next step of signing the keys and creating the trust model. I've signed 3 keys and set the trust. When I list the keys, I get the following: [ir at app1 ~]$ gpg --list-keys gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 4 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 4u gpg: next trustdb check due at 2020-02-29 What does it mean that the next trustdb check is due in 2020? I'm not clear on how frequently the trustdb needs to be updated. I assumed that the trustdb updated each time I imported a key, or when I set the trust on an imported key. Thanks for your help. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Smith, Cathy Sent: Wednesday, February 24, 2010 6:47 PM To: gnupg-users at gnupg.org Subject: Migrating from PGP to GPG question Folks We are starting to migrate from OpenPGP to GnuPG. One of the batch jobs I have to convert uses: pgp +force This is supposed to assume a "yes" to any interactive questions. I wasn't clear after reading the man pages about the gpg --batch option. Can someone tell me if the --batch and the --yes options are mutually exclusive? Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From cathy.smith at pnl.gov Wed Mar 10 00:46:20 2010 From: cathy.smith at pnl.gov (Smith, Cathy) Date: Tue, 9 Mar 2010 15:46:20 -0800 Subject: Migrating from PGP to GPG question References: <4A009880.8090807@christiantena.net> Message-ID: <70086D201BD484439914C36F5C8BF16101A1B7A11B7A@EMAIL04.pnl.gov> Folks A quick question about signing the imported PGP public keys. One of the options under gpg --edit-key is enable. Do I need to enable the key or is that the default? Thanks for your help. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov -----Original Message----- From: Smith, Cathy Sent: Wednesday, February 24, 2010 6:47 PM To: gnupg-users at gnupg.org Subject: Migrating from PGP to GPG question Folks We are starting to migrate from OpenPGP to GnuPG. One of the batch jobs I have to convert uses: pgp +force This is supposed to assume a "yes" to any interactive questions. I wasn't clear after reading the man pages about the gpg --batch option. Can someone tell me if the --batch and the --yes options are mutually exclusive? Thanks. Cathy --- Cathy L. Smith IT Engineer Pacific Northwest National Laboratory Phone:? 509.375.2687 Fax:??? ????509.375.2330 Email:? cathy.smith at pnl.gov From expires2010 at ymail.com Wed Mar 10 10:42:19 2010 From: expires2010 at ymail.com (MFPA) Date: Wed, 10 Mar 2010 09:42:19 +0000 Subject: Migrating from PGP to GPG question In-Reply-To: <70086D201BD484439914C36F5C8BF16101A1B7A11B7A@EMAIL04.pnl.gov> References: <4A009880.8090807@christiantena.net> <70086D201BD484439914C36F5C8BF16101A1B7A11B7A@EMAIL04.pnl.gov> Message-ID: <176120470.20100310094219@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Cathy On Tuesday 9 March 2010 at 11:46:20 PM, you wrote: > Folks > A quick question about signing the imported PGP public keys. One > of the options under gpg --edit-key is enable. Do I need to enable the key or is that the default? Enable is default, same as in PGP. Both offer the ability to disable a key, so that you cannot encrypt to it or sign with it but you can still decrypt and can still verify signatures. - -- Best regards MFPA mailto:expires2010 at ymail.com Life is far too important a thing ever to talk seriously about -----BEGIN PGP SIGNATURE----- iQCVAwUBS5dpm6ipC46tDG5pAQoeJQQAyfBu7fd8Yr8QqGCjodqc7R0YgILUbQdB bU4K9/S1fLe/LC2e7G8Kx/enGE7MST6owPKx+Bi/my0j8Jtr5Uu4kgn6223FTgbo Hkw84r02PGhQswYn+zH26FoH/oWDSdlKey927C5fSExbGJjqtGznBSNuJ0KnZTA3 CO0Rno1os3U= =9lRF -----END PGP SIGNATURE----- From john_espiro at yahoo.com Thu Mar 11 07:25:45 2010 From: john_espiro at yahoo.com (john espiro) Date: Wed, 10 Mar 2010 22:25:45 -0800 (PST) Subject: No subject Message-ID: <759584.37483.qm@web46010.mail.sp1.yahoo.com> I am using paperkey 1.2 from http://www.jabberwocky.com/software/paperkey/ and dmtxwrite version 0.7.3 libdmtx version 0.7.3 If I run this command: gpg --export-secret-key mykey at me.com | paperkey --ignore-crc-error --output-type raw | dmtxwrite -e8 -f png > my_pdf_file.png I get the 2D barcode generated correctly -- if the key is 1024 or 2048. If I try this with a secret key that is 4096, I am left with 20x20 pixel image that in no way looks complete. I wonder if there's a limitation with either paperkey or dmtxwrite, or if I am doing something wrong. If this isn't the right forum, please let me know... John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john_espiro at yahoo.com Thu Mar 11 09:16:47 2010 From: john_espiro at yahoo.com (john espiro) Date: Thu, 11 Mar 2010 00:16:47 -0800 (PST) Subject: Paperkey (Was: Re: ) Message-ID: <284819.31224.qm@web46004.mail.sp1.yahoo.com> Sorry for the empty subject... fixed now ________________________________ From: john espiro To: gnupg-users at gnupg.org Sent: Thu, March 11, 2010 7:25:45 AM Subject: I am using paperkey 1.2 from http://www.jabberwocky.com/software/paperkey/ and dmtxwrite version 0.7.3 libdmtx version 0.7.3 If I run this command: gpg --export-secret-key mykey at me.com | paperkey --ignore-crc-error --output-type raw | dmtxwrite -e8 -f png > my_pdf_file.png I get the 2D barcode generated correctly -- if the key is 1024 or 2048. If I try this with a secret key that is 4096, I am left with 20x20 pixel image that in no way looks complete. I wonder if there's a limitation with either paperkey or dmtxwrite, or if I am doing something wrong. If this isn't the right forum, please let me know... John -------------- next part -------------- An HTML attachment was scrubbed... URL: From firasmr786 at gmail.com Thu Mar 11 09:29:15 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Thu, 11 Mar 2010 13:59:15 +0530 Subject: Off-The-Record Email Message-ID: <4B98A9DB.1070309@gmail.com> I'm a user of Pidgin with the off-the-record plugin: http://www.cypherpunks.ca/otr/help/3.2.0/levels.php?lang=en http://www.cypherpunks.ca/otr/help/3.2.0/authenticate.php?lang=en Is there a way to be able to have off-the-record email conversations with GPG technology? It would definitely be a terrific thing. Email is traditionally supposed to mirror paper mail and paper mail is usually not thought of as being off-the-record, so I guess that's probably why no one really thinks about it. But if the technology exists, it would be fantastic to have OTR email conversations every now and then. I came across some interesting articles and papers worth checking out: http://circle.ubc.ca/handle/2429/18249 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.2823 but nothing out there for users to be able to use. From firasmr786 at gmail.com Thu Mar 11 09:39:33 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Thu, 11 Mar 2010 14:09:33 +0530 Subject: Implications Of The Recent RSA Vulnerability Message-ID: <4B98AC45.1020207@gmail.com> With the recent news of researchers being able to crack 1024-bit RSA keys using power fluctuations, I was wondering if it would be a good idea to switch the RSA keys I have to some other algorithm. Both my signing and encryption keys are 4096-bit keys. Am I vulnerable to this security hole? Is it possible to generate a new keypair and retain/transfer the old signatures from my email buddies? Ref: http://www.engadget.com/2010/03/09/1024-bit-rsa-encryption-cracked-by-carefully-starving-cpu-of-ele/ From firasmr786 at gmail.com Thu Mar 11 09:20:08 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Thu, 11 Mar 2010 13:50:08 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints Message-ID: <4B98A7B8.8080408@gmail.com> I'm a user of Pidgin with the off-the-record plugin: http://www.cypherpunks.ca/otr/help/3.2.0/levels.php?lang=en http://www.cypherpunks.ca/otr/help/3.2.0/authenticate.php?lang=en In order to use GPG based email encryption properly, it's important for users to authenticate with each other and verify that the public keys downloaded from the keyservers have fingerprints that match the ones on their respective computers. Typically the securest way to crosscheck fingerprints is via a secure channel such as an in-person meeting. But a phone call comes pretty close too (assuming the fact that it would be difficult to mount a voice man-in-the-middle attack). But what if there was no way to meet in person, make a phone call or a VoIP call. I was wondering if using Pidgin with the OTR plugin (and authenticating the OTR session using the Q&A method; see above link) could be considered a secure channel to exchange and crosscheck GPG key fingerprints in such a case. Any thoughts? From danm at prime.gushi.org Thu Mar 11 10:59:45 2010 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Thu, 11 Mar 2010 04:59:45 -0500 (EST) Subject: Implications Of The Recent RSA Vulnerability In-Reply-To: <4B98AC45.1020207@gmail.com> References: <4B98AC45.1020207@gmail.com> Message-ID: On Thu, 11 Mar 2010, erythrocyte wrote: > With the recent news of researchers being able to crack 1024-bit RSA > keys using power fluctuations, I was wondering if it would be a good > idea to switch the RSA keys I have to some other algorithm. Both my > signing and encryption keys are 4096-bit keys. Am I vulnerable to this > security hole? > > Is it possible to generate a new keypair and retain/transfer the old > signatures from my email buddies? > > Ref: > http://www.engadget.com/2010/03/09/1024-bit-rsa-encryption-cracked-by-carefully-starving-cpu-of-ele/ Okay, let me sum up this article for you: Researchers who had physical enough access to be able to rewire the private-key-holder's system's power supply were able to compromise that system. If you're at that point, I don't think key length is your problem. -Dan Mahoney -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From wk at gnupg.org Thu Mar 11 11:35:24 2010 From: wk at gnupg.org (Werner Koch) Date: Thu, 11 Mar 2010 11:35:24 +0100 Subject: Off-The-Record Email In-Reply-To: <4B98A9DB.1070309@gmail.com> (erythrocyte's message of "Thu, 11 Mar 2010 13:59:15 +0530") References: <4B98A9DB.1070309@gmail.com> Message-ID: <87mxyfkuxf.fsf@vigenere.g10code.de> On Thu, 11 Mar 2010 09:29, firasmr786 at gmail.com said: > Is there a way to be able to have off-the-record email conversations > with GPG technology? It would definitely be a terrific thing. Email is I was pondering with the idea to use the WoT or an existsing OpenPGP key for fingerprint checking. No concrete design, though. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From christoph.anton.mitterer at physik.uni-muenchen.de Thu Mar 11 13:03:33 2010 From: christoph.anton.mitterer at physik.uni-muenchen.de (Christoph Anton Mitterer) Date: Thu, 11 Mar 2010 13:03:33 +0100 Subject: Off-The-Record Email In-Reply-To: <87mxyfkuxf.fsf@vigenere.g10code.de> References: <4B98A9DB.1070309@gmail.com> <87mxyfkuxf.fsf@vigenere.g10code.de> Message-ID: <1268309013.17480.14.camel@etppc09.garching.physik.uni-muenchen.de> I'd personally prefer having a real OpenPGP plugin for gpg,... Wouldn't that be the real solution? Cheers, Chris. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3387 bytes Desc: not available URL: From nagaram.c at symphony.cc Thu Mar 11 13:52:21 2010 From: nagaram.c at symphony.cc (nagaram.c) Date: Thu, 11 Mar 2010 06:52:21 -0600 Subject: gpg encryption failed no public key Message-ID: <3CED30E0253D4F8D988381AE0716287A@symphony.com> Hi, I am new to gpg command line utility for file encryption/decryption. I have installed gpg4win v 2.0.2 & trying to encrypt a file with a key that I imported which is also listing while typing list-keys command The issue is that I am getting encryption failed no public key while typing in the below command >gpg -recipient testUserID -encrypt abc.txt In one of the posts I found that this is due to not specifying keyring location with using -keyring option But while I used below command with specifying keyring as below >gpg -recipient testIUserID -keyring C:/Documents & Settings/username/Application Data/gnupg/pubring.gpg -encrypt abc.txt I am getting below error gpg: keyblock resource 'C:/Documents & Settings/username/Application Data/gnupg/C:/Documents' no such file or directory usage: gpg [options] [filename] Please help Thanks, Nag -------------- next part -------------- An HTML attachment was scrubbed... URL: From firasmr786 at gmail.com Thu Mar 11 16:33:37 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Thu, 11 Mar 2010 21:03:37 +0530 Subject: Implications Of The Recent RSA Vulnerability In-Reply-To: References: <4B98AC45.1020207@gmail.com> Message-ID: <4B990D51.3000709@gmail.com> On 3/11/2010 3:29 PM, Dan Mahoney, System Admin wrote: > On Thu, 11 Mar 2010, erythrocyte wrote: >> Ref: >> http://www.engadget.com/2010/03/09/1024-bit-rsa-encryption-cracked-by-carefully-starving-cpu-of-ele/ >> > > Okay, let me sum up this article for you: > > Researchers who had physical enough access to be able to rewire the > private-key-holder's system's power supply were able to compromise that > system. > > If you're at that point, I don't think key length is your problem. Alrighty. But doesn't this compromise the layer of security offered by the passphrase? What's the point having a passphrase at all, if it's so easy to compromise a private key? From rjh at sixdemonbag.org Thu Mar 11 16:43:03 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 11 Mar 2010 10:43:03 -0500 Subject: Implications Of The Recent RSA Vulnerability In-Reply-To: <4B990D51.3000709@gmail.com> References: <4B98AC45.1020207@gmail.com> <4B990D51.3000709@gmail.com> Message-ID: <2BEDF9B7-4AF9-46FE-B270-FB50B6F13B96@sixdemonbag.org> > Alrighty. But doesn't this compromise the layer of security offered by > the passphrase? What's the point having a passphrase at all, if it's so > easy to compromise a private key? You might as well ask, "what's the point of OpenPGP at all, if it's so easy to Van Eyck your monitor?" Or, "if it's so easy to plant a keylogger?" Or, "if it's so easy for someone to whisk me up off the street into a dark van and play the bongos on my kneecaps until I tell my secrets?" Or? the list goes on and on. OpenPGP assumes the endpoints of the communication are secure. If they're not, there's nothing OpenPGP can do to help you make it secure. If you think this is a problem, then I would observe your microwave oven does a really lousy job of keeping your beer cold. All tools have preconditions: the existence of a precondition doesn't mean the tool is broken. The precondition for a microwave oven is, "the food must need heating." The precondition for OpenPGP is, "the endpoints must be secure." -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3916 bytes Desc: not available URL: From dave.smith at st.com Thu Mar 11 16:43:32 2010 From: dave.smith at st.com (David SMITH) Date: Thu, 11 Mar 2010 15:43:32 +0000 Subject: Implications Of The Recent RSA Vulnerability In-Reply-To: <4B990D51.3000709@gmail.com> References: <4B98AC45.1020207@gmail.com> <4B990D51.3000709@gmail.com> Message-ID: <4B990FA4.6080704@st.com> erythrocyte wrote: > On 3/11/2010 3:29 PM, Dan Mahoney, System Admin wrote: >> On Thu, 11 Mar 2010, erythrocyte wrote: >>> Ref: >>> http://www.engadget.com/2010/03/09/1024-bit-rsa-encryption-cracked-by-carefully-starving-cpu-of-ele/ >>> >> Okay, let me sum up this article for you: >> >> Researchers who had physical enough access to be able to rewire the >> private-key-holder's system's power supply were able to compromise that >> system. >> >> If you're at that point, I don't think key length is your problem. > > Alrighty. But doesn't this compromise the layer of security offered by > the passphrase? What's the point having a passphrase at all, if it's so > easy to compromise a private key? Well, I've only read the "engadget" writeup, but assuming it's correct, the attack only applies to systems where the attacker has physical access to a system containing the private key. As a general rule, when using GnuPG you would keep your private key on your local system, so it would only be a problem if your local system were cracked and the attacker could download the private key from your machine, or if your machine were to fall into the attacker's hands. However, even if the attacker manages to get hold of your private key file, they still need the passphrase to get the key so that they can use it for the RSA encryption operation they want to attack using this technique. If they have both the private key /and/ the passphrase, then the game is already over. So, basically, it's highly unlikely that you're vulnerable to this attack. The sort of systems that are vulnerable to the attack are ones where the RSA key is embedded inside such that the attacker, with physical access to the system, can use it for the encryption operation but not read it out. This attack allows the cracker to determine the embedded key. In terms of whether it compromises the passphrase protection, no. To be able to use the attack, the attacker needs to run the RSA algorithm with your private key. To be able to do that, they need your passphrase in the first place, otherwise, how can they get your private key to feed in to RSA? From dshaw at jabberwocky.com Thu Mar 11 16:45:55 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 11 Mar 2010 10:45:55 -0500 Subject: Implications Of The Recent RSA Vulnerability In-Reply-To: <4B98AC45.1020207@gmail.com> References: <4B98AC45.1020207@gmail.com> Message-ID: On Mar 11, 2010, at 3:39 AM, erythrocyte wrote: > With the recent news of researchers being able to crack 1024-bit RSA > keys using power fluctuations, I was wondering if it would be a good > idea to switch the RSA keys I have to some other algorithm. Both my > signing and encryption keys are 4096-bit keys. Am I vulnerable to this > security hole? Basically, no, and for several reasons. There are a few things that need to be understood about the new attack. Briefly, this is an attack that relies on manipulating the power supply to the CPU, in order to cause it to make errors in RSA signatures. If you process a lot of these errored signatures, you can recover the secret key. In practice, and with GPG, however, it's a pretty hard attack to mount. First of all, you have to have access to and the ability to manipulate the power supply to the CPU. If someone had that kind of access to your machine, there are better attacks that can be mounted (keyboard sniffer, copying the hard drive, etc.) Secondly, your 4096 bit key is much larger than the 1024-bit keys the researchers were able to break. Thirdly, the attacker needs thousands and thousands of signatures with errors in them. This takes time to gather, increasing the amount of time that the attacker needs to be manipulating your power supply. Lastly, and perhaps most significantly, GPG has resistance to this particular attack anyway: it checks all signatures after creation to make sure that nothing like this happened. If an attacker managed to make the CPU hiccup and make an error when generating the signature, the signature check would see the signature was invalid and cause GPG to exit with an error. David From rjh at sixdemonbag.org Thu Mar 11 16:46:54 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 11 Mar 2010 10:46:54 -0500 Subject: Off-The-Record Email In-Reply-To: <4B98A9DB.1070309@gmail.com> References: <4B98A9DB.1070309@gmail.com> Message-ID: <24E68274-ADD9-4F23-A8DB-474759C3D682@sixdemonbag.org> > Is there a way to be able to have off-the-record email conversations > with GPG technology? It would definitely be a terrific thing. Not really. OTR uses DHKEA for symmetric key negotiation. This is an interactive protocol: you send some information, the other person sends some information back, back-and-forth a few times until a symmetric key emerges from the mathemagic. Email is not an interactive protocol. You could probably invent a way to do OTR via email, but it would probably be a horrible kludge. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3916 bytes Desc: not available URL: From firasmr786 at gmail.com Thu Mar 11 16:51:05 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Thu, 11 Mar 2010 21:21:05 +0530 Subject: Implications Of The Recent RSA Vulnerability In-Reply-To: <2BEDF9B7-4AF9-46FE-B270-FB50B6F13B96@sixdemonbag.org> References: <4B98AC45.1020207@gmail.com> <4B990D51.3000709@gmail.com> <2BEDF9B7-4AF9-46FE-B270-FB50B6F13B96@sixdemonbag.org> Message-ID: <4B991169.4000800@gmail.com> On 3/11/2010 9:13 PM, Robert J. Hansen wrote: > OpenPGP assumes the endpoints of the communication are secure. > If they're not, there's nothing OpenPGP can do to help you make it secure. > ...All tools have preconditions: the existence of a precondition doesn't mean the tool is broken. > The precondition for a microwave oven is, "the food must need heating." > The precondition for OpenPGP is, "the endpoints must be secure." How very eloquently put :-) . Makes sense. Thanks :-) . From firasmr786 at gmail.com Thu Mar 11 16:52:21 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Thu, 11 Mar 2010 21:22:21 +0530 Subject: Implications Of The Recent RSA Vulnerability In-Reply-To: References: <4B98AC45.1020207@gmail.com> Message-ID: <4B9911B5.4040902@gmail.com> On 3/11/2010 9:15 PM, David Shaw wrote: > Basically, no, and for several reasons. There are a few things that need to be understood about the new attack. Briefly, this is an attack that relies on manipulating the power supply to the CPU, in order to cause it to make errors in RSA signatures. If you process a lot of these errored signatures, you can recover the secret key. > > In practice, and with GPG, however, it's a pretty hard attack to mount. First of all, you have to have access to and the ability to manipulate the power supply to the CPU. If someone had that kind of access to your machine, there are better attacks that can be mounted (keyboard sniffer, copying the hard drive, etc.) Secondly, your 4096 bit key is much larger than the 1024-bit keys the researchers were able to break. Thirdly, the attacker needs thousands and thousands of signatures with errors in them. This takes time to gather, increasing the amount of time that the attacker needs to be manipulating your power supply. Lastly, and perhaps most significantly, GPG has resistance to this particular attack anyway: it checks all signatures after creation to make sure that nothing like this happened. If an attacker managed to make the CPU hiccup and make an error when generating the signature, the signature check would see the signature was invalid and cause GPG to exit w ith an error. Thanks for the explanation. Makes sense :-) . From kgo at grant-olson.net Thu Mar 11 19:23:51 2010 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 11 Mar 2010 13:23:51 -0500 Subject: gpg encryption failed no public key In-Reply-To: <3CED30E0253D4F8D988381AE0716287A@symphony.com> References: <3CED30E0253D4F8D988381AE0716287A@symphony.com> Message-ID: <4B993537.70509@grant-olson.net> On 3/11/2010 7:52 AM, nagaram.c wrote: > Hi, > > > > I am new to gpg command line utility for file encryption/decryption. I > have installed gpg4win v 2.0.2 & trying to encrypt a file with a key > that I imported which is also listing while typing list-keys command > > > > The issue is that I am getting encryption failed no public key while > typing in the below command > >>gpg ?recipient testUserID ?encrypt abc.txt > > > > In one of the posts I found that this is due to not specifying keyring > location with using ?keyring option > > > > But while I used below command with specifying keyring as below > > > >>gpg ?recipient testIUserID ?keyring C:/Documents & > Settings/username/Application Data/gnupg/pubring.gpg ?encrypt abc.txt > > > > I am getting below error > > > > gpg: keyblock resource ?C:/Documents & Settings/username/Application > Data/gnupg/C:/Documents? no such file or directory > > usage: gpg [options] [filename] > > The first command isn't working because you need to double-dash the options. "--recipient" and "--encrypt". You really shouldn't need the -keyring option if you're using your default keyring. But for the option to work, you would need quotes around the filename since it has spaces in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Thu Mar 11 23:53:03 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 11 Mar 2010 17:53:03 -0500 Subject: Paperkey (Was: Re: ) In-Reply-To: <284819.31224.qm@web46004.mail.sp1.yahoo.com> References: <284819.31224.qm@web46004.mail.sp1.yahoo.com> Message-ID: On Mar 11, 2010, at 3:16 AM, john espiro wrote: > I am using paperkey 1.2 from http://www.jabberwocky.com/software/paperkey/ > and > dmtxwrite version 0.7.3 > libdmtx version 0.7.3 > > If I run this command: > gpg --export-secret-key mykey at me.com | paperkey --ignore-crc-error --output-type raw | dmtxwrite -e8 -f png > my_pdf_file.png > > I get the 2D barcode generated correctly -- if the key is 1024 or 2048. If I try this with a secret key that is 4096, I am left with 20x20 pixel image that in no way looks complete. I wonder if there's a limitation with either paperkey or dmtxwrite, or if I am doing something wrong. Paperkey doesn't care what size the key is. Try doing that same command line, but use "wc -c" instead of the dmtxwrite part to check that the output is larger than with a 2048 bit key. Perhaps dmtxwrite is having a problem? David From mlb at imparisystems.com Fri Mar 12 01:40:36 2010 From: mlb at imparisystems.com (Matt Burkhardt) Date: Thu, 11 Mar 2010 19:40:36 -0500 Subject: Question about passphrase-fd Message-ID: <1268354436.2892.43.camel@mlb-dell> Long story short, I use amanda for my backups and I've been using encryptsimple for my backups. My PC died completely, and I'm trying to get the backups onto another machine. I've stepped through the programs and have found that it's calling gpg with gpg --batch --quiet --no-mdc-warning --decrypt --passphrase-fd 3 3 From dshaw at jabberwocky.com Fri Mar 12 03:36:03 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 11 Mar 2010 21:36:03 -0500 Subject: Question about passphrase-fd In-Reply-To: <1268354436.2892.43.camel@mlb-dell> References: <1268354436.2892.43.camel@mlb-dell> Message-ID: On Mar 11, 2010, at 7:40 PM, Matt Burkhardt wrote: > Long story short, I use amanda for my backups and I've been using encryptsimple for my backups. My PC died completely, and I'm trying to get the backups onto another machine. I've stepped through the programs and have found that it's calling gpg with > > gpg --batch --quiet --no-mdc-warning --decrypt --passphrase-fd 3 3 > I was under the impression that the passphrase (.am_passphrase) was just a clear text secret phrase. However, the gpg call errors out with: > > gpg: decryption failed: bad key The "bad key" error doesn't mean the passphrase is wrong (that would be "invalid passphrase"). It often means that the file you are decrypting is corrupt. Was the file you are decrypting encrypted with a passphrase only or with a public key? David From dougb at dougbarton.us Fri Mar 12 06:24:26 2010 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 11 Mar 2010 21:24:26 -0800 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B98A7B8.8080408@gmail.com> References: <4B98A7B8.8080408@gmail.com> Message-ID: <4B99D00A.10507@dougbarton.us> On 3/11/2010 12:20 AM, erythrocyte wrote: > But what if there was no way to meet in person, make a phone call or a > VoIP call. I was wondering if using Pidgin with the OTR plugin (and > authenticating the OTR session using the Q&A method; see above link) > could be considered a secure channel to exchange and crosscheck GPG key > fingerprints in such a case. "Secure" in this context is a relative term. (Note, I'm a long time user of pidgin+OTR and a longer-time user of PGP, so I'm actually familiar with what you're proposing.) If you know the person you're IM'ing well enough, you can do a pretty good job of validating their OTR fingerprint. But how "secure" that is depends on your threat model. Are you going to be encrypting sensitive financial data? Fruit cake recipes? Blueprints for nuclear weapons? Is the security of your communication something that you're wagering your life (or the lives of others) on? Is your communication of high enough value that your associate could have a gun to their head held by someone who is forcing them to answer your OTR questions truthfully? (Remember, you can't see them, or hear stress in their voice, you can only see what they type.) Have you and your associate pre-established a code question to handle the gun-to-the-head scenario? Hopefully that's enough questions to illustrate the point. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From nagaram.c at symphony.cc Fri Mar 12 07:11:51 2010 From: nagaram.c at symphony.cc (nagaram.c) Date: Fri, 12 Mar 2010 00:11:51 -0600 Subject: gpg encryption failed no public key In-Reply-To: <4B993537.70509@grant-olson.net> References: <3CED30E0253D4F8D988381AE0716287A@symphony.com> <4B993537.70509@grant-olson.net> Message-ID: <1D6024DDF0E3421AAE76BF2D02B610CC@symphony.com> Thanks for the response, the command >gpg --recepient testuserID --encrypt abc.txt I used has double dashes still I gives the same error. I think I am using the default keyring as I didn't change its location Thanks, Nag -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Grant Olson Sent: Thursday, March 11, 2010 12:24 PM To: gnupg-users at gnupg.org Subject: Re: gpg encryption failed no public key On 3/11/2010 7:52 AM, nagaram.c wrote: > Hi, > > > > I am new to gpg command line utility for file encryption/decryption. I > have installed gpg4win v 2.0.2 & trying to encrypt a file with a key > that I imported which is also listing while typing list-keys command > > > > The issue is that I am getting encryption failed no public key while > typing in the below command > >>gpg -recipient testUserID -encrypt abc.txt > > > > In one of the posts I found that this is due to not specifying keyring > location with using -keyring option > > > > But while I used below command with specifying keyring as below > > > >>gpg -recipient testIUserID -keyring C:/Documents & > Settings/username/Application Data/gnupg/pubring.gpg -encrypt abc.txt > > > > I am getting below error > > > > gpg: keyblock resource 'C:/Documents & Settings/username/Application > Data/gnupg/C:/Documents' no such file or directory > > usage: gpg [options] [filename] > > The first command isn't working because you need to double-dash the options. "--recipient" and "--encrypt". You really shouldn't need the -keyring option if you're using your default keyring. But for the option to work, you would need quotes around the filename since it has spaces in it. From firasmr786 at gmail.com Fri Mar 12 08:36:46 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Fri, 12 Mar 2010 13:06:46 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B99D00A.10507@dougbarton.us> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> Message-ID: <4B99EF0E.3040908@gmail.com> On 3/12/2010 10:54 AM, Doug Barton wrote: > "Secure" in this context is a relative term. (Note, I'm a long time user > of pidgin+OTR and a longer-time user of PGP, so I'm actually familiar > with what you're proposing.) If you know the person you're IM'ing well > enough, you can do a pretty good job of validating their OTR > fingerprint. But how "secure" that is depends on your threat model. Are > you going to be encrypting sensitive financial data? Fruit cake recipes? > Blueprints for nuclear weapons? Is the security of your communication > something that you're wagering your life (or the lives of others) on? Hmmm...if I understand it correctly, if and when the OTR session is fully verified/authenticated it doesn't matter what the content of the data you transmit is. It could be any of the above - fruit cake recipes, financial data, et al. > Is your communication of high enough value that your associate could have a > gun to their head held by someone who is forcing them to answer your OTR > questions truthfully? (Remember, you can't see them, or hear stress in > their voice, you can only see what they type.) Have you and your > associate pre-established a code question to handle the gun-to-the-head > scenario? > > Hopefully that's enough questions to illustrate the point. :) I don't think OTR technology can claim to solve the gun-to-the-head scenario. Although it claims to give users the benefit of perfect-forward-secrecy and repudiation, I think such things matter little in a court of law. People get convicted either wrongly or rightly, based on spoofed emails and plain-text emails all the time. I think the same goes for GPG based email encryption as well. GPG-encryption doesn't protect end-points. It only protects the channel between them. The more end-points there are, the more vulnerable such encrypted emails become. The only scenario I see that minimizes end-point vulnerability is to encrypt data to oneself. One end-point, one source of potential compromise. Even that is susceptible to a rubber hose attack. In some countries people are required to decrypt data if asked by law enforcement and refusal to comply means jail time. Bottom-line IMHO, you can't let out your inner demons just because there's encryption technology. That isn't what it was built for afaik. The safest possible place for data to reside in is within the confines of one's own brain. So I envision myself using OTR-based-IM and GPG-based-email-encryption only with a prior understanding of these deficiencies. If I'm confident enough that the end-points are secure during an OTR-IM session that has then been authenticated, can I use such an IM session to exchange and crosscheck my friend's GPG public key fingerprint that I've downloaded from a keyserver for email encryption purposes? PS: Despite the much hyped security behind SSL based websites such as online banking, if you care to look around you'll soon realize that even that isn't as bullet-proof as one would like to think. There have been instances where unscrupulous people have gotten digitally signed certificates from TTPs/CAs (reputed ones I might add) for businesses that don't exist, etc. And with companies like Thawte that besides their traditional for-profit CA business model, also provide individual users free SSL certificates using email-based authentication, a lay person who doesn't recognize the different kinds of Thawte certificates could as well trust that a given bank website is genuine when in fact it might be a fraud. All in all, encryption isn't the panacea that we'd like it to be. At least not yet. There are multiple attack vectors that crop up all the time - from social engineering to mathematical/technological. -- erythrocyte From f.schwind at chili-radiology.com Fri Mar 12 09:37:49 2010 From: f.schwind at chili-radiology.com (Florian Schwind) Date: Fri, 12 Mar 2010 09:37:49 +0100 Subject: gpg encryption failed no public key In-Reply-To: <1D6024DDF0E3421AAE76BF2D02B610CC@symphony.com> References: <3CED30E0253D4F8D988381AE0716287A@symphony.com> <4B993537.70509@grant-olson.net> <1D6024DDF0E3421AAE76BF2D02B610CC@symphony.com> Message-ID: <4B99FD5D.5070505@chili-radiology.com> Hi, On 12.03.2010 07:11, nagaram.c wrote: > Thanks for the response, the command > >> gpg --recepient testuserID --encrypt abc.txt > > I used has double dashes still I gives the same error. > > I think I am using the default keyring as I didn't change its location try using the "--homedir " option > Thanks, > Nag Greetings Florian > -----Original Message----- > From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] > On Behalf Of Grant Olson > Sent: Thursday, March 11, 2010 12:24 PM > To: gnupg-users at gnupg.org > Subject: Re: gpg encryption failed no public key > > On 3/11/2010 7:52 AM, nagaram.c wrote: >> Hi, >> >> >> >> I am new to gpg command line utility for file encryption/decryption. I >> have installed gpg4win v 2.0.2& trying to encrypt a file with a key >> that I imported which is also listing while typing list-keys command >> >> >> >> The issue is that I am getting encryption failed no public key while >> typing in the below command >> >>> gpg -recipient testUserID -encrypt abc.txt >> >> >> >> In one of the posts I found that this is due to not specifying keyring >> location with using -keyring option >> >> >> >> But while I used below command with specifying keyring as below >> >> >> >>> gpg -recipient testIUserID -keyring C:/Documents& >> Settings/username/Application Data/gnupg/pubring.gpg -encrypt abc.txt >> >> >> >> I am getting below error >> >> >> >> gpg: keyblock resource 'C:/Documents& Settings/username/Application >> Data/gnupg/C:/Documents' no such file or directory >> >> usage: gpg [options] [filename] >> >> > > The first command isn't working because you need to double-dash the > options. "--recipient" and "--encrypt". > > You really shouldn't need the -keyring option if you're using your > default keyring. But for the option to work, you would need quotes > around the filename since it has spaces in it. From mlb at imparisystems.com Fri Mar 12 11:27:45 2010 From: mlb at imparisystems.com (Matt Burkhardt) Date: Fri, 12 Mar 2010 05:27:45 -0500 Subject: Question about passphrase-fd In-Reply-To: References: <1268354436.2892.43.camel@mlb-dell> Message-ID: <1268389665.2822.8.camel@mlb-dell> On Thu, 2010-03-11 at 21:36 -0500, David Shaw wrote: > > Long story short, I use amanda for my backups and I've been using > encryptsimple for my backups. My PC died completely, and I'm trying > to get the backups onto another machine. I've stepped through the > programs and have found that it's calling gpg with > > > > gpg --batch --quiet --no-mdc-warning --decrypt --passphrase-fd 3 > 3 > > > I was under the impression that the passphrase (.am_passphrase) was > just a clear text secret phrase. However, the gpg call errors out > with: > > > > gpg: decryption failed: bad key > > The "bad key" error doesn't mean the passphrase is wrong (that would > be "invalid passphrase"). It often means that the file you are > decrypting is corrupt. Was the file you are decrypting encrypted with > a passphrase only or with a public key? Here's the code that calls gpg for the encryption: gpg --batch --no-secmem-warning --disable-mdc --symmetric --cipher-algo AES256 --passphrase-fd 3 3 From rjh at sixdemonbag.org Fri Mar 12 13:03:05 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 12 Mar 2010 07:03:05 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B99EF0E.3040908@gmail.com> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> Message-ID: <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> > I don't think OTR technology can claim to solve the gun-to-the-head > scenario. Although it claims to give users the benefit of > perfect-forward-secrecy and repudiation, I think such things matter > little in a court of law. People get convicted either wrongly or > rightly, based on spoofed emails and plain-text emails all the time. Sources, please: I'd like to see citations for "people get convicted ... based on spoofed emails and plain-text emails all the time." Based on plain-text emails, sure. Spoofed emails, though, that's a bit of a stretch and I'm going to need to see cites. Either way, this kind of raises the question, "so why do you want to use OTR, anyway?" If the entire point of OTR is PFS/R, and you don't believe OTR can solve PFS/R, then why use OTR? > So I envision myself using OTR-based-IM and GPG-based-email-encryption > only with a prior understanding of these deficiencies. If I'm confident > enough that the end-points are secure during an OTR-IM session that has > then been authenticated, can I use such an IM session to exchange and > crosscheck my friend's GPG public key fingerprint that I've downloaded > from a keyserver for email encryption purposes? The question isn't whether you can. The question is whether it's wise. The principle of using one credential to authorize the use of another credential is about as old as the hills. The ways to exploit this are about as old as the hills, too. I'm out the door for work in a few minutes so I can't spend the 20m looking up a definitive cite, but I'd suggest looking in Ross Anderson's _Security Engineering_. It's pretty comprehensive; it's where I'd start looking. From nagaram.c at symphony.cc Fri Mar 12 14:19:17 2010 From: nagaram.c at symphony.cc (nagaram.c) Date: Fri, 12 Mar 2010 07:19:17 -0600 Subject: gpg encryption failed no public key In-Reply-To: <4B99FD5D.5070505@chili-radiology.com> References: <3CED30E0253D4F8D988381AE0716287A@symphony.com> <4B993537.70509@grant-olson.net><1D6024DDF0E3421AAE76BF2D02B610CC@symphony.com> <4B99FD5D.5070505@chili-radiology.com> Message-ID: <8AAA0DD69BFF42C3B7434222D02313C4@symphony.com> I figured out the issue.... Need to sign the key after it is imported. Nag -----Original Message----- From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Florian Schwind Sent: Friday, March 12, 2010 2:38 AM To: gnupg-users at gnupg.org Subject: Re: gpg encryption failed no public key Hi, On 12.03.2010 07:11, nagaram.c wrote: > Thanks for the response, the command > >> gpg --recepient testuserID --encrypt abc.txt > > I used has double dashes still I gives the same error. > > I think I am using the default keyring as I didn't change its location try using the "--homedir " option > Thanks, > Nag Greetings Florian > -----Original Message----- > From: gnupg-users-bounces at gnupg.org [mailto:gnupg-users-bounces at gnupg.org] > On Behalf Of Grant Olson > Sent: Thursday, March 11, 2010 12:24 PM > To: gnupg-users at gnupg.org > Subject: Re: gpg encryption failed no public key > > On 3/11/2010 7:52 AM, nagaram.c wrote: >> Hi, >> >> >> >> I am new to gpg command line utility for file encryption/decryption. I >> have installed gpg4win v 2.0.2& trying to encrypt a file with a key >> that I imported which is also listing while typing list-keys command >> >> >> >> The issue is that I am getting encryption failed no public key while >> typing in the below command >> >>> gpg -recipient testUserID -encrypt abc.txt >> >> >> >> In one of the posts I found that this is due to not specifying keyring >> location with using -keyring option >> >> >> >> But while I used below command with specifying keyring as below >> >> >> >>> gpg -recipient testIUserID -keyring C:/Documents& >> Settings/username/Application Data/gnupg/pubring.gpg -encrypt abc.txt >> >> >> >> I am getting below error >> >> >> >> gpg: keyblock resource 'C:/Documents& Settings/username/Application >> Data/gnupg/C:/Documents' no such file or directory >> >> usage: gpg [options] [filename] >> >> > > The first command isn't working because you need to double-dash the > options. "--recipient" and "--encrypt". > > You really shouldn't need the -keyring option if you're using your > default keyring. But for the option to work, you would need quotes > around the filename since it has spaces in it. _______________________________________________ Gnupg-users mailing list Gnupg-users at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users From firasmr786 at gmail.com Fri Mar 12 13:46:28 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Fri, 12 Mar 2010 18:16:28 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> Message-ID: <4B9A37A4.6010303@gmail.com> On 3/12/2010 5:33 PM, Robert J. Hansen wrote: >> I don't think OTR technology can claim to solve the gun-to-the-head >> scenario. Although it claims to give users the benefit of >> perfect-forward-secrecy and repudiation, I think such things matter >> little in a court of law. People get convicted either wrongly or >> rightly, based on spoofed emails and plain-text emails all the time. > > Sources, please: I'd like to see citations for "people get convicted ... based on spoofed emails and plain-text emails all the time." Based on plain-text emails, sure. Spoofed emails, though, that's a bit of a stretch and I'm going to need to see cites. Umm I'm not an expert or anything but I think it really depends on where you live. If you belong to a minority people susceptible to persecution by a state agency, then yea sure there are many records of wrongful detention and arbitrary human rights abuses based on false pretenses. Even if those pretenses are 'cooked up', or 'spoofed'. Amnesty International and Human Rights Watch are sites worth checking out for information on this. It's difficult to achieve immunity from a rogue state agency. Technology and encryption isn't the way to stop these kinds of things. In some cases it might help, but only up to a point. I think Bruce Schneier is right when he says that what are needed instead are laws and legal mechanisms for protection of human rights and civil liberties. See Schneier's talk, "Future of Privacy": http://www.openrightsgroup.org/blog/2009/Bruce-Schneier-video-and-book-giveaway > Either way, this kind of raises the question, "so why do you want to use OTR, anyway?" If the entire point of OTR is PFS/R, and you don't believe OTR can solve PFS/R, then why use OTR? Interesting question. I think OTR is a great theoretical concept. I just ignore the PFS/R part when using it. PFS/R might be effective if you're potentially up against a rogue employer, etc. but it's got its limitations when it comes to dealing with agencies of the State IMHO. Same goes for Plausible Deniability, etc. This is what Bruce Schneier noted in an article from 2008 on PD BTW: "*So we cannot break the deniability feature in TrueCrypt 6.0. But*, *honestly, I wouldn't trust it* ". http://www.schneier.com/blog/archives/2008/07/truecrypts_deni.html If you really think about it, when you look at people who've gotten convicted and/or framed based on plain text unsigned email, then it goes to show that there's no point in inventing a technology that specifically provides PD from a cryptographic perspective, because unsigned email is already plausibly deniable. Yet juries & courts regularly convict people despite their best efforts to claim innocence, Who's to say what a regular Joe jury would think of about such things. The fact is that we're living in an era when the vast majority of people use technology without really understanding the nuances that underlie it. Second, even with PD encryption technologies such as Truecrypt, it's easy to look at the problem from a law enforcement officer's perspective. Compel the individual to lie to a question. Compel him to take a polygraph on his statement. And then convict him based on a polygraph. Add in rubber hose attack techniques to the mix and it could get worse... >> So I envision myself using OTR-based-IM and GPG-based-email-encryption >> only with a prior understanding of these deficiencies. If I'm confident >> enough that the end-points are secure during an OTR-IM session that has >> then been authenticated, can I use such an IM session to exchange and >> crosscheck my friend's GPG public key fingerprint that I've downloaded >> from a keyserver for email encryption purposes? > > The question isn't whether you can. The question is whether it's wise. The principle of using one credential to authorize the use of another credential is about as old as the hills. The ways to exploit this are about as old as the hills, too. I'm out the door for work in a few minutes so I can't spend the 20m looking up a definitive cite, but I'd suggest looking in Ross Anderson's _Security Engineering_. It's pretty comprehensive; it's where I'd start looking. Thanks :-) . I'll try and take a look. PS: On that last point on SSL pitfalls I mentioned in my earlier email a couple of additional points that I thought would be good to understand. All it takes is for one CA to be compromised (a rogue element within the CA perhaps, etc. ) and the entire system comes crumbling down. Also, a typical browser such as Firefox will have almost 200 root certificates from various CAs. Each of these adds a given amount of risk, that really should be made transparent to end-users IMHO. Some belong to well known CAs, while others belong to less reputable ones. Plus some CAs will still use outdated hash algorithms to sign certificates. This has allowed people in some cases to generate fake certificates and spoof well known websites. I learned about this last point from a Security Now episode. BTW Schneier did a nice interview discussing some SSL pitfalls here http://www.v3.co.uk/v3/news/2258899/rsa-2010-q-bruce-schneier . -- erythrocyte From rjh at sixdemonbag.org Fri Mar 12 20:31:31 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 12 Mar 2010 14:31:31 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B9A37A4.6010303@gmail.com> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> Message-ID: <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> > you live. If you belong to a minority people susceptible to persecution > by a state agency, then yea sure there are many records of wrongful > detention and arbitrary human rights abuses based on false pretenses. Sure. But the problem here isn't spoofed emails. The problem here is living in an area where basic human rights aren't respected. The spoofed emails didn't get them convicted: the spoofed emails were cooked up to provide political cover for a conviction that was preordained. So I think the statement, "people get convicted ... based on spoofed emails ... all the time" is overreaching. The basis for their conviction is they're members of a persecuted minority -- not spoofed emails. > Interesting question. I think OTR is a great theoretical concept. I just > ignore the PFS/R part when using it. Which leaves the question unanswered: since OTR exists to provide PFS/R, and you ignore PFS/R, why use OTR? > Yet juries & courts > regularly convict people despite their best efforts to claim innocence, This is kind of trivial. When an accused criminal is arraigned, they are given the chance to plead guilty or not guilty. The only way to get a trial is to plead not guilty: if you plead guilty you go straight to the sentencing phase. So yes, in every criminal trial there's a defendant who is making his or her best effort to claim innocence. Some are innocent, some are guilty, and it's the jury's job to figure out guilt or innocence. So yes, I agree with you. I just don't understand what you're getting at. > Second, even with PD encryption technologies such as Truecrypt, it's > easy to look at the problem from a law enforcement officer's > perspective. Compel the individual to lie to a question. Compel him to > take a polygraph on his statement. And then convict him based on a > polygraph. Add in rubber hose attack techniques to the mix and it could > get worse... If you live in a place that does things like this, they can already throw you in the gulag under any pretense they want. What you need is to either (a) move somewhere else, (b) foment a revolution, or (c) keep your head down and pray the government doesn't notice you. GnuPG won't help you out with (a) or (c). GnuPG might help you out with (b)... but only by helping you keep information safe between the endpoints. If you're concerned about the secret police kicking down the door and practicing field expedient dentistry on you, you don't need GnuPG, you need a CNN camera crew and an AK-47. This does not mean GnuPG is defective. It means you need to understand your problem, your solution, and what tools you need to enact your solution. From expires2010 at ymail.com Fri Mar 12 20:40:24 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 12 Mar 2010 19:40:24 +0000 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B9A37A4.6010303@gmail.com> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> Message-ID: <823381916.20100312194024@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi erythrocyte On Friday 12 March 2010 at 12:46:28 PM, you wrote: > a typical browser such as Firefox will have almost 200 root > certificates from various CAs. 208 here, using Firefox 3.5.8 > Each of these adds a given amount of risk, that really should be > made transparent to end-users IMHO. I think you might mean the risk should be made *clear* to end-users? Security is already *transparent* to end users visiting a "secure" website whose root certificate the browser already trusts. > Some belong to well known CAs, while others belong to less reputable > ones. A lot there that I've not heard of. Could be perfectly reputable, but I am unaware of their reputation... - -- Best regards MFPA mailto:expires2010 at ymail.com Think for yourself. Otherwise you have to believe what other people tell you. -----BEGIN PGP SIGNATURE----- iQCVAwUBS5qYx6ipC46tDG5pAQpQsAP/TTwx9dfhUkdRCK3F6oGsiOUrmMP0SfZ8 zapd3RArehlkMChSUm2v4+DViQ8ZyOHc51S8sxuqPnnNb+ZXRaXx09vxkJSXmrR4 mQmnTQNIMDWLacUeI8hRNEVXriLpzgka0bX9q0QtsX1ZhqhLQmqLAT8CrsUn//Ek SX1KIDCHXF4= =kqyg -----END PGP SIGNATURE----- From john_espiro at yahoo.com Fri Mar 12 21:42:30 2010 From: john_espiro at yahoo.com (john espiro) Date: Fri, 12 Mar 2010 12:42:30 -0800 (PST) Subject: Paperkey (Was: Re: ) In-Reply-To: References: <284819.31224.qm@web46004.mail.sp1.yahoo.com> Message-ID: <719848.8240.qm@web46008.mail.sp1.yahoo.com> Hi David - Thanks for the quick reply. I should note that I am on a Windows XP box. When I run gpg --export-secret-key my at key.com | paperkey --output-type raw for both the 2048 and 4096, I note that the output for the 4096 key is about 10% logner than that of the 2048 key. I am not familiar with wc.exe, but will google it... John ________________________________ From: David Shaw Paperkey doesn't care what size the key is. Try doing that same command line, but use "wc -c" instead of the dmtxwrite part to check that the output is larger than with a 2048 bit key. Perhaps dmtxwrite is having a problem? David -------------- next part -------------- An HTML attachment was scrubbed... URL: From dougb at dougbarton.us Fri Mar 12 21:44:47 2010 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 12 Mar 2010 12:44:47 -0800 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B99EF0E.3040908@gmail.com> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> Message-ID: <4B9AA7BF.7080400@dougbarton.us> On 3/11/2010 11:36 PM, erythrocyte wrote: > On 3/12/2010 10:54 AM, Doug Barton wrote: >> "Secure" in this context is a relative term. (Note, I'm a long time user >> of pidgin+OTR and a longer-time user of PGP, so I'm actually familiar >> with what you're proposing.) If you know the person you're IM'ing well >> enough, you can do a pretty good job of validating their OTR >> fingerprint. But how "secure" that is depends on your threat model. Are >> you going to be encrypting sensitive financial data? Fruit cake recipes? >> Blueprints for nuclear weapons? Is the security of your communication >> something that you're wagering your life (or the lives of others) on? > > > Hmmm...if I understand it correctly, if and when the OTR session is > fully verified/authenticated it doesn't matter what the content of the > data you transmit is. It could be any of the above - fruit cake recipes, > financial data, et al. You posited a scenario where you are using OTR communications to verify a PGP key. My assumption (and pardon me if it was incorrect) was that you had a security-related purpose in mind for the verified key. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From rdpalmer70 at hotmail.com Wed Mar 10 22:07:55 2010 From: rdpalmer70 at hotmail.com (Robert Palmer) Date: Wed, 10 Mar 2010 16:07:55 -0500 Subject: updprefs command and changing key Message-ID: During exchange of a public key to a 3rd party - they rejected the key for not having a compatible cipher; so, after doing some research the key was edited within gpg to update prefs on the key which now shows a compatible cipher (in this case, AES-256). I re-exported the public key and noticed that the ascii representation was different - this leads me to my question, which is: is this new key 100% compatible with the old key? To elaborate, will previous other 3rd party entities (equipped only with the non-updated prefs version) still be able to decrypt and accept messages signed with the new key? Preliminary testing shows that the updated prefs version encrypted message is able to be decrypted and signature verified on the non-updated prefs version keyring system. I am thinking (from preliminary tests) that the "key" information does not get updated at all - but, somehow, the cipher preferences are embedded in the public key - hence, the reason that the exported public key ASCII representation was different before and after updating preferences. Any understanding that someone can add to this would be very much appreciated. Thanks. --Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From Clayton.A.Eggie at jci.com Thu Mar 11 06:36:08 2010 From: Clayton.A.Eggie at jci.com (Clayton.A.Eggie at jci.com) Date: Wed, 10 Mar 2010 23:36:08 -0600 Subject: Pass phrase help Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 24462 bytes Desc: not available URL: From kgo at grant-olson.net Fri Mar 12 22:10:09 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 12 Mar 2010 16:10:09 -0500 Subject: updprefs command and changing key In-Reply-To: References: Message-ID: <4B9AADB1.8000603@grant-olson.net> On 3/10/2010 4:07 PM, Robert Palmer wrote: > During exchange of a public key to a 3^rd party ? they rejected the key > for not having a compatible cipher; so, after doing some research the > key was edited within gpg to update prefs on the key which now shows a > compatible cipher (in this case, AES-256). I re-exported the public key > and noticed that the ascii representation was different ? this leads me > to my question, which is: is this new key 100% compatible with the old > key? To elaborate, will previous other 3^rd party entities (equipped > only with the non-updated prefs version) still be able to decrypt and > accept messages signed with the new key? Preliminary testing shows that > the updated prefs version encrypted message is able to be decrypted and > signature verified on the non-updated prefs version keyring system. > > > > I am thinking (from preliminary tests) that the ?key? information does > not get updated at all ? but, somehow, the cipher preferences are > embedded in the public key ? hence, the reason that the exported public > key ASCII representation was different before and after updating > preferences. > > > > Any understanding that someone can add to this would be very much > appreciated. Thanks. > Yep. The key itself is the same and the encoded preferences changed. Your old contacts can still do all the same stuff they were before using your old preferences until they update their copy of your public key. Your new ones will use the new preferences. Nothing should break. If you're using the keyservers, you'll want to send the new public key out so that people can get your new preferences. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From expires2010 at ymail.com Fri Mar 12 22:14:19 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 12 Mar 2010 21:14:19 +0000 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B9A37A4.6010303@gmail.com> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> Message-ID: <645129904.20100312211420@my_localhost> Hi erythrocyte On Friday 12 March 2010 at 12:46:28 PM, you wrote: > If you really think about it, when you look at people who've gotten > convicted and/or framed based on plain text unsigned email, then it > goes to show that there's no point in inventing a technology that > specifically provides PD from a cryptographic perspective, because > unsigned email is already plausibly deniable. Yet juries & courts > regularly convict people despite their best efforts to claim > innocence, Who's to say what a regular Joe jury would think of about > such things. I would question whether the defence solicitor was fit to practice if he didn't produce expert witnesses who could explain this sufficiently clearly for the jury to understand. -- Best regards MFPA mailto:expires2010 at ymail.com Dogs look up to us. Cats look down on us. Pigs treat us as equals. From kgo at grant-olson.net Fri Mar 12 21:06:17 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 12 Mar 2010 15:06:17 -0500 Subject: Question about passphrase-fd In-Reply-To: <1268389665.2822.8.camel@mlb-dell> References: <1268354436.2892.43.camel@mlb-dell> <1268389665.2822.8.camel@mlb-dell> Message-ID: <4B9A9EB9.5060906@grant-olson.net> On 3/12/2010 5:27 AM, Matt Burkhardt wrote: > > Here's the code that calls gpg for the encryption: > > gpg --batch --no-secmem-warning --disable-mdc --symmetric --cipher-algo AES256 --passphrase-fd 3 3 > > According to the man pages, it says not to use the --cipher-algo but > doesn't mention if that's needed in order to decrypt the files. Would > that have to happen? > > Thanks! > gpg should know how the file was encrypted. You shouldn't need to specify anything to decrypt. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From firasmr786 at gmail.com Fri Mar 12 22:35:49 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 03:05:49 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B9AA7BF.7080400@dougbarton.us> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <4B9AA7BF.7080400@dougbarton.us> Message-ID: <4B9AB3B5.3080408@gmail.com> On 3/13/2010 2:14 AM, Doug Barton wrote: > You posited a scenario where you are using OTR communications to verify > a PGP key. My assumption (and pardon me if it was incorrect) was that > you had a security-related purpose in mind for the verified key. Yes :-) . -- erythrocyte From kgo at grant-olson.net Fri Mar 12 22:27:54 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 12 Mar 2010 16:27:54 -0500 Subject: Pass phrase help In-Reply-To: References: Message-ID: <4B9AB1DA.7090707@grant-olson.net> On 3/11/2010 12:36 AM, Clayton.A.Eggie at jci.com wrote: > > I misplaced my PINENTRY passphrase. Is there some way to recover it or > will I need to remove GNU and start anew? I need to decrypt a document > from a vendor that has my public key. This is what I'm looking at: > Unfortunately, you're screwed... If you generated a revocation certificate, you can send that out so that people know the key is bad. Here's one quick article that explains the process: http://www.gnupg.org/documentation/faqs.en.html#q4.17 If you want/need to continue using encryption, you'll need to generate a new private key. You don't need to reinstall gnupg. You can just choose "Keys -> New Key" from the GNU Privacy Assistant. You'll then either need to send the new key to the vendor or to the keyservers, and have people use that one. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Fri Mar 12 21:25:27 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 12 Mar 2010 15:25:27 -0500 Subject: gpg encryption failed no public key In-Reply-To: <8AAA0DD69BFF42C3B7434222D02313C4@symphony.com> References: <3CED30E0253D4F8D988381AE0716287A@symphony.com> <4B993537.70509@grant-olson.net><1D6024DDF0E3421AAE76BF2D02B610CC@symphony.com> <4B99FD5D.5070505@chili-radiology.com> <8AAA0DD69BFF42C3B7434222D02313C4@symphony.com> Message-ID: <4B9AA337.6040704@grant-olson.net> On 3/12/2010 8:19 AM, nagaram.c wrote: > > I figured out the issue.... > > Need to sign the key after it is imported. > > Nag You shouldn't need to sign the key. It should give you a warning but let you encrypt it anyway: > It is NOT certain that the key belongs to the person named > in the user ID. If you *really* know what you are doing, > you may answer the next question with yes. > > Use this key anyway? (y/N) Signing will remove that warning, but you don't need to sign every single key you import to use encryption. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From firasmr786 at gmail.com Fri Mar 12 23:04:59 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 03:34:59 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> Message-ID: <4B9ABA8B.9050407@gmail.com> On 3/13/2010 1:01 AM, Robert J. Hansen wrote: > Sure. But the problem here isn't spoofed emails. The problem here is living in an area where basic human rights aren't respected. The spoofed emails didn't get them convicted: the spoofed emails were cooked up to provide political cover for a conviction that was preordained. > > So I think the statement, "people get convicted ... based on spoofed emails ... all the time" is overreaching. The basis for their conviction is they're members of a persecuted minority -- not spoofed emails. Sure, that is such a valid point. I'm a completely new user to GPG, so do pardon some of my ruminations :-) . I realize they might not be completely correct. I guess what I'm trying to say here is that because regular people don't understand what spoofing actually is, that by itself is a security hole. The only way to correct something like that is to educate people and to educate oneself. I also think the word 'spoofing' could apply not just to emails, but to other things such as forging real-life identities such as passports, etc as well. There's no way I could be trained enough to recognize spoofing of the latter kind even at a keysigning party. So as I begin to use GPG, I'm becoming more and more aware of the limitations that one has to come across - be they technological or social. > Which leaves the question unanswered: since OTR exists to provide PFS/R, and you ignore PFS/R, why use OTR? I actually use Pidgin OTR because a. it gives me the PFS/R option if and when I do think that might help (realizing its limitations nevertheless). b. I just think the ease with which users can authenticate makes it a good choice. The secret answer method of authenticating is easy for most of my friends to understand. > If you live in a place that does things like this, they can already throw you in the gulag under any pretense they want... Well, I do think that's such a relative thing. Just because you don't notice these kinds of things going on in the place where you live doesn't mean they don't happen. How many people actually bother to look? I guess what I'm saying here is that human rights abuses can occur anywhere and everywhere. > ... but only by helping you keep information safe between the endpoints... This does not mean GnuPG is defective. It means you need to understand your problem, your solution, and what tools you need to enact your solution. I think that that makes perfect sense. :-) -- erythrocyte From dshaw at jabberwocky.com Fri Mar 12 23:14:38 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 12 Mar 2010 17:14:38 -0500 Subject: updprefs command and changing key In-Reply-To: References: Message-ID: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> On Mar 10, 2010, at 4:07 PM, Robert Palmer wrote: > During exchange of a public key to a 3rd party ? they rejected the key for not having a compatible cipher; so, after doing some research the key was edited within gpg to update prefs on the key which now shows a compatible cipher (in this case, AES-256). I re-exported the public key and noticed that the ascii representation was different ? this leads me to my question, which is: is this new key 100% compatible with the old key? To elaborate, will previous other 3rd party entities (equipped only with the non-updated prefs version) still be able to decrypt and accept messages signed with the new key? Preliminary testing shows that the updated prefs version encrypted message is able to be decrypted and signature verified on the non-updated prefs version keyring system. > > I am thinking (from preliminary tests) that the ?key? information does not get updated at all ? but, somehow, the cipher preferences are embedded in the public key ? hence, the reason that the exported public key ASCII representation was different before and after updating preferences. This is exactly correct. The prefs are just a field attached to the key. However, your 3rd party should not have rejected the key. The OpenPGP preferences system is designed to *always* reach a valid answer. Every preference list contains Triple-DES, whether you explicitly list it there or not, and every OpenPGP program is compatible with Triple-DES. If no other compatible ciphers are found, the answer is Triple-DES. David From firasmr786 at gmail.com Fri Mar 12 23:18:44 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 03:48:44 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <823381916.20100312194024@my_localhost> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <823381916.20100312194024@my_localhost> Message-ID: <4B9ABDC4.5030206@gmail.com> On 3/13/2010 1:10 AM, MFPA wrote: >> Each of these adds a given amount of risk, that really should be >> made transparent to end-users IMHO. > > > I think you might mean the risk should be made *clear* to end-users? > Security is already *transparent* to end users visiting a "secure" website > whose root certificate the browser already trusts. I guess you could think of it that way. I guess what I'm trying to say is that there might be instances where your security requirements aren't in line with what your browser already trusts. And there has to be a method to improve that and make it more "clear" / "transparent" / etc. >> Some belong to well known CAs, while others belong to less reputable >> ones. > > A lot there that I've not heard of. Could be perfectly reputable, but > I am unaware of their reputation... Again 'repute' in this context is relative. People's gold-standards can vary. I might be comfortable in trusting CA-A because they've actually never ever screwed up in the past, while I wouldn't feel the same way with CA-B because they actually have. It all goes back to how you define your security requirements. Steve Gibson on his podcast, Security Now, once talked about how a certificate from a well known CA was spoofed because of a weak hash algorithm that was used in signing. -- erythrocyte From dshaw at jabberwocky.com Fri Mar 12 23:24:03 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 12 Mar 2010 17:24:03 -0500 Subject: Question about passphrase-fd In-Reply-To: <1268389665.2822.8.camel@mlb-dell> References: <1268354436.2892.43.camel@mlb-dell> <1268389665.2822.8.camel@mlb-dell> Message-ID: <3C58D77F-652F-4E27-AA53-6ACBA1234291@jabberwocky.com> On Mar 12, 2010, at 5:27 AM, Matt Burkhardt wrote: > On Thu, 2010-03-11 at 21:36 -0500, David Shaw wrote: >> > Long story short, I use amanda for my backups and I've been using encryptsimple for my backups. My PC died completely, and I'm trying to get the backups onto another machine. I've stepped through the programs and have found that it's calling gpg with >> > >> > gpg --batch --quiet --no-mdc-warning --decrypt --passphrase-fd 3 3> > >> > I was under the impression that the passphrase (.am_passphrase) was just a clear text secret phrase. However, the gpg call errors out with: >> > >> > gpg: decryption failed: bad key >> >> The "bad key" error doesn't mean the passphrase is wrong (that would be "invalid passphrase"). It often means that the file you are decrypting is corrupt. Was the file you are decrypting encrypted with a passphrase only or with a public key? > > Here's the code that calls gpg for the encryption: > > gpg --batch --no-secmem-warning --disable-mdc --symmetric --cipher-algo AES256 --passphrase-fd 3 3 > > According to the man pages, it says not to use the --cipher-algo but doesn't mention if that's needed in order to decrypt the files. Would that have to happen? No. You need to specify it for encryption, but on decryption (except in certain special cases, and this is not one of them) GPG can see what cipher was used directly from the encrypted file and handle it automatically. David From firasmr786 at gmail.com Fri Mar 12 23:08:10 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 03:38:10 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> Message-ID: <4B9ABB4A.1060803@gmail.com> On 3/12/2010 5:33 PM, Robert J. Hansen wrote: > The question isn't whether you can. The question is whether it's wise. The principle of using one credential to authorize the use of another credential is about as old as the hills. The ways to exploit this are about as old as the hills, too. That actually got me thinking. Aren't keysigning parties based on that model anyway? You have an existing credential - a passport. You then use that credential to verify another - a PGP key. -- erythrocyte From faramir.cl at gmail.com Fri Mar 12 23:36:30 2010 From: faramir.cl at gmail.com (Faramir) Date: Fri, 12 Mar 2010 19:36:30 -0300 Subject: gpg encryption failed no public key In-Reply-To: <4B9AA337.6040704@grant-olson.net> References: <3CED30E0253D4F8D988381AE0716287A@symphony.com> <4B993537.70509@grant-olson.net><1D6024DDF0E3421AAE76BF2D02B610CC@symphony.com> <4B99FD5D.5070505@chili-radiology.com> <8AAA0DD69BFF42C3B7434222D02313C4@symphony.com> <4B9AA337.6040704@grant-olson.net> Message-ID: <4B9AC1EE.9080708@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Grant Olson escribi?: ... >> It is NOT certain that the key belongs to the person named >> in the user ID. If you *really* know what you are doing, >> you may answer the next question with yes. >> >> Use this key anyway? (y/N) > > Signing will remove that warning, but you don't need to sign every > single key you import to use encryption. IIRC, some GUIs don't provide that confirmation, and reject the key, so maybe it would be a good idea to issue a local signature. Also, it helps to distinguish between a key you have checked, and "new keys" that may have been created by Eve. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLmsHuAAoJEMV4f6PvczxAT3cIAJVnvF8fI+WWqXrtkJXur46w tkmnPrMWgB4ejJNgAKLiG7AE216GC/268pV593TXRydQe3OWAjR90bp5XcUPaH+B sxZ8139xuEI6IEu77l0uj7dtJ43FCKhhWrLdrPVx9NpvhhV2Th1odtdJiuMoxlgg 787x4fRH5cGfYHhA7fIOJ/Yqv9QgUdnMX7UMK/JcFITzRjHzDnPpYNTYXNAk1IWz t9u7WhR/MKtbPeHc3j4H2qNgr8lzJ5TRCgzC6EzrfimfYmFITM4tcUNPyNuRZBc5 Z3ZtvS5y3OIS9YnztClpyEhozLbW4qzTb9RQAXzpCnfSMtS3PMMeBUrzie6WDfQ= =V+Em -----END PGP SIGNATURE----- From firasmr786 at gmail.com Sat Mar 13 00:14:09 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 04:44:09 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <645129904.20100312211420@my_localhost> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <645129904.20100312211420@my_localhost> Message-ID: On Sat, Mar 13, 2010 at 2:44 AM, MFPA wrote: > I would question whether the defence solicitor was fit to practice if > he didn't produce expert witnesses who could explain this sufficiently > clearly for the jury to understand. > LOL ...Easier said than done, IMHO :-) :-P . -- erythrocyte -------------- next part -------------- An HTML attachment was scrubbed... URL: From faramir.cl at gmail.com Sat Mar 13 00:31:46 2010 From: faramir.cl at gmail.com (Faramir) Date: Fri, 12 Mar 2010 20:31:46 -0300 Subject: updprefs command and changing key In-Reply-To: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> Message-ID: <4B9ACEE2.9060501@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David Shaw escribi?: ... > However, your 3rd party should not have rejected the key. The OpenPGP preferences system is designed to *always* reach a valid answer. Every preference list contains Triple-DES, whether you explicitly list it there or not, and every OpenPGP program is compatible with Triple-DES. If no other compatible ciphers are found, the answer is Triple-DES. Just a question, and I don't have any intention about doing it, but, is there a way to disable the usage of 3DES in GnuPG, when encrypting? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLms7iAAoJEMV4f6PvczxApuMH+wY28C56ZFIeB5kraiMnqGH4 NsvxMN6bECWRokuci0EMr7sgWU7PNQTiaIYqZoUXpXITgcs8rwPDeYfh6zPj6IPP BlOEFv9IlV276rM1761iNYzVabVwLlV/AGlYXUE10uTiFGQCk0rhzTRNC697iDRa kkaAOAmLKkMRuXw9iql2PRwzp+YrunIM2/3/j8n88WZIIdbtntqtkEz74VAtf9YA TP46T/zXAPb/gVILLdKzvnGZqbjIxk5j9odZrLrNVGgpC8DDmFTqsimF2t61Batr 0zUwu7gtOUQei1OJd3rOMimEniyiWnZdPal4LjbWoDE6rSiEFp1VS0jJM3GFQ14= =3sKN -----END PGP SIGNATURE----- From kgo at grant-olson.net Sat Mar 13 00:51:31 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 12 Mar 2010 18:51:31 -0500 Subject: updprefs command and changing key In-Reply-To: <4B9ACEE2.9060501@gmail.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> Message-ID: <4B9AD383.2030309@grant-olson.net> On 3/12/2010 6:31 PM, Faramir wrote: > > Just a question, and I don't have any intention about doing it, but, > is there a way to disable the usage of 3DES in GnuPG, when encrypting? > > Best Regards Doing that wouldn't comply with the spec. The spec says that implementations MUST support 3DES: http://tools.ietf.org/html/rfc4880#section-9.2 It's the only encryption algorithm that must be implemented, so that's why it ends up being the final fallback option. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Sat Mar 13 01:07:08 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 12 Mar 2010 19:07:08 -0500 Subject: updprefs command and changing key In-Reply-To: <4B9ACEE2.9060501@gmail.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> Message-ID: On Mar 12, 2010, at 6:31 PM, Faramir wrote: > David Shaw escribi?: > ... >> However, your 3rd party should not have rejected the key. The OpenPGP preferences system is designed to *always* reach a valid answer. Every preference list contains Triple-DES, whether you explicitly list it there or not, and every OpenPGP program is compatible with Triple-DES. If no other compatible ciphers are found, the answer is Triple-DES. > > Just a question, and I don't have any intention about doing it, but, > is there a way to disable the usage of 3DES in GnuPG, when encrypting? Patch the source :) There is no way other than that. 3DES is a required part of OpenPGP, so if you remove it, you're not going to play well with the other programs out there. David From JPClizbe at tx.rr.com Sat Mar 13 05:36:02 2010 From: JPClizbe at tx.rr.com (John Clizbe) Date: Fri, 12 Mar 2010 22:36:02 -0600 Subject: updprefs command and changing key In-Reply-To: <4B9ACEE2.9060501@gmail.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> Message-ID: <4B9B1632.3000100@tx.rr.com> Faramir wrote: > Just a question, and I don't have any intention about doing it, but, > is there a way to disable the usage of 3DES in GnuPG, when encrypting? Sure, the source is available -- the result just won't be a valid OpenPGP implementation any longer. Now for my "Just a Question": Why on earth would you want to? To quote a friend of mine discussing 3DES: > It's perfectly safe. In fact, 3DES is probably the most trustworthy > algorithm on this list. A few years ago when Schneier was asked for his > pick for "most trusted encryption algorithm," he said something like > "3DES. Nothing else even comes close." Sure, use AES for new crypto > software, but if you absolutely _must_ have the most overdesigned, > overbuilt thing out there... > > It's been subjected to withering cryptanalysis for coming up on 30 years > now. It's one of the standard ciphers graduate students are exposed to > in cryptography/cryptanalysis courses. It has turned a generation of > brilliant young graduate students into burned out alcoholic wrecks. I > have participated in bar crawls after getting beaten by 3DES. > > It is big, clumsy, ungainly and slow. It has all the aesthetic values > of the Soviet Realism school of art, and processes data about as fast as > a snail coming off a three-day scopolamine trip. > > And it is still beating up every cryptanalyst out there and stealing > their lunch money. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sat Mar 13 07:00:57 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Mar 2010 01:00:57 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B9ABA8B.9050407@gmail.com> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> Message-ID: <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> > I guess what I'm trying to say here is that because regular people don't > understand what spoofing actually is, that by itself is a security hole. Semantics. A security hole is a way by which the security policy may be violated. Most people don't bother to think about policy in the first place. This devolves into a philosophical question of, "is the fact most people don't bother to think about their security policy a way by which their security policy can be violated?" It turns into a how-many-angels-can-dance-on-the-head-of-a-pin thing. But it is at the very least a problem and you'll find few people here disagree with that. > There's no way I could be trained enough to > recognize spoofing of the latter kind even at a keysigning party. A serious question here -- have you considered writing Immigration and Customs Enforcement or the Border Patrol (or equivalent groups, wherever you are) and asking them for information on how to distinguish real passports from forgeries? Most governments are very willing to tell people what to look for. It's in their best interests for official identity documents to not be forged, and for forgeries to be discovered as quickly as possible. When I've asked the United States government about this they've always been cooperative. You'd be amazed what you can learn just by having the chutzpah to walk up to someone who knows and saying, "hi, could you share?" :) > b. I just think the ease with which users can authenticate makes it > a good choice. The secret answer method of authenticating is > easy for most of my friends to understand. It is also a far weaker form of authentication than is often recommended for OpenPGP keys. Not that this makes the technique invalid, but the weaker authentication needs to at least be considered. > Well, I do think that's such a relative thing. Just because you don't > notice these kinds of things going on in the place where you live > doesn't mean they don't happen. How many people actually bother to look? The United States has 1400 independent daily newspapers, each of whom employ a large number of people whose job it is to look. On top of that you have groups like the Innocence Project that look for abuses in criminal courts, you have groups like ACCURATE that look for abuses in voting, you have... The Western tradition of government usually involves a lot of people looking. This is certainly not to say that abuses don't happen -- they clearly do -- but they do not occur at the frequency many fear. From rjh at sixdemonbag.org Sat Mar 13 07:10:20 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Mar 2010 01:10:20 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B9ABB4A.1060803@gmail.com> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9ABB4A.1060803@gmail.com> Message-ID: <6C67E73E-8835-4F5A-A2B8-F199EE0DF3A1@sixdemonbag.org> > You have an existing credential - a passport. > You then use that credential to verify another - a PGP key. The passport isn't used to verify the OpenPGP key. The passport is used to verify *identity*. The key fingerprint is used to verify the OpenPGP key. A signature is a statement of "I believe this person is associated with this OpenPGP key." To do that, you have to first verify the person is who you think they are (the passport); you have to verify the key is what you think it is (the fingerprint); and then you make a statement about the two being associated. From rjh at sixdemonbag.org Sat Mar 13 07:11:56 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Mar 2010 01:11:56 -0500 Subject: updprefs command and changing key In-Reply-To: <4B9ACEE2.9060501@gmail.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> Message-ID: <874F58BD-0DC1-41B9-A879-821AD60D1D8D@sixdemonbag.org> > Just a question, and I don't have any intention about doing it, but, > is there a way to disable the usage of 3DES in GnuPG, when encrypting? Kind of, but it's not recommended. "--cipher-algo AES" will do it, but please don't. This kind of brute force approach is almost always the wrong thing to do. From rjh at sixdemonbag.org Sat Mar 13 07:13:17 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Mar 2010 01:13:17 -0500 Subject: updprefs command and changing key In-Reply-To: References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> Message-ID: > There is no way other than that. 3DES is a required part of OpenPGP, so if you remove it, you're not going to play well with the other programs out there. --cipher-algo [something other than 3DES] won't do it? Faramir was asking only about disabling it when encrypting: I was under the impression --cipher-algo could be used to do that. Not that I think people should, of course. :) From firasmr786 at gmail.com Sat Mar 13 08:06:47 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 12:36:47 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <6C67E73E-8835-4F5A-A2B8-F199EE0DF3A1@sixdemonbag.org> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9ABB4A.1060803@gmail.com> <6C67E73E-8835-4F5A-A2B8-F199EE0DF3A1@sixdemonbag.org> Message-ID: On Sat, Mar 13, 2010 at 11:40 AM, Robert J. Hansen wrote: > > You have an existing credential - a passport. > > You then use that credential to verify another - a PGP key. > > The passport isn't used to verify the OpenPGP key. The passport is used to > verify *identity*. The key fingerprint is used to verify the OpenPGP key. > > A signature is a statement of "I believe this person is associated with > this OpenPGP key." To do that, you have to first verify the person is who > you think they are (the passport); you have to verify the key is what you > think it is (the fingerprint); and then you make a statement about the two > being associated. > I'm a little confused as to how does that make it any different from using the Pidgin OTR method. I simply open up an OTR session, ask my friend a question the answer to which is secret (only known to him) and thereby authenticate that it is in fact him that I'm talking to. Next, over this secure connection, we exchange our email-encryption key fingerprints and verify them and then sign them, in effect stating like you mentioned: "Yes, I believe this person is associated with this OpenPGP key." -------------- next part -------------- An HTML attachment was scrubbed... URL: From firasmr786 at gmail.com Sat Mar 13 08:14:59 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 12:44:59 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> Message-ID: On Sat, Mar 13, 2010 at 11:30 AM, Robert J. Hansen wrote: > > There's no way I could be trained enough to > > recognize spoofing of the latter kind even at a keysigning party. > > A serious question here -- have you considered writing Immigration and > Customs Enforcement or the Border Patrol (or equivalent groups, wherever you > are) and asking them for information on how to distinguish real passports > from forgeries? > > Most governments are very willing to tell people what to look for. It's in > their best interests for official identity documents to not be forged, and > for forgeries to be discovered as quickly as possible. When I've asked the > United States government about this they've always been cooperative. > > You'd be amazed what you can learn just by having the chutzpah to walk up > to someone who knows and saying, "hi, could you share?" :) > The reason I think that it's still difficult is because even immigration officials get duped all the time. > b. I just think the ease with which users can authenticate makes it > > a good choice. The secret answer method of authenticating is > > easy for most of my friends to understand. > > It is also a far weaker form of authentication than is often recommended > for OpenPGP keys. Not that this makes the technique invalid, but the weaker > authentication needs to at least be considered. > Okay. What weakness(es) do I need to be wary of? > > Well, I do think that's such a relative thing. Just because you don't > > notice these kinds of things going on in the place where you live > > doesn't mean they don't happen. How many people actually bother to look? > > The United States has 1400 independent daily newspapers, each of whom > employ a large number of people whose job it is to look. On top of that you > have groups like the Innocence Project that look for abuses in criminal > courts, you have groups like ACCURATE that look for abuses in voting, you > have... > > The Western tradition of government usually involves a lot of people > looking. This is certainly not to say that abuses don't happen -- they > clearly do -- but they do not occur at the frequency many fear. > Pardon me for being skeptical about all of that. I realize that this is a controversial issue and I'm respectful of what you believe. -- erythrocyte -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Sat Mar 13 08:30:11 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Mar 2010 02:30:11 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9ABB4A.1060803@gmail.com> <6C67E73E-8835-4F5A-A2B8-F199EE0DF3A1@sixdemonbag.org> Message-ID: <5414C321-4D8B-4DBA-9A96-0BBC270CDFA6@sixdemonbag.org> > I'm a little confused as to how does that make it any different from using the Pidgin OTR method. It's a question of degree, not kind. > I simply open up an OTR session, ask my friend a question the answer to which is secret (only known to him) How do you know the secret is known only to him? Most "secrets" really aren't; a good investigator can discover an awful lot of "secret" information about someone. Shared-secret authentication is one of the weakest forms out there. It's better than nothing, but it's not something that ought be relied upon. People tend to vastly overestimate how secret their secrets are. As an example, a few years ago I saw in a spy novel (set in the modern day) two protagonists negotiating a phone number over an insecure line. "Hey, that guy we know who did X? Take his phone number, subtract this number from it. The resulting phone number is what you need to call." It sounds great and reliable: it's a shared secret. The problem is it's totally bogus. Phone numbers aren't random. In the United States, for instance, phone numbers follow the NPA-NXX format. That reduces this question down to a glorified Sudoku: a skilled investigator could figure it out in just a few minutes. From rjh at sixdemonbag.org Sat Mar 13 08:44:56 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Mar 2010 02:44:56 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> Message-ID: > The reason I think that it's still difficult is because even immigration officials get duped all the time. Cites, please. Show me studies showing how often immigration officials get duped, and how often they correctly flag false passports. When verifying an identity document, the null hypothesis is "this document is invalid." Rejecting a good passport is a Type I error; accepting a bad passport is a Type II error. Please show me published estimates of Type I and Type II errors by immigration officials. When you say "all the time," it seems that you mean the Type II error rate is through the roof, and I'm going to need evidence before I accept that claim. Even then ? so what? Let's say the Type II rate is 25%. That's a very high Type II rate; most people would think that failing to recognize one set of fake IDs per four is a really bad error rate. Yet, if you're at a keysigning party where there are five people independently applying a 25%-faulty test, the likelihood of accepting a fake ID is under 1%. > Okay. What weakness(es) do I need to be wary of? See previous message. > Pardon me for being skeptical about all of that. I realize that this is a controversial issue and I'm respectful of what you believe. There is a difference between being skeptical and being cynical. I am all in favor of skepticism, but modern cynicism is a puerile philosophy and I'll have none of it. Skepticism insists on evidence at each step and follows that evidence wherever it leads. Modern cynicism believes it already knows where that evidence must lead, and thus there's no need to discover evidence and reason concretely about one's discoveries. From ciprian.craciun at gmail.com Sat Mar 13 07:52:27 2010 From: ciprian.craciun at gmail.com (Ciprian Dorin, Craciun) Date: Sat, 13 Mar 2010 08:52:27 +0200 Subject: Paperkey (Was: Re: ) In-Reply-To: <719848.8240.qm@web46008.mail.sp1.yahoo.com> References: <284819.31224.qm@web46004.mail.sp1.yahoo.com> <719848.8240.qm@web46008.mail.sp1.yahoo.com> Message-ID: <8e04b5821003122252o25cdf3batc0bf5fd851838aee@mail.gmail.com> I've used the `dtmx` tool to export some GPG keys (exactly a 4096 bits one) and it worked. What I did was something like: paperkey --secret-key ./key.gpg --output ./key.paperkey --output-type raw dmtxwrite --encoding 8 --format png --resolution 72 <./key.paperkey >./key.png And everything worked just perfectly. But after looking through my scripts (because I've automated the entire process), I see a test where I check if the size of the file to be encoded is less than 1555 bytes, because it seems that dtmx (in fact the specification?) doesn't allow files larger than this. Another quirk that I've found is that decoding back that image after being printed, photographed and put back in my computer worked Ok for small sizes (~200-300 bytes), but for other files (closer to ~1000 bytes) I was not able to decode the image back even after some image processing that enhances the contrast, sharpens the colors, etc. (I haven't tried a scanner, but I guess that would have worked.) (But the original file spitted out by dtmx was decoded just fine.) Ciprian. On Fri, Mar 12, 2010 at 10:42 PM, john espiro wrote: > Hi David - > > Thanks for the quick reply. > > I should note that I am on a Windows XP box. > > When I run gpg --export-secret-key my at key.com | paperkey? --output-type raw > for both the 2048 and 4096, I note that the output for the 4096 key is about > 10% logner than that of the 2048 key. > > I am not familiar with wc.exe, but will google it... > > John From laurent.jumet at skynet.be Sat Mar 13 08:58:26 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Sat, 13 Mar 2010 08:58:26 +0100 Subject: updprefs command and changing key In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello David ! David Shaw wrote: >> Just a question, and I don't have any intention about doing it, but, >> is there a way to disable the usage of 3DES in GnuPG, when encrypting? > Patch the source :) > There is no way other than that. 3DES is a required part of OpenPGP, so if > you remove it, you're not going to play well with the other programs out > there. In my opinion, if you have something like this in GPG.CONF: default-preference-list S7 S11 S12 S13 S1 S10 S3 S4 S2 S9 S8 H3 H8 H9 H10 H11 H2 H1 Z1 Z2 Z3 Z0 personal-cipher-preferences S7 S11 S12 S13 S1 S10 S3 S4 S2 S9 S8 and assuming that 3DES is S2, that means that it's relegated so far that it won't be used except if recipient key's preferences default to almost only 3DES. - -- Laurent Jumet KeyID: 0xCFAF704C -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) iHEEAREDADEFAkubRv8qGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB RjcwNEMuYXNjAAoJEPUdbaDPr3BMRaUAoIfnKqDynQKuUIHQ8BCe3t7QYkmcAJ98 YYw1SgBTCUOMRSnbm6QLrVsnog== =2xBw -----END PGP SIGNATURE----- From expires2010 at ymail.com Sat Mar 13 11:14:35 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 13 Mar 2010 10:14:35 +0000 Subject: updprefs command and changing key In-Reply-To: References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> Message-ID: <944950702.20100313101435@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 13 March 2010 at 12:07:08 AM, in , David Shaw wrote: > On Mar 12, 2010, at 6:31 PM, Faramir wrote: >> is there a way to disable the usage of 3DES in GnuPG, when >> encrypting? > Patch the source :) > There is no way other than that. Wouldn't "--disable-cipher-algo 3DES" achieve this? - -- Best regards MFPA mailto:expires2010 at ymail.com If you can't convince them, confuse them. -----BEGIN PGP SIGNATURE----- iQCVAwUBS5tlkaipC46tDG5pAQqy8AP/YsupAdKAMH6Yd8ZLWc4obxClpk2y5nGu P8cWrWApkKEgMqBxrSaJJqnTfXwuSYVl3F4pYwy7RVjJV8GpzJ7iPKYoyqsE18/H X7/tBdzcDhwCX/SlleW2BtdZCuJYEF6U/1e3vuyKC3wYjYnCcxqP43MLvBg4mppu Ub6rNEoY9tg= =p+Vu -----END PGP SIGNATURE----- From john_espiro at yahoo.com Sat Mar 13 11:22:17 2010 From: john_espiro at yahoo.com (john espiro) Date: Sat, 13 Mar 2010 02:22:17 -0800 (PST) Subject: Paperkey (Was: Re: ) In-Reply-To: <8e04b5821003122252o25cdf3batc0bf5fd851838aee@mail.gmail.com> References: <284819.31224.qm@web46004.mail.sp1.yahoo.com> <719848.8240.qm@web46008.mail.sp1.yahoo.com> <8e04b5821003122252o25cdf3batc0bf5fd851838aee@mail.gmail.com> Message-ID: <838438.97993.qm@web46005.mail.sp1.yahoo.com> Hi there - Thanks to your help, and David's, I have tried a few other things. Using yoru script I found that indeed it was dtmx that was failing due to the file being larger than 1555 bytes. I deleted all of the commented lines such as this, and then ran dtmxwrite: # Secret portions of key C8093ECE9373F385DB82D721245C4CBC467F1AE1 # Base16 data extracted Sat Mar 13 10:47:10 2010 # Created with paperkey 1.2 by David Shaw # # File format: # a) 1 octet: Version of the paperkey format (currently 0). # b) 1 octet: OpenPGP key or subkey version (currently 4) # c) n octets: Key fingerprint (20 octets for a version 4 key or subkey) # d) 2 octets: 16-bit big endian length of the following secret data # e) n octets: Secret data: a partial OpenPGP secret key or subkey packet as # specified in RFC 4880, starting with the string-to-key usage # octet and continuing until the end of the packet. # Repeat fields b through e as needed to cover all subkeys. # That worked and it successfully generated the bar code. I found that adding in some of the commented lines still allowed the bar code to be generated, albeit a different bar code. What is the advantage of encoding the commented lines into the bar code? I'll go investigate if paperkey will allow an output without the commented sections. John -------------- next part -------------- An HTML attachment was scrubbed... URL: From John at Mozilla-Enigmail.org Sat Mar 13 11:55:01 2010 From: John at Mozilla-Enigmail.org (John Clizbe) Date: Sat, 13 Mar 2010 04:55:01 -0600 Subject: updprefs command and changing key In-Reply-To: <944950702.20100313101435@my_localhost> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <944950702.20100313101435@my_localhost> Message-ID: <4B9B6F05.400@Mozilla-Enigmail.org> MFPA wrote: > On Saturday 13 March 2010 at 12:07:08 AM, in > , David Shaw > wrote: >> On Mar 12, 2010, at 6:31 PM, Faramir wrote: >>> is there a way to disable the usage of 3DES in GnuPG, when >>> encrypting? >> Patch the source :) >> There is no way other than that. > > Wouldn't "--disable-cipher-algo 3DES" achieve this? "Google Is Your Friend?" http://www.google.com/search?&q=disable-cipher-algo+3des http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025042.html "One" is, of course, free to shoot oneself in the foot. There is little rational rationale for disabling 3DES. But if "one" wishes to, then by all means go ahead. -- John P. Clizbe Inet:John (a) Mozilla-Enigmail.org You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net or mailto:pgp-public-keys at gingerbear.net?subject=HELP Q:"Just how do the residents of Haiku, Hawai'i hold conversations?" A:"An odd melody / island voices on the winds / surplus of vowels" From firasmr786 at gmail.com Sat Mar 13 12:06:52 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 16:36:52 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <5414C321-4D8B-4DBA-9A96-0BBC270CDFA6@sixdemonbag.org> References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9ABB4A.1060803@gmail.com> <6C67E73E-8835-4F5A-A2B8-F199EE0DF3A1@sixdemonbag.org> <5414C321-4D8B-4DBA-9A96-0BBC270CDFA6@sixdemonbag.org> Message-ID: On Sat, Mar 13, 2010 at 1:00 PM, Robert J. Hansen wrote: > > I'm a little confused as to how does that make it any different from > using the Pidgin OTR method. > > It's a question of degree, not kind. > > > I simply open up an OTR session, ask my friend a question the answer to > which is secret (only known to him) > > How do you know the secret is known only to him? Most "secrets" really > aren't; a good investigator can discover an awful lot of "secret" > information about someone. Shared-secret authentication is one of the > weakest forms out there. It's better than nothing, but it's not something > that ought be relied upon. People tend to vastly overestimate how secret > their secrets are. > > As an example, a few years ago I saw in a spy novel (set in the modern day) > two protagonists negotiating a phone number over an insecure line. "Hey, > that guy we know who did X? Take his phone number, subtract this number > from it. The resulting phone number is what you need to call." > > It sounds great and reliable: it's a shared secret. The problem is it's > totally bogus. Phone numbers aren't random. In the United States, for > instance, phone numbers follow the NPA-NXX format. That reduces this > question down to a glorified Sudoku: a skilled investigator could figure it > out in just a few minutes. > Thanks for the explanation. Makes sense :-) . I think I understand the pitfalls much better now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From free10pro at gmail.com Sat Mar 13 12:15:32 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sat, 13 Mar 2010 03:15:32 -0800 Subject: key question In-Reply-To: <5987695.20100308213818@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> Message-ID: <4B9B73D4.4090305@gmail.com> Hello MFPA, I couldn't respond to your post for a while. So here it is. On Mon, 8 Mar 2010 21:38:18 +0000 MFPA wrote: >> I never asserted that you said the key's originator owned the >> information stored in the key. I was quoting the context of what your >> reply about the originator having "some rights" was about. I would >> never try to insert words into your mouth. > > I just wanted anybody reading this after the event to be clear the > quoted line about owning was not anything *I* have said. Okay. So we both misunderstood each other. Problem solved. >> Really, I am not interested in talking about what the law says. The law >> may be right, or the law may be wrong. I don't want to know what the >> law thinks, I want to know what you think. > > The legal aspect is an integral part of the answer to your question; > it demonstrates that rights to privacy and to an element of control > over one's personal information are not something I dreamt out of thin > air. Whatever different views people may have on moral or ethical > rights, there are situations where processing/storage/dissemination of > personal information is the subject of an established body of > legislation and legal precedent. All that is open to question is the > extent and nature of privacy "rights" that may exist beyond the narrow > set enshrined in law and the slightly wider set in documents such as > ECHR. The issue of law is not "an integral part of the answer" to the question of what should be. It is an integral part of the answer to what is. If I were to ask you whether every day should be like Christmas, you would likely respond that every day couldn't be like Christmas. Sure, every day couldn't be like Christmas, because of the way people are, but that doesn't mean that that is the way things ought to be. The reason I wanted you to discuss what you believe without regard to the law is because the law is just another man's opinion. I was asking for only yours. >> For the record, I don't believe that the key holder should upload the >> key if the key's originator doesn't want > > Seeing as we are framing this in terms of "rights," do you believe the > holder has a right to upload in these circumstances but "should not" > exercise that right? It depends. Are we talking about ethical rights or lawful rights. I think the key holder has the ethical and lawful rights to use and distribute the key if the key's originator doesn't forbid him. If the keyholder is forbidden, he has the lawful right, but not an ethical right. But the key holder shouldn't have to ask the originator what he may do with the key. The key holder should, by default, have freedom. But if the originator doesn't want his key disseminated, he should say so. And by the way, I apply this rule to me. >> But I don't believe the originator has a /right/ to prevent the key >> holder from sharing it. > > Morally and ethically, I disagree. To use an example with phone > numbers: say I had a personal friend who was an insurance broker with > a teenaged daughter and elderly parents. I would suggest it's > perfectly in order for me to pass to a third party my mate's business > number. I definitely have no moral or ethical right to pass on his > daughter's or parent's numbers or his personal number. Some would > argue he has a right to give me a good beating if I did. So a buddy's business number is public information, and you can share it if you like. But a /public/ key, which by default is considered publicly shareable information, isn't. I get it! So it goes like this. A business telephone number is considered by most to be shareable, and because of that, it is ethically shareable. A public key is considered by most to be shareable, and because of that, it isn't ethically shareable. > In practical terms, the originator currently has no means to prevent > this sharing, whether or not he has a right. In a certain narrow set > of circumstances, there could be an argument for legal redress if the > originator's personal information was shared. Interesting. "... [C]urrently has no means ...." Sounds like you may want some delicious DRM. >> I don't believe the keyserver (or the church) is responsible for >> another's actions. But I wanted to see whether you thought the >> keyserver should be responsible. > > I also don't think a webhost should be deemed responsible if somebody > posts unlawful material on a site or forum that happens to be hosted > on their servers. I agree. I don't believe in guilt by association, including unintentional association. >> The "rights" that you are asserting are similar to copyrights. They >> both restrict the copying and dissemination of the information >> associated with them. > > I cannot conceive of anything other than a presumption of privacy in > respect of the personal information usually present in the UIDs, and > have always been amazed at the number of people displaying it openly > on their public keys. I can't speak for other people, but I can for me. Take a look at the UIDs on my key, which is 0xC7C66ADF3DB6D884. And also, take a look at my master key 0x2188A92DF05045C2 that I signed the other key with. Each of those e-mail addresses on my keys are ones that were already associated with my real name. I had given each of those addresses to family, friends, associates, businesses, or a combination of them. Not one of those accounts had given me any anonymity, and each had been shared outside of people I knew personally. By uploading a key with those addresses on it, does that mean I gave up privacy that I already had? No. I only made it possible for people to now communicate with me with more privacy than they could have had before. I wanted to use PGP within my existing situation. If in the future I want to go underground with a pseudonymous identity, then I will create a PGP key specifically for it. Or if I would like to have a pseudonymous identity as well my real identity, then I would have a separate key and identity that I would protect. We all want an amount of anonymity and privacy. But we each want a different level of it. I believe that many of us on this mailing list want to use cryptography in association with our real identities. Others don't. They prefer anonymity. I like anonymity, and I want it for most of my use of the Internet. But when I post to this mailing list or use those e-mail accounts listed on my public keys, I want to associate them with my real identity. >> So if the key holder can't ethically (not talking >> about physically) share the key or modify it, then what "rights" does >> the key holder have? > > Any use whatsoever that in no way compromises the privacy of the > originator's personal information. That is to say none. Well, other than the fact that he can encrypt a message to the originator's key and use it in accordance with the key owner's wishes. Hansen said it best, "DRM of the honor system." >> Your purpose for keyservers and my purpose for keyservers are different. >> I believe that keyservers should be for the public dissemination of >> keys. You believe that keyservers should be for the private >> dissemination of keys. > > I believe anybody with my details should be able to fetch my key from > a server, but looking at my key should give them no extra personal > information about me. Private dissemination within a public venue. >> What /you/ want is a keyserver that you can upload publicly and share >> privately. I want is a keyserver that I can upload publicly and share >> publicly. > >> Remember that they are called public keyservers. And like a public >> restroom, they can be used by deviant and saint alike. > >> You shouldn't assail the public keyservers. > > My intention was merely to challenge the statement "it's a good idea > to upload your key to a keyserver," since I had seen such sentiments > expressed without qualification various places previously but had > always seen more good reasons against than in favour. I got into a > much longer (and more interesting) discussion than expected. /My way is true and holy. Follow in my foot steps./ I think that you are wrong, because you seem to insist that others must do as you do. It would be equally wrong for me to insist that others must do as I do. You and I have different goals--remember that. The user's purpose is what matters. What does he want to accomplish? Is it only secrecy of his messages? Anonymity? Who is he communicating with? What would meet his needs? It is questions like these that must first be answered. Because they define the purpose. If these questions aren't answered, either consciously or unconsciously, then user has failed before he has started. Why? Because it is like traveling without first determining a destination. When purpose is defined, it is the director of action. The user must yield to purpose if he is to succeed. Then he must let purpose to choose the path. >> You should be calling for an additional kind of keyserver to fill >> the niche of people like you. > > I think it would work better if the option of increased privacy could > be integrated into the mainstream servers. It's unlikely to happen. You are more likely to have the existing keyservers integrate the functionality that you want if you first create a special keyserver for your niche, and then, if it is popular enough, talk them into integrating it. That way you can have the kind of keyserver that you want, now, rather than waiting years to, hopefully, succeed in changing the existing keyservers. -Paul -- If you send me a message, assume that it will be read in transit. But if you want some privacy, then please use my PGP key when sending me messages. +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From firasmr786 at gmail.com Sat Mar 13 13:08:30 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 17:38:30 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> Message-ID: On Sat, Mar 13, 2010 at 1:14 PM, Robert J. Hansen wrote: > Even then ? so what? Let's say the Type II rate is 25%. That's a very > high Type II rate; most people would think that failing to recognize one set > of fake IDs per four is a really bad error rate. Yet, if you're at a > keysigning party where there are five people independently applying a > 25%-faulty test, the likelihood of accepting a fake ID is under 1%. > It really depends on how you're calculating combined probability. If you take an example of 4 individuals at a keysigning party, The combined probability that all individuals would accept a fake ID would be 1/4 * 1/4 * 1/4 * 1/4 = 0.00390625 . However, the combined probability that at least one of the encounters would result in accepting a fake ID would be 1/4 + 1/4 + 1/4 + 1/4 = 1 . Please do correct me if I've made a mistake. I'm not a math guru by any means. But all that aside, I'm pretty sure news reports, etc. of human traffickers, smugglers, spies, etc. all confirm the fact that national IDs such as passports can be forged and do in fact slip by immigration authorities pretty commonly. I think I've gotten the answer to the question in thread. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Sat Mar 13 13:43:24 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 13 Mar 2010 07:43:24 -0500 Subject: updprefs command and changing key In-Reply-To: References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> Message-ID: <3EB03194-6F7F-4F47-8878-CF69305BD519@jabberwocky.com> On Mar 13, 2010, at 1:13 AM, Robert J. Hansen wrote: >> There is no way other than that. 3DES is a required part of OpenPGP, so if you remove it, you're not going to play well with the other programs out there. > > --cipher-algo [something other than 3DES] won't do it? Faramir was asking only about disabling it when encrypting: I was under the impression --cipher-algo could be used to do that. We were discussing this in the context of the cipher preferences system (Subject "updprefs command and changing key"). You cannot remove 3DES from the preferences, even with disable-cipher-algo. You can positively force any cipher algo you like via cipher-algo (rather than by removing one from the available list), but cipher-algo disables preferences altogether (with the usual shoot-yourself-in-the-foot ability that grants you). David From dshaw at jabberwocky.com Sat Mar 13 13:45:06 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 13 Mar 2010 07:45:06 -0500 Subject: updprefs command and changing key In-Reply-To: <944950702.20100313101435@my_localhost> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <944950702.20100313101435@my_localhost> Message-ID: <818185F1-AA03-48E1-9963-27370D3EF23B@jabberwocky.com> On Mar 13, 2010, at 5:14 AM, MFPA wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Saturday 13 March 2010 at 12:07:08 AM, in > , David Shaw > wrote: > > >> On Mar 12, 2010, at 6:31 PM, Faramir wrote: > >>> is there a way to disable the usage of 3DES in GnuPG, when >>> encrypting? > >> Patch the source :) > >> There is no way other than that. > > Wouldn't "--disable-cipher-algo 3DES" achieve this? Try it - make a key that has only 3DES in its preferences, and then try encrypting to it with --disable-cipher-algo 3DES set. You'll end up with 3DES anyway. The way the code is structured, if the cipher selection algorithm fails (and it will in this case - the key requires 3DES, but you've disabled 3DES) so GPG has to resolve the crisis somehow - and it resolves it by using 3DES as it "knows" that OpenPGP requires it to be present. David From kloecker at kde.org Sat Mar 13 13:51:47 2010 From: kloecker at kde.org (Ingo =?utf-8?q?Kl=C3=B6cker?=) Date: Sat, 13 Mar 2010 13:51:47 +0100 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> Message-ID: <201003131351.54343@thufir.ingo-kloecker.de> On Saturday 13 March 2010, erythrocyte wrote: > On Sat, Mar 13, 2010 at 1:14 PM, Robert J. Hansen wrote: > > Even then ? so what? Let's say the Type II rate is 25%. That's a > > very high Type II rate; most people would think that failing to > > recognize one set of fake IDs per four is a really bad error rate. > > Yet, if you're at a keysigning party where there are five people > > independently applying a 25%-faulty test, the likelihood of > > accepting a fake ID is under 1%. > > It really depends on how you're calculating combined probability. If > you take an example of 4 individuals at a keysigning party, > > The combined probability that all individuals would accept a fake ID > would be 1/4 * 1/4 * 1/4 * 1/4 = 0.00390625 . > > However, the combined probability that at least one of the encounters > would result in accepting a fake ID would be 1/4 + 1/4 + 1/4 + 1/4 > = 1 . > > Please do correct me if I've made a mistake. I'm not a math guru by > any means. Sorry, but your calculation is wrong. If the calculation was correct then with 5 encounters the probability would be 1.25 which is an impossibility. Probability is never negative and never > 1. (People say all the time that they are 110 % sure that something will happen, but mathematically that's complete nonsense.) The probability that the fake ID is rejected by all individuals is (1 - 1/4)^4. Consequently, the probability that the fake ID is not rejected by all individuals (i.e. it is accepted at least by one individual) is 1 - (1 - 1/4)^4. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Sat Mar 13 13:58:40 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 13 Mar 2010 07:58:40 -0500 Subject: updprefs command and changing key In-Reply-To: <4B9B6F05.400@Mozilla-Enigmail.org> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <944950702.20100313101435@my_localhost> <4B9B6F05.400@Mozilla-Enigmail.org> Message-ID: On Mar 13, 2010, at 5:55 AM, John Clizbe wrote: > MFPA wrote: >> On Saturday 13 March 2010 at 12:07:08 AM, in >> , David Shaw >> wrote: >>> On Mar 12, 2010, at 6:31 PM, Faramir wrote: >>>> is there a way to disable the usage of 3DES in GnuPG, when >>>> encrypting? >>> Patch the source :) >>> There is no way other than that. >> >> Wouldn't "--disable-cipher-algo 3DES" achieve this? > > "Google Is Your Friend?" > http://www.google.com/search?&q=disable-cipher-algo+3des > > http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025042.html > > "One" is, of course, free to shoot oneself in the foot. There is little rational > rationale for disabling 3DES. It won't work anyway. You can't remove 3DES from the cipher preferences with disable-cipher-algo. The best you can do is set a personal-cipher-preferences with ciphers other than 3DES and then simply decline to communicate at all with people who have a 3DES-only key. To make matters worse, not only does it not work in preventing 3DES being selected via preferences, disable-cipher-algo also has the unpleasant side effect of making the user unable to *decrypt* 3DES messages as well. So setting disable-cipher-algo 3DES both doesn't accomplish what it was intended to, and also breaks other things. I'd avoid it ;) There will eventually come a day when 3DES will have to go. We're not there yet, and it'll be a big deal from the OpenPGP perspective, given the special position that 3DES has within the protocol. David From firasmr786 at gmail.com Sat Mar 13 14:01:39 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sat, 13 Mar 2010 18:31:39 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <201003131351.54343@thufir.ingo-kloecker.de> References: <4B98A7B8.8080408@gmail.com> <201003131351.54343@thufir.ingo-kloecker.de> Message-ID: 2010/3/13 Ingo Kl?cker > Sorry, but your calculation is wrong. If the calculation was correct > then with 5 encounters the probability would be 1.25 which is an > impossibility. Probability is never negative and never > 1. (People say > all the time that they are 110 % sure that something will happen, but > mathematically that's complete nonsense.) > > The probability that the fake ID is rejected by all individuals is > ?(1 - 1/4)^4. > Consequently, the probability that the fake ID is not rejected by all > individuals (i.e. it is accepted at least by one individual) is > ?1 - (1 - 1/4)^4. Ah yes. That makes sense :-) . Thank you. From rdpalmer70 at hotmail.com Fri Mar 12 23:32:05 2010 From: rdpalmer70 at hotmail.com (Robert Palmer) Date: Fri, 12 Mar 2010 17:32:05 -0500 Subject: updprefs command and changing key In-Reply-To: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> Message-ID: Thanks David for helping to clarify. -----Original Message----- From: David Shaw [mailto:dshaw at jabberwocky.com] Sent: Friday, March 12, 2010 5:15 PM To: Robert Palmer Cc: gnupg-users at gnupg.org Subject: Re: updprefs command and changing key On Mar 10, 2010, at 4:07 PM, Robert Palmer wrote: > During exchange of a public key to a 3rd party - they rejected the key for not having a compatible cipher; so, after doing some research the key was edited within gpg to update prefs on the key which now shows a compatible cipher (in this case, AES-256). I re-exported the public key and noticed that the ascii representation was different - this leads me to my question, which is: is this new key 100% compatible with the old key? To elaborate, will previous other 3rd party entities (equipped only with the non-updated prefs version) still be able to decrypt and accept messages signed with the new key? Preliminary testing shows that the updated prefs version encrypted message is able to be decrypted and signature verified on the non-updated prefs version keyring system. > > I am thinking (from preliminary tests) that the "key" information does not get updated at all - but, somehow, the cipher preferences are embedded in the public key - hence, the reason that the exported public key ASCII representation was different before and after updating preferences. This is exactly correct. The prefs are just a field attached to the key. However, your 3rd party should not have rejected the key. The OpenPGP preferences system is designed to *always* reach a valid answer. Every preference list contains Triple-DES, whether you explicitly list it there or not, and every OpenPGP program is compatible with Triple-DES. If no other compatible ciphers are found, the answer is Triple-DES. David From dshaw at jabberwocky.com Sat Mar 13 14:25:45 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 13 Mar 2010 08:25:45 -0500 Subject: Paperkey (Was: Re: ) In-Reply-To: <838438.97993.qm@web46005.mail.sp1.yahoo.com> References: <284819.31224.qm@web46004.mail.sp1.yahoo.com> <719848.8240.qm@web46008.mail.sp1.yahoo.com> <8e04b5821003122252o25cdf3batc0bf5fd851838aee@mail.gmail.com> <838438.97993.qm@web46005.mail.sp1.yahoo.com> Message-ID: On Mar 13, 2010, at 5:22 AM, john espiro wrote: > Hi there - > > Thanks to your help, and David's, I have tried a few other things. Using yoru script I found that indeed it was dtmx that was failing due to the file being larger than 1555 bytes. > > I deleted all of the commented lines such as this, and then ran dtmxwrite: > > # Secret portions of key C8093ECE9373F385DB82D721245C4CBC467F1AE1 > # Base16 data extracted Sat Mar 13 10:47:10 2010 > # Created with paperkey 1.2 by David Shaw > # > # File format: > # a) 1 octet: Version of the paperkey format (currently 0). > # b) 1 octet: OpenPGP key or subkey version (currently 4) > # c) n octets: Key fingerprint (20 octets for a version 4 key or subkey) > # d) 2 octets: 16-bit big endian length of the following secret data > # e) n octets: Secret data: a partial OpenPGP secret key or subkey packet as > # specified in RFC 4880, starting with the string-to-key usage > # octet and continuing until the end of the packet. > # Repeat fields b through e as needed to cover all subkeys. > # > > That worked and it successfully generated the bar code. > > I found that adding in some of the commented lines still allowed the bar code to be generated, albeit a different bar code. > > What is the advantage of encoding the commented lines into the bar code? I'll go investigate if paperkey will allow an output without the commented sections. paperkey can generate text output (which has the comments on top) and raw output. The raw output is binary (so not directly printable as text, and obviously no comments), but has the advantage of being significantly smaller as one byte is one byte, rather than the 3 bytes it takes up in text form. If you are piping to something like dmtx, you should use raw output (--output-type raw). David From expires2010 at ymail.com Sat Mar 13 15:38:45 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 13 Mar 2010 14:38:45 +0000 Subject: updprefs command and changing key In-Reply-To: References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <944950702.20100313101435@my_localhost> <4B9B6F05.400@Mozilla-Enigmail.org> Message-ID: <908386837.20100313143845@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi David On Saturday 13 March 2010 at 12:58:40 PM, you wrote: > It won't work anyway. You can't remove 3DES from the cipher > preferences with disable-cipher-algo. [...] > To make matters worse, not only does it not work in > preventing 3DES being selected via preferences, disable-cipher-algo > also has the unpleasant side effect of making the user unable to > *decrypt* 3DES messages as well. > So setting disable-cipher-algo 3DES both doesn't accomplish what it > was intended to, and also breaks other things. I'd avoid it ;) Fair enough. I just wondered. - -- Best regards MFPA mailto:expires2010 at ymail.com Another person's secret is like another person's money: you are not as careful with it as you are with your own -----BEGIN PGP SIGNATURE----- iQCVAwUBS5ujfKipC46tDG5pAQooygP+OHhC84sISlYWw4lCTsmTlT8MTmm0HnaS t64tex6nF1xJj5yNsiWnqvOQwZrXpkBKP5kqJMlEkoxJEtfl7XE1jEh9Mm+Vu1fB b9SL4kxCZKcfgHe6qlC5/5eLC5/cnd42mdoC6IsdonYbjn+v90zEItT1NgSt1gMc RuICnIWMXCk= =244H -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sat Mar 13 17:34:28 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Mar 2010 11:34:28 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> Message-ID: <11FB525F-0B83-4F23-A0F1-697CA747041D@sixdemonbag.org> On Mar 13, 2010, at 7:08 AM, erythrocyte wrote: > However, the combined probability that at least one of the encounters would result in accepting a fake ID would be 1/4 + 1/4 + 1/4 + 1/4 = 1 . 99.6%; a little different. The binomial theorem gives us the correct numbers. 0 failures: 31.6% 1 failure: 42.2% 2 failures: 21.1% 3 failures: 4.7% 4 failures: 0.4% Anyway. This handwaves the fact that 99.6% of the time, someone at the keysigning party will say, "hey, that's weird!" and show it to everyone else at the keysigning party. Even if your very high Type II error rate is correct, then assuming there's not some deep systemic reason for the failure (i.e., all trials are independent), you still have nothing to worry about. You can have a test that immigration officials screw up 25% of the time, and still have it be perfectly suitable for a keysigning party. From rjh at sixdemonbag.org Sat Mar 13 17:43:44 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Mar 2010 11:43:44 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> Message-ID: > But all that aside, I'm pretty sure news reports, etc. of human traffickers, smugglers, spies, etc. all confirm the fact that national IDs such as passports can be forged and do in fact slip by immigration authorities pretty commonly. Only because the news doesn't report on people who get arrested based on false identity documents. By the very nature of journalism, it pays more attention to the extreme and the unusual than it does the mundane and humdrum. If a madman shoots 14 people in a shopping mall in Oconomowoc, that's news: if 1,400 people die of cancer nationwide that day, it doesn't even get a mention. Following the news would lead you to thinking you needed to buy body armor, not that you could stand to lose a few pounds and you should stop smoking. Be careful about forming your opinions of normalcy from watching news reports. From jeandavid8 at verizon.net Sat Mar 13 18:12:05 2010 From: jeandavid8 at verizon.net (Jean-David Beyer) Date: Sat, 13 Mar 2010 12:12:05 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> Message-ID: <4B9BC765.5080404@verizon.net> Robert J. Hansen wrote: >> But all that aside, I'm pretty sure news reports, etc. of human >> traffickers, smugglers, spies, etc. all confirm the fact that >> national IDs such as passports can be forged and do in fact slip by >> immigration authorities pretty commonly. > > Only because the news doesn't report on people who get arrested based > on false identity documents. By the very nature of journalism, it > pays more attention to the extreme and the unusual than it does the > mundane and humdrum. If a madman shoots 14 people in a shopping mall > in Oconomowoc, that's news: if 1,400 people die of cancer nationwide > that day, it doesn't even get a mention. Following the news would > lead you to thinking you needed to buy body armor, not that you could > stand to lose a few pounds and you should stop smoking. A larger example is that if some madmen flew aircraft into the World Trade Center killing 3000 or so people, that gets a lot of news and a Department of Homeland Security set up, but if we kill 10 times that every year in automobile accidents, do we get highways redesigned, automobiles redesigned, driving tests improved, etc.? > > Be careful about forming your opinions of normalcy from watching news > reports. > -- .~. Jean-David Beyer Registered Linux User 85642. /V\ PGP-Key: 9A2FC99A Registered Machine 241939. /( )\ Shrewsbury, New Jersey http://counter.li.org ^^-^^ 12:05:01 up 52 days, 13:25, 4 users, load average: 4.36, 4.36, 4.64 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From expires2010 at ymail.com Sat Mar 13 21:05:21 2010 From: expires2010 at ymail.com (MFPA) Date: Sat, 13 Mar 2010 20:05:21 +0000 Subject: key question In-Reply-To: <4B9B73D4.4090305@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> <4B9B73D4.4090305@gmail.com> Message-ID: <1199247098.20100313200521@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Saturday 13 March 2010 at 11:15:32 AM, in , Paul Richard Ramer wrote: > The issue of law is not "an integral part of the > answer" to the question of what should be. It is an > integral part of the answer to what is. I see what you mean, but I would say it is integral to both. > If I were to ask you whether every day should be like > Christmas, you would likely respond that every day > couldn't be like Christmas. Sure, every day couldn't > be like Christmas, because of the way people are, but > that doesn't mean that that is the way things ought to > be. Although it isn't really that simple. For example in the UK, the vast majority of shops are closed on Christmas day and most people don't go to work (except for essential services, hospitality, and the few shops/petrol stations that are open). Whether people ought to be "wage-slaves," giving up most of their time to their "master" in return for barely enough to live on, is another question. > The reason I wanted you to discuss what you believe > without regard to the law is because the law is just > another man's opinion. I was asking for only yours. Fair enough. I think I gave both. >>> For the record, I don't believe that the key holder >>> should upload the key if the key's originator doesn't >>> want >> Seeing as we are framing this in terms of "rights," do >> you believe the holder has a right to upload in these >> circumstances but "should not" exercise that right? > It depends. Are we talking about ethical rights or > lawful rights. > I think the key holder has the ethical and lawful > rights to use and distribute the key if the key's > originator doesn't forbid him. If the keyholder is > forbidden, he has the lawful right, but not an ethical > right. Yes, assuming the key showed no personal information. Depending on the jurisdiction and the circumstances, the key holder *might not* have the lawful right to distribute the key originator's personal information. > But the key holder shouldn't have to ask the originator > what he may do with the key. The key holder should, by > default, have freedom. Why? The personal information in the key UIDs is that of the originator, not the holder. If the key reveals no personal information, then I agree. > But if the originator doesn't want his key disseminated, he should > say so. If the key reveals no personal information, then I agree. But why would the holder need to be told the originator doesn't want his personal information circulated without his permission? > And by the way, I apply this rule to me. Which rule? You've already stated that you don't believe the holder should upload the key if the originator doesn't want, so presumably you mean that you would tell somebody if you didn't want them to pass on or upload a key you created? >>> But I don't believe the originator has a /right/ to >>> prevent the key holder from sharing it. >> Morally and ethically, I disagree. To use an example >> with phone numbers: say I had a personal friend who >> was an insurance broker with a teenaged daughter and >> elderly parents. I would suggest it's perfectly in >> order for me to pass to a third party my mate's >> business number. I definitely have no moral or ethical >> right to pass on his daughter's or parent's numbers or >> his personal number. Some would argue he has a right >> to give me a good beating if I did. > So a buddy's business number is public information, and > you can share it if you like. But a /public/ key, > which by default is considered publicly shareable > information, isn't. What do you mean "by default?" As far as I know the "public" in "public key" simply refers to the fact that it *can* be made public without compromising the security of the encryption or digital signatures. That does *not* mean that the personal information usually included in key UIDs for ease of use is publicly shareable. > I get it! So it goes like this. A business telephone > number is considered by most to be shareable, and > because of that, it is ethically shareable. A public > key is considered by most to be shareable, and because > of that, it isn't ethically shareable. A business telephone number *is* considered by most to be ethically shareable. Key UIDs often contain personal contact details and/or aliases. Other people's personal contact details are *not* considered by most to be ethically shareable, and certainly not ethically publishable. > Interesting. "... [C]urrently has no means ...." > Sounds like you may want some delicious DRM. Nothing drastic enough for most to consider it DRM, IMHO. It would be enough for me if keyservers honoured the no-modify flag (with suitable originator-verification and appropriate measures when synchronising) subject to the exception you mentioned previously where somebody revokes a signature they previously placed on that key. Those who desired that anybody could freely upload their keys to servers would simply unset the no-modify flag. > I can't speak for other people, but I can for me. Take > a look at the UIDs on my key, which is > 0xC7C66ADF3DB6D884. And also, take a look at my master > key 0x2188A92DF05045C2 that I signed the other key > with. > Each of those e-mail addresses on my keys are ones that > were already associated with my real name. I had given > each of those addresses to family, friends, associates, > businesses, or a combination of them. Not one of those > accounts had given me any anonymity, and each had been > shared outside of people I knew personally. > By uploading a key with those addresses on it, does > that mean I gave up privacy that I already had? No. It looks to me as if the answer is "yes." Unless each person who had one of your email addresses already knew the other addresses before seeing them on your key, they now have extra information about you. And the addresses have jumped from "shared outside of people [you] knew personally" to published in a universally-accessible location. However minor/negligible or unimportant you may consider it, that's a reduction in privacy. > I only made it possible for people to now communicate with me with > more privacy than they could have had before. And probably shared more of your email addresses with each person than they had before. > I wanted to use PGP within my existing situation. Horses for courses, as they say. I know several people who give a unique email address to each contact. In their situation, it would be inappropriate to publish (or even circulate) a key containing all their email addresses, unless the addresses could be hashed in the UIDs. > If in the future I want to go underground with a > pseudonymous identity, then I will create a PGP key > specifically for it. And in that eventuality, do you see the attraction of optionally hashing email addresses and names in UIDs, so that somebody who knows your email address can find your key but somebody who inspects your key gains no information about you from it? > Or if I would like to have a > pseudonymous identity as well my real identity, then I > would have a separate key and identity that I would > protect. That would be a bit of a bind if you felt that everybody you gave the pseudonymous key to would need *telling* not to circulate or publish it without checking with you first. > We all want an amount of anonymity and privacy. But we > each want a different level of it. For some people, that amount could effectively be "none" judging by their profile and postings on the likes of Facebook. > I believe that many > of us on this mailing list want to use cryptography in > association with our real identities. Others don't. You find both camps on this list and elsewhere. > They prefer anonymity. Or using a pseudonym, which is not the same thing as anonymity. > I like anonymity, and I want it for most of my use of > the Internet. But when I post to this mailing list or > use those e-mail accounts listed on my public keys, I > want to associate them with my real identity. Mine varies between fairly random usernames, MFPA if the site doesn't insist on something longer, and just a couple of things where I use my real name. >>> So if the key holder can't ethically (not talking >>> about physically) share the key or modify it, then >>> what "rights" does the key holder have? >> Any use whatsoever that in no way compromises the >> privacy of the originator's personal information. > That is to say none. Well, other than the fact that he > can encrypt a message to the originator's key and use > it in accordance with the key owner's wishes. The function of the public key is to encrypt messages and to authenticate/verify digital signatures. Other than that, what do you believe the holder has a "right" to do with a key without referring to the originator? (Yes, it can also carry signatures from other people's keys attesting to their belief in the claimed identity of the originator, but this would usually have involved some contact with the originator.) > Hansen said it best, "DRM of the honor system." DRM, in the generally accepted use of the term, is all about greed. And sometimes about copyright or licensing. That is a completely different objective from wishing to keep the key originator's personal information private. DRM usually relies on some measure of intentionally crippling a device or application. Asking somebody before passing on their personal information cripples nothing. Being unable to *upload* somebody else's key to a server would cripple nothing: you already have the key. An option to hash names and email addresses in UIDs would cripple nothing if the plaintext name or email address could still be used to locate the key on the server. IMHO, the only connection between the two is semantic: the keys are stored in a digital form and we have been discussing what "rights" the key holder has in respect of the key originator's personal information. >> I believe anybody with my details should be able to >> fetch my key from a server, but looking at my key >> should give them no extra personal information about >> me. > Private dissemination within a public venue. I don't know why, but that simple phrase suggests to me that you think it would be a bad thing. >>> You shouldn't assail the public keyservers. >> My intention was merely to challenge the statement >> "it's a good idea to upload your key to a keyserver," >> since I had seen such sentiments expressed without >> qualification various places previously but had always >> seen more good reasons against than in favour. I got >> into a much longer (and more interesting) discussion >> than expected. > /My way is true and holy. Follow in my foot steps./ That's similar to my impression of the statement I was challenging. > I think that you are wrong, because you seem to insist > that others must do as you do. It would be equally > wrong for me to insist that others must do as I do. Have I "insisted on" anything beyond the basic courtesy of obtaining consent before passing on other people's personal information? > You and I have different goals--remember that. We definitely have different thoughts on what information we wish to put on public record on a keyserver. > The user's purpose is what matters. What does he want > to accomplish? Is it only secrecy of his messages? > Anonymity? Who is he communicating with? What would > meet his needs? > It is questions like these that must first be answered. > Because they define the purpose. If these questions > aren't answered, either consciously or unconsciously, > then user has failed before he has started. > Why? Because it is like traveling without first > determining a destination. When purpose is defined, it > is the director of action. The user must yield to > purpose if he is to succeed. Then he must let purpose > to choose the path. Very eloquently put. >>> You should be calling for an additional kind of >>> keyserver to fill the niche of people like you. >> I think it would work better if the option of >> increased privacy could be integrated into the >> mainstream servers. > It's unlikely to happen. You are more likely to have > the existing keyservers integrate the functionality > that you want if you first create a special keyserver > for your niche, and then, if it is popular enough, talk > them into integrating it. I would have to persuade somebody with the appropriate skills. Presumably the hashed name or email address option in the UID would be the easier bit to implement, since a nil return on a search would simply require hashing the search string (with whatever standard hash function has been predetermined) and trying again. Honouring keyserver-no-modify would require much more in-depth consideration, such as how best to authenticate, signature revocations, and sending/receiving updates through synchronisation with other servers. > That way you can have the kind of keyserver that you > want, now, rather than waiting years to, hopefully, > succeed in changing the existing keyservers. I read at http://www.imc.org/ietf-openpgp/mail-archive/msg34233.html that the SKS keyservers didnt exist when rfc2440 was published (including defining the no-modify flag). I wonder if keyserver-no-modify has been neglected by the keyservers for technical reasons, or was just too low down a list of priorities? (I googled but couldn't find anything on this question.) - -- Best regards MFPA mailto:expires2010 at ymail.com Oven mitt: A partially charred grease stain that fits over the hand. -----BEGIN PGP SIGNATURE----- iQCVAwUBS5vwCKipC46tDG5pAQqkPgP+N2zYUSupAQMSiZGVwuTUQMeZSgmjnKuK zoSOKrZxPMzYyE3DXOiwTt2Pn3SI86NgbBzUPld+IlCRb/m/up+UMXJ+QdX5NHIJ lTAP2tPtVvzsghMv+C+PvI2+6K3llVVqPfslVK8twH75nHdyBe4L73VfxJVt/J13 mRQYKMQ3BNM= =Ff19 -----END PGP SIGNATURE----- From faramir.cl at gmail.com Sun Mar 14 02:03:29 2010 From: faramir.cl at gmail.com (Faramir) Date: Sat, 13 Mar 2010 22:03:29 -0300 Subject: updprefs command and changing key In-Reply-To: <4B9B1632.3000100@tx.rr.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <4B9B1632.3000100@tx.rr.com> Message-ID: <4B9C35E1.9050009@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 John Clizbe escribi?: > Faramir wrote: >> Just a question, and I don't have any intention about doing it, but, >> is there a way to disable the usage of 3DES in GnuPG, when encrypting? > > Sure, the source is available -- the result just won't be a valid OpenPGP > implementation any longer. Ok, I was clear about that part. > Now for my "Just a Question": Why on earth would you want to? I would not do that, but since the original question in this thread was about having to change the prefs because they didn't show a compatible algo (and AES256 was required), I thought _maybe_ the people refusing to encrypt with 3DES had disabled it. But I suppose they checked the key manually, and noticed AES256 was not listed. It was just curiosity. By the way, is it possible to disable some other encryption algo, but without forcing GnuPG to use a chosen algo? I mean... lets suppose I don't want to use AES, but I'm ok with twofish, 3DES, and Camellia (any of there would be good enough). > To quote a friend of mine discussing 3DES: >> It's perfectly safe. In fact, 3DES is probably the most trustworthy >> algorithm on this list. A few years ago when Schneier was asked for his >> pick for "most trusted encryption algorithm," he said something like >> "3DES. Nothing else even comes close." Sure, use AES for new crypto ... >> It is big, clumsy, ungainly and slow. It has all the aesthetic values >> of the Soviet Realism school of art, and processes data about as fast as >> a snail coming off a three-day scopolamine trip. ... Yes, I still remember that post ;) Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLnDXhAAoJEMV4f6PvczxA0GoH/02fnQkkFBlGMwn074mYwDx1 NLVWUEYj7vHv60awvmgfeuQt17Bh7eiidKa4X9TohJANg4h9cdbsW1gS4qxnMnpb mWIhmANVOU24iTw5DkKmmqATcJptXyCopxqyFaYTWN9Z02Mq7kJTYg56BQDzycd4 YX9FNr1InY/kvE4xh49ZXA+6hFdjY3xXAam4Tti3L7aFo9cngqEsmOmmjqLKg7nL NJwGFkhzTr8jCoQ1Aj09FY5V1ZZQ0HZUzImh40uVoT7WcWaVCwmO2MUCaXNvndue YcX6WEv8fJ4TI+48G+a2KiAPBfvJDH6npQhEpz5/VkdJxRMm7vPus1eW5HMI0Og= =DdOO -----END PGP SIGNATURE----- From firasmr786 at gmail.com Sun Mar 14 02:06:04 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sun, 14 Mar 2010 06:36:04 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <11FB525F-0B83-4F23-A0F1-697CA747041D@sixdemonbag.org> References: <4B98A7B8.8080408@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> <11FB525F-0B83-4F23-A0F1-697CA747041D@sixdemonbag.org> Message-ID: On Sat, Mar 13, 2010 at 10:04 PM, Robert J. Hansen wrote: > > 99.6%; a little different. ?The binomial theorem gives us the correct numbers. > > 0 failures: 31.6% > 1 failure: 42.2% > 2 failures: 21.1% > 3 failures: 4.7% > 4 failures: 0.4% Alrighty... :-) . So the combined probability that there would be >= 1 failures would be 68.4% . > Anyway. [...] someone at the keysigning party will say, "hey, that's weird!" and show it to everyone else at the keysigning party. Umm.. if I understand the nature of the probability tests or calculations just mentioned above, the results have to be accepted as they are. They either got it wrong or right. Those individuals who got it wrong might have actually had that thought, "hey, that's weird", but eventually they did go ahead and make that wrong decision. I'm just recollecting some probability concepts and hypothesis testing concepts I learned a long time ago. And besides, even if the above weren't true, how do I know that someone who does have that thought will make sure to check with others at the keysigning party? >?...assuming there's not some deep systemic reason for the failure (i.e., all > trials are independent), you still have nothing to worry about.... I guess depending on one's security policy or requirements that's a pretty weighty assumption to make. Also, there's a difference between deciding a stranger's identity solely based on a passport/national ID versus checking his/her ID _and_ getting to know them a little better. And that decision lies in the hands of the user. It's a more social issue I guess. Anyhow, I've learned so much from this great discussion over the past few days. Let me thank all who've cared to enlighten a new user such as me about these things. This is definitely a great community! :-) From rjh at sixdemonbag.org Sun Mar 14 03:38:43 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Mar 2010 21:38:43 -0500 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> <11FB525F-0B83-4F23-A0F1-697CA747041D@sixdemonbag.org> Message-ID: <4B9C4C33.507@sixdemonbag.org> On 3/13/10 8:06 PM, erythrocyte wrote: > Umm.. if I understand the nature of the probability tests or > calculations just mentioned above You don't. If person A and person B disagree on whether something is fake, the operating assumption is that it's fake. The burden is on the person claiming it's *not* fake to persuade the person claiming it *is* fake that they're wrong. Alan: "Hey, Bill, did you see this ID? It looks fishy." Bill: "It looked good to me." Alan: "It doesn't look good to me." Bill: "Okay. Let me show you why I thought it was good, and let's take it from there..." > And besides, even if the above weren't true, how do I know that > someone who does have that thought will make sure to check with others > at the keysigning party? There is a word for someone who keeps their mouth shut about fake IDs at keysigning parties. That word is *conspirator*. If you're assuming everyone else at the keysigning party is a conspirator, then sure, you're out of luck. But in that case, you were out of luck before you even stepped in the door. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From dshaw at jabberwocky.com Sun Mar 14 03:49:34 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 13 Mar 2010 21:49:34 -0500 Subject: updprefs command and changing key In-Reply-To: <4B9C35E1.9050009@gmail.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <4B9B1632.3000100@tx.rr.com> <4B9C35E1.9050009@gmail.com> Message-ID: <3B013477-57DB-4092-AFA9-D25631395571@jabberwocky.com> On Mar 13, 2010, at 8:03 PM, Faramir wrote: > It was just curiosity. By the way, is it possible to disable some > other encryption algo, but without forcing GnuPG to use a chosen algo? I > mean... lets suppose I don't want to use AES, but I'm ok with twofish, > 3DES, and Camellia (any of there would be good enough). Sure. If you just don't list AES in your preferences, nobody will use it when encrypting to you. Similarly, if you have personal-cipher-preferences and you leave off AES, you won't use it when encrypting to someone else. You can do that for any cipher that isn't 3DES. 3DES is the only special one here. David From firasmr786 at gmail.com Sun Mar 14 07:52:23 2010 From: firasmr786 at gmail.com (erythrocyte) Date: Sun, 14 Mar 2010 12:22:23 +0530 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B9C4C33.507@sixdemonbag.org> References: <4B98A7B8.8080408@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> <11FB525F-0B83-4F23-A0F1-697CA747041D@sixdemonbag.org> <4B9C4C33.507@sixdemonbag.org> Message-ID: On Sun, Mar 14, 2010 at 8:08 AM, Robert J. Hansen wrote: > On 3/13/10 8:06 PM, erythrocyte wrote: >> Umm.. if I understand the nature of the probability tests or >> calculations just mentioned above, the results have to be accepted as >> they are. They either got it wrong or right. Those individuals who got >> it wrong might have actually had that thought, "hey, that's weird", >> but eventually they did go ahead and make that wrong decision. I'm >> just recollecting some probability concepts and hypothesis testing >> concepts I learned a long time ago. > > You don't. > > If person A and person B disagree on whether something is fake, the > operating assumption is that it's fake. ?The burden is on the person > claiming it's *not* fake to persuade the person claiming it *is* fake > that they're wrong. > > Alan: "Hey, Bill, did you see this ID? ?It looks fishy." > Bill: "It looked good to me." > Alan: "It doesn't look good to me." > Bill: "Okay. ?Let me show you why I thought it was good, and let's take > ? ? ? it from there..." Hmmm...I know this is already getting off-topic. But let me qualify that by saying that it really depends on what error you're calculating here. From my understanding, the probabilities calculated give you random error. That is "given a population of 4 people, there is a 68.4% chance that there would >=1 failures purely by random effects regardless of what actions they may or may not take to influence their chances of making a mistake" . These calculations do not give you the effects of systematic error or bias. Systematic error would be what you're referring to. That can be different. The sum error would be a combination of random and systematic error. Of course, all of this gives us a picture of the average chances of error. When it comes to individual people, like you and I, we are not averages. Some of us will be more adept than others at not making mistakes and that in turn will depend on a whole slew of other factors. Now all of that should be taken into account when thinking about one's security policy. And I might add that all of this also depends on what your perspective is. I for one did not envision a scenario where Alan and Bill from your example, would discuss their ruminations with each other. Of course that might happen. But not necessarily always. That's just human behavior perhaps. >> besides, even if the above weren't true, how do I know that >> someone who does have that thought will make sure to check with others >> at the keysigning party? > > There is a word for someone who keeps their mouth shut about fake IDs at > keysigning parties. ?That word is *conspirator*. Or *incompetent*, *stupid*, *lazy*, *not learned*, *unsure*, *unaware*, etc. It could be any combination of the above :-) . From faramir.cl at gmail.com Sun Mar 14 08:05:22 2010 From: faramir.cl at gmail.com (Faramir) Date: Sun, 14 Mar 2010 03:05:22 -0400 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> <4B99D00A.10507@dougbarton.us> <4B99EF0E.3040908@gmail.com> <69BCFCB2-1907-4F2F-9797-D65A54AC7D45@sixdemonbag.org> <4B9A37A4.6010303@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> Message-ID: <4B9C8AB2.7050705@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 erythrocyte escribi?: ... > The combined probability that all individuals would accept a fake ID > would be 1/4 * 1/4 * 1/4 * 1/4 = 0.00390625 . > > However, the combined probability that at least one of the encounters > would result in accepting a fake ID would be 1/4 + 1/4 + 1/4 + 1/4 = 1 . > > Please do correct me if I've made a mistake. I'm not a math guru by any > means. If memory doesn't betray me, it would be a binomial probability... if I could remember how to use these things... but without doubts, the added probability is not 1. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLnIqxAAoJEMV4f6PvczxAJt0IAI/BbIOq4GBFKZlq4jrfnTOm i7SStJN3YX2fN1JtYUfiVKYHDFvb5VNVxwOERng5UUtw3vOeQzSNS40LWDmC4pJP ldXUn+lfRi1gu+nkY3rD3WV0fHGFNDHs2ZqGoc0+GZPqCVetM/3OZ5eNi1daLbjb ZYKfdtmfDdEj7WejSKJ6dz6QE/GUyAuVHgZam3KiYFX32uYgy9++ohVXJlxa5Q1d jwQYtZ0WvUYBM6BDHKtY4pDn4Z3kp6sqOqlj3k8tehAeU3By25JPj+2q8I5I3nTH 0t4Uwyj0krKcuBY311KZ1OqY0T39I3kau7c8oAup/hBEIevZsSNeyYpkT+w3N0U= =ouEd -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Sun Mar 14 08:49:05 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 14 Mar 2010 03:49:05 -0400 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: References: <4B98A7B8.8080408@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> <11FB525F-0B83-4F23-A0F1-697CA747041D@sixdemonbag.org> <4B9C4C33.507@sixdemonbag.org> Message-ID: <4B9C94F1.8040902@sixdemonbag.org> On 3/14/10 1:52 AM, erythrocyte wrote: > From my understanding, the probabilities calculated give you > random error. That is "given a population of 4 people, there is a > 68.4% chance that there would >=1 failures purely by random effects > regardless of what actions they may or may not take to influence their > chances of making a mistake" . No. "Given a population of four inspectors, there is a 68% chance of one or more failures *due to their actions, inactions and random chance*." Think about a busy street. If there's a 50% chance of a pedestrian in the crosswalk getting turned into a new decoration on the front grill of the cross-town bus, that doesn't mean you should put on a blindfold before stepping out on the street. That would just be crazy. Yet, if the likelihood is 50% "regardless of what actions they may or may not take to influence their chances of making a mistake," then not only is it not crazy to put on a blindfold -- why not put on an iPod, too? > These calculations do not give you the effects of systematic error or > bias. Systematic error would be what you're referring to. That can be > different. Yes. But so far you've failed to even present the *normal* Type II error rate. I'm willing to stipulate a very high normal Type II error rate, but if you want me to believe there's a systemic Type II problem I'm going to need to see citations. > Of course, all of this gives us a picture of the average chances of > error. When it comes to individual people, like you and I, we are not > averages. Of course we are. That's the entire point of statistics. If I know the average IQ is 100, and the standard deviation is 16 points, then if I pull a random person out of a hat I'm about 95% likely they score between an 84 and a 116. Nicholas Taleb (a pretty well-respected statistician and epistemologist) divides the world into Mediocristan and Extremistan. In Mediocristan, the law of averages dominates. In Extremistan, the bell curve exists but its tails are so bizarrely shaped that many statistical tools fail. Independent error is Mediocristan. Systemic error tends to lead to Extremistan. Independent errors are highly predictable and can be accounted for. Systemic error destroys independence, and the entire system comes off the rails shortly thereafter. I'm willing to posit independent error here, and even a really high rate of independent error: but before I say "document inspections are in the land of Extremistan," I'm going to need to see some numbers backing that up. > And I might add that all of this also depends on what your perspective > is. I for one did not envision a scenario where Alan and Bill from > your example, would discuss their ruminations with each other. Err -- why wouldn't they? This is a keysigning party. It is in everyone's best interests to accept all good IDs. If I see an ID that I believe is false, then it is in my own best interests to bring it to the attention of everyone. If I reject an ID incorrectly and refuse to sign, then I am damaging my own standing in the Web of Trust. > Or *incompetent*, *stupid*, *lazy*, *not learned*, *unsure*, > *unaware*, etc. It could be any combination of the above :-) . You keep on inventing ever-more new and exotic ways to suggest systemic bias, without ever giving numbers supporting the claim. If *everyone* is incompetent, stupid, lazy, unsure or unaware, then yes, you've got a really interesting keysigning party (in the "may you live in interesting times" sense of the phrase) and I suggest getting out of there as soon as possible. But that's a stretch I'm simply not willing to grant you. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From expires2010 at ymail.com Sun Mar 14 13:18:18 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 14 Mar 2010 12:18:18 +0000 Subject: Using the OTR plugin with Pidgin for verifying GPG public key fingerprints In-Reply-To: <4B9C94F1.8040902@sixdemonbag.org> References: <4B98A7B8.8080408@gmail.com> <75976148-4F08-4492-AB96-FDF3F15638B9@sixdemonbag.org> <4B9ABA8B.9050407@gmail.com> <84987CD0-CD31-4A21-9EBD-D7329A530E29@sixdemonbag.org> <11FB525F-0B83-4F23-A0F1-697CA747041D@sixdemonbag.org> <4B9C4C33.507@sixdemonbag.org> <4B9C94F1.8040902@sixdemonbag.org> Message-ID: <1491084460.20100314121818@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Robert On Sunday 14 March 2010 at 7:49:05 AM, you wrote: > This is a keysigning party. It is in everyone's best interests to > accept all good IDs. If I see an ID that I believe is false, then it is > in my own best interests to bring it to the attention of everyone. If I > reject an ID incorrectly and refuse to sign, then I am damaging my own > standing in the Web of Trust. Presumably less damage than if you failed to spot a fake ID and went ahead with the signing? - -- Best regards MFPA mailto:expires2010 at ymail.com Two rights do not make a wrong. They make an airplane. -----BEGIN PGP SIGNATURE----- iQCVAwUBS5zULKipC46tDG5pAQq/iQP/aRKLLJbuvkF8J9atNZNOXGFxeoJ+z8Tc ibYEanyF5jECjTEVKzVWCYtD0XKPy2xSNjNbDmf1+MrNp6aiEtJMagiP+UochYq/ MbBFnY2SY3PMrFetO6D0/4gKCE1mu4uaqiuVpxqFv+HJ8z8QvKrrw+MyWCRnNb7U HqQUejgi6Nc= =l+qX -----END PGP SIGNATURE----- From expires2010 at ymail.com Sun Mar 14 13:26:04 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 14 Mar 2010 12:26:04 +0000 Subject: updprefs command and changing key In-Reply-To: <3B013477-57DB-4092-AFA9-D25631395571@jabberwocky.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <4B9B1632.3000100@tx.rr.com> <4B9C35E1.9050009@gmail.com> <3B013477-57DB-4092-AFA9-D25631395571@jabberwocky.com> Message-ID: <1627435166.20100314122604@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi David On Sunday 14 March 2010 at 2:49:34 AM, you wrote: > On Mar 13, 2010, at 8:03 PM, Faramir wrote: >> It was just curiosity. By the way, is it possible to disable some >> other encryption algo, but without forcing GnuPG to use a chosen algo? I >> mean... lets suppose I don't want to use AES, but I'm ok with twofish, >> 3DES, and Camellia (any of there would be good enough). > Sure. If you just don't list AES in your preferences, nobody will > use it when encrypting to you. Similarly, if you have > personal-cipher-preferences and you leave off AES, you won't use it > when encrypting to someone else. Would "--disable-cipher-algo AES" add anything to that? Or cause potential problems? - -- Best regards MFPA mailto:expires2010 at ymail.com Life is far too important a thing ever to talk seriously about -----BEGIN PGP SIGNATURE----- iQCVAwUBS5zV5aipC46tDG5pAQp5jgP9GJcc85zx5d/dmpyuwsFHHO0L1PFxRCAR 6eBYQJqfDEwwPw+ofggumdkyOLK9bpJMLZJHuPOWvHfgMcMD+il82Y6ISu0h1xQQ 0RCQFL9SPCaRJsatLwIapSiTioMnesfl0Z7OtZMQMBNfowRJq6A2lbWww2ahmSnh npe0IgFjJWI= =jkoK -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sun Mar 14 14:19:46 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 14 Mar 2010 09:19:46 -0400 Subject: updprefs command and changing key In-Reply-To: <1627435166.20100314122604@my_localhost> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <4B9B1632.3000100@tx.rr.com> <4B9C35E1.9050009@gmail.com> <3B013477-57DB-4092-AFA9-D25631395571@jabberwocky.com> <1627435166.20100314122604@my_localhost> Message-ID: <699CD008-240B-4181-A157-552CBE241868@jabberwocky.com> On Mar 14, 2010, at 8:26 AM, MFPA wrote: >>> It was just curiosity. By the way, is it possible to disable some >>> other encryption algo, but without forcing GnuPG to use a chosen algo? I >>> mean... lets suppose I don't want to use AES, but I'm ok with twofish, >>> 3DES, and Camellia (any of there would be good enough). > >> Sure. If you just don't list AES in your preferences, nobody will >> use it when encrypting to you. Similarly, if you have >> personal-cipher-preferences and you leave off AES, you won't use it >> when encrypting to someone else. > > Would "--disable-cipher-algo AES" add anything to that? Or cause > potential problems? Potential problems. If you have AES in your key preferences, but you disable it, you are telling people to use AES - but then not decrypting it. Basically, you can guarantee you won't encrypt to anyone using AES if you disable it, but this also means you won't be able to decrypt anything that comes to you in AES. David From expires2010 at ymail.com Sun Mar 14 15:17:31 2010 From: expires2010 at ymail.com (MFPA) Date: Sun, 14 Mar 2010 14:17:31 +0000 Subject: updprefs command and changing key In-Reply-To: <699CD008-240B-4181-A157-552CBE241868@jabberwocky.com> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <4B9B1632.3000100@tx.rr.com> <4B9C35E1.9050009@gmail.com> <3B013477-57DB-4092-AFA9-D25631395571@jabberwocky.com> <1627435166.20100314122604@my_localhost> <699CD008-240B-4181-A157-552CBE241868@jabberwocky.com> Message-ID: <1004533040.20100314141731@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 14 March 2010 at 1:19:46 PM, in , David Shaw wrote: > On Mar 14, 2010, at 8:26 AM, MFPA wrote: >> Would "--disable-cipher-algo AES" add anything to >> that? Or cause potential problems? > Potential problems. If you have AES in your key > preferences, but you disable it, you are telling people > to use AES - but then not decrypting it. > Basically, you can guarantee you won't encrypt to > anyone using AES if you disable it, but this also means > you won't be able to decrypt anything that comes to you > in AES. And if my key preferences and personal-cipher-preferences both omitted AES, I'm not using AES anyway, so disabling it would make no difference. Unless a sender is forcing that algo. Is there anything the disable-cipher-algo option is actually useful for? - -- Best regards MFPA mailto:expires2010 at ymail.com All generalizations are dangerous, even this one. -----BEGIN PGP SIGNATURE----- iQCVAwUBS5zwAaipC46tDG5pAQq7dQP7BQCUQML5wzN4/z7vmrr9earp0k2ASGRl rgn++oVvF9jyps3Z1yfFHZMW5mVUzndx3ungjZPvOTXTO6BwgUHcSEzb4xB0sUYq g3/jJqV9Jt5Peav1IKBt9OR1U5LWoNI1Mz1pVSAUiLAofAHP/zWdFw07S9u0EY2M DCk7jWZ4BM4= =hhy3 -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sun Mar 14 16:43:28 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 14 Mar 2010 11:43:28 -0400 Subject: updprefs command and changing key In-Reply-To: <1004533040.20100314141731@my_localhost> References: <1AE45E4C-20C1-4E3D-996A-32A3C6D8653E@jabberwocky.com> <4B9ACEE2.9060501@gmail.com> <4B9B1632.3000100@tx.rr.com> <4B9C35E1.9050009@gmail.com> <3B013477-57DB-4092-AFA9-D25631395571@jabberwocky.com> <1627435166.20100314122604@my_localhost> <699CD008-240B-4181-A157-552CBE241868@jabberwocky.com> <1004533040.20100314141731@my_localhost> Message-ID: On Mar 14, 2010, at 10:17 AM, MFPA wrote: >> On Mar 14, 2010, at 8:26 AM, MFPA wrote: >>> Would "--disable-cipher-algo AES" add anything to >>> that? Or cause potential problems? > >> Potential problems. If you have AES in your key >> preferences, but you disable it, you are telling people >> to use AES - but then not decrypting it. > >> Basically, you can guarantee you won't encrypt to >> anyone using AES if you disable it, but this also means >> you won't be able to decrypt anything that comes to you >> in AES. > > And if my key preferences and personal-cipher-preferences both omitted > AES, I'm not using AES anyway, so disabling it would make no > difference. Unless a sender is forcing that algo. Correct. And if a sender forced that algo, they would be doing so in violation of OpenPGP. GnuPG will decrypt the message anyway, but it will print a warning that the sender violated your preferences (this warning is actually required by the OpenPGP spec). > Is there anything the disable-cipher-algo option is actually useful > for? Not in general use. It's handy for testing and debugging. David From jimoe at sohnen-moe.com Sun Mar 14 20:24:14 2010 From: jimoe at sohnen-moe.com (James Moe) Date: Sun, 14 Mar 2010 12:24:14 -0700 Subject: Restarting gpg-agent Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, opensuse v11.2, linux 2.6.31.12-0.1-desktop x86_64, gpg v2.0.12. The docs at cover starting gpg-agent pretty well. What is missing is how to re-start it. If gpg-agent is terminated for some reason, or the system is booted, the file <.gpg-agent.info> is left behind. Because the file exists, when .bashrc is run it detects the file and does not start gpg-agent. Is there some way to: 1. Detect if gpg-agent is running. If not, erase <.gpg-agent.info>, or 2. Erase <.gpg-agent.info> at boot time. - -- James Moe jimoe at sohnen-moe dot com 520.743.3936 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkudN90ACgkQzTcr8Prq0ZMySACgkW6NISv89nIdgQaeTSdGIpgf 1gIAoKJDb4iDdwoi60iNBAjFLVBhORq0 =MkjM -----END PGP SIGNATURE----- From dougb at dougbarton.us Sun Mar 14 22:40:03 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 14 Mar 2010 14:40:03 -0700 Subject: Restarting gpg-agent In-Reply-To: References: Message-ID: <4B9D57B3.7070203@dougbarton.us> On 03/14/10 12:24, James Moe wrote: > Hello, > opensuse v11.2, linux 2.6.31.12-0.1-desktop x86_64, gpg v2.0.12. > The docs at cover starting gpg-agent pretty > well. What is missing is how to re-start it. > If gpg-agent is terminated for some reason, or the system is booted, > the file <.gpg-agent.info> is left behind. Because the file exists, when > .bashrc is run it detects the file and does not start gpg-agent. > Is there some way to: > 1. Detect if gpg-agent is running. If not, erase <.gpg-agent.info>, or > 2. Erase <.gpg-agent.info> at boot time. http://dougbarton.us/PGP/index.html, click on the link for the gpg-agent script. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From lists at michel-messerschmidt.de Sun Mar 14 22:16:00 2010 From: lists at michel-messerschmidt.de (Michel Messerschmidt) Date: Sun, 14 Mar 2010 22:16:00 +0100 Subject: Restarting gpg-agent In-Reply-To: References: Message-ID: <20100314211600.GA23808@hiro.matrix> On Sun, Mar 14, 2010 at 12:24:14PM -0700, James Moe wrote: > Hello, > opensuse v11.2, linux 2.6.31.12-0.1-desktop x86_64, gpg v2.0.12. > The docs at cover starting gpg-agent pretty > well. What is missing is how to re-start it. > If gpg-agent is terminated for some reason, or the system is booted, > the file <.gpg-agent.info> is left behind. Because the file exists, when > .bashrc is run it detects the file and does not start gpg-agent. > Is there some way to: > 1. Detect if gpg-agent is running. If not, erase <.gpg-agent.info>, or > 2. Erase <.gpg-agent.info> at boot time. This works for me (in .bashrc): export GNUPGHOME="${HOME}/.gnupg" GPGAGENT=/usr/bin/gpg-agent GA_INFO_FILE="${GNUPGHOME}/gpg-agent-info-$(hostname)" # check that gpg-agent is executable and enabled in the gpg config if grep -qs '^[[:space:]]*use-agent' "${GNUPGHOME}/gpg.conf" && test -x ${GPGAGENT}; then # always re-read the gpg-agent info file to find the running instance if [ -r "${GA_INFO_FILE}" ]; then . "${GA_INFO_FILE}" fi # start gpg-agent if no running instance is found if test -z "${GPG_AGENT_INFO}" || ! kill -0 `grep GPG_AGENT_INFO ${GA_INFO_FILE} | cut -d: -f 2 -` 2>/dev/null; then # enable ssh support by default if set in global Xsession options if grep -qs '^[[:space:]]*use-ssh-agent' /etc/X11/Xsession.options; then GA_SSH=--enable-ssh-support fi # execute gpg-agent and export environment variables eval $(${GPGAGENT} --daemon ${GA_SSH} --sh --write-env-file=${GA_INFO_FILE}) fi export GPG_AGENT_INFO export SSH_AUTH_SOCK export SSH_AGENT_PID fi HTH, Michel From free10pro at gmail.com Mon Mar 15 08:54:03 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Mon, 15 Mar 2010 00:54:03 -0700 Subject: key question In-Reply-To: <1199247098.20100313200521@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> <4B9B73D4.4090305@gmail.com> <1199247098.20100313200521@my_localhost> Message-ID: <4B9DE79B.3050402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, 13 Mar 2010 20:05:21 +0000 MFPA wrote: >> And by the way, I apply this rule to me. > > Which rule? You've already stated that you don't believe the holder > should upload the key if the originator doesn't want, so presumably > you mean that you would tell somebody if you didn't want them to pass > on or upload a key you created? Scrap that sentence that you quoted. Below is what I said before that sentence, and these paragraphs below are what I believe. And I govern me by what I believe. /I think the key holder has the ethical and lawful rights to use and distribute the key if the key's originator doesn't forbid him. If the key holder is forbidden, he has the lawful right, but not an ethical right. But the key holder shouldn't have to ask the originator what he may do with the key. The key holder should, by default, have freedom. But if the originator doesn't want his key disseminated, he should say so./ >> Each of those e-mail addresses on my keys are ones that >> were already associated with my real name. I had given >> each of those addresses to family, friends, associates, >> businesses, or a combination of them. Not one of those >> accounts had given me any anonymity, and each had been >> shared outside of people I knew personally. > >> By uploading a key with those addresses on it, does >> that mean I gave up privacy that I already had? No. > > It looks to me as if the answer is "yes." Unless each person who had > one of your email addresses already knew the other addresses before > seeing them on your key, they now have extra information about you. > And the addresses have jumped from "shared outside of people [you] > knew personally" to published in a universally-accessible location. > However minor/negligible or unimportant you may consider it, that's a > reduction in privacy. > > >> I only made it possible for people to now communicate with me with >> more privacy than they could have had before. > > And probably shared more of your email addresses with each person than > they had before. If you knew more about how I shared those e-mail addresses, you might conclude differently. I think that I disclosed less than you may have gotten the impression that I did, since those addresses were never private information. > Horses for courses, as they say. I know several people who give a > unique email address to each contact. In their situation, it would be > inappropriate to publish (or even circulate) a key containing all > their email addresses, unless the addresses could be hashed in the > UIDs. Personally, I prefer to give an e-mail address, and then filter messages based upon the sender. But that is my preference. I don't believe it is The One True Way. :-) >> We all want an amount of anonymity and privacy. But we >> each want a different level of it. > > For some people, that amount could effectively be "none" judging by > their profile and postings on the likes of Facebook. Unfortunately, yes. :-\ Thank God that I never chose to do such foolishness. Although technically I have an account on one of the social networking sites, it contains nothing more than a name and is only minimally used for affairs concerning other people. :-| >> If in the future I want to go underground with a >> pseudonymous identity, then I will create a PGP key >> specifically for it. > > And in that eventuality, do you see the attraction of optionally > hashing email addresses and names in UIDs, so that somebody who > knows your email address can find your key but somebody who > inspects your key gains no information about you from it? Probably not. I might consider it, though. I would most likely create a UID like your's--pseudonym and nothing more. Then use the key with e-mail accounts that would never have information about my real identity. This doesn't mean that the hashed UIDs idea couldn't be good for someone else. >> They prefer anonymity. > > Or using a pseudonym, which is not the same thing as anonymity. Anything that connects two or more messages together, whether it be a key ID, pseudonym, or secret pass phrase or sign, is less than perfect anonymity. Even speech patterns will give less than perfect anonymity. Perfect anonymity is difficult, if not impossible, to achieve. It can also be impractical, e.g. if I don't have a way of knowing that I am communicating with the same person each time, how can I know that I am not talking to an enemy. If I am to have multiple communications with an anonymous entity, I have to know that the last anonymous entity and the one that I am talking to now are the same. There has to be something identifying. It doesn't matter what it is, but it must be there. Would I risk sharing secret information with the wrong person? Perfect anonymity is like perfect privacy. They are both impossible to have if we are to live our lives while having relationships and associations. Perfect privacy means not knowing anyone or seeing anyone. Because once someone has seen you, learned information about you, or seen where you have gone, you have lost some privacy. You no longer have perfect privacy. In fact, just by posting to this mailing list we have given up some privacy or anonymity. The nature of the way we write, what we think, the experiences that we relate--all of these reveal something about ourselves. None of this is to say that we shouldn't have privacy or anonymity. It is just that we should realize that we need to balance our need for privacy and anonymity with the needs and desires of the way that we want to live. Similarly, perfect anonymity will fail once someone can connect multiple messages or activities to an identity (whether or not that identity is a pseudonym, real name, or something else). My needs or desires may be different from your needs and desires. And our needs and desires may be different than John Doe's needs and desires. It doesn't, by necessity, make any of us better than the others. >> I like anonymity, and I want it for most of my use of >> the Internet. But when I post to this mailing list or >> use those e-mail accounts listed on my public keys, I >> want to associate them with my real identity. > > Mine varies between fairly random usernames, MFPA if the site doesn't > insist on something longer, and just a couple of things where I use my > real name. I too avoid using my real name for most things. I only use my real name when I want it associated with whatever the item is or if, for some reason, a real name is required of me. >>> I believe anybody with my details should be able to >>> fetch my key from a server, but looking at my key >>> should give them no extra personal information about >>> me. > >> Private dissemination within a public venue. > > I don't know why, but that simple phrase suggests to me that you think > it would be a bad thing. No, I think that it is fine. Probably the reason that sentence comes off the way it does is that I previously inferred that you wanted a "keyserver that you can upload publicly and download privately", and I felt that your answer to that question skirted around saying "yes". But truly, it is private dissemination within a public venue. Nothing is wrong with that, but it is different than what the keyservers are currently for, which is public dissemination. I can see how some people, such as yourself, would like to have such a system. But it shouldn't be touted as The One True Way any more than the current system. >> /My way is true and holy. Follow in my foot steps./ > > That's similar to my impression of the statement I was challenging. I don't like anyone telling me that something *must* be done a certain way; when in reality, it was just their preference. >> I think that you are wrong, because you seem to insist >> that others must do as you do. It would be equally >> wrong for me to insist that others must do as I do. > > Have I "insisted on" anything beyond the basic courtesy of obtaining > consent before passing on other people's personal information? - From reading all of the posts by you to this thread, I would infer that you been, at least somewhat, projecting your goals and needs and desires onto whoever the user is. It is a subtlety to your posts. I imagine that you will tell me that I am a fruit cake, but I could waste my words on a whole post to demonstrate this subtlety. As for the rest of the issues, everyone has different goals and needs. It would be foolish for us to assume what is best for all users. There is no One True Way and no one-size-fits-all. - -Paul - -- "Plagiarism is the greatest form of flattery." --self +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQGcBAEBCAAGBQJLnedqAAoJEJhBiuhgbQLISpwL/jwWQa421CrF/MHWdtjfHxs8 Bxfqic0JgcVTLiy+1X7JaGdtgytXafSjW1EVj8cpA1zOVyDnxPRjO7kLwGxm6GcL tXHD/FKT3lecZveVNC7ioWITFuXJgkpVk5AaC9KyGJ69TmpovgOMRugvqVxgAtjq flPALiBMU5apvzMVmuQKuTlRXoNmUn8gvJ2fnaU8uge8Yut2e6DVX/32Tj92jNAq CsjWKzlwJSgDb5fHlupsURuFQXl6RzwngA6G0fvEX4NOMYVn9wGE6oveYzQ6aUdH tG+0QjzKS9J3vqnhnjziJ8JK3D5CURdcW9r+UBLTairoQGERneBAoL7G9+fcEfjM am7OgNUxOA5cvW03hmz3dBQM3XC/03FYR2z2vpPFwjy2U+D0r2UcudLvrG738MgZ GQGdBOZ8iIs9VqggUVTDz9c6JZ9/zItxcudu6zd975H1Op1nwhI8Xy4v9Mn+MMm6 3LSn4jcx45Ai147ZnDG0JPfdsS3MECbkFdFCQnc3SQ== =WrIX -----END PGP SIGNATURE----- From free10pro at gmail.com Mon Mar 15 09:28:16 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Mon, 15 Mar 2010 01:28:16 -0700 Subject: key question In-Reply-To: <1736930089.20100308183141@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B921851.9050201@gmail.com> <1024723752.20100307164609@my_localhost> <4B94AAEA.5040904@gmail.com> <1736930089.20100308183141@my_localhost> Message-ID: <4B9DEFA0.4020202@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Mon, 8 Mar 2010 18:31:41 +0000 MFPA wrote: >> I am also assuming that the user has intelligence and judgment. > > A useful combination, sadly not common enough (-; Better than useful, it is essential. :-) >> I mean that he must be able to realize that he needs to be competent >> in the tool that he is using. How could a person of judgment believe >> that he could have the minimum knowledge of how to use cryptography >> and his OpenPGP tool, and believe that he will successfully protect >> his privacy? > > Even intelligence and judgment together do not necessarily lead to > perfect decisions. The point when the user *thinks* he has sufficient > knowledge or competence does not automatically coincide with the point > at which this is true. Good judgment will lead to good decisions. >> I have been naive before. But I didn't begin using GnuPGP while I was >> still naive about it. I studied how cryptography and OpenPGP worked, >> how to use gpg, and how to use it with e-mail and files. > > Many people are less patient than you must be; I have heard numerous > people advocate the "ready, fire,aim" approach to life. The "ready, fire, aim" approach leads to missed targets and the death or injury of bystanders. Uh . . . metaphorically speaking, of course. >> That is what I was saying in the previous posting. Someone who desires >> privacy will do what it takes to get it. That includes dispelling his >> naivety with knowledge. > > Which is an ongoing process. An individual desirous of privacy is > likely to continue finding new threats and/or new protections for as > long as they care to keep looking. Knowledge is the first step to wisdom. You can have knowledge without wisdom, but you cannot have wisdom without knowledge. >> As for the person not realizing how easy it would be to accidentally >> upload a public key to a keyserver, I was never that naive. I was aware >> of it from the beginning. My key wasn't on the keyservers, initially (I >> chose to upload it later). But I knew that if I was careless it could >> wind up there. > > Were you aware because of something you read, or because of > experimentation? Neither; I deduced it. Also no one told me about traffic analysis, but I deduced it and later read about it. - -Paul - -- Lex Luthor: Miss Teschmacher, people can read _War and Peace_ and think it's a simple adventure story. Others read a gum wrapper and unlock secrets of the universe. Miss Teschmacher: Lex, what has chewing gum got to do with secrets of the universe? Lex Luthor: Right. Right, Miss Teschmacher. --From the movie _Superman_ +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQGcBAEBCAAGBQJLne+NAAoJEJhBiuhgbQLIsikL/jmcQHWw1YUPlOrA+kXDXx1v C7jQI9KZm8+in9SLmebWxUNBnKbN9gzVJQyDg6Md2qtpJ4lY/ot7T4E8J0Sk0Y9K c0X+2WoNcZFzg1lA4mHa5/riOtfL7swOUiy0UhtFN7+r3rP/5uIZy0PQn573RZut cqb2SI56DlEop3+905ZRtd5rXPzOY9zyWa9RFlYX1RHrpon/aWA9xr7rGUb+ZGuz scm4/Tm8yVQ0CM2ssdzGkQTw2/x9HTkWdzupvgCePn6aqfRJY7dhi/KSkKuvLfWV 9vBVrKG8JLPsqsoRYRUrBXXnhJvy7rnnAP1KBVDnFViLoJAMI/Fza3+7ueYtjp9j RExjwoWb0KHo7gWzrLmb7W0/R7Q+0m4Rnj/wU9alftCeSR4SP+frBHmVosGkw71E 6byJoj/no+aRRoRi4XAo+VZg9b9Fc9d+f9njv7ga2dYmvazDBixidJT7iKEqIivf gUC2UUmDDfNG4Rb4Kt8PyrIB01BSXb3SEby38JM7SQ== =0xQk -----END PGP SIGNATURE----- From expires2010 at ymail.com Mon Mar 15 11:53:33 2010 From: expires2010 at ymail.com (MFPA) Date: Mon, 15 Mar 2010 10:53:33 +0000 Subject: key question In-Reply-To: <4B9DEFA0.4020202@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B921851.9050201@gmail.com> <1024723752.20100307164609@my_localhost> <4B94AAEA.5040904@gmail.com> <1736930089.20100308183141@my_localhost> <4B9DEFA0.4020202@gmail.com> Message-ID: <1229801937.20100315105333@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 15 March 2010 at 8:28:16 AM, in , Paul Richard Ramer wrote: > Better than useful, it is essential. :-) Essential? Plenty of people manage without it. (-; > Good judgment will lead to good decisions. Good judgment will lead to a preponderance of good decisions, not to a 100% record of good decisions. > The "ready, fire, aim" approach leads to missed targets > and the death or injury of bystanders. Uh . . . > metaphorically speaking, of course. It also leads to taking action quickly and building momentum. It can often be easier to change direction in the light of new knowledge and the wisdom of others, than to overcome the inertia of inaction and start out in the right direction once you have learnt "everything." Of course, it depends what type of endeavour you are undertaking. (-: > Knowledge is the first step to wisdom. You can have > knowledge without wisdom, but you cannot have wisdom > without knowledge. Unless you subscribe to the view that knowledge as what you learn from your own mistakes and wisdom as what you learn from other people's mistakes. I've heard it stated often enough (usually by the same people who advocate "ready, fire, aim"). - -- Best regards MFPA mailto:expires2010 at ymail.com Vegetarian: Indian word for lousy hunter!!! -----BEGIN PGP SIGNATURE----- iQCVAwUBS54RyKipC46tDG5pAQq42gP/fcWDVGQH5YvCJS1fMwssTNxnuU8J0rRk D5ils7sUGdFUD2ruIqTIhadQOf8gujSCi5bKPbelHsAyFcueKw8Jlluzx0pwQOnn AgEX0/4OpFPNQYRIFzGSWKy7zE0mStvWwwFcYp4bp5zyVs1Ej93na6zMb8THuHbP Y6GWznAY2uk= =bAoq -----END PGP SIGNATURE----- From roam at ringlet.net Mon Mar 15 11:58:27 2010 From: roam at ringlet.net (Peter Pentchev) Date: Mon, 15 Mar 2010 12:58:27 +0200 Subject: Restarting gpg-agent In-Reply-To: <20100314211600.GA23808@hiro.matrix> References: <20100314211600.GA23808@hiro.matrix> Message-ID: <20100315105827.GA1314@straylight.m.ringlet.net> On Sun, Mar 14, 2010 at 10:16:00PM +0100, Michel Messerschmidt wrote: > On Sun, Mar 14, 2010 at 12:24:14PM -0700, James Moe wrote: > > Hello, > > opensuse v11.2, linux 2.6.31.12-0.1-desktop x86_64, gpg v2.0.12. > > The docs at cover starting gpg-agent pretty > > well. What is missing is how to re-start it. > > If gpg-agent is terminated for some reason, or the system is booted, > > the file <.gpg-agent.info> is left behind. Because the file exists, when > > .bashrc is run it detects the file and does not start gpg-agent. > > Is there some way to: > > 1. Detect if gpg-agent is running. If not, erase <.gpg-agent.info>, or > > 2. Erase <.gpg-agent.info> at boot time. > > > This works for me (in .bashrc): A good idea, and well written :) Just one minor thing... > # start gpg-agent if no running instance is found > if test -z "${GPG_AGENT_INFO}" || > ! kill -0 `grep GPG_AGENT_INFO ${GA_INFO_FILE} | cut -d: -f 2 -` 2>/dev/null; then In this way, you risk a false positive if gpg-agent has died (or not been started at all, but a .gpg-agent.info file has been left over) and there is another process with the same process ID. This *can* happen, whether by random chance at system startup, or by random chance on a long-running system with PID's wrapping around. A slightly better (if somewhat more convoluted) way could be something like: gpg_agent_pid='' gpg_agent_running='' if [ -n "${GPG_AGENT_INFO}" ] && [ -r "$GA_INFO_FILE" ]; then gpg_agent_pid=`grep GPG_AGENT_INFO "${GA_INFO_FILE}" | cut -d: -f 2 -` fi if [ -n "$gpg_agent_pid" ] && expr "x$gpg_agent_pid" : 'x[0-9]*$' > /dev/null; then if pgrep gpg-agent | fgrep -qw "$gpg_agent_pid" > /dev/null; then gpg_agent_running='1' fi fi if [ -n "$gpg_agent_running" ]; then ... fi Please don't take this as criticism, just an idea :) And, of course, it assumes that the OS has pgrep(1). G'luck, Peter -- Peter Pentchev roam at ringlet.net roam at space.bg roam at FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 What would this sentence be like if pi were 3? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 834 bytes Desc: not available URL: From expires2010 at ymail.com Mon Mar 15 15:49:32 2010 From: expires2010 at ymail.com (MFPA) Date: Mon, 15 Mar 2010 14:49:32 +0000 Subject: key question In-Reply-To: <4B9DE79B.3050402@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> <4B9B73D4.4090305@gmail.com> <1199247098.20100313200521@my_localhost> <4B9DE79B.3050402@gmail.com> Message-ID: <898525505.20100315144932@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 15 March 2010 at 7:54:03 AM, in , Paul Richard Ramer wrote: > If you knew more about how I shared those e-mail > addresses, you might conclude differently. OK > I think that I disclosed less than you may have gotten > the impression that I did, since those addresses were > never private information. I don't understand the comment that they were never private information. They will have been private information from their inception up until the time you publicised them or published them. > Personally, I prefer to give an e-mail address, and > then filter messages based upon the sender. But that > is my preference. I don't believe it is The One True > Way. :-) It is simplest, and almost certainly most common, to just have a small number of addresses. Multiple addresses and/or disposable addresses can be a useful tool, but they can add complexity with no real advantage if their use is not properly thought out. >>> If in the future I want to go underground with a >>> pseudonymous identity, then I will create a PGP key >>> specifically for it. >> And in that eventuality, do you see the attraction of >> optionally hashing email addresses and names in UIDs, >> so that somebody who knows your email address can find >> your key but somebody who inspects your key gains no >> information about you from it? > Probably not. I might consider it, though. I would > most likely create a UID like your's--pseudonym and > nothing more. Then use the key with e-mail accounts > that would never have information about my real > identity. > This doesn't mean that the hashed UIDs idea couldn't be > good for someone else. I see the target user as somebody who wishes to keep their personal contact details private, but wants openPGP users who already have their contact details to be able to discover their key. Not wishing to reveal my email address in my key, when faced with all the literature saying I should, was one of the main reasons I didn't adopt PGP the first couple of times I looked at it. Since I have no reason to expect my thoughts on this to be unique, I believe the hashing option for the information in UIDs would remove an obstacle that deters some people from using openPGP. > Anything that connects two or more messages together, > whether it be a key ID, pseudonym, or secret pass > phrase or sign, is less than perfect anonymity. Even > speech patterns will give less than perfect anonymity. > Perfect anonymity is difficult, if not impossible, to > achieve. It can also be impractical, e.g. if I don't > have a way of knowing that I am communicating with the > same person each time, how can I know that I am not > talking to an enemy. Even if you know it is the same person, you could still be talking to an enemy. You may not realise they are a spy working for a rival organisation, for example. > If I am to have multiple communications with an > anonymous entity, I have to know that the last > anonymous entity and the one that I am talking to now > are the same. There has to be something identifying. > It doesn't matter what it is, but it must be there. > Would I risk sharing secret information with the wrong > person? That doesn't only apply to anonymous entities. For example, is today's John Smith the same John Smith I communicated with last week? > Perfect anonymity is like perfect privacy. They are > both impossible to have if we are to live our lives > while having relationships and associations. What is perfect anonymity? If I recognise somebody by sight as being somebody I have seen before but know nothing about, are they no longer perfectly anonymous to me? Is somebody with many short-term relationships and associations more anonymous than somebody with fewer but long-term? One is known to more people but each knows less about them. > Perfect privacy means not knowing anyone or seeing > anyone. Because once someone has seen you, learned > information about you, or seen where you have gone, you > have lost some privacy. You no longer have perfect > privacy. True. > In fact, just by posting to this mailing list we have > given up some privacy or anonymity. The nature of the > way we write, what we think, the experiences that we > relate--all of these reveal something about ourselves. When the reader is Big Brother, or a potential employer or blackmailer etc., that might matter. When the reader is a random stranger, I prefer to think it doesn't. I'm confident I don't post anything that should prompt anybody to identify and come after me. > Similarly, perfect anonymity will fail once someone can > connect multiple messages or activities to an identity > (whether or not that identity is a pseudonym, real > name, or something else). How is that of consequence until they make the link between the identity and the person (or people) behind it? Knowledge that "John Smith" engages in certain activities is of no use until the "John Smith" in question has been pinpointed. > My needs or desires may be different from your needs > and desires. And our needs and desires may be > different than John Doe's needs and desires. It > doesn't, by necessity, make any of us better than the > others. I'm sure neither of us claimed it did (-; >>>> I believe anybody with my details should be able to >>>> fetch my key from a server, but looking at my key >>>> should give them no extra personal information about >>>> me. >>> Private dissemination within a public venue. >> I don't know why, but that simple phrase suggests to >> me that you think it would be a bad thing. > No, I think that it is fine. Probably the reason that > sentence comes off the way it does is that I previously > inferred that you wanted a "keyserver that you can > upload publicly and download privately", and I felt > that your answer to that question skirted around saying > "yes". It did, because I was not sure I could attach the correct meaning to "upload publicly and download privately" to answer "yes." (-: > But truly, it is private dissemination within a public > venue. Nothing is wrong with that, but it is different > than what the keyservers are currently for, which is > public dissemination. > I can see how some people, such as yourself, would like > to have such a system. But it shouldn't be touted as > The One True Way any more than the current system. Public dissemination is definitely the keyservers' function, but is it also their purpose? Why would I want to download somebody's key? 1. to verify a signature. 2. to sign their key after meeting them and verifying ID documents. 3. to encrypt a message to them. For 1 and 2, I already know the key ID. For 3, I already know the email address. Is there something I have missed about the purpose of a keyserver, that dictates it needs to show me the email address if I don't already know it? I'm not saying one way is "right" and another is "wrong," just that exposing personal contact details is a privacy concern and I don't see any inherent advantage. >> Have I "insisted on" anything beyond the basic >> courtesy of obtaining consent before passing on other >> people's personal information? > - From reading all of the posts by you to this thread, > I would infer that you been, at least somewhat, > projecting your goals and needs and desires onto > whoever the user is. It is a subtlety to your posts. Perhaps. But there are posts by people pointing out that things I have raised have been discussed multiple times in the past. This confirms that some other people share (or have shared) some of my concerns. > I imagine that you will tell me that I am a fruit cake, > but I could waste my words on a whole post to > demonstrate this subtlety. I'm sure if you did it would make interesting reading, but it's not necessary. > As for the rest of the issues, everyone has different > goals and needs. It would be foolish for us to assume > what is best for all users. I believe "it is 'best for all users' to advocate greater care with other people's personal information," is not a foolish assumption. > There is no One True Way and no one-size-fits-all. Indeed. The UID hashing idea, that I read about during the life of this thread, would be an additional option to accommodate an increased range of privacy goals. Possibly that particular niche is too marginal to be worth implementing, but it shouldn't be dismissed without consideration. - -- Best regards MFPA mailto:expires2010 at ymail.com Dogs look up to us. Cats look down on us. Pigs treat us as equals. -----BEGIN PGP SIGNATURE----- iQCVAwUBS55JBKipC46tDG5pAQodLAP9HoBUZ50LYBcrN+STXoPSGIRAPJP62AvA JxeSKykKIjxVAJwRlFoHnyMv6J4yL16hwx85rPhxXUzz4P1t8Hasefmqie4quYEU UDtzw4Fm+xVQzj9K01OsPoNIF4LlefsLgkPNt/SXZz34mtf2d/rbt8D0apVwtYwc DeGecgLKsKs= =g48B -----END PGP SIGNATURE----- From wk at gnupg.org Mon Mar 15 17:54:49 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Mar 2010 17:54:49 +0100 Subject: Restarting gpg-agent In-Reply-To: <20100315105827.GA1314@straylight.m.ringlet.net> (Peter Pentchev's message of "Mon, 15 Mar 2010 12:58:27 +0200") References: <20100314211600.GA23808@hiro.matrix> <20100315105827.GA1314@straylight.m.ringlet.net> Message-ID: <87d3z5ikyu.fsf@vigenere.g10code.de> On Mon, 15 Mar 2010 11:58, roam at ringlet.net said: >> # start gpg-agent if no running instance is found >> if test -z "${GPG_AGENT_INFO}" || >> ! kill -0 `grep GPG_AGENT_INFO ${GA_INFO_FILE} | cut -d: -f 2 -` 2>/dev/null; then > > In this way, you risk a false positive if gpg-agent has died (or not > been started at all, but a .gpg-agent.info file has been left over) I have not follewed this thread. However the code above is far too complex. For years gpg-agent is able to test whether it is already running, just call gpg-agent and don't pass the --daemon option: $ gpg-agent gpg-agent: gpg-agent running and available $ echo $? 0 $ GPG_AGENT_INFO= gpg-agent gpg-agent: no gpg-agent running in this session $ echo $? 2 Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From listen at story-games.at Mon Mar 15 17:17:08 2010 From: listen at story-games.at (Aaron Berthold) Date: Mon, 15 Mar 2010 17:17:08 +0100 Subject: Portable GnuPG? (Ideally with portable TB+Enigmail) Message-ID: <4B9E5D84.6060104@story-games.at> Hi everybody! I've been using GnuPG for a while now (The 1.x branch in combination with TB and Enigmail, to be precise.) and have been very happy with it, happy enough that I keep trying to "convert" people, running little informal workshops showing my friends and aquaintances the basics of encryption and how to use it. One barrier so far is that people sometimes are hesistant to install a bunch of stuff just to check something out, especially when it's something "weird", like crypto. So I've been thinking that a portable version, complete with TV, Enigmail and trustdb/pubring/secring files safed on a flash drive would be useful, as I could just show people how it worked right on their own pcs without much installation or configuration. Sadly, I'm not skilled enough to do this myself and my online search has only found something like http://portableapps.com/node/11402 , which didn't work when I tried it. (Installed it using the instruction at the link, Enigmail didn't find the portable gnupg version. -_-'') So, have I missed anything that's already out there or am I out of luck? Aaron From kgo at grant-olson.net Mon Mar 15 21:14:14 2010 From: kgo at grant-olson.net (Grant Olson) Date: Mon, 15 Mar 2010 16:14:14 -0400 Subject: Portable GnuPG? (Ideally with portable TB+Enigmail) In-Reply-To: <4B9E5D84.6060104@story-games.at> References: <4B9E5D84.6060104@story-games.at> Message-ID: <4B9E9516.4080407@grant-olson.net> On 3/15/2010 12:17 PM, Aaron Berthold wrote: > > Sadly, I'm not skilled enough to do this myself and my online search has > only found something like http://portableapps.com/node/11402 , which > didn't work when I tried it. (Installed it using the instruction at the > link, Enigmail didn't find the portable gnupg version. -_-'') > I think you just found the wrong page. Install the latest thunderbirdPortable from here: http://portableapps.com/support/thunderbird_portable And install gpg from here: http://portableapps.com/support/thunderbird_portable#encryption This one isn't listed as a development test or beta status like the page you had. Then install Enigmail. It worked fine for me. Also keep in mind it's not a good idea to insert a USB Drive with your private key into an untrusted computer. You might want to make a dummy key for demo purposes. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From listen at story-games.at Mon Mar 15 22:24:57 2010 From: listen at story-games.at (Aaron Berthold) Date: Mon, 15 Mar 2010 22:24:57 +0100 Subject: Portable GnuPG? (Ideally with portable TB+Enigmail) Message-ID: <4B9EA5A9.9090704@story-games.at> On 15.03.2010 21:14, Grant Olson wrote: > I think you just found the wrong page. Install the latest > thunderbirdPortable from here: > > http://portableapps.com/support/thunderbird_portable > > And install gpg from here: > > http://portableapps.com/support/thunderbird_portable#encryption > > This one isn't listed as a development test or beta status like the page > you had. > > Then install Enigmail. > > It worked fine for me. Thanks, I'll try that one. (Weird that I didn't find it. Huh...) > Also keep in mind it's not a good idea to insert a USB Drive with your > private key into an untrusted computer. You might want to make a dummy > key for demo purposes. Yeah, getting copies of your private keys on untrusted pcs (and entering the passphrase there) is a Bad Idea. I'll probably make a zipped "blank package", with TB/Enigmail/Gnupg installed but without keys or anything, to show keygen, importing etc. So I could extract the prepared package, show my stuff and then just delete the whole thing and start from from the fresh package on the next computer. (Although, ideally, people would say "Wow, that's awesome!" and just keep using the programs. ^_^ ) Aaron From benjamin at py-soft.co.uk Mon Mar 15 22:27:51 2010 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Mon, 15 Mar 2010 21:27:51 +0000 Subject: Restarting gpg-agent In-Reply-To: <87d3z5ikyu.fsf@vigenere.g10code.de> References: <20100314211600.GA23808@hiro.matrix> <20100315105827.GA1314@straylight.m.ringlet.net> <87d3z5ikyu.fsf@vigenere.g10code.de> Message-ID: <732076a81003151427v2c97337at49705aaa4a5c4ac3@mail.gmail.com> On 15 March 2010 16:54, Werner Koch wrote: > For years gpg-agent is able to test whether it is already > running, just call gpg-agent and don't pass the --daemon option: This is what I use the fall back as part of MacGPG2: (* start-gpg-agent Part of the MacGPG2 project - http://macgpg2.sourceforge.net Released under v3 of the GPL *) -- Sleep for two seconds. delay 2 -- Try to contact gpg-agent set gpgAgentRunning to do shell script "/usr/local/bin/gpg-agent >& /dev/null; echo $?; exit 0" -- If that fails, look for env file. if gpgAgentRunning > 0 then set gpgAgentRunning to do shell script "[ -f $HOME/.gpg-agent-info ] && (source $HOME/.gpg-agent-info && export GPG_AGENT_INFO && /usr/local/bin/gpg-agent >& /dev/null) ; echo $?; exit 0" end if -- If that also fails, start a new copy of gpg-agent if gpgAgentRunning > 0 then do shell script "/usr/local/bin/gpg-agent --daemon --use-standard-socket --write-env > /dev/null" end if Should be easy to understand and implement in another scripting language. Ben From andre at amorim.me Mon Mar 15 23:47:59 2010 From: andre at amorim.me (Andre Amorim) Date: Mon, 15 Mar 2010 22:47:59 +0000 Subject: Portable GnuPG? (Ideally with portable TB+Enigmail) In-Reply-To: <4B9EA5A9.9090704@story-games.at> References: <4B9EA5A9.9090704@story-games.at> Message-ID: Maybe winPT portable as a GUI. But last time I got some alerts made by my antivirus while runing winpt portable.... Now what I'm doing is have my pendrive (better with CD read only system if you're got a truly paranoia) with Ubuntu Privacy Remix installed https://www.privacy-cd.org/ .. + Truecrypt GUI ready to run. All the best Andre Amorim. On 15 March 2010 21:24, Aaron Berthold wrote: > > On 15.03.2010 21:14, Grant Olson wrote: >> I think you just found the wrong page. ?Install the latest >> thunderbirdPortable from here: >> >> http://portableapps.com/support/thunderbird_portable >> >> And install gpg from here: >> >> http://portableapps.com/support/thunderbird_portable#encryption >> >> This one isn't listed as a development test or beta status like the page >> you had. >> >> Then install Enigmail. >> >> It worked fine for me. > > Thanks, I'll try that one. (Weird that I didn't find it. Huh...) > >> Also keep in mind it's not a good idea to insert a USB Drive with your >> private key into an untrusted computer. ?You might want to make a dummy >> key for demo purposes. > > Yeah, getting copies of your private keys on untrusted pcs (and entering > the passphrase there) is a Bad Idea. I'll probably make a zipped "blank > package", with TB/Enigmail/Gnupg installed but without keys or anything, > to show keygen, importing etc. So I could extract the prepared package, > show my stuff and then just delete the whole thing and start from from > the fresh package on the next computer. (Although, ideally, people would > say "Wow, that's awesome!" and just keep using the programs. ^_^ ) > > Aaron > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Andre Amorim GnuPG KEY ID: 0x587B1970 FingerPrint: 42AE C929 4D91 4591 4E75 430F 78D9 53B4 587B 1970 Download: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x587B1970 From jpboard2 at yahoo.com Tue Mar 16 02:02:41 2010 From: jpboard2 at yahoo.com (James Board) Date: Mon, 15 Mar 2010 18:02:41 -0700 (PDT) Subject: Corrupted File Message-ID: <244985.59554.qm@web45906.mail.sp1.yahoo.com> I have a fairly large file (about 10 mbytes) that was corrupted on disk. About 5-10 pages of the file (4096-byte blocks) were lost and set to zero. The file is a PGP encryption of a another file which is a 'tar' file of other smaller ASCII text files. I would like to decrypt as much of this file as possible. I know with several blank pages, I can never fully recover the file. However, most of the data is still legitimate. Is it possible to recover it with the gpg tools? To this point, I had been using the older PGP 5.0 version, but I can try gpg if it can decrypt most of the file. jp From free10pro at gmail.com Tue Mar 16 07:02:15 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Mon, 15 Mar 2010 23:02:15 -0700 Subject: key question In-Reply-To: <898525505.20100315144932@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> <4B9B73D4.4090305@gmail.com> <1199247098.20100313200521@my_localhost> <4B9DE79B.3050402@gmail.com> <898525505.20100315144932@my_localhost> Message-ID: <4B9F1EE7.9000404@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello MFPA, On Mon, 15 Mar 2010 14:49:32 +0000 MFPA wrote: >> I think that I disclosed less than you may have gotten >> the impression that I did, since those addresses were >> never private information. > > I don't understand the comment that they were never private > information. They will have been private information from their > inception up until the time you publicised them or published them. I meant that at the time that I decided to include them into my key's UIDs, I had already shared those e-mail addresses a lot. >> Probably not. I might consider it, though. I would >> most likely create a UID like your's--pseudonym and >> nothing more. Then use the key with e-mail accounts >> that would never have information about my real >> identity. > >> This doesn't mean that the hashed UIDs idea couldn't be >> good for someone else. > > I see the target user as somebody who wishes to keep their personal > contact details private, but wants openPGP users who already have > their contact details to be able to discover their key. > > Not wishing to reveal my email address in my key, when faced with all > the literature saying I should, was one of the main reasons I didn't > adopt PGP the first couple of times I looked at it. Since I have no > reason to expect my thoughts on this to be unique, I believe the > hashing option for the information in UIDs would remove an obstacle > that deters some people from using openPGP. Given the current system, I think that it would be good to educate new adopters that an e-mail address in the UID is optional. >> If I am to have multiple communications with an >> anonymous entity, I have to know that the last >> anonymous entity and the one that I am talking to now >> are the same. There has to be something identifying. >> It doesn't matter what it is, but it must be there. >> Would I risk sharing secret information with the wrong >> person? > > That doesn't only apply to anonymous entities. For example, is today's > John Smith the same John Smith I communicated with last week? Well, unless you have a way to prove who John Smith is, he is about as anonymous as a pseudonymous entity. >> Perfect anonymity is like perfect privacy. They are >> both impossible to have if we are to live our lives >> while having relationships and associations. > > What is perfect anonymity? If I recognise somebody by sight as being > somebody I have seen before but know nothing about, are they no longer > perfectly anonymous to me? Is somebody with many short-term > relationships and associations more anonymous than somebody with fewer > but long-term? One is known to more people but each knows less about > them. Perfect (i.e. absolute) anonymity is the quality of having the inability to connect any actions to an entity, regardless of whether that entity is identified by a speech pattern, pseudonym, real name, or something else. >> In fact, just by posting to this mailing list we have >> given up some privacy or anonymity. The nature of the >> way we write, what we think, the experiences that we >> relate--all of these reveal something about ourselves. > > When the reader is Big Brother, or a potential employer or blackmailer > etc., that might matter. When the reader is a random stranger, I > prefer to think it doesn't. I'm confident I don't post anything that > should prompt anybody to identify and come after me. I was just referring to privacy disclosure as though it were measured by a scale measuring from absolutely no disclosure to total disclosure. >> Similarly, perfect anonymity will fail once someone can >> connect multiple messages or activities to an identity >> (whether or not that identity is a pseudonym, real >> name, or something else). > > How is that of consequence until they make the link between the > identity and the person (or people) behind it? Knowledge that "John > Smith" engages in certain activities is of no use until the "John > Smith" in question has been pinpointed. I wasn't talking about practicality but about absolutes. In absolutes, if two messages are connected to the same identity, there is no longer absolute anonymity. But this doesn't matter, because, in practicality, no person has yet been identified. >>>> Private dissemination within a public venue. > >>> I don't know why, but that simple phrase suggests to >>> me that you think it would be a bad thing. > >> No, I think that it is fine. Probably the reason that >> sentence comes off the way it does is that I previously >> inferred that you wanted a "keyserver that you can >> upload publicly and download privately", and I felt >> that your answer to that question skirted around saying >> "yes". > > It did, because I was not sure I could attach the correct meaning to > "upload publicly and download privately" to answer "yes." (-: Understood. I think that "private dissemination within a public venue" is a better description than "upload publicly and download privately". > Public dissemination is definitely the keyservers' function, but is it > also their purpose? > > Why would I want to download somebody's key? > 1. to verify a signature. > 2. to sign their key after meeting them and verifying ID documents. > 3. to encrypt a message to them. > > For 1 and 2, I already know the key ID. For 3, I already know the > email address. > > Is there something I have missed about the purpose of a keyserver, > that dictates it needs to show me the email address if I don't already > know it? > > I'm not saying one way is "right" and another is "wrong," just that > exposing personal contact details is a privacy concern and I don't see > any inherent advantage. Different things for different people. That's my belief. :-) >> I imagine that you will tell me that I am a fruit cake, >> but I could waste my words on a whole post to >> demonstrate this subtlety. > > I'm sure if you did it would make interesting reading, but it's not > necessary. Far too unnecessary. ;-) >> There is no One True Way and no one-size-fits-all. > > Indeed. The UID hashing idea, that I read about during the life of > this thread, would be an additional option to accommodate an increased > range of privacy goals. Possibly that particular niche is too marginal > to be worth implementing, but it shouldn't be dismissed without > consideration. Because that niche might be to marginal, I recommended that making a working keyserver with those features would be the way to go. Then, if the usage is high enough, get the other keyservers to implement it. If you (or someone else who is interested) have the right skills, you could download the SKS keyserver code that is located at http://sks-keyserver.googlecode.com/files/sks-1.1.1.tgz and begin hacking it. Then after you have created working code, you could try to get it integrated into the existing codebase. - -Paul - -- "You are free to rip me off. Just remember to credit me." --self PGP Key ID: 0x3DB6D884 PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQGcBAEBCAAGBQJLnx7QAAoJEJhBiuhgbQLItNAMAITPNECEql+ajKABdpcTjEWp 1Zwylp920T4j0SZX+761pIsgwCEuy2FpDylJRI3+Iw7JmS/OK/0HWFOUvlo81fwz evXChj22E4e60j+hTIAj75bI9ziZsHN3gKXOtau1RZPgN4Zhb5xtbMXcRDQmbyjW cZtUoEbadLN/izRoJCZcp9Cll6q+hMUTwQ/W8IhqLaGNqztxplydO+dZsEydhTXT nQRFOkJu/eknutHIQpS1p0j/ZieX1xnB/h5GxQ8r8B8ZqEXGp7elCWT4bDBs6h4G RAIIQM3RUYaXiZRNFZ0EXTyw3xb52lNS0VBEsx6AY7O5DZUrdO0/igmZVeRoWD0H /MVia4kXbGBCws/QXLpeuX8Nh3X8DyTXsXM92lRusybXWGcJnYYmq5Fyy7EBuE6v QGvvNoqKBIgjyyW3tnTatjOtaHskPJDZ33zegjU/eaXM0eelONOefYkvEHXj0ydY kwBb2J3/u6dMM7/ubdUZTDuG4+eLpS8P4pr03oWkqQ== =W33K -----END PGP SIGNATURE----- From expires2010 at ymail.com Tue Mar 16 11:24:52 2010 From: expires2010 at ymail.com (MFPA) Date: Tue, 16 Mar 2010 10:24:52 +0000 Subject: key question In-Reply-To: <4B9F1EE7.9000404@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> <4B9B73D4.4090305@gmail.com> <1199247098.20100313200521@my_localhost> <4B9DE79B.3050402@gmail.com> <898525505.20100315144932@my_localhost> <4B9F1EE7.9000404@gmail.com> Message-ID: <1862286029.20100316102452@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 16 March 2010 at 6:02:15 AM, in , Paul Richard Ramer wrote: > On Mon, 15 Mar 2010 14:49:32 +0000 MFPA wrote: >> I don't understand the comment that they were never >> private information. They will have been private >> information from their inception up until the time you >> publicised them or published them. > I meant that at the time that I decided to include them > into my key's UIDs, I had already shared those e-mail > addresses a lot. I see what you mean, but I would still consider them to be private information. I have a record of numerous people's email addresses and phone numbers but each is a piece of private information appertaining to the person it can be used to contact. > Given the current system, I think that it would be good > to educate new adopters that an e-mail address in the > UID is optional. So do I. >> That doesn't only apply to anonymous entities. For >> example, is today's John Smith the same John Smith I >> communicated with last week? > Well, unless you have a way to prove who John Smith is, > he is about as anonymous as a pseudonymous entity. That's what I meant: the fact of it being his real name rather than a pseudonym makes no difference. > Understood. I think that "private dissemination within > a public venue" is a better description than "upload > publicly and download privately". It also has the feel of quite a catchy slogan. (-; >> Indeed. The UID hashing idea, that I read about during >> the life of this thread, would be an additional option >> to accommodate an increased range of privacy goals. >> Possibly that particular niche is too marginal to be >> worth implementing, but it shouldn't be dismissed >> without consideration. > Because that niche might be to marginal, I recommended > that making a working keyserver with those features > would be the way to go. Then, if the usage is high > enough, get the other keyservers to implement it. > If you (or someone else who is interested) have the > right skills, you could download the SKS keyserver code > that is located at > http://sks-keyserver.googlecode.com/files/sks-1.1.1.tgz > and begin hacking it. Then after you have created > working code, you could try to get it integrated into > the existing codebase. That obviously makes sense. - -- Best regards MFPA mailto:expires2010 at ymail.com Put knot yore trust inn spel chequers -----BEGIN PGP SIGNATURE----- iQCVAwUBS59cfKipC46tDG5pAQpVbgP+JCkJpwt0cNSInmRB4mB+egOsUfN9WaIy wEvnYTia+IeuWuPx7FMcYARVH+UCitOsvcnHmjg7pYvGcjnXiFqGzlSVL4J4rIgk 3BjpEbRn6hNc5lnFSYGATkjIUP+Xii7E173z/qBWA/zl4m5ngWnhKMoyhA0Yr+LC vuxcjrJL/c8= =YhGS -----END PGP SIGNATURE----- From kgo at grant-olson.net Tue Mar 16 15:02:33 2010 From: kgo at grant-olson.net (Grant Olson) Date: Tue, 16 Mar 2010 10:02:33 -0400 Subject: Should I set cert-digest-algo? Message-ID: <4B9F8F79.3050105@grant-olson.net> A while ago I stumbled onto instructions to up my prefs to use a better hash than SHA1: http://www.debian-administration.org/users/dkg/weblog/48 Today I was surfing around, and saw some relatively recent posts on the list that said setting "digest-algo" in gpg.conf was a Bad Idea(tm). I didn't find any threads on setting "cert-digest-algo", but the manpage notes that this can cause interoperability issues. So is setting "cert-digest-algo SHA256" okay, or is it going to cause problems? -Grant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Tue Mar 16 15:38:58 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 16 Mar 2010 10:38:58 -0400 Subject: Should I set cert-digest-algo? In-Reply-To: <4B9F8F79.3050105@grant-olson.net> References: <4B9F8F79.3050105@grant-olson.net> Message-ID: <4B9F9802.9040201@fifthhorseman.net> On 03/16/2010 10:02 AM, Grant Olson wrote: > A while ago I stumbled onto instructions to up my prefs to use a better > hash than SHA1: > > http://www.debian-administration.org/users/dkg/weblog/48 Hi Grant, i'm the author of that post. > Today I was surfing around, and saw some relatively recent posts on the > list that said setting "digest-algo" in gpg.conf was a Bad Idea(tm). I > didn't find any threads on setting "cert-digest-algo", but the manpage > notes that this can cause interoperability issues. > > So is setting "cert-digest-algo SHA256" okay, or is it going to cause I've used cert-digest-algo SHA512 (even more likely to cause interop problems than SHA256) ever since i wrote that post, and i have gotten no complaints at all about my certifications being unusable. this may have something to do with who i interact with, though (mostly other free software folks); you might have a different experience if you have contacts who are locked into ancient software for one reason or another. I think that SHA256 should be pretty unobjectionable these days. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 891 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Tue Mar 16 16:18:03 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 16 Mar 2010 11:18:03 -0400 Subject: Should I set cert-digest-algo? In-Reply-To: <4B9F8F79.3050105@grant-olson.net> References: <4B9F8F79.3050105@grant-olson.net> Message-ID: On Mar 16, 2010, at 10:02 AM, Grant Olson wrote: > A while ago I stumbled onto instructions to up my prefs to use a better > hash than SHA1: > > http://www.debian-administration.org/users/dkg/weblog/48 > > Today I was surfing around, and saw some relatively recent posts on the > list that said setting "digest-algo" in gpg.conf was a Bad Idea(tm). I > didn't find any threads on setting "cert-digest-algo", but the manpage > notes that this can cause interoperability issues. > > So is setting "cert-digest-algo SHA256" okay, or is it going to cause > problems? It depends on who you are communicating with. If they're using a fairly recent version of GnuPG or PGP, then it's fine. If there is someone using old software in the mix, then you'll be preventing them from using your key and any signatures you make. David From Rhiannon at viva.org.uk Tue Mar 16 18:47:53 2010 From: Rhiannon at viva.org.uk (Rhiannon Buck) Date: Tue, 16 Mar 2010 17:47:53 +0000 Subject: Gnupg stopped working after being moved to new host Message-ID: Hi Our host (Cedant) was bought out by Aplus so we have been moved to their new super-snazzy servers. Unfortunately the encrypted emails with credit card information which are sent through to our shop for staff to process are all coming through blank. Do you know which files I need to change to get it working again? I've changed these: Putenv $plainTxt $crypted system The host does have Gnupg installed Many Thanks Daisy-Mae daizzychain at hotmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From reynt0 at cs.albany.edu Wed Mar 17 01:58:37 2010 From: reynt0 at cs.albany.edu (reynt0) Date: Tue, 16 Mar 2010 20:58:37 -0400 (EDT) Subject: key question In-Reply-To: <4B9F1EE7.9000404@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> <4B9B73D4.4090305@gmail.com> <1199247098.20100313200521@my_localhost> <4B9DE79B.3050402@gmail.com> <898525505.20100315144932@my_localhost> <4B9F1EE7.9000404@gmail.com> Message-ID: On Mon, 15 Mar 2010 14:49:32 +0000 MFPA wrote: . . . >> In fact, just by posting to this mailing list we have >> given up some privacy or anonymity. The nature of the >> way we write, what we think, the experiences that we >> relate--all of these reveal something about ourselves. > > When the reader is Big Brother, or a potential employer or blackmailer > etc., that might matter. When the reader is a random stranger, I > prefer to think it doesn't. I'm confident I don't post anything that > should prompt anybody to identify and come after me. . . . Of course, if only one person subscribed to the list is using a gmail address, Google will have the opportunity to run their analytical algorithms on all posts, and add information they find about content, interests, attitudes, etc to the profiles they try to maintain about everyone in the known universe. And isn't their business model based on making all that info conveniently usable for anyone in the known or unknown universe who has a few dollars to partner with them or maybe even just plain pay for it? The concept of personhood built in to European culture (and its American derivatives) in general presumes anonymity of the inner self. That is part of why it is interesting to watch things now, as the combination of decreased locational community in the industrial+ age and increased access to electronically-mediated self-expression results in mindless Facebook/etc displays, and to wonder what cultural adaptations might arise. European extensions of privacy protections to electronic activities being one example of adaptation. I have been appreciating the comments by MFPA (who seems to be in England?, a country with its own problems about personal privacy, cf www.privacyinternational.org/article.shtml?cmd%5B347%5D=x-347-559597 ) as an expression of careful fastidiousness about privacy. From kgo at grant-olson.net Wed Mar 17 01:49:51 2010 From: kgo at grant-olson.net (Grant) Date: Tue, 16 Mar 2010 20:49:51 -0400 Subject: Gnupg stopped working after being moved to new host In-Reply-To: References: Message-ID: <4BA0272F.2000102@grant-olson.net> On 3/16/2010 1:47 PM, Rhiannon Buck wrote: > Unfortunately the encrypted emails with credit card information which > are sent through to our shop for staff to process are all coming through > blank. > > > > Do you know which files I need to change to get it working again? I?ve > changed these: > > Putenv > > $plainTxt > > $crypted > > system > > > > The host does have Gnupg installed > You're going to need to provide A LOT more details to get some help. To start with, did the keyring get migrated as well? Are the public keys you need on the new server? (gpg --list-keys) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From expires2010 at ymail.com Wed Mar 17 21:21:37 2010 From: expires2010 at ymail.com (MFPA) Date: Wed, 17 Mar 2010 20:21:37 +0000 Subject: key question In-Reply-To: References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> <4B9B73D4.4090305@gmail.com> <1199247098.20100313200521@my_localhost> <4B9DE79B.3050402@gmail.com> <898525505.20100315144932@my_localhost> <4B9F1EE7.9000404@gmail.com> Message-ID: <1661805449.20100317202137@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Wednesday 17 March 2010 at 12:58:37 AM, in , reynt0 wrote: > On Mon, 15 Mar 2010 14:49:32 +0000 MFPA wrote: . . . >> When the reader is Big Brother, or a potential >> employer or blackmailer etc., that might matter. When >> the reader is a random stranger, I prefer to think it >> doesn't. I'm confident I don't post anything that >> should prompt anybody to identify and come after me. > . . . > Of course, if only one person subscribed to the list is > using a gmail address, Google will have the opportunity > to run their analytical algorithms on all posts, and > add information they find about content, interests, > attitudes, etc to the profiles they try to maintain > about everyone in the known universe. Unfortunately, even if nobody subscribes to the list with a gmail address we have no way of knowing if anybody archives their mail to one. Anyway, the list archives are available various places on the internet, some of which don't make the best job of hiding people's email addresses; Google (or anybody else) have the opportunity to analyse the posts there. > And isn't their > business model based on making all that info > conveniently usable for anyone in the known or unknown > universe who has a few dollars to partner with them or > maybe even just plain pay for it? Yes, their old "don't be evil" motto should have been suffixed with "(do as we say, not as we do)." (-; Unfortunately, refusing to email people on gmail addresses, as advocated at www.google-watch.org/gmail.html and other places is ineffective, since the recipient can simply give you a different address and set it to forward to their gmail account. Using https://ssl.scroogle.org/cgi-bin/nbbwssl.cgi rather than www.google.com as your search site feels as if it should be more private but scroogle's lack of anything labelled "privacy policy" is of concern. > I have been appreciating the comments by MFPA (who > seems to be in England?, a country with its own > problems about personal privacy, cf > www.privacyinternational.org/article.shtml?cmd%5B347%5D=x-347-559597 > ) as an expression of careful fastidiousness about > privacy. Yes, we are spied on by all sorts of entities, from police and local government to agencies of the national government to private entities running petrol stations, car parks, shopping centres, etc. I always think the correct response to seeing a sign like, "this forecourt is monitored by CCTV with ANPR," would be to cover your number plates before entering and uncover them after leaving. We are routinely asked for completely irrelevant personal details when signing up for utility or banking services or when applying for a job, and many people are still daft enough to supply them without question. As well as spying on us, the UK government and its agencies have a record of not protecting the information it holds. See, for example, http://news.bbc.co.uk/1/hi/7103566.stm http://www.securitypark.co.uk/security_article263344.html http://news.bbc.co.uk/1/hi/7704611.stm http://www.computing.co.uk/computing/news/2229271/176-government-breaches http://news.softpedia.com/news/Yet-Another-Data-Leak-from-the-UK-Ministry-of-Defense-94403.shtml These breaches alone make it vital to be as careful as reasonably possible when sharing your personal information, and not to share anything the other party cannot demonstrate is necessary. Giving a unique email address each time, for example, helps to identify who is failing to safeguard your data and should not be trusted. - -- Best regards MFPA mailto:expires2010 at ymail.com Don't cry because it is over - smile because it happened -----BEGIN PGP SIGNATURE----- iQCVAwUBS6E54aipC46tDG5pAQoh8QQAk75SZm2x2+t/+9AtUzYQ8vJRKEmA7E4I K0yLgZKblIVcE8tfO2ZvPM3gS8sYAV8Suxj0Y2mila0aVjIH/YF1OEGVlf7FATv4 JHXZ91x/S4N53z67tiSbsz/YgMoKJRSd67md9oPhJDCAKaor30y02xou0fcy9veq SaO7qHDA9/Q= =fVEB -----END PGP SIGNATURE----- From alavarre at gmail.com Wed Mar 17 20:40:38 2010 From: alavarre at gmail.com (C. Andrews Lavarre) Date: Wed, 17 Mar 2010 15:40:38 -0400 Subject: Where to find g13? Message-ID: <4BA13036.1020005@gmail.com> Hello. Can someone please show me a link to download and install *G13*, the LUKS replacement? Alternatively, would you suggest an exit to the quagmire below... Extensive googling has not succeeded. I am on OpenSuSE 11.2 (kernel 2.6.31.12-0.1-default) with their selection of GPG 1.2.0.12-2.3. I've tried upgrading directly from gnupg.org and end up with the same version. I'm trying to install OpenVAS and Nessus. Both fail with the installed gpgme 1.2.0-2.5. Googling tells me that gpgme 1.1.18 works, but I haven't been able to find that, although I *have* obtained gpgme 1.3.0 source. Compiling gpgme 1.3.0 from source fails with a warning that g13 is not available. I cannot find a copy on my system or in its repositories. It is just a *configure* warning, so I can proceed to *make*, but then that then fails with error: assuan.h: No such file or directory We load libassuan and try again. But it still fails. So I'm getting nowhere fast. Thanks in advance, Andy From free10pro at gmail.com Thu Mar 18 05:48:36 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Wed, 17 Mar 2010 21:48:36 -0700 Subject: Corrupted File In-Reply-To: <244985.59554.qm@web45906.mail.sp1.yahoo.com> References: <244985.59554.qm@web45906.mail.sp1.yahoo.com> Message-ID: <4BA1B0A4.1040403@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello James, On Mon, 15 Mar 2010 18:02:41 -0700 (PDT) James Board wrote: > I have a fairly large file (about 10 mbytes) that was corrupted on disk. About 5-10 pages of the file (4096-byte blocks) were lost and set to zero. The file is a PGP encryption of a another file which is a 'tar' file of other smaller ASCII text files. > > I would like to decrypt as much of this file as possible. I know with several blank pages, I can never fully recover the file. However, most of the data is still legitimate. Is it possible to recover it with the gpg tools? To this point, I had been using the older PGP 5.0 version, but I can try gpg if it can decrypt most of the file. Have you tried decrypting the file with either PGP or GnuPG? Also, where in the file is the corruption? If the head of the file is corrupted, then you won't get your data back. The reason why is that with an OpenPGP message the file is encrypted with a symmetric encryption key (a.k.a. session key), and then the symmetric key is encrypted with the recipient's asymmetric encryption key (a.k.a. public key) and stored in a "packet" inside the encrypted file. This packet precedes the data packet, which contains the encrypted data. An OpenPGP message would look something like this: +----------------------------+ | Various packets, including | <--- Without this ... | session key packet | +----------------------------+ | | | Data packet | <--- ... you can't decrypt that. | | +----------------------------+ However, if only the data packet is damaged, you may be able to get some of the data back. I experimented with this by using a tar file of a few ASCII files in order to simulate your situation. I corrupted the beginning of the file, and gpg couldn't recognize it as an OpenPGP message. Then I tried corrupting some of the end of the file, and I could successfully decrypt and extract the text files from the tar file. Out of four text files in the tar file, three were good and the last was damaged too badly to understand what its original content was. Restoring from a backup would be best, if you have one. Also, if anything that I said was unclear to you, just let me know. - -Paul - -- New Windows 7: Double the DRM, Double the fun! Learn more: +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQGcBAEBCAAGBQJLobCPAAoJEJhBiuhgbQLI3QYL/0EWtWOc/0AC01jOD/uEW27O 8CJkSM0qJaDQQB+oCUeDsPUIWcX6si2v90+dpFvl7ecMi0x/aizSdVjWC9Pd6/u2 X+JWKsHw/2OKG7yKcgpozwSwdOP8fi1FjGkcKllnWrYbT0GC3G0ewCxidqs5aG4p zsojJ6pmkfqlHdw5HYreJlmBS8MGujDy48Z5hY5xhgbDboTbZoSdyWarQfOODLYR 9zYh8bOKv8oDjCMcoQuexfwxAOn9y8YdxTiunqAcW026NfZ32d4C3X0xjYCAzja8 DkGzuKtipreEG1amKG0JO44TY8hb/6/BkGNQAl4BwonGgWXEWbiWCe7OJdq77FEJ GE3wdG3T7cgi6P6TuafUm3OOL36Ay9xwBe901OfM5qW/yH9QoIJ9+5y2Ibi9fiqF JISIA3XFC40bvybizLV7kU1YP52g+g0H8QDbuv97Ssxg27MHUE8cuQT2LzOEnbQN /NSG2W3a/Y4FmaFDr5GZrQVLk3Rt52zu9Gz+RR824A== =eLxS -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Thu Mar 18 06:03:32 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 18 Mar 2010 01:03:32 -0400 Subject: Science News on statistics Message-ID: <4BA1B424.7000508@sixdemonbag.org> A while ago we had a discussion here about the use of statistics --- particularly, Type II error rates. It turns out that /Science News/ has a pretty good article on statistics and its limitations . It's accessible to the layman: it might be a little much to swallow in places, but by and large if you survived high school math you'll survive the article. If you don't want to click on the embedded link (and who could blame you), then C&P this link: http://www.sciencenews.org/view/feature/id/57091/title/Odds_Are,_Its_Wrong -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From eggled at gmail.com Thu Mar 18 12:50:59 2010 From: eggled at gmail.com (Daniel Eggleston) Date: Thu, 18 Mar 2010 06:50:59 -0500 Subject: Secure unattended decryption Message-ID: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> I know it's sort of a contradiction in terms, but hear me out: The case I'm looking at is a High Availability environment hosting a database. The database is comprised of many Unix files, encrypted via AES, on shared storage. If the node accessing the database loses enough of its redundant hardware that it can no longer function as the database server, control must failover to the secondary node. Since the client systems are the priority, the goal is the shortest downtime possible. The encryption key for the databases is stored on-disk, encrypted with PGP (Gnupg specifically). At first startup, it's no big deal to have the DBA enter a passphrase to start the database server. Once a failover occurs, though, time is of the essence. Since paging someone to come enter a passphrase can take 15 minutes or more after-hours, I'm trying to come up with a feasible way to allow the second node to access the encrypted databases without human intervention, with the ultimate goal that if somebody does somehow walk out with the storage containing the databases, there will be no way to gain access to the data. I was thinking this could be done using gpg-agent, and entering the passphrase when the server starts up (and the failover can happen arbitrarily, months or even years after the machine boots). The problem I've encountered is that there doesn't appear to be a way to cache the passphrase infinitely. (I read some documentation that said that passing -1 to the cache-ttl parameters would work, but it doesn't). I've considered setting the cache-ttl parameters to large values (i.e. two weeks) and requiring the DBA to re-enter the passphrase once a week. This isn't ideal, but it's better than nothing. Does anybody here have any experience with this sort of situation? I realize that anything short of requiring a user with the passphrase at the terminal is inherently less secure, but uptime is king, and I'm looking for an "as secure as possible while not requiring human intervention in the event of a failover". -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgo at grant-olson.net Thu Mar 18 16:37:40 2010 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 18 Mar 2010 11:37:40 -0400 Subject: Secure unattended decryption In-Reply-To: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> Message-ID: <4BA248C4.1020408@grant-olson.net> On 3/18/2010 7:50 AM, Daniel Eggleston wrote: > ..., with the ultimate goal > that if somebody does somehow walk out with the storage containing the > databases, there will be no way to gain access to the data. Physically walk out? You could use some full disk encryption instead. And a lock on the server room door helps. ;-) Hypothetically? Like someone hacking ssh or nfs or something? Like you said, it's a bit of a contradiction. Now someone can just hack the nodes. (Or even the clients that are accessing the nodes. But they could probably do that now.) How specifically do you imagine someone stealing the data? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From eggled at gmail.com Thu Mar 18 16:59:17 2010 From: eggled at gmail.com (Daniel Eggleston) Date: Thu, 18 Mar 2010 10:59:17 -0500 Subject: Secure unattended decryption In-Reply-To: <4BA248C4.1020408@grant-olson.net> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> <4BA248C4.1020408@grant-olson.net> Message-ID: <90f9e6571003180859q40230cdbqc7e13210d82e7695@mail.gmail.com> On Thu, Mar 18, 2010 at 10:37 AM, Grant Olson wrote: > On 3/18/2010 7:50 AM, Daniel Eggleston wrote: > > ..., with the ultimate goal > > that if somebody does somehow walk out with the storage containing the > > databases, there will be no way to gain access to the data. > > Physically walk out? You could use some full disk encryption instead. > And a lock on the server room door helps. ;-) Hypothetically? Like > someone hacking ssh or nfs or something? Like you said, it's a bit of a > contradiction. Now someone can just hack the nodes. (Or even the > clients that are accessing the nodes. But they could probably do that > now.) > > How specifically do you imagine someone stealing the data? > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > Well, the data theft truly is hypothetical - you see, the data will be stored on a SAN, so physical theft is an extremely minor probability (but still one that must be considered). Physical security will differ from client to client, since it will be implemented without my supervision. Full-disk encryption still requires that the DBA enter a passphrase at the time of mounting the disks and doesn't solve anything (and is less cross-platform, there may be many different flavors of Unix including HP-UX, AIX, and Linux); and encryption of just the databases allows the database application to optimize block-sizes (which differs from file to file based on the data types being stored). Hacking the nodes will be a risk regardless - anybody gaining root is game over, anyway. Once the database is mounted and accessed, PGP will no longer be required; what I am trying to accomplish is entering the PGP an arbitrarily long time before actually using it (i.e. infinite). In reality, this is a business requirement more than a philosophical one. The concern is : a) an unprivileged user with server access should not be able to access the actual database files (OS permissions) but, assuming they managed to gain access, the data should be useless. b) a hardware admin, if they manage to bypass physical security and walk out with the SAN, the data contained should be useless. Of course, somebody knows the passphrase, and there is an element of trust, but that's not really what's on trial here - as I said, it's a business requirement that stems from responsibility to clients. Thanks for the interest; I'm hoping somebody has done something similar to this in the past with regards to the unattended failover. -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From f_philipp at fastmail.net Thu Mar 18 18:11:23 2010 From: f_philipp at fastmail.net (Florian Philipp) Date: Thu, 18 Mar 2010 18:11:23 +0100 Subject: Secure unattended decryption In-Reply-To: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> Message-ID: <4BA25EBB.8060209@fastmail.net> Am 18.03.2010 12:50, schrieb Daniel Eggleston: [...] > > The encryption key for the databases is stored on-disk, encrypted with > PGP (Gnupg specifically). At first startup, it's no big deal to have the > DBA enter a passphrase to start the database server. Once a failover > occurs, though, time is of the essence. Since paging someone to come > enter a passphrase can take 15 minutes or more after-hours, I'm trying > to come up with a feasible way to allow the second node to access the > encrypted databases without human intervention, with the ultimate goal > that if somebody does somehow walk out with the storage containing the > databases, there will be no way to gain access to the data. I was > thinking this could be done using gpg-agent, and entering the passphrase > when the server starts up (and the failover can happen arbitrarily, > months or even years after the machine boots). > > The problem I've encountered is that there doesn't appear to be a way to > cache the passphrase infinitely. (I read some documentation that said > that passing -1 to the cache-ttl parameters would work, but it doesn't). > I've considered setting the cache-ttl parameters to large values (i.e. > two weeks) and requiring the DBA to re-enter the passphrase once a > week. This isn't ideal, but it's better than nothing. [...] You could create an encrypted partition/lvm volume/loopback device and put the key on it in plaintext. On boot-up, the DBA enters the password to unlock and mount the partition. After this, the key is protected by filesystem permissions. If someone walks out with the harddisk, all he has is an encrypted partition. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Thu Mar 18 19:43:16 2010 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 18 Mar 2010 14:43:16 -0400 Subject: Secure unattended decryption In-Reply-To: <90f9e6571003180859q40230cdbqc7e13210d82e7695@mail.gmail.com> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> <4BA248C4.1020408@grant-olson.net> <90f9e6571003180859q40230cdbqc7e13210d82e7695@mail.gmail.com> Message-ID: <4BA27444.8090307@grant-olson.net> On 3/18/2010 11:59 AM, Daniel Eggleston wrote: > Full-disk encryption still requires that the DBA enter a > passphrase at the time of mounting the disks and doesn't solve anything > (and is less cross-platform, there may be many different flavors of Unix > including HP-UX, AIX, and Linux); and encryption of just the databases > allows the database application to optimize block-sizes (which differs > from file to file based on the data types being stored). > > Hacking the nodes will be a risk regardless - anybody gaining root is > game over, anyway. Once the database is mounted and accessed, PGP will > no longer be required; what I am trying to accomplish is entering the > PGP an arbitrarily long time before actually using it (i.e. infinite). > Not sure exactly what sort of database you're using, but gpg (to my knowledge) doesn't do block-level/random access. You can't just mount the database, stop using pgp, and write a block here and a block there. You need to use gpg to encrypt the whole file on each write and decrypt on each read. If you've got an uber-database on a SAN where there's lots of reads and writes, and DBA's are tuning block size and what not, it seems like the wrong tool for the job. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From kgo at grant-olson.net Thu Mar 18 20:03:35 2010 From: kgo at grant-olson.net (Grant Olson) Date: Thu, 18 Mar 2010 15:03:35 -0400 Subject: Secure unattended decryption In-Reply-To: <4BA27444.8090307@grant-olson.net> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> <4BA248C4.1020408@grant-olson.net> <90f9e6571003180859q40230cdbqc7e13210d82e7695@mail.gmail.com> <4BA27444.8090307@grant-olson.net> Message-ID: <4BA27907.8010909@grant-olson.net> On 3/18/2010 2:43 PM, Grant Olson wrote: > On 3/18/2010 11:59 AM, Daniel Eggleston wrote: > > Not sure exactly what sort of database you're using, but gpg (to my > knowledge) doesn't do block-level/random access. You can't just mount > the database, stop using pgp, and write a block here and a block there. > You need to use gpg to encrypt the whole file on each write and decrypt > on each read. If you've got an uber-database on a SAN where there's > lots of reads and writes, and DBA's are tuning block size and what not, > it seems like the wrong tool for the job. > But if that is what you want to do: http://www.gnupg.org/faq.html#q4.14 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From esteban.francisco at gmail.com Thu Mar 18 19:13:23 2010 From: esteban.francisco at gmail.com (Esteban Monge) Date: Thu, 18 Mar 2010 12:13:23 -0600 Subject: FLISOL 2010 Costa Rica Message-ID: Hello: I am Esteban Monge, I live in Costa Rica and help the Red Costarricense de Software Libre (RCSL). Sorry for my english... but I need help. The day of FLISOL (April 24, 2010) we want make a little web conference about GPG, the idea is make a little demo to firm mails o encrypt a transmission (very simple, because only we have 60 minutes), I want the presence of one GPG developer, if possible that speak spanish, but this is not a problem, I can find one traductor. I will use DimDim for the remote transmission, It is a little project to bring web conferences based in OpenSource, the expositor must have web cam and microphone. Thanks for your attention and great job. Original spanish text... Soy Esteban Monge de Costa Rica y colaboro para la Red Costarricense de Software Libre (RCSL). El d?a del FLISOL (24 de abril del presenta a?o) queremos dar una "charla t?cnica" de GPG, mi idea es hacer un peque?o demo de como hacer una firma para adjuntar en correo o encriptar comunicaciones (es algo muy simple solo se dispone de una hora), pero adem?s de eso me gustar?a contar con la presencia de alg?n desarrollador de GPG que pueda tener disposici?n para hacerlo y que lo haga en espa?ol... si no es posible en ese idioma ver? como conseguir un traductor (es lo de menos). La persona no va a tener que estar presente, si tiene disponible un micr?fono y una webcam ser?a posible que nos de la charla por medio de DimDim, un sitio web que utiliza software libre para hacer video conferencias (tiene dos modalidades una de pago y otra gratuita). La charla mas que toda seria introductoria y que explique un poco la historia de GPG, mas o menos que dure 20 minutos para usar los restantes en el demo de como hacer la firma. Les agradezco su atenci?n y colaboraci?n. -- http://nuevaeracr.blogspot.com Linux user number 478378 Linux machine number 386687 Tec. Esteban Monge Mar?n Tel: (506) 8379-3562 ?No habr? manera de desarrollarnos y salir de la pobreza mientras los pocos negocios grandes de nuestro medio se entreguen a las econom?as for?neas y nosotros nos quedemos con solo negocios de pobre, mientras en vez de ser propietarios de nuestro propio pa?s nos convirtamos en un ej?rcito de empleados del exterior? Jos? Figueres Ferrer, 1952. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eggled at gmail.com Fri Mar 19 02:20:45 2010 From: eggled at gmail.com (Daniel Eggleston) Date: Thu, 18 Mar 2010 20:20:45 -0500 Subject: Secure unattended decryption In-Reply-To: <4BA2BF95.10101@futureware.at> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> <4BA2BF95.10101@futureware.at> Message-ID: <90f9e6571003181820x1300e3a8n3345046088395278@mail.gmail.com> Yea, I don't need to have it entered automatically at boot time (if that's possible, I've just thrown all semblance of true security out the window). All I was looking for is a way to have gpg cache the passphrase for an indefinite amount of time; and a human can enter the passphrase at boot. It sounds like gpg is probably not more qualified than any other encryption tool for this job, because the solutions thrown out here are quite feasible without gpg. On Thu, Mar 18, 2010 at 7:04 PM, Philipp G?hring wrote: > Hi Daniel, > > > I'm trying > > to come up with a feasible way to allow the second node to access the > > encrypted databases without human intervention, with the ultimate goal > > that if somebody does somehow walk out with the storage containing the > > databases, there will be no way to gain access to the data. > > Yes, exactly. So you have to bind the encryption key geographically to > your server-room. > > There are several possible ways to do this: > > You can use a USB Crypto-Token on a 3 meter USB cable, where the Crypto > Token is behind a wall in a second room (that is secured differently > from the server room), the cable goes through a small hole in the wall, > but does not allow to pull the token through the wall, and the other end > of the cable is plugged into the server in the serverroom. If an > attacker wants to take the server+storage from the server room, he has > to unplug the USB token, and can't take it with him, since it's not in > the same room. > > Another mechanism is Routing Security: > You setup full-disk encryption the primary server. In the bootloader / > initial ramdisk, you setup a SSH server on a special port. You make sure > that it isn't easily visible for a user on the screen when booting. > You then take a client, which could be on a second server somewhere else > in the building, or somewhere on the internet, and you make sure that > you have a somewhat physically secured routing infrastructure. The > client automatically regularly tries to contact the SSH server on the > fixed IP address that is routed to your datacenter/server. If it > succeeds to connect to the boot-SSH server, it automatically remotely > enters the private key / passphrase to decrypt the harddisk. > This way, if an attacker walks out with your server, he would also have > to walk out with the routed IP space, so that he can boot it up again. > It only boots automatically if it is in the right place. > > You can get some inspiration here, but I would not suggest to use it as is: > http://www.debian-administration.org/articles/579 > > > Best regards, > Philipp > > -- Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From free10pro at gmail.com Fri Mar 19 07:54:06 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Thu, 18 Mar 2010 23:54:06 -0700 Subject: key question In-Reply-To: <1199247098.20100313200521@my_localhost> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> <4B9B73D4.4090305@gmail.com> <1199247098.20100313200521@my_localhost> Message-ID: <4BA31F8E.1050704@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, 13 Mar 2010 20:05:21 +0000 MFPA wrote: >> I can't speak for other people, but I can for me. Take >> > a look at the UIDs on my key, which is >> > 0xC7C66ADF3DB6D884. And also, take a look at my master >> > key 0x2188A92DF05045C2 that I signed the other key >> > with. > >> > Each of those e-mail addresses on my keys are ones that >> > were already associated with my real name. I had given >> > each of those addresses to family, friends, associates, >> > businesses, or a combination of them. Not one of those >> > accounts had given me any anonymity, and each had been >> > shared outside of people I knew personally. > >> > By uploading a key with those addresses on it, does >> > that mean I gave up privacy that I already had? No. > > It looks to me as if the answer is "yes." Unless each person who had > one of your email addresses already knew the other addresses before > seeing them on your key, they now have extra information about you. > And the addresses have jumped from "shared outside of people [you] > knew personally" to published in a universally-accessible location. > However minor/negligible or unimportant you may consider it, that's a > reduction in privacy. You are, of course, assuming all of my contacts know what PGP is, how to use a keyserver, and have fetched and examined my key. Although I have potentially disclosed my e-mail addresses to the whole world, my actual disclosure has been less than had I posted those e-mail addresses to a web page or handed a copy of my key UIDs to whomever. But you know what? I don't care. I created those UIDs with the belief that if I shared them with one person, I shared them with the world. I intentionally made that information public, which is different from accidental disclosure. Also the use of a keyserver in my case was good, because I don't have any means of distributing my key electronically other than by e-mailing my key to every person that may request it. So a keyserver fits the way I want to work. - -Paul - -- Privacy is good. Use PGP. +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQGcBAEBCAAGBQJLox97AAoJEJhBiuhgbQLIgEAL/1hXd6DAMcX+goDdipUMt1Yd 5dqnSKbGsC0Rp9Ewa2aZTPzfb4AyAdhjugp+2oX17+47Ijz8CgRP5iCSzEwhW6gl JqKWrKL13f88vN97iauBI/TYiUoEBpMFvreYlu0X8g7qGK9WN1ul4SfFUNaBbXJt /OXfACs7PbSUSN8XvqprOHV+p9uAFNpLIjIYpKZpt4GzhjIF7ifg7fBSw8VdXXBI qahG0c6OqFBU10kJgZlHOM+ZSoqlS9B3M3DR54DLmgwNOhzFkOu5lgOpURY9FrZP 4XYt5hasn/FapiUh5qk8A0QRSLrXUyM7jgntK6KwIFHmurss+eyZRfxBnzveVVbR M2WM9k+AyQnpWwjpxeAR2qQAAjljBDj5TuAEYwlXw6dBb/eQAUcr3SmEdSUDx9BV Q2x37xMN5191xEYqVjNT5FtQko2wGCFSA4qWRbvi+DXV0KVGbTW1N2FBXLtQS1Gc QtndM+4MIf9UkLMnUYJriDnQmgOPiQmJAJzi8gnhuQ== =hLHd -----END PGP SIGNATURE----- From benjamin at py-soft.co.uk Fri Mar 19 10:49:40 2010 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Fri, 19 Mar 2010 09:49:40 +0000 Subject: gpg-agent problems under MacOSX - libassuan v2.0.0 related? Message-ID: <732076a81003190249g4f01c6a9h69b7ccbe6e4d266e@mail.gmail.com> I am having problems with unpatched gpg-agent under Snow Leopard with gnupg v2.0.15: ./gpg-agent --daemon --verbose --use-standard-socket --no-detach gpg-agent[9481]: listening on socket `/Users/benjamin/.gnupg/S.gpg-agent' gpg-agent[9481]: listening on socket `/Users/benjamin/.gnupg/S.gpg-agent.ssh' GPG_AGENT_INFO=/Users/benjamin/.gnupg/S.gpg-agent:9482:1; export GPG_AGENT_INFO; SSH_AUTH_SOCK=/Users/benjamin/.gnupg/S.gpg-agent.ssh; export SSH_AUTH_SOCK; SSH_AGENT_PID=9482; export SSH_AGENT_PID; gpg-agent[9482]: gpg-agent (GnuPG) 2.0.15 started Macintosh:agent benjamin$ gpg-agent[9482]: handler 0x305630 for fd 7 started gpg-agent[9482]: starting a new PIN Entry gpg-agent[9482]: handler 0x305630 for fd 7 terminated gpg-agent[9482]: handler 0x3055a0 for fd 7 started gpg-agent[9482]: starting a new PIN Entry gpg-agent[9482]: handler 0x3055a0 for fd 7 terminated gpg-agent[9482]: handler 0x3058d0 for fd 7 started gpg-agent[9482]: can't connect my own socket: Invalid value passed to IPC gpg-agent[9482]: this process is useless - shutting down gpg-agent[9482]: gpg-agent (GnuPG) 2.0.15 stopped This issue has been confirmed by other people using my MacGPG2 package albeit with a patched copy of gpg-agent. I haven't had chance to investigate this thoroughly at this stage. GnuPG is compiled with the following options: export MACOSX_DEPLOYMENT_TARGET=10.4 export CFLAGS="-mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" export CC=/usr/bin/gcc-4.0 (Above necessary to generate Universal Binary that works on Tiger and above) ./configure --disable-dependency-tracking --with-pinentry-pgm=/usr/local/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac [...] configure: checking for libraries checking for gpg-error-config... /usr/local/bin/gpg-error-config checking for GPG Error - version >= 1.4... yes (1.7) checking for libgcrypt-config... /usr/local/bin/libgcrypt-config checking for LIBGCRYPT - version >= 1.4.0... yes (1.4.5) checking LIBGCRYPT API version... okay checking for libassuan-config... /usr/local/bin/libassuan-config checking for LIBASSUAN - version >= 2.0.0... yes (2.0.0) checking LIBASSUAN API version... okay checking for ksba-config... /usr/local/bin/ksba-config checking for KSBA - version >= 1.0.2... yes (1.0.7) checking KSBA API version... okay checking for usb_bulk_write in -lusb... yes checking for usb_create_match... no checking for library containing dlopen... none required checking for openpty in -lutil... no checking for shred... /usr/bin/shred checking for pth-config... /usr/local/bin/pth-config checking for PTH - version >= 1.3.7... yes checking whether PTH installation is sane... yes [...] GnuPG v2.0.15 has been configured as follows: Platform: Darwin (i386-apple-darwin10.2.0) OpenPGP: yes S/MIME: yes Agent: yes Smartcard: yes Protect tool: (default) Default agent: (default) Default pinentry: /usr/local/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac Default scdaemon: (default) Default dirmngr: (default) The only significant change is the move to libassuan v2.0.0, which I strongly suspect as it provides the IPC library. libassuan was compiled with the same options as v1.0.5: export MACOSX_DEPLOYMENT_TARGET=10.4 export CFLAGS="-mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc" export CC=/usr/bin/gcc-4.0 $ ./configure --enable-static=no --disable-dependency-tracking checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... i386-apple-darwin10.2.0 checking host system type... i386-apple-darwin10.2.0 configure: autobuild project... libassuan configure: autobuild revision... 2.0.0 configure: autobuild hostname... Macintosh.local configure: autobuild timestamp... 20100319-094319 checking for style of include used by make... GNU checking for gcc... /usr/bin/gcc-4.0 checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc-4.0 accepts -g... yes checking for /usr/bin/gcc-4.0 option to accept ISO C89... none needed checking dependency style of /usr/bin/gcc-4.0... none checking how to run the C preprocessor... /usr/bin/gcc-4.0 -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for a sed that does not truncate output... /usr/bin/sed checking for fgrep... /usr/bin/grep -F checking for ld used by /usr/bin/gcc-4.0... /usr/libexec/gcc/i686-apple-darwin10/4.0.1/ld checking if the linker (/usr/libexec/gcc/i686-apple-darwin10/4.0.1/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm checking the name lister (/usr/bin/nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes checking for /usr/libexec/gcc/i686-apple-darwin10/4.0.1/ld option to reload object files... -r checking for objdump... no checking how to recognize dependent libraries... pass_all checking for ar... ar checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm output from /usr/bin/gcc-4.0 object... ok checking for dsymutil... dsymutil checking for nmedit... nmedit checking for lipo... lipo checking for otool... otool checking for otool64... no checking for -single_module linker flag... yes checking for -exported_symbols_list linker flag... yes checking for dlfcn.h... yes checking for objdir... .libs checking if /usr/bin/gcc-4.0 supports -fno-rtti -fno-exceptions... no checking for /usr/bin/gcc-4.0 option to produce PIC... -fno-common -DPIC checking if /usr/bin/gcc-4.0 PIC flag -fno-common -DPIC works... yes checking if /usr/bin/gcc-4.0 static flag -static works... no checking if /usr/bin/gcc-4.0 supports -c -o file.o... yes checking if /usr/bin/gcc-4.0 supports -c -o file.o... (cached) yes checking whether the /usr/bin/gcc-4.0 linker (/usr/libexec/gcc/i686-apple-darwin10/4.0.1/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin10.2.0 dyld checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for windres... no checking for gawk... (cached) awk checking for gcc... (cached) /usr/bin/gcc-4.0 checking whether we are using the GNU C compiler... (cached) yes checking whether /usr/bin/gcc-4.0 accepts -g... (cached) yes checking for /usr/bin/gcc-4.0 option to accept ISO C89... (cached) none needed checking dependency style of /usr/bin/gcc-4.0... (cached) none checking how to run the C preprocessor... /usr/bin/gcc-4.0 -E checking whether /usr/bin/gcc-4.0 and cc understand -c and -o together... yes checking whether ln -s works... yes checking whether make sets $(MAKE)... (cached) yes checking if gcc supports -Wpointer-arith... yes checking for setsockopt... yes checking for ANSI C header files... (cached) yes checking for string.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking sys/uio.h usability... yes checking sys/uio.h presence... yes checking for sys/uio.h... yes checking for stdint.h... (cached) yes checking for inttypes.h... (cached) yes checking for uintptr_t... yes checking for an ANSI C-conforming const... yes checking for inline... inline checking for size_t... yes checking return type of signal handlers... void checking whether sys_siglist is declared... no checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking for socklen_t... yes checking for struct cmsghdr.cmsg_len... yes checking for gpg-error-config... /usr/local/bin/gpg-error-config checking for GPG Error - version >= 1.4... yes checking for flockfile... yes checking for funlockfile... yes checking for library containing nanosleep... none required checking for funopen... yes checking for isascii... yes checking for putc_unlocked... yes checking for memrchr... no checking for stpcpy... yes checking for unistd.h... (cached) yes checking for setenv... yes checking for vasprintf... yes checking for SO_PEERCRED... no configure: creating ./config.status config.status: creating Makefile config.status: creating m4/Makefile config.status: creating src/Makefile config.status: creating doc/Makefile config.status: creating tests/Makefile config.status: creating src/libassuan-config config.status: creating src/versioninfo.rc config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands Ben From expires2010 at ymail.com Fri Mar 19 14:06:38 2010 From: expires2010 at ymail.com (MFPA) Date: Fri, 19 Mar 2010 13:06:38 +0000 Subject: key question In-Reply-To: <4BA31F8E.1050704@gmail.com> References: <4B85A4DB.9030108@googlemail.com> <4B85C1A0.3050403@Mozilla-Enigmail.org> <1224920514.20100225025503@my_localhost> <4B85F433.1040405@Mozilla-Enigmail.org> <1912204946.20100225142453@my_localhost> <4B86DC42.3070602@sixdemonbag.org> <1216241405.20100226173852@my_localhost> <4B880D84.4060608@sixdemonbag.org> <1734230733.20100226201447@my_localhost> <4B8839D2.4080206@sixdemonbag.org> <333644023.20100227035202@my_localhost> <4B921894.5050301@gmail.com> <69266957.20100306163402@my_localhost> <4B948C8C.8010007@gmail.com> <5987695.20100308213818@my_localhost> <4B9B73D4.4090305@gmail.com> <1199247098.20100313200521@my_localhost> <4BA31F8E.1050704@gmail.com> Message-ID: <596474860.20100319130638@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Friday 19 March 2010 at 6:54:06 AM, in , Paul Richard Ramer wrote: > On Sat, 13 Mar 2010 20:05:21 +0000 MFPA wrote: >> It looks to me as if the answer is "yes." Unless each >> person who had one of your email addresses already >> knew the other addresses before seeing them on your >> key, they now have extra information about you. And >> the addresses have jumped from "shared outside of >> people [you] knew personally" to published in a >> universally-accessible location. However >> minor/negligible or unimportant you may consider it, >> that's a reduction in privacy. > You are, of course, assuming all of my contacts know > what PGP is, how to use a keyserver, and have fetched > and examined my key. OK, I should have qualified "they now have extra information about you" with "potentially" or "access to." > Although I have potentially disclosed my e-mail addresses to the > whole world, my actual disclosure has been less than had I posted > those e-mail addresses to a web page or handed a copy of my key UIDs > to whomever. The lower level of spam from publicising your email addresses on a keyserver compared to web page suggests the first of these is true (although that may be related to ease of extraction of email addresses). I'm not sure how you would go about measuring the second. (-; > But you know what? I don't care. I'm clear that this doesn't bother you. > I created those UIDs > with the belief that if I shared them with one person, > I shared them with the world. Of course, but it doesn't have to be that way. I do not see that users of openPGP gain anything at all from this public exposure of their private details, if their key could be usefully be made publicly available without. > I intentionally made > that information public, which is different from > accidental disclosure. Yes it is. > Also the use of a keyserver in my case was good, > because I don't have any means of distributing my key > electronically other than by e-mailing my key to every > person that may request it. So a keyserver fits the > way I want to work. Well, you *could* include it in every email you send out; or use an email auto-responder, post it on a web page, post it to BigLumber, etc and use a signature notation (or a note in a comment line or an email footer) to link to it. But most of these options probably fit the way of working you describe less well than using a keyserver. - -- Best regards MFPA mailto:expires2010 at ymail.com Confusion is always the most honest response -----BEGIN PGP SIGNATURE----- iQCVAwUBS6N28qipC46tDG5pAQosPwP/T1UBiDz3i0w3bob+Yd//OwxLQHvWyhnI +kRzUO2SWTdqbntSZBWlVJXiWeNcB5d8cV9AYbf48TUrqVMV5tHzdMrm3iiOwP4f rzGNWbN717TECS+R4ZIE+L6e2foYD3iQSmj5cDtBWpok+OZtaViRRRnVbb+40VvQ VlLKjQrgf/0= =7B90 -----END PGP SIGNATURE----- From marcio.barbado at gmail.com Fri Mar 19 18:17:12 2010 From: marcio.barbado at gmail.com (M.B.Jr.) Date: Fri, 19 Mar 2010 14:17:12 -0300 Subject: Secure unattended decryption In-Reply-To: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> Message-ID: <2df3b0cb1003191017r5260df1cpa4ab12f0b39e688f@mail.gmail.com> Hi Daniel, On Thu, Mar 18, 2010 at 8:50 AM, Daniel Eggleston wrote: > I know it's sort of a contradiction in terms, but hear me out: > > The case I'm looking at is a High Availability environment hosting a > database. The database is comprised of many Unix files, encrypted via AES, > on shared storage. If the node accessing the database loses enough of its > redundant hardware that it can no longer function as the database server, > control must failover to the secondary node. Since the client systems are > the priority, the goal is the shortest downtime possible. > > The encryption key for the databases is stored on-disk, encrypted with PGP > (Gnupg specifically). Sort of a conceptual remark at this point. See, this database password you refer to is a symmetrical one. And you stated you keep it on-disk, encrypted with GnuPG. So, is this last GnuPG encryption also symmetrical? If so, and if your DBA is GnuPG's password keeper, GnuPG's encryption would make little sense, considering you're concerned with "high availability". It would be more sensible to cease that encryption cascading (databases's AES + GnuPG's some supposedly symmetrical algo) and let your DBA carry somehow the AES clear text password, directly. Check your database's documentation. Perhaps it could maintain authentication after a failover. And chances increase in redundant environments, if the referred system depends only on its own encryption resources. Regards, Marcio Barbado, Jr. From jimoe at sohnen-moe.com Fri Mar 19 20:32:23 2010 From: jimoe at sohnen-moe.com (James Moe) Date: Fri, 19 Mar 2010 12:32:23 -0700 Subject: gpg-agent is ignored Message-ID: Tbird v3.0.3, gnupg v2.0.12, enigmail v1.0.1 I have started gpg-agent, have exported the variables from <.gpg-agent.info>. Yet every time I save enigmail's preferences I get the message "...to change passphrase caching options, please configure your gpg-agent tool." Hmm. Which settings must be configured? Where is the conf located? -- James Moe jimoe at sohnen-moe dot com 520.743.3936 From eggled at gmail.com Fri Mar 19 21:26:09 2010 From: eggled at gmail.com (eggled at gmail.com) Date: Fri, 19 Mar 2010 15:26:09 -0500 Subject: Secure unattended decryption In-Reply-To: <2df3b0cb1003191017r5260df1cpa4ab12f0b39e688f@mail.gmail.com> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> <2df3b0cb1003191017r5260df1cpa4ab12f0b39e688f@mail.gmail.com> Message-ID: <20100319202609.GE25130@pokeserver.eggled.dyndns.org> On Fri, Mar 19, 2010 at 02:17:12PM -0300, M.B.Jr. wrote: > Hi Daniel, > > > On Thu, Mar 18, 2010 at 8:50 AM, Daniel Eggleston wrote: > > I know it's sort of a contradiction in terms, but hear me out: > > > > The case I'm looking at is a High Availability environment hosting a > > database. The database is comprised of many Unix files, encrypted via AES, > > on shared storage. If the node accessing the database loses enough of its > > redundant hardware that it can no longer function as the database server, > > control must failover to the secondary node. Since the client systems are > > the priority, the goal is the shortest downtime possible. > > > > The encryption key for the databases is stored on-disk, encrypted with PGP > > (Gnupg specifically). > > > Sort of a conceptual remark at this point. > > See, this database password you refer to is a symmetrical one. And you > stated you keep it on-disk, encrypted with GnuPG. > > So, is this last GnuPG encryption also symmetrical? > > If so, and if your DBA is GnuPG's password keeper, GnuPG's encryption > would make little sense, considering you're concerned with "high > availability". > > It would be more sensible to cease that encryption cascading > (databases's AES + GnuPG's some supposedly symmetrical algo) and let > your DBA carry somehow the AES clear text password, directly. > > Check your database's documentation. Perhaps it could maintain > authentication after a failover. And chances increase in redundant > environments, if the referred system depends only on its own > encryption resources. > > > Regards, > > > > Marcio Barbado, Jr. Yes, well, changing the AES key on a database (Which may be several hundred gigabytes) is time consuming. Changing a GPG passphrase is not. Using assymetric encryption of the AES key using GPG makes it very easy to change the gpg encryption key passphrase regularly. Thanks for the input; I agree that in general the cascading encryption would be cumbersome and not worthwhile, but it's been carefully considered, and the method chosen was not by mistake. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From kgo at grant-olson.net Fri Mar 19 22:25:46 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 19 Mar 2010 17:25:46 -0400 Subject: Secure unattended decryption In-Reply-To: <2df3b0cb1003191017r5260df1cpa4ab12f0b39e688f@mail.gmail.com> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> <2df3b0cb1003191017r5260df1cpa4ab12f0b39e688f@mail.gmail.com> Message-ID: <4BA3EBDA.3040500@grant-olson.net> On 3/19/2010 1:17 PM, M.B.Jr. wrote: >> >> The encryption key for the databases is stored on-disk, encrypted with PGP >> (Gnupg specifically). > > > Sort of a conceptual remark at this point. > > See, this database password you refer to is a symmetrical one. And you > stated you keep it on-disk, encrypted with GnuPG. > Apologies Daniel. That went right over my head. I didn't realize you were talking about two separate keys. I thought you were saying you had a key that was a gpg key, not that you were encrypting database key X with gpg key Y. Ignore pretty much everything I said. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Fri Mar 19 22:30:24 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 19 Mar 2010 17:30:24 -0400 Subject: Secure unattended decryption In-Reply-To: <20100319202609.GE25130@pokeserver.eggled.dyndns.org> References: <90f9e6571003180450y28aaf8b3ub517a543c6e4521a@mail.gmail.com> <2df3b0cb1003191017r5260df1cpa4ab12f0b39e688f@mail.gmail.com> <20100319202609.GE25130@pokeserver.eggled.dyndns.org> Message-ID: <4BA3ECF0.803@sixdemonbag.org> On 3/19/2010 4:26 PM, eggled at gmail.com wrote: > Yes, well, changing the AES key on a database (Which may be several > hundred gigabytes) is time consuming. Only if you design your database poorly. This is a solved problem in both database design and filesystem design. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From kgo at grant-olson.net Fri Mar 19 22:30:32 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 19 Mar 2010 17:30:32 -0400 Subject: gpg-agent is ignored In-Reply-To: References: Message-ID: <4BA3ECF8.1010008@grant-olson.net> On 3/19/2010 3:32 PM, James Moe wrote: > Tbird v3.0.3, gnupg v2.0.12, enigmail v1.0.1 > > I have started gpg-agent, have exported the variables from > <.gpg-agent.info>. Yet every time I save enigmail's preferences I get > the message "...to change passphrase caching options, please configure > your gpg-agent tool." > > Hmm. Which settings must be configured? Where is the conf located? > The file is 'gpg-agent.conf'. It's located in your gpg configuration directory. You can find that for your OS by running gpg --version. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From weberjn at gmail.com Fri Mar 19 21:51:40 2010 From: weberjn at gmail.com (Juergen Weber) Date: Fri, 19 Mar 2010 21:51:40 +0100 Subject: gpg symmetric to Java JCA decryption Message-ID: <1964cfb61003191351g7e60b59bx2402f3fb621abc99@mail.gmail.com> Hi, has anybody tried to decrypt a symmetric gpg encryption with Java using Java Cryptography Architecture included in the JDK? echo hello | gpg -c --cipher-algo 3DES -a --passphrase "my pass" | java MyDeCrypt --cipher-algo 3DES --passphrase "my pass" should result in hello This should be possible, I googled for a sample, but there seems to be none. Thanks, Juergen http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html echo hello | gpg -c --cipher-algo 3DES -a --passphrase "my pass" -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.5 (GNU/Linux) jA0EAgMC3WQttb9CgbRgyRyF8HBgQEDfx1FR9w5/E6lDFicD9IRm+jbSDBn9 =Uj3h -----END PGP MESSAGE----- From dshaw at jabberwocky.com Fri Mar 19 23:23:13 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Fri, 19 Mar 2010 18:23:13 -0400 Subject: gpg symmetric to Java JCA decryption In-Reply-To: <1964cfb61003191351g7e60b59bx2402f3fb621abc99@mail.gmail.com> References: <1964cfb61003191351g7e60b59bx2402f3fb621abc99@mail.gmail.com> Message-ID: <5DD47BBD-D3EA-4AE7-968C-09CEA926D39F@jabberwocky.com> On Mar 19, 2010, at 4:51 PM, Juergen Weber wrote: > Hi, > > has anybody tried to decrypt a symmetric gpg encryption with Java > using Java Cryptography Architecture included in the JDK? > > echo hello | gpg -c --cipher-algo 3DES -a --passphrase "my pass" | > java MyDeCrypt --cipher-algo 3DES --passphrase "my pass" > > should result in hello > > This should be possible, I googled for a sample, but there seems to be none. GnuPG encrypts using the OpenPGP standard. The Java cryptography architecture doesn't follow that spec (that "file format" if you like). If you want to do OpenPGP in Java, I suggest http://www.bouncycastle.org/java.html which is a provider for the cryptography architecture. David From federalhillrent at yahoo.com Fri Mar 19 22:36:53 2010 From: federalhillrent at yahoo.com (FederalHill) Date: Fri, 19 Mar 2010 14:36:53 -0700 (PDT) Subject: Secure unattended decryption In-Reply-To: <4BA3ECF0.803@sixdemonbag.org> Message-ID: <321634.87176.qm@web36303.mail.mud.yahoo.com> Are there refernces where such procedures are detailed that I might look at? ? --- On Fri, 3/19/10, Robert J. Hansen wrote: From: Robert J. Hansen Subject: Re: Secure unattended decryption To: gnupg-users at gnupg.org Date: Friday, March 19, 2010, 5:30 PM On 3/19/2010 4:26 PM, eggled at gmail.com wrote: > Yes, well, changing the AES key on a database (Which may be several > hundred gigabytes) is time consuming. Only if you design your database poorly.? This is a solved problem in both database design and filesystem design. -----Inline Attachment Follows----- _______________________________________________ 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 rjh at sixdemonbag.org Fri Mar 19 23:48:52 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 19 Mar 2010 18:48:52 -0400 Subject: Secure unattended decryption In-Reply-To: <321634.87176.qm@web36303.mail.mud.yahoo.com> References: <321634.87176.qm@web36303.mail.mud.yahoo.com> Message-ID: <4BA3FF54.2060806@sixdemonbag.org> On 3/19/2010 5:36 PM, FederalHill wrote: > Are there refernces where such procedures are detailed that I might look at? http://scholar.google.com Check for "encrypted database rekeying". -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From hamilric at us.ibm.com Fri Mar 19 23:06:26 2010 From: hamilric at us.ibm.com (Richard Hamilton) Date: Fri, 19 Mar 2010 16:06:26 -0600 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) Message-ID: I am out of the office until 03/22/2010. I am out of the office until Monday March 21st. If this is a production problem, please call the solution center at 918-573-2336 or email Bob Olson at Robert.Olson at williams.com. I will have limited mail and cell phone access. Note: This is an automated response to your message "Re: Secure unattended decryption" sent on 3/19/10 14:26:09. This is the only notification you will receive while this person is away. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jimoe at sohnen-moe.com Sat Mar 20 00:09:19 2010 From: jimoe at sohnen-moe.com (James Moe) Date: Fri, 19 Mar 2010 16:09:19 -0700 Subject: gpg-agent is ignored In-Reply-To: <4BA3ECF8.1010008@grant-olson.net> References: <4BA3D147.8040707@sohnen-moe.com> <4BA3ECF8.1010008@grant-olson.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/19/2010 02:30 PM, Grant Olson wrote: >> Tbird v3.0.3, gnupg v2.0.12, enigmail v1.0.1 >> >> I have started gpg-agent, have exported the variables from >> <.gpg-agent.info>. Yet every time I save enigmail's preferences I get >> the message "...to change passphrase caching options, please configure >> your gpg-agent tool." >> > The file is 'gpg-agent.conf'. It's located in your gpg configuration > directory. You can find that for your OS by running gpg --version. > There is no file in <.gnupg>. What minimum set of settings are required to please Engimail? - -- James Moe jimoe at sohnen-moe dot com 520.743.3936 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkukBB8ACgkQzTcr8Prq0ZO1/ACgpnk8CFvSsswvPc7thEKQ+AJ3 LHYAnRgsruJicLFHmPsftxZdKL7DHlJE =2xMB -----END PGP SIGNATURE----- From gesbbb at yahoo.com Sat Mar 20 00:39:14 2010 From: gesbbb at yahoo.com (Jerry) Date: Fri, 19 Mar 2010 19:39:14 -0400 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: References: Message-ID: <20100319193914.2e4c8a87@scorpio.seibercom.net> On Fri, 19 Mar 2010 16:06:26 -0600 Richard Hamilton articulated: >I am out of the office until 03/22/2010. > >I am out of the office until Monday March 21st. If this is a >production problem, please call the solution center at 918-573-2336 or >email Bob Olson at Robert.Olson at williams.com. I will have limited mail >and cell phone access. > > >Note: This is an automated response to your message "Re: Secure >unattended decryption" sent on 3/19/10 14:26:09. > >This is the only notification you will receive while this person is >away. It must be that time of year again; birds sing, flowers bloom and broken 'vacation' message auto responders flourish. In any case, I am calling the number he published. Maybe they can fix the 'vacation message' apparatus. -- Jerry gesbbb at yahoo.com Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ What this country needs is a good five cent ANYTHING! From kgo at grant-olson.net Sat Mar 20 00:42:33 2010 From: kgo at grant-olson.net (Grant Olson) Date: Fri, 19 Mar 2010 19:42:33 -0400 Subject: gpg-agent is ignored In-Reply-To: References: <4BA3D147.8040707@sohnen-moe.com> <4BA3ECF8.1010008@grant-olson.net> Message-ID: <4BA40BE9.3030803@grant-olson.net> On 3/19/2010 7:09 PM, James Moe wrote: > On 03/19/2010 02:30 PM, Grant Olson wrote: >>> Tbird v3.0.3, gnupg v2.0.12, enigmail v1.0.1 >>> >>> I have started gpg-agent, have exported the variables from >>> <.gpg-agent.info>. Yet every time I save enigmail's preferences I get >>> the message "...to change passphrase caching options, please configure >>> your gpg-agent tool." >>> >> The file is 'gpg-agent.conf'. It's located in your gpg configuration >> directory. You can find that for your OS by running gpg --version. > > There is no file in <.gnupg>. > What minimum set of settings are required to please Engimail? > You probably just need something like: default-cache-ttl 600 Where 600 is the number of seconds the password is cached. My whole gpg-agent.conf file is: default-cache-ttl 600 max-cache-ttl 999999 And that's working for me. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sat Mar 20 00:44:38 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 19 Mar 2010 19:44:38 -0400 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: <20100319193914.2e4c8a87@scorpio.seibercom.net> References: <20100319193914.2e4c8a87@scorpio.seibercom.net> Message-ID: <4BA40C66.7060605@sixdemonbag.org> On 3/19/2010 7:39 PM, Jerry wrote: > It must be that time of year again; birds sing, flowers bloom and > broken 'vacation' message auto responders flourish. In any case, I am > calling the number he published. Maybe they can fix the 'vacation > message' apparatus. More often than not, these sorts of problem can be fixed more effectively by the list owner unsubscribing the offending email address. Let's let the list owners handle this, and not run the risk of a half-dozen of us calling this guy's workplace and getting him in trouble just because he had a braino when he left on vacation. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From brad at fineby.me.uk Sat Mar 20 12:17:03 2010 From: brad at fineby.me.uk (Brad Rogers) Date: Sat, 20 Mar 2010 11:17:03 +0000 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: <4BA40C66.7060605@sixdemonbag.org> References: <20100319193914.2e4c8a87@scorpio.seibercom.net> <4BA40C66.7060605@sixdemonbag.org> Message-ID: <20100320111703.44332fbb@abydos.stargate.org.uk> On Fri, 19 Mar 2010 19:44:38 -0400 "Robert J. Hansen" wrote: Hello Robert, > half-dozen of us calling this guy's workplace and getting him in > trouble just because he had a braino when he left on vacation. It'd serve him right. Unless his employer pays him to read the list. -- Regards _ / ) "The blindingly obvious is / _)rad never immediately apparent" Well well well, you just can't tell My Michelle - Guns 'N' Roses From rjh at sixdemonbag.org Sat Mar 20 13:34:52 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 20 Mar 2010 08:34:52 -0400 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: <20100320111703.44332fbb@abydos.stargate.org.uk> References: <20100319193914.2e4c8a87@scorpio.seibercom.net> <4BA40C66.7060605@sixdemonbag.org> <20100320111703.44332fbb@abydos.stargate.org.uk> Message-ID: <4BA4C0EC.6040703@sixdemonbag.org> On 3/20/2010 7:17 AM, Brad Rogers wrote: > It'd serve him right. Unless his employer pays him to read the > list. There are a fair number of jobs that would. Let's not make presumptions, and let's let the list moderators handle this. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From gesbbb at yahoo.com Sat Mar 20 13:49:46 2010 From: gesbbb at yahoo.com (Jerry) Date: Sat, 20 Mar 2010 08:49:46 -0400 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: <20100320111703.44332fbb@abydos.stargate.org.uk> References: <20100319193914.2e4c8a87@scorpio.seibercom.net> <4BA40C66.7060605@sixdemonbag.org> <20100320111703.44332fbb@abydos.stargate.org.uk> Message-ID: <20100320084946.35f9b3d6@scorpio.seibercom.net> On Sat, 20 Mar 2010 11:17:03 +0000 Brad Rogers articulated: >On Fri, 19 Mar 2010 19:44:38 -0400 >"Robert J. Hansen" wrote: > >Hello Robert, > >> half-dozen of us calling this guy's workplace and getting him in >> trouble just because he had a braino when he left on vacation. > >It'd serve him right. Unless his employer pays him to read the list. Scenario 1: He is the boss, therefore no harm is done. Scenario 2: He is not the boss; however, he is permitted to use company time on private projects. Again, no harm is done. Scenario 3: He is not the boss, nor is he allowed to waste company time on private projects. In this scenario, the company gains by outing an employee who is wasting company resources and time on private projects. No matter how you look at it, it is a "Win Win" situation. -- Jerry gesbbb at yahoo.com Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ Nature, to be commanded, must be obeyed. Francis Bacon From rjh at sixdemonbag.org Sat Mar 20 13:58:55 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 20 Mar 2010 08:58:55 -0400 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: <20100320084946.35f9b3d6@scorpio.seibercom.net> References: <20100319193914.2e4c8a87@scorpio.seibercom.net> <4BA40C66.7060605@sixdemonbag.org> <20100320111703.44332fbb@abydos.stargate.org.uk> <20100320084946.35f9b3d6@scorpio.seibercom.net> Message-ID: <4BA4C68F.90306@sixdemonbag.org> On 3/20/2010 8:49 AM, Jerry wrote: > Scenario 3: > > He is not the boss, nor is he allowed to waste company time on private > projects. In this scenario, the company gains by outing an employee who > is wasting company resources and time on private projects. Scenario 4: He is not the boss and is on the list with his company's permission. However, like many businesses, his company is very sensitive to complaints from outside. He probably doesn't lose his job or anything, but does get a dressing-down from the folks who sign his paychecks, and winds up thinking about this list, "gee, what a bunch of rude and insensitive people -- as if *they've* never made an error before." ... The more we talk about this, the more we damage the list's signal to noise ratio. Originally, he just sent *one* off-topic message to the list. That has now spawned an entire thread of off-topic messages. Why are we still talking about this? Let's let the list moderators handle it, and go back to on-topic discussions. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From eggled at gmail.com Sat Mar 20 14:01:50 2010 From: eggled at gmail.com (eggled at gmail.com) Date: Sat, 20 Mar 2010 08:01:50 -0500 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: <20100320084946.35f9b3d6@scorpio.seibercom.net> References: <20100319193914.2e4c8a87@scorpio.seibercom.net> <4BA40C66.7060605@sixdemonbag.org> <20100320111703.44332fbb@abydos.stargate.org.uk> <20100320084946.35f9b3d6@scorpio.seibercom.net> Message-ID: <20100320130150.GH25130@pokeserver.eggled.dyndns.org> On Sat, Mar 20, 2010 at 08:49:46AM -0400, Jerry wrote: > On Sat, 20 Mar 2010 11:17:03 +0000 > Brad Rogers articulated: > > >On Fri, 19 Mar 2010 19:44:38 -0400 > >"Robert J. Hansen" wrote: > > > >Hello Robert, > > > >> half-dozen of us calling this guy's workplace and getting him in > >> trouble just because he had a braino when he left on vacation. > > > >It'd serve him right. Unless his employer pays him to read the list. > > Scenario 1: > > He is the boss, therefore no harm is done. > > Scenario 2: > > He is not the boss; however, he is permitted to use company time on > private projects. Again, no harm is done. > > Scenario 3: > > He is not the boss, nor is he allowed to waste company time on private > projects. In this scenario, the company gains by outing an employee who > is wasting company resources and time on private projects. > > No matter how you look at it, it is a "Win Win" situation. > > -- > Jerry > gesbbb at yahoo.com > > Disclaimer: off-list followups get on-list replies or get ignored. > Please do not ignore the Reply-To header. > __________________________________________________________________ > > Nature, to be commanded, must be obeyed. > > Francis Bacon > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users I don't think "Win-Win" means what you think it means. At best for him, no harm is done. At worst, he gets a reprimand or gets in trouble. I happen to be an employee (not a boss), who is not expressly permitted to use company time on private projects. As it turns out, though, my job is right now requiring me to do some research about gnupg. (Just a scenario you left out) And, all that is completely irrelevant. Contacting his coworkers for help will make extra work for several people, removing his auto-reminder (probably a helpdesk ticket, etc.). OR, the moderators can just click "remove" next to his name and send an email informing him of the situation on his return. 5 minutes, which is about what anybody would spend explaining the situation to the his coworkers to effect a solution that, at best, is "No harm done". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From f_philipp at fastmail.net Sat Mar 20 14:36:45 2010 From: f_philipp at fastmail.net (Florian Philipp) Date: Sat, 20 Mar 2010 14:36:45 +0100 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: <20100320130150.GH25130@pokeserver.eggled.dyndns.org> References: <20100319193914.2e4c8a87@scorpio.seibercom.net> <4BA40C66.7060605@sixdemonbag.org> <20100320111703.44332fbb@abydos.stargate.org.uk> <20100320084946.35f9b3d6@scorpio.seibercom.net> <20100320130150.GH25130@pokeserver.eggled.dyndns.org> Message-ID: <4BA4CF6D.60009@fastmail.net> Am 20.03.2010 14:01, schrieb eggled at gmail.com: > On Sat, Mar 20, 2010 at 08:49:46AM -0400, Jerry wrote: >> On Sat, 20 Mar 2010 11:17:03 +0000 >> Brad Rogers articulated: >> >>> On Fri, 19 Mar 2010 19:44:38 -0400 >>> "Robert J. Hansen" wrote: [...] I hope you people realize that you just produced 7 times as much spam ... err ... "unhelpful communication" as Richard Hamilton has done with his single notification. Couldn't you have sent him a single, private mail telling him that you find his behavior wrong instead of talking about telling it someone else? Florian Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From eggled at gmail.com Sat Mar 20 13:41:25 2010 From: eggled at gmail.com (eggled at gmail.com) Date: Sat, 20 Mar 2010 07:41:25 -0500 Subject: Secure unattended decryption In-Reply-To: <4BA3FF54.2060806@sixdemonbag.org> References: <321634.87176.qm@web36303.mail.mud.yahoo.com> <4BA3FF54.2060806@sixdemonbag.org> Message-ID: <20100320124125.GG25130@pokeserver.eggled.dyndns.org> On Fri, Mar 19, 2010 at 06:48:52PM -0400, Robert J. Hansen wrote: > On 3/19/2010 5:36 PM, FederalHill wrote: > > Are there refernces where such procedures are detailed that I might look at? > > http://scholar.google.com > > Check for "encrypted database rekeying". > > Maybe I'm doing it wrong, but all I see are patents and research projects ongoing at IBM. That tells me that nobody has solved this problem sufficiently. When you use a block cipher on billions of blocks, there is no way to rekey the database without decrypting and re-encrypting all those blocks. If you've solved it, why don't you go talk to IBM or Sun - they'd be very interested to hear how to quickly rekey a block-encrypted file spanning multiple terabytes. There might be some money in it for you. > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rjh at sixdemonbag.org Sat Mar 20 15:00:11 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 20 Mar 2010 10:00:11 -0400 Subject: Secure unattended decryption In-Reply-To: <20100320124125.GG25130@pokeserver.eggled.dyndns.org> References: <321634.87176.qm@web36303.mail.mud.yahoo.com> <4BA3FF54.2060806@sixdemonbag.org> <20100320124125.GG25130@pokeserver.eggled.dyndns.org> Message-ID: <4BA4D4EB.7080304@sixdemonbag.org> On 3/20/2010 8:41 AM, eggled at gmail.com wrote: > Maybe I'm doing it wrong, but all I see are patents and research > projects ongoing at IBM. You're doing it wrong. Keep searching. I know there's at least one paper readily findable in Google Scholar that tells you exactly how BitLocker does it. Most academics are incredibly vain types. If an academic tells you that he or she knows a paper exists, odds are good that's because he or she either wrote it or contributed to it in a significant way. Given this, you might want to try doing a Google Scholar search on '"Robert J. Hansen" encryption'. Once you find a paper name and an author, try Googling on that and see if the paper author doesn't have a free version up available for download. Basic research is a skill worth learning. Good luck! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From dshaw at jabberwocky.com Sat Mar 20 15:50:16 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 20 Mar 2010 10:50:16 -0400 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: <20100320130150.GH25130@pokeserver.eggled.dyndns.org> References: <20100319193914.2e4c8a87@scorpio.seibercom.net> <4BA40C66.7060605@sixdemonbag.org> <20100320111703.44332fbb@abydos.stargate.org.uk> <20100320084946.35f9b3d6@scorpio.seibercom.net> <20100320130150.GH25130@pokeserver.eggled.dyndns.org> Message-ID: <31648466-B7C2-4368-92E0-29B37600DD06@jabberwocky.com> There was *one* auto-reply message, and it has not reoccured. Whatever was wrong is clearly resolved. Let's move on. There is nothing else to see here. David From dshaw at jabberwocky.com Sat Mar 20 16:12:00 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 20 Mar 2010 11:12:00 -0400 Subject: Secure unattended decryption In-Reply-To: <4BA4D4EB.7080304@sixdemonbag.org> References: <321634.87176.qm@web36303.mail.mud.yahoo.com> <4BA3FF54.2060806@sixdemonbag.org> <20100320124125.GG25130@pokeserver.eggled.dyndns.org> <4BA4D4EB.7080304@sixdemonbag.org> Message-ID: On Mar 20, 2010, at 10:00 AM, Robert J. Hansen wrote: > On 3/20/2010 8:41 AM, eggled at gmail.com wrote: >> Maybe I'm doing it wrong, but all I see are patents and research >> projects ongoing at IBM. > > You're doing it wrong. Keep searching. I know there's at least one > paper readily findable in Google Scholar that tells you exactly how > BitLocker does it. > > Most academics are incredibly vain types. If an academic tells you that > he or she knows a paper exists, odds are good that's because he or she > either wrote it or contributed to it in a significant way. Given this, > you might want to try doing a Google Scholar search on '"Robert J. > Hansen" encryption'. Once you find a paper name and an author, try > Googling on that and see if the paper author doesn't have a free version > up available for download. > > Basic research is a skill worth learning. Good luck! Being helpful on mailing lists is similarly a skill worth learning. If there is a particular paper you want to point to, give the cite. Why make someone guess that you were referring to yourself, then search for the paper you carefully didn't mention the title of, then try and find a free-to-download version - and then scold them for not succeeding? This isn't a puzzle game. For the archives, the paper in question is "Implementing BitLocker Drive Encryption for Forensic Analysis". You can download it at http://jessekornblum.com/publications/di09.html David From benjamin at py-soft.co.uk Sat Mar 20 17:58:13 2010 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sat, 20 Mar 2010 16:58:13 +0000 Subject: gpg-agent problems under MacOSX - libassuan v2.0.0 related? In-Reply-To: <732076a81003190249g4f01c6a9h69b7ccbe6e4d266e@mail.gmail.com> References: <732076a81003190249g4f01c6a9h69b7ccbe6e4d266e@mail.gmail.com> Message-ID: <732076a81003200958m763af3a0w16eb589e626d80e9@mail.gmail.com> On 19 March 2010 09:49, Benjamin Donnachie wrote: > I am having problems with unpatched gpg-agent under Snow Leopard with > gnupg v2.0.15: > gpg-agent[9482]: can't connect my own socket: Invalid value passed to IPC > gpg-agent[9482]: this process is useless - shutting down Continued testing has shown that this behaviour is only exhibited when using standard sockets. When not using them I have, so far, been unable to replicate this problem. Ben From faramir.cl at gmail.com Sun Mar 21 00:15:24 2010 From: faramir.cl at gmail.com (Faramir) Date: Sat, 20 Mar 2010 20:15:24 -0300 Subject: AUTO: Richard Hamilton is out of the office (returning 03/22/2010) In-Reply-To: <20100320084946.35f9b3d6@scorpio.seibercom.net> References: <20100319193914.2e4c8a87@scorpio.seibercom.net> <4BA40C66.7060605@sixdemonbag.org> <20100320111703.44332fbb@abydos.stargate.org.uk> <20100320084946.35f9b3d6@scorpio.seibercom.net> Message-ID: <4BA5570C.6050008@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jerry escribi?: ... > Scenario 1: > > He is the boss, therefore no harm is done. > > Scenario 2: > > He is not the boss; however, he is permitted to use company time on > private projects. Again, no harm is done. > > Scenario 3: > > He is not the boss, nor is he allowed to waste company time on private > projects. In this scenario, the company gains by outing an employee who > is wasting company resources and time on private projects. Scenario 4: He is not the boss, but the IT person supposed to handle some security/privacy stuff. Part of his job would be to keep an eye on security/privacy tools like GnuPG, so he must read the list. But maybe the boss won't see it that way, unless provided a long explanation. And even after that, maybe the boss will say "ok, you can read that list... but if I ever catch you watching porn, you are fired!" (boss ran out of arguments, but is still suspecting the employee is wasting company time). Anyway, I think the message said "This is the only notification you will receive while this person is away.", so we won't receive an auto-reply for each message we send... IMHO, it doesn't even require the moderator to take measures. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLpVcLAAoJEMV4f6PvczxACLYH/jOUOv+7OJirMz5DuEwTT4Gk u7Z8Tx3TyIouviRt2XxnFdxpMEsDD8+LlapSW6Z13YKbSXT+bXpmAJGjTZIQtFZm lA/XkdLE7RkIWR1f61ssOsnzpNYnENPLaanThLwcdSRECa8MFOQyzxXJIne9ZX8D nnHIVsht1LakKGMcNAMU757IGE+QXLca+yf1r8zxlkBw5cHu/1gJ9CDCgyW8/mou /YFIhxZyJ+9rtM39DopcCCOr92nkh5Px33ICUYodd/HpoR4pD3h/d6VUUOpme1eb LPIX0PwCCLUbFl/WwOLwaF3yvL25hYVw1WL1PWzi1Oe4ycqJLdzq3e6Ez299tf4= =0TrR -----END PGP SIGNATURE----- From allen.schultz at gmail.com Sat Mar 20 23:50:41 2010 From: allen.schultz at gmail.com (Allen Schultz) Date: Sun, 21 Mar 2010 03:20:41 +0430 Subject: Keyservers Message-ID: <201003210320.41911.allen.schultz@gmail.com> I know this keeps coming up. But what is the best server out there to grab keys from users on this list. There are a few of you I don't have keys for. Thanks in advance. Schultz, Allen D -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: This is a digitally signed message part. URL: From rjh at sixdemonbag.org Sun Mar 21 01:09:15 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 20 Mar 2010 20:09:15 -0400 Subject: Keyservers In-Reply-To: <201003210320.41911.allen.schultz@gmail.com> References: <201003210320.41911.allen.schultz@gmail.com> Message-ID: <4BA563AB.8080205@sixdemonbag.org> On 3/20/2010 6:50 PM, Allen Schultz wrote: > I know this keeps coming up. But what is the best server out there to > grab keys from users on this list. There are a few of you I don't > have keys for. "Best" is inherently subjective. However, many people here use pool.sks-keyservers.net and are happy with it. It's as good a choice as any. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From dshaw at jabberwocky.com Sun Mar 21 01:57:04 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 20 Mar 2010 20:57:04 -0400 Subject: Keyservers In-Reply-To: <201003210320.41911.allen.schultz@gmail.com> References: <201003210320.41911.allen.schultz@gmail.com> Message-ID: On Mar 20, 2010, at 6:50 PM, Allen Schultz wrote: > I know this keeps coming up. But what is the best server out there to grab > keys from users on this list. There are a few of you I don't have keys for. The easy answer is that is doesn't matter. With few exceptions, you can think of the keyserver world as having only two servers: "keyserver.pgp.com", and "everybody else". The PGP.com one does some validation (by mailing the user ID on the key) that the keyholder is reachable via that address. The other servers do not validate, but have the advantage of more keys. You get to pick which you want more - there is no one right answer, and GnuPG will happily talk to either. (At the risk of reopening the recent discussion of whether people can/should upload someone else's keys to a keyserver, it's worth noting that keyserver.pgp.com only accepts key submissions from the address named on the key). Anyway, if you choose "everybody else", at least in theory, it doesn't matter which of the "everybody else" servers you hit. They synchronize with each other, so will have the same keys. In practice, there are a bunch of servers around the world, which might go up or down, so some folks have set up a special server name that round-robins among several running servers. It checks the various servers twice a day and only includes healthy ones in the list. All that is a longwinded way of saying to try "pool.sks-keyservers.net". ;) David From faramir.cl at gmail.com Sun Mar 21 01:55:16 2010 From: faramir.cl at gmail.com (Faramir) Date: Sat, 20 Mar 2010 21:55:16 -0300 Subject: Keyservers In-Reply-To: <201003210320.41911.allen.schultz@gmail.com> References: <201003210320.41911.allen.schultz@gmail.com> Message-ID: <4BA56E74.8010208@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Allen Schultz escribi?: > I know this keeps coming up. But what is the best server out there to grab > keys from users on this list. There are a few of you I don't have keys for. > > Thanks in advance. The most recommended one is pool.sks-keyservers.net It is not a single server, but a pool of servers, the list is checked to include only servers known to be "alive" and well synchronized. Any server of that list "talks" with the other servers, so each one should have the same keys. Best Regards P.S: some people use pgp.mit.edu, which used to be using an older kind of server, and it didn't "talk" with other servers, but I eared it was updated to a new version. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLpW50AAoJEMV4f6PvczxAC7gIAJBHPrKCym89UwiUhNqA8PwB wSe4oiYVy+74FaX2K0DdbPXWZMvy3bsfMrmbk7bfyvc1rlVp7tBLaF/kiTHL964d 79u7c+pBwp1Ji1DpbzoywDM1iUXxOPvlqvd1lOsBFYcpmKMH1DzIBFQkBOeb3a1k x5G/NAD/Hoc4YUH6euT1L2Wmxusp1MdxpNggDBcWicGXmNiOYw5FTFaxuok10vtF 6QeyHV8hY8iEs5bKWlyMiNxyGMEWsG/lTwD/rX6YubKALnsudFaF5p8quUBfeiHV NiMS8fHTdiFAsM/jwM+g6kxcS3iFAeyY5OMZ370JqxOlL3ILY48rkgFXPb+XJLI= =aJib -----END PGP SIGNATURE----- From dougb at dougbarton.us Sun Mar 21 02:09:48 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 20 Mar 2010 18:09:48 -0700 Subject: Generating a new key Message-ID: <4BA571DC.5050205@dougbarton.us> I've been following the discussions about new key types, sizes, etc. with interest for a while now since my old DSA/El Gamal key (vintage 2003) is a bit long in the tooth, and I've been lusting after bigger hashes, and better long-term security. Up till now my interest has been mostly academic since I didn't have the easy access to key signing events that I once did, but there is one coming up next week at IETF 77 that I will likely be attending, so I thought now is a good time. Here are my choices for the various options, I'm curious if anyone sees anything glaringly horrible about them. :) gnupg version: 2.0.14 The FreeBSD ports for gnupg, libassuan, etc. haven't been updated yet, and unless there is a truly compelling reason to update them myself, I'd rather put my time into something else. Signing key: 2048 RSA 1024 RSA seems right out based on recent events, however I can't see any reasoning for a larger signing key, and I've read all the discussion on why this is the default and don't see anything wrong with it (in my expert opinion). :) Capabilities: SCA I don't have a particular need for an authentication key atm, but I might someday, and I'd really rather avoid a proliferation of new keys, subkeys, etc. I'm aiming to make this my one key for another good long while. If I get 7 years out of this one (like I did my DSA key) that'll be a good achievement I think. Photo UID: 30915 bytes This is a 175x200 jpeg, and I didn't think a 30k image was that large, but gpg complains that it's "very large" or some such. I could strip it down to a smaller size if this is truly too large, but the file size now makes the photo just usable as it is. Encryption subkey: 4096 RSA Here is where I differ from the defaults. I understand the argument about a 1,000 meter wall vs. a 100,000 meter wall, however the larger key doesn't make any appreciable difference to the encrypted file size, and I like the idea of having an encryption key large enough that I don't have to worry about things staying encrypted for the foreseeable future. So, anything painfully stupid in there? Regards, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dougb at dougbarton.us Sun Mar 21 03:10:34 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 20 Mar 2010 19:10:34 -0700 Subject: 2.0.14 --gen-key interface nit Message-ID: <4BA5801A.1000500@dougbarton.us> Howdy, Playing around with key generation there was something banging around in the back of my mind and it finally hit me: Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Authenticate (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished --- Real name: Douglas Barton Email address: dougb at dougbarton.us Comment: You selected this USER-ID: "Douglas Barton " Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o The Q option behaves inconsistently between these two menus. In the capabilities menu it means "we're done, and all is well;" in the uid section O ("oh") means Ok, but Q bails out of the whole key generation process. The easiest way to fix this would probably be to change the capabilities menu since that's an --expert option. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From rjh at sixdemonbag.org Sun Mar 21 03:15:37 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 20 Mar 2010 22:15:37 -0400 Subject: Generating a new key In-Reply-To: <4BA571DC.5050205@dougbarton.us> References: <4BA571DC.5050205@dougbarton.us> Message-ID: <4BA58149.1010504@sixdemonbag.org> On 3/20/2010 9:09 PM, Doug Barton wrote: > Here are my choices for the various options, I'm curious if anyone sees > anything glaringly horrible about them. :) ObAdvice: it's probably best to stick with the defaults unless you've got clear needs the defaults don't meet. Or, if you just like to tinker around with things. You don't need to tinker with settings in order to make GnuPG work well. All that said: > Here is where I differ from the defaults. I understand the argument > about a 1,000 meter wall vs. a 100,000 meter wall, however the larger > key doesn't make any appreciable difference to the encrypted file size, > and I like the idea of having an encryption key large enough that I > don't have to worry about things staying encrypted for the foreseeable > future. Large keys like this may give you some headaches down the road. Increasingly, we're moving to a handheld culture: whether a BlackBerry, an iPhone or an Android, the cell phone is becoming increasingly important as an electronic communications tool. It's reasonable to think that in the next five years OpenPGP will come to cell phones in one way or another. If so, you will discover that 4k encryption keys are painfully slow on handheld devices. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From dougb at dougbarton.us Sun Mar 21 04:22:12 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 20 Mar 2010 20:22:12 -0700 Subject: Generating a new key In-Reply-To: <4BA58149.1010504@sixdemonbag.org> References: <4BA571DC.5050205@dougbarton.us> <4BA58149.1010504@sixdemonbag.org> Message-ID: <4BA590E4.5080003@dougbarton.us> On 03/20/10 19:15, Robert J. Hansen wrote: > On 3/20/2010 9:09 PM, Doug Barton wrote: >> Here are my choices for the various options, I'm curious if anyone sees >> anything glaringly horrible about them. :) > > ObAdvice: it's probably best to stick with the defaults unless you've > got clear needs the defaults don't meet. Or, if you just like to tinker > around with things. Guilty. :) >> Here is where I differ from the defaults. I understand the argument >> about a 1,000 meter wall vs. a 100,000 meter wall, however the larger >> key doesn't make any appreciable difference to the encrypted file size, >> and I like the idea of having an encryption key large enough that I >> don't have to worry about things staying encrypted for the foreseeable >> future. > > Large keys like this may give you some headaches down the road. > Increasingly, we're moving to a handheld culture: whether a BlackBerry, > an iPhone or an Android, the cell phone is becoming increasingly > important as an electronic communications tool. > > It's reasonable to think that in the next five years OpenPGP will come > to cell phones in one way or another. If so, you will discover that 4k > encryption keys are painfully slow on handheld devices. Yes, that's a consideration, however in 5 years we'll have had at least 2 iterations of Moore's Law, and in my experience so far I do much more signing than I do encryption. Thanks for the review. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dshaw at jabberwocky.com Sun Mar 21 04:28:55 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sat, 20 Mar 2010 23:28:55 -0400 Subject: Generating a new key In-Reply-To: <4BA571DC.5050205@dougbarton.us> References: <4BA571DC.5050205@dougbarton.us> Message-ID: On Mar 20, 2010, at 9:09 PM, Doug Barton wrote: > I've been following the discussions about new key types, sizes, etc. > with interest for a while now since my old DSA/El Gamal key (vintage > 2003) is a bit long in the tooth, and I've been lusting after bigger > hashes, and better long-term security. Up till now my interest has been > mostly academic since I didn't have the easy access to key signing > events that I once did, but there is one coming up next week at IETF 77 > that I will likely be attending, so I thought now is a good time. > > Here are my choices for the various options, I'm curious if anyone sees > anything glaringly horrible about them. :) As a rule of thumb, only deviate from the defaults if there is a particular reason to do so. The defaults are carefully chosen to be a reasonable choice for the majority of people. > gnupg version: 2.0.14 > The FreeBSD ports for gnupg, libassuan, etc. haven't been updated yet, > and unless there is a truly compelling reason to update them myself, I'd > rather put my time into something else. No worries here. > Signing key: 2048 RSA > 1024 RSA seems right out based on recent events, however I can't see any > reasoning for a larger signing key, and I've read all the discussion on > why this is the default and don't see anything wrong with it (in my > expert opinion). :) It's the default anyway, so that's fine. > Capabilities: SCA > I don't have a particular need for an authentication key atm, but I > might someday, and I'd really rather avoid a proliferation of new keys, > subkeys, etc. I'm aiming to make this my one key for another good long > while. If I get 7 years out of this one (like I did my DSA key) that'll > be a good achievement I think. I wouldn't do this. The default is SC (sign+certify). If you want an authentication key at some point in the future, I recommend a subkey. If you make your primary key the authentication key, you need to have that key online, and lose the ability to store it offline someday. > Photo UID: 30915 bytes > This is a 175x200 jpeg, and I didn't think a 30k image was that large, > but gpg complains that it's "very large" or some such. I could strip it > down to a smaller size if this is truly too large, but the file size now > makes the photo just usable as it is. 30k is a little big, but don't shrink its dimensions. Instead, shrink its color depth and perhaps lower the JPEG quality level a bit. > Encryption subkey: 4096 RSA > Here is where I differ from the defaults. I understand the argument > about a 1,000 meter wall vs. a 100,000 meter wall, however the larger > key doesn't make any appreciable difference to the encrypted file size, > and I like the idea of having an encryption key large enough that I > don't have to worry about things staying encrypted for the foreseeable > future. Frankly, you don't have much to worry about with a 2048 bit key either. It also is slightly odd to use an encryption key that is so much larger than your signing key. Another reason to not go 4096 is it removes the ability to use a smartcard in the future. The smartcard is (currently) limited to 3072-bit keys. I'd leave this at the default value. David From kgo at grant-olson.net Sun Mar 21 04:33:59 2010 From: kgo at grant-olson.net (Grant Olson) Date: Sat, 20 Mar 2010 23:33:59 -0400 Subject: Generating a new key In-Reply-To: <4BA590E4.5080003@dougbarton.us> References: <4BA571DC.5050205@dougbarton.us> <4BA58149.1010504@sixdemonbag.org> <4BA590E4.5080003@dougbarton.us> Message-ID: <4BA593A7.30609@grant-olson.net> On 3/20/2010 11:22 PM, Doug Barton wrote: > > Yes, that's a consideration, however in 5 years we'll have had at least > 2 iterations of Moore's Law, and in my experience so far I do much more > signing than I do encryption. > > Thanks for the review. :) > > > Doug > I stumbled on this wikipedia page a few weeks ago: http://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths I'm not sure how up-to-date the info is, but it basically says that even with Moore's law, 2048 bit keys should be good until 2030. I would think if you want to future-proof anything, it'd be the primary key. You can create a separate signing subkey with a more reasonable bit length. And then if you need to crank up the signing/encryption key bit-lengths in the future, you can create new subkeys and expire the old ones, and you'll keep all your signatures on the existing primary key. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From faramir.cl at gmail.com Sun Mar 21 04:40:08 2010 From: faramir.cl at gmail.com (Faramir) Date: Sun, 21 Mar 2010 00:40:08 -0300 Subject: Generating a new key In-Reply-To: <4BA571DC.5050205@dougbarton.us> References: <4BA571DC.5050205@dougbarton.us> Message-ID: <4BA59518.8000904@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Doug Barton escribi?: ... > Signing key: 2048 RSA > 1024 RSA seems right out based on recent events, however I can't see any > reasoning for a larger signing key, and I've read all the discussion on > why this is the default and don't see anything wrong with it (in my > expert opinion). :) IMHO, the main key (used to sign other keys), is the most important one, since you can add or revoke subkeys, but the main one, can't be changed. If the key length chosen becomes unsafe, you should revoke the key and make a new one, so I would chose a length with a larger security margin, like RSA 2048 (by the way, RSA 2048 is the new default in current version of GnuPG). IIRC, RSA 2048 is considered to remain safe until 2030 (according to a wikipedia article quoting RSA estimations). Of course that estimation may change. ... > Encryption subkey: 4096 RSA Well, if you want to store something encrypted, and it must remain safe at least until 2030, maybe you can use that length, since it would give you a larger security margin. Another thing to consider, is SHA is not as safe as it used to be, and it it becomes easily crackeable, signatures issued using SHA can become unsafe. So maybe you'd like to use SHA-256 instead of SHA-128. If I'm not wrong, you would need to add the following lines to your gpg.conf file, before generating your key: s2k-digest-algo SHA256 cert-digest-algo SHA256 The first line tells gnupg to use SHA-256 instead of SHA-1 to mangle the passphrases. I don't really know what is that mangling thing, but if the idea is to replace SHA-1 with SHA-256, it can be useful. (I have a bad feeling about telling other people to use that line). The second line tells gnupg to use SHA-256 instead of SHA-1 for signing other keys. But beware, older implementations of PGP maybe won't be able to read SHA-256 (but probably, these implementations are outdated). Best Regards The second line -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLpZUXAAoJEMV4f6PvczxAEcEH/RD4szs4GozPBPKW7BBWG8vu RUMQFgEtapnLd9cfZmdH5MQUHYTossHlx9PwoX5c7hYPWf8IcDbiNYjHoE3ZSiVF kfAZpsO9Y1pFqnJS9ikpp8ZoAKp48J/Ex/INViHn5pVpm07xvA4DyCD4TJJAF1AP Gdiicof5RC/o9xIxIrsVMBAs1IH3h4ZK6FK6DoSpJDN9+RaLtiiIf/4UuWv4ZWfZ K+VsA2SEjgaRFV9y15J39RR5PwfZZcEIspoNmSVvkL8TRcN2bip4cglNyRLwUyaF KBCkKi+3ykyAAA+jSKQggGUlrBOEe4kyxKbflcJEtwNsAb6QIdOsQhLP0fOq6tU= =VGBG -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Sun Mar 21 05:10:17 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 21 Mar 2010 00:10:17 -0400 Subject: Generating a new key In-Reply-To: <4BA59518.8000904@gmail.com> References: <4BA571DC.5050205@dougbarton.us> <4BA59518.8000904@gmail.com> Message-ID: <018FA53A-CA5F-4DAC-9E2F-9C9C00AA8C7E@jabberwocky.com> On Mar 20, 2010, at 11:40 PM, Faramir wrote: > Another thing to consider, is SHA is not as safe as it used to be, and > it it becomes easily crackeable, signatures issued using SHA can become > unsafe. So maybe you'd like to use SHA-256 instead of SHA-128. If I'm > not wrong, you would need to add the following lines to your gpg.conf > file, before generating your key: > s2k-digest-algo SHA256 > cert-digest-algo SHA256 > > The first line tells gnupg to use SHA-256 instead of SHA-1 to mangle the > passphrases. I don't really know what is that mangling thing, but if the > idea is to replace SHA-1 with SHA-256, it can be useful. (I have a bad > feeling about telling other people to use that line). It's what GnuPG uses (in combination with a few other things) to convert your typeable-by-a-human passphrase into the symmetric key used to encrypt the secret key: S2K stands for "String to Key". It's okay to use SHA-256 here, but note that it means you might have problems moving your secret key to a different program that doesn't support SHA-256. There aren't a vast number of current programs that don't support SHA-256 these days, but there are some pretty old installations out there. Incidentally, you don't have to set s2k-digest-algo before you generate your key. If you want to "upgrade" an existing key passphrase so it is mangled via SHA-256, just set the s2k-digest-algo and change the passphrase (you can even change it to what it is currently set to - it's the change at all that causes the passphrase to be remangled). A somewhat larger risk here is that the s2k-digest-algo also applies to symmetrically encrypted data (i.e. gpg --symmetric). You need to make sure your recipient can handle it before using it. > The second line tells gnupg to use SHA-256 instead of SHA-1 for signing > other keys. And also your own key (in the self-signatures that contain the preferences and other key items). > But beware, older implementations of PGP maybe won't be able to read > SHA-256 (but probably, these implementations are outdated). Yes, they are outdated, but they do exist. How common they are depends on your community. If you're talking about the open-source community or people on this list, for example, I'd be surprised to see more than a small number. If you're talking about code that was installed a while back, then you'd likely see more that can't handle it. David From dougb at dougbarton.us Sun Mar 21 05:29:49 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 20 Mar 2010 21:29:49 -0700 Subject: Generating a new key In-Reply-To: References: <4BA571DC.5050205@dougbarton.us> Message-ID: <4BA5A0BD.8070403@dougbarton.us> On 03/20/10 20:28, David Shaw wrote: > On Mar 20, 2010, at 9:09 PM, Doug Barton wrote: > >> Capabilities: SCA I don't have a particular need for an >> authentication key atm, but I might someday, and I'd really rather >> avoid a proliferation of new keys, subkeys, etc. I'm aiming to make >> this my one key for another good long while. If I get 7 years out >> of this one (like I did my DSA key) that'll be a good achievement I >> think. > > I wouldn't do this. The default is SC (sign+certify). If you want > an authentication key at some point in the future, I recommend a > subkey. If you make your primary key the authentication key, you > need to have that key online, and lose the ability to store it > offline someday. I thought about that actually, and was unclear about two things. It doesn't seem to me that an authentication key would need signatures, is that correct? The other is in reference to what you said above. If I add an authentication subkey is it possible to store just the subkey separate from the "main" SC key? I'm familiar with the concept of on-line vs. off-line keys and fairly familiar with the security implications relative to my work with DNSSEC, just not sure how they relate here. >> Photo UID: 30915 bytes This is a 175x200 jpeg, and I didn't think a >> 30k image was that large, but gpg complains that it's "very large" >> or some such. I could strip it down to a smaller size if this is >> truly too large, but the file size now makes the photo just usable >> as it is. > > 30k is a little big, but don't shrink its dimensions. Instead, > shrink its color depth and perhaps lower the JPEG quality level a > bit. Ok, saving it at 77% instead of 100% and removing all the exif data got me down to 6140, which is just below the magic number of 6k. I can tell the difference between the two images, but the smaller one still serves the purpose. >> Encryption subkey: 4096 RSA Here is where I differ from the >> defaults. I understand the argument about a 1,000 meter wall vs. a >> 100,000 meter wall, however the larger key doesn't make any >> appreciable difference to the encrypted file size, and I like the >> idea of having an encryption key large enough that I don't have to >> worry about things staying encrypted for the foreseeable future. > > Frankly, you don't have much to worry about with a 2048 bit key > either. It also is slightly odd to use an encryption key that is so > much larger than your signing key. Another reason to not go 4096 is > it removes the ability to use a smartcard in the future. The > smartcard is (currently) limited to 3072-bit keys. That's a good point, thanks. I've no plans to use a smartcard but no sense in gratuitously eliminating that possibility either. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From dshaw at jabberwocky.com Sun Mar 21 05:35:57 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 21 Mar 2010 00:35:57 -0400 Subject: Generating a new key In-Reply-To: <4BA5A0BD.8070403@dougbarton.us> References: <4BA571DC.5050205@dougbarton.us> <4BA5A0BD.8070403@dougbarton.us> Message-ID: <53D2CE80-3173-4619-B174-CFD602C128C6@jabberwocky.com> On Mar 21, 2010, at 12:29 AM, Doug Barton wrote: > On 03/20/10 20:28, David Shaw wrote: >> On Mar 20, 2010, at 9:09 PM, Doug Barton wrote: >> >>> Capabilities: SCA I don't have a particular need for an >>> authentication key atm, but I might someday, and I'd really rather >>> avoid a proliferation of new keys, subkeys, etc. I'm aiming to make >>> this my one key for another good long while. If I get 7 years out >>> of this one (like I did my DSA key) that'll be a good achievement I >>> think. >> >> I wouldn't do this. The default is SC (sign+certify). If you want >> an authentication key at some point in the future, I recommend a >> subkey. If you make your primary key the authentication key, you >> need to have that key online, and lose the ability to store it >> offline someday. > > I thought about that actually, and was unclear about two things. It > doesn't seem to me that an authentication key would need signatures, is > that correct? The other is in reference to what you said above. If I add > an authentication subkey is it possible to store just the subkey > separate from the "main" SC key? I'm familiar with the concept of > on-line vs. off-line keys and fairly familiar with the security > implications relative to my work with DNSSEC, just not sure how they > relate here. GnuPG supports an offline key setup where the primary key is kept offline and the subkeys are kept online (and yes, you can store an authentication subkey separate from the main key). This works very well for the common OpenPGP case where the primary key is the most important one (as it is used to certify new subkeys, among other things). If you lose/compromise/etc your online subkeys, just use the offline primary to revoke them and make new subkeys. The primary isn't kept with the subkeys, so it is much less likely to be lost/compromised along with them. David From dougb at dougbarton.us Sun Mar 21 05:52:57 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 20 Mar 2010 21:52:57 -0700 Subject: Generating a new key In-Reply-To: <53D2CE80-3173-4619-B174-CFD602C128C6@jabberwocky.com> References: <4BA571DC.5050205@dougbarton.us> <4BA5A0BD.8070403@dougbarton.us> <53D2CE80-3173-4619-B174-CFD602C128C6@jabberwocky.com> Message-ID: <4BA5A629.9030405@dougbarton.us> On 03/20/10 21:35, David Shaw wrote: > > GnuPG supports an offline key setup where the primary key is kept offline and the subkeys are kept online (and yes, you can store an authentication subkey separate from the main key). This works very well for the common OpenPGP case where the primary key is the most important one (as it is used to certify new subkeys, among other things). If you lose/compromise/etc your online subkeys, just use the offline primary to revoke them and make new subkeys. The primary isn't kept with the subkeys, so it is much less likely to be lost/compromised along with them. Ok, got it, thanks. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From benjamin at py-soft.co.uk Sun Mar 21 14:47:22 2010 From: benjamin at py-soft.co.uk (Benjamin Donnachie) Date: Sun, 21 Mar 2010 13:47:22 +0000 Subject: gpg-agent problems under MacOSX - libassuan v2.0.0 related? In-Reply-To: <732076a81003200958m763af3a0w16eb589e626d80e9@mail.gmail.com> References: <732076a81003190249g4f01c6a9h69b7ccbe6e4d266e@mail.gmail.com> <732076a81003200958m763af3a0w16eb589e626d80e9@mail.gmail.com> Message-ID: <732076a81003210647q17620a00wbe99a3b052be2d04@mail.gmail.com> On 20 March 2010 16:58, Benjamin Donnachie wrote: > Continued testing has shown that this behaviour is only exhibited when > using standard sockets. ?When not using them I have, so far, been > unable to replicate this problem. Ticket created - https://bugs.g10code.com/gnupg/issue1205 Ben From stefanxe at gmx.net Sun Mar 21 16:35:28 2010 From: stefanxe at gmx.net (Stefan Xenon) Date: Sun, 21 Mar 2010 16:35:28 +0100 Subject: OpenPGP Card: modifying key length fails on Linux Message-ID: <4BA63CC0.4020104@gmx.net> Hi! I use an OpenPGP Card v2 and GnuPG 1.4.10 on both Windows and Linux. When generating keys on the card, GnuPG is asking at one point which key length it should use. If I modify the default key length of 2048 to 1024 or 3072 the following error appears: gpg: sending command `SCD SETATTR' to agent failed: ec=6.88 gpg: error changing size of key 1 to 2048 bits: Allgemeiner Fehler Because of this, modification of the key length does not work for me on Linux. But it works on Windows even with the same GnuPG version. After I modified the default key size on Windows, key generation on the card succeeds on Linux even with 3072 bit. Any ideas? After running into this problem I tried to modify the key length under Linux with GnuPG v2 but it does not ask me which key length it should use. Also I did not find any option to specify it explicitly. How to specify the to be generated key length with GnuPG 2? Regards Stefan From weberjn at gmail.com Sun Mar 21 22:09:25 2010 From: weberjn at gmail.com (Juergen Weber) Date: Sun, 21 Mar 2010 22:09:25 +0100 Subject: gpg symmetric to Java JCA decryption In-Reply-To: <5DD47BBD-D3EA-4AE7-968C-09CEA926D39F@jabberwocky.com> References: <1964cfb61003191351g7e60b59bx2402f3fb621abc99@mail.gmail.com> <5DD47BBD-D3EA-4AE7-968C-09CEA926D39F@jabberwocky.com> Message-ID: <1964cfb61003211409x1ab9d369kb4e099d782b2e455@mail.gmail.com> On Fri, Mar 19, 2010 at 11:23 PM, David Shaw wrote: > On Mar 19, 2010, at 4:51 PM, Juergen Weber wrote: > >> Hi, >> >> has anybody tried to decrypt a symmetric gpg encryption with Java >> using Java Cryptography Architecture included in the JDK? >> >> echo hello | ?gpg -c --cipher-algo 3DES -a --passphrase "my pass" | >> java MyDeCrypt --cipher-algo 3DES --passphrase "my pass" >> >> should result in hello >> >> This should be possible, I googled for a sample, but there seems to be none. > > GnuPG encrypts using the OpenPGP standard. ?The Java cryptography architecture doesn't follow that spec (that "file format" if you like). If you want to do OpenPGP in Java, I suggest http://www.bouncycastle.org/java.html which is a provider for the cryptography architecture. > > David No, I don't need OpenPGP, just need symmetric encryption done by a standard command line Unix tool and decryption by means of the Java runtime library. Guess I'll take openssl, looks like this works with Java: http://forums.sun.com/thread.jspa?threadID=5153188 Juergen From free10pro at gmail.com Sun Mar 21 22:59:46 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sun, 21 Mar 2010 14:59:46 -0700 Subject: Generating a new key In-Reply-To: <4BA59518.8000904@gmail.com> References: <4BA571DC.5050205@dougbarton.us> <4BA59518.8000904@gmail.com> Message-ID: <4BA696D2.3000203@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, 21 Mar 2010 00:40:08 -0300 Faramir wrote: > Another thing to consider, is SHA is not as safe as it used to be, and > it it becomes easily crackeable, signatures issued using SHA can become > unsafe. So maybe you'd like to use SHA-256 instead of SHA-128. If I'm I believe that you meant SHA-1 and not SHA-128, because there isn't a hash called SHA-128. Also SHA-1 is a 160 bit hash. > The first line tells gnupg to use SHA-256 instead of SHA-1 to mangle the > passphrases. I don't really know what is that mangling thing, but if the > idea is to replace SHA-1 with SHA-256, it can be useful. (I have a bad > feeling about telling other people to use that line). In addition to what David said, the passphrase mangling uses iterations of the hash algorithm to slow down a brute force attack on the passphrase. So for a fictional example, GnuPG will hash the word "dog" and produce "0123456789". Then it will iterate by taking the output of the hash algorithm and use it as input to another instance of hashing. So in this example it would take the output of "0123456789" and hash it to produce "9876543210". The default iteration count is 65536 and can be set by --s2k-count option. However, if you want to change the default, I would suggest that you read this first . - -Paul - -- "Plagiarism is the greatest form of flattery." --self +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQGcBAEBCAAGBQJLppatAAoJEJhBiuhgbQLIGSIMAJZXHvZxkq4SbscU/gykyaYC o/Eb5G/+VC+DRZuskUHCJ5nZykfKu3Wy93G4pj6zTEaLyJQChH22NGzp3PF185RN XF/x04StFdjJ9AB/2QgB4gOk2JVCGkUAd75C0wP2wywyfKE57+tdNA7W5Og3duIm 7pq0ixINjlO/06cVuzy8VzE45TcUKYtweT4eboA/WkRZrd2IgwBETvgYIpyjM96n TrJ7vQKBQBGtGmbNTGa1jNMuGYUGUqj8P+CCt3OvGjNUIl2wfwoXm13evQdd6gTY 8maXd3Zcshr7ethhpAo575J9hn568tBXj2bc0avEd1PZ3hWn1GyNQki/XZP7QV8Q 4g2n6ISJ1mEhSQuVeyBZ3gLp7ispARRxgOI+j02pTyLn69xPe33Afr44P/hNxXRB HrV56GdT3TvoS0IJgy5IH2drsMO+q4oN65EKhYxllpJ+gNtuFdGpV2xqfYh0VVfj hLWGtmY5bUkO53XFiB7ECXjqeq2RLkyctIRbHfqAgg== =b8BH -----END PGP SIGNATURE----- From rjh at sixdemonbag.org Mon Mar 22 00:06:13 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 21 Mar 2010 19:06:13 -0400 Subject: Generating a new key In-Reply-To: <4BA696D2.3000203@gmail.com> References: <4BA571DC.5050205@dougbarton.us> <4BA59518.8000904@gmail.com> <4BA696D2.3000203@gmail.com> Message-ID: <4BA6A665.3020609@sixdemonbag.org> On 3/21/10 5:59 PM, Paul Richard Ramer wrote: > I believe that you meant SHA-1 and not SHA-128, because there isn't a > hash called SHA-128. There is, although the name is unofficial and not widely used. When people migrated from MD5 to SHA-1, there were a lot of protocols that only had 128 bits reserved for the hash. A common hack was to use SHA-1 and drop 32 bits. RIPEMD-128 is RIPEMD-160 with 32 bits dropped, and RIPEMD-128 is an officially recognized name. A fair number of people applied the same reasoning to SHA-1, and thus SHA-128 was born. Unlike RIPEMD-128, SHA-128 was never official. The name never took off, although the hack was pretty commonly used. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From dshaw at jabberwocky.com Mon Mar 22 00:29:12 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 21 Mar 2010 19:29:12 -0400 Subject: Generating a new key In-Reply-To: <4BA6A665.3020609@sixdemonbag.org> References: <4BA571DC.5050205@dougbarton.us> <4BA59518.8000904@gmail.com> <4BA696D2.3000203@gmail.com> <4BA6A665.3020609@sixdemonbag.org> Message-ID: <5589A751-3D2E-4631-8812-888944C02FBD@jabberwocky.com> On Mar 21, 2010, at 7:06 PM, Robert J. Hansen wrote: > On 3/21/10 5:59 PM, Paul Richard Ramer wrote: >> I believe that you meant SHA-1 and not SHA-128, because there isn't a >> hash called SHA-128. > > There is, although the name is unofficial and not widely used. And more specifically, it is not used in OpenPGP or GnuPG. David From mailinglisten at hauke-laging.de Mon Mar 22 05:11:36 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 22 Mar 2010 05:11:36 +0100 Subject: using a smartcard without keytocard Message-ID: <201003220511.37172.mailinglisten@hauke-laging.de> Hello, I have just bought a gnupg smartcard, copied my subkeys to it, and it works. I have been using a key on several computers. Now I want the other systems to use the smartcard, too, so that I can delete the private keys there. The content of the smartcard is shown by --card-status and I could even use the authentication key for an SSH connection. For SSH connections gpg-agent looks at tha smartcard by default but it does not for normal key lookup. I just get an error message (something like "no private key found") if I delete the private keys. Is there an "official" way to tell gpg to use the smartcard? Anything except copying the keys to the card again (executing keytocard on all systems)? I had the idea that exporting the secret keys on the system which initialized the smartcard might work. But for convenience I decided not to use the smartcard at home so I imported the secret keys there... BTW: Does it make sense that the smartcard number is stored with the secret key stub after the keytocard command? I haven't tried but I guess that copying the same key to another card wouldn't work. Hauke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From expires2010 at ymail.com Mon Mar 22 13:48:30 2010 From: expires2010 at ymail.com (MFPA) Date: Mon, 22 Mar 2010 12:48:30 +0000 Subject: 2.0.14 --gen-key interface nit In-Reply-To: <4BA5801A.1000500@dougbarton.us> References: <4BA5801A.1000500@dougbarton.us> Message-ID: <648460228.20100322124830@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Sunday 21 March 2010 at 2:10:34 AM, in , Doug Barton wrote: > Howdy, > Playing around with key generation there was something > banging around in the back of my mind and it finally > hit me: > Possible actions for a RSA key: Sign Certify Encrypt > Authenticate Current allowed actions: Sign Certify > Authenticate > (S) Toggle the sign capability (E) Toggle the > encrypt capability (A) Toggle the authenticate > capability (Q) Finished The thing that stands out to me is the lack of an option to toggle the certify capability. > --- > Real name: Douglas Barton Email address: > dougb at dougbarton.us Comment: You selected this USER-ID: > "Douglas Barton " > Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o > The Q option behaves inconsistently between these two > menus. In the capabilities menu it means "we're done, > and all is well;" in the uid section O ("oh") means Ok, > but Q bails out of the whole key generation process. > The easiest way to fix this would probably be to change > the capabilities menu since that's an --expert option. I always interpreted the capabilities menu as a sub-menu of the key generation process, so it seemed logical that quitting the sub-menu would revert to the parent menu. Are you advocating (when in the capabilities menu) an "okay" or "save" selection to keep the changes you've made and for "quit" to discard the changes? - -- Best regards MFPA mailto:expires2010 at ymail.com Puns are bad but poetry is verse. -----BEGIN PGP SIGNATURE----- iQCVAwUBS6dnSaipC46tDG5pAQprVAP/VQRTNbu//skcjHhd3ucPrRL2TDIzjykm DuL5OxiQmhd45cGSKFgtZaqUm6hQrDrlowmUaGq800lZRZHnfmNGSrJA843YM5e9 lz63miC0vaZSBJ5wj7/bWk4SjQvjjx0A6KeE9hhE9f9fnRI1G2kynVIZ24SggIGc IzN8dxnTkzY= =dohn -----END PGP SIGNATURE----- From andre at bluesalamand.de Sat Mar 20 15:17:55 2010 From: andre at bluesalamand.de (=?iso-8859-1?Q?Andr=E9_Ludwig?=) Date: Sat, 20 Mar 2010 15:17:55 +0100 Subject: Delete secret key without public key Message-ID: <3430391A-5B91-4D2D-9E38-9B026284A6DE@bluesalamand.de> Hi! I've got a secret key which is useless (ID AB756AEB) and I want to delete it from my keyring. This secret key has no associated public key. The problem is, that it only shows up in the gpg2 --edit-key mode after typing "toggle" followed by return. It doesn't show up on gpg2 --list-secret-keys. I read the FAQ and found this: http://www.gnupg.org/faq.html#q4.6 So I tried out to find the long keyID for my problematic secret key. But the "--use-colons"-option doesn't really work with --edit-key after a "toggle", it only gives me my user IDs. "gpg2 --delete-secret-key AB756AEB" doesn't work either. So how can I get the long keyID or how can I delete this secret-key? Please add me as CC in replies to this Mail. Thank you very much, Andr? ============= shematic output: $ gpg2 --help gpg (GnuPG/MacGPG2) 2.0.14 libgcrypt 1.4.5 Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. [...] $ gpg2 --edit-key andre Geheimer Schl?ssel ist vorhanden. pub 1024D/ACA3438B erzeugt: 2003-12-05 verf?llt: niemals Aufruf: SC Vertrauen: uneingeschr?nkt G?ltigkeit: uneingeschr?nkt sub 1536g/7469868B erzeugt: 2003-12-05 verfallen: 2010-03-08 Aufruf: E sub 2048g/8605C6C9 erzeugt: 2010-03-07 verf?llt: 2012-03-06 Aufruf: E [ uneing.] (1). Andr? Ludwig [widerrufen] (2) Andr? Ludwig [ uneing.] (3) Andr? Ludwig [ uneing.] (4) Andr? Ludwig Befehl> toggle sec 1024D/ACA3438B erzeugt: 2003-12-05 verf?llt: niemals ssb 1536g/7469868B erzeugt: 2003-12-05 verf?llt: niemals ssb 2048g/AB756AEB erzeugt: 2010-03-07 verf?llt: niemals <<<<<<<<<<<<<<<<<<<<<<<<<<< WANT TO DELETE THIS ONE ssb 2048g/8605C6C9 erzeugt: 2010-03-07 verf?llt: niemals (1) Andr? Ludwig (2) Andr? Ludwig (3) Andr? Ludwig $ gpg2 --with-colons --list-keys andre tru::1:1268680745:1310335397:3:1:5 pub:u:1024:17:33ACE6FBACA3438B:1070622740:::u:::scESC: uid:u::::1267979329::3332EBD5F03657462C477121634ACECA1B92423F::Andr? Ludwig : uid:r::::::C27A194598C48F51B5829D63E8A4ED95C71F6DE9::Andr? Ludwig : uid:u::::1267979337::9FBFE293AE50491B3A9D79825E2EC28E0DA3C8EE::Andr? Ludwig : uid:u::::1267979337::D26CA709DCA720197ECFF757A1D118968B041E9E::Andr? Ludwig : sub:e:1536:16:8125E9097469868B:1070622743:1268065682:::::e: sub:u:2048:16:4523360E8605C6C9:1267979156:1331051156:::::e: $ gpg2 --with-colons --list-secret-keys andre sec::1024:17:33ACE6FBACA3438B:1070622740::::::scESC:::: uid:::::1267979329::3332EBD5F03657462C477121634ACECA1B92423F::Andr? Ludwig : uid:::::::C27A194598C48F51B5829D63E8A4ED95C71F6DE9::Andr? Ludwig : uid:::::1267979337::9FBFE293AE50491B3A9D79825E2EC28E0DA3C8EE::Andr? Ludwig : uid:::::1267979337::D26CA709DCA720197ECFF757A1D118968B041E9E::Andr? Ludwig : ssb::1536:16:8xxxxxx4469868B:10xxxxxx3:1268xxxxx82:::::e:::: ssb::2048:16:467xxxxx0E8605C6C9:126xxxxxx56:13xxxxxx156:::::e:::: $ gpg2 --with-colons --edit-key andre Geheimer Schl?ssel ist vorhanden. pub:u:1024:17:33ACE6FBACA3438B:1070622740:0::u:::sc fpr:::::::::985A4829196EE9198B530CF033ACE6FBACA3438B: sub:e:1536:16:xxxxxxx097469868B:10xxxxxx43:1xxxxxxxx82:::::e fpr:::::::::0A02031164C31753F6614F9B8125E9097469868B: sub:u:2048:16:45xxxxxxxE8605C6C9:12xxxxxxx6:13xxxxxxxx56:::::e fpr:::::::::18CBAFB85E09304E13A0D4444523360E8605C6C9: uid:u::::::::Andr? Ludwig :::S9 S8 S7 S3 S2 H2 H3 Z2 Z1,mdc,no-ks-modify:1,p: uid:r::::::::Andr? Ludwig :::,no-ks-modify:2,r: uid:u::::::::Andr? Ludwig :::S9 S8 S7 S3 S2 H2 H3 Z2 Z1,mdc,no-ks-modify:3,: uid:u::::::::Andr? Ludwig :::S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1,mdc,no-ks-modify:4,: Befehl> toggle uid:u::::::::Andr? Ludwig ::::1,: uid:u::::::::Andr? Ludwig ::::2,: uid:u::::::::Andr? Ludwig ::::3,: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: Signierter Teil der Nachricht URL: From mailinglisten at hauke-laging.de Mon Mar 22 14:17:47 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 22 Mar 2010 14:17:47 +0100 Subject: Delete secret key without public key In-Reply-To: <3430391A-5B91-4D2D-9E38-9B026284A6DE@bluesalamand.de> References: <3430391A-5B91-4D2D-9E38-9B026284A6DE@bluesalamand.de> Message-ID: <201003221417.47437.mailinglisten@hauke-laging.de> Am Samstag 20 M?rz 2010 15:17:55 schrieb Andr? Ludwig: > So I tried out to find the long keyID for my problematic secret key. But > the "--use-colons"-option doesn't really work with --edit-key after a > "toggle", it only gives me my user IDs. "gpg2 --delete-secret-key > AB756AEB" doesn't work either. So how can I get the long keyID or how can > I delete this secret-key? I think this solves your problem: gpg --keyid-format long --edit-key ... Hauke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From dshaw at jabberwocky.com Mon Mar 22 15:30:36 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 22 Mar 2010 10:30:36 -0400 Subject: 2.0.14 --gen-key interface nit In-Reply-To: <648460228.20100322124830@my_localhost> References: <4BA5801A.1000500@dougbarton.us> <648460228.20100322124830@my_localhost> Message-ID: On Mar 22, 2010, at 8:48 AM, MFPA wrote: >> Howdy, > >> Playing around with key generation there was something >> banging around in the back of my mind and it finally >> hit me: > >> Possible actions for a RSA key: Sign Certify Encrypt >> Authenticate Current allowed actions: Sign Certify >> Authenticate > >> (S) Toggle the sign capability (E) Toggle the >> encrypt capability (A) Toggle the authenticate >> capability (Q) Finished > > The thing that stands out to me is the lack of an option to toggle the > certify capability. That is by design, though the reason why is different for primary keys and subkeys. For primary keys, OpenPGP requires this. All primary keys must be able to certify. For subkeys, the web of trust is built between signatures on primary keys, so a certifying subkey would not actually serve any purpose (signatures from it would be ignored). Note there is no official standard web of trust document that defines this, but it is the convention that all current programs that use the web of trust adhere to. >> Real name: Douglas Barton Email address: >> dougb at dougbarton.us Comment: You selected this USER-ID: >> "Douglas Barton " > >> Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o > >> The Q option behaves inconsistently between these two >> menus. In the capabilities menu it means "we're done, >> and all is well;" in the uid section O ("oh") means Ok, >> but Q bails out of the whole key generation process. > >> The easiest way to fix this would probably be to change >> the capabilities menu since that's an --expert option. > > I always interpreted the capabilities menu as a sub-menu of the key > generation process, so it seemed logical that quitting the sub-menu > would revert to the parent menu. That was my intent when I added that feature. That doesn't make it ideal, of course :) I'm open to changing it, but ideally this would be in a backwards compatible way. David From marco+gnupg at websource.ch Mon Mar 22 19:50:49 2010 From: marco+gnupg at websource.ch (Marco Steinacher) Date: Mon, 22 Mar 2010 19:50:49 +0100 Subject: using a smartcard without keytocard In-Reply-To: <201003220511.37172.mailinglisten@hauke-laging.de> References: <201003220511.37172.mailinglisten@hauke-laging.de> Message-ID: <4BA7BC09.6000103@websource.ch> Hauke Laging wrote: > I have just bought a gnupg smartcard, copied my subkeys to it, and it works. I > have been using a key on several computers. Now I want the other systems to > use the smartcard, too, so that I can delete the private keys there. The > content of the smartcard is shown by --card-status and I could even use the > authentication key for an SSH connection. > > For SSH connections gpg-agent looks at tha smartcard by default but it does > not for normal key lookup. I just get an error message (something like "no > private key found") if I delete the private keys. > > Is there an "official" way to tell gpg to use the smartcard? Anything except > copying the keys to the card again (executing keytocard on all systems)? I think deleting the the private key and issuing a 'gpg --card-status' should be enough. With that, gpg should automatically generate the secret key stubs which refer to the keys on that specific card. (Alternatively, you could export the secret key stubs on the machine where you have moved the keys to your card. An import these stubs on the machines on which you want to use the card.) > I had the idea that exporting the secret keys on the system which initialized > the smartcard might work. But for convenience I decided not to use the > smartcard at home so I imported the secret keys there... I'm not sure what exactly you are getting at but if you have used the keytocard command to transfer the keys to the card then the secret keys in your keyring have been replaced by stubs. I.e. they are now only stored on the smartcard and can't be retrieved anymore, unless you had a copy stored elsewhere. If you want to use the same keys without the smartcard at home, you have to have a copy of the secret keys before you moved them to the card. Make sure to import the real secret keys and not the stubs on that machine. (I assume you have thought about the security implications of doing so.) > BTW: Does it make sense that the smartcard number is stored with the secret > key stub after the keytocard command? I haven't tried but I guess that copying > the same key to another card wouldn't work. I think it just tells gnupg which card to use (or to request if it's not inserted). In order to copy the same key to multiple cards you have to make a copy of the secret keys before you move them to the first card, because 'keytocard' will replace the secret keys by stubs as explained above. Then you can re-import the secret keys from that copy and move them to another card. Marco -- OpenPGP Key ID: 0x62937F7F -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From dshaw at jabberwocky.com Mon Mar 22 21:40:48 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Mon, 22 Mar 2010 16:40:48 -0400 Subject: using a smartcard without keytocard In-Reply-To: <201003220511.37172.mailinglisten@hauke-laging.de> References: <201003220511.37172.mailinglisten@hauke-laging.de> Message-ID: <33D2CBA7-66B3-4442-86C8-1FB427ADD0FB@jabberwocky.com> On Mar 22, 2010, at 12:11 AM, Hauke Laging wrote: > Hello, > > I have just bought a gnupg smartcard, copied my subkeys to it, and it works. I > have been using a key on several computers. Now I want the other systems to > use the smartcard, too, so that I can delete the private keys there. The > content of the smartcard is shown by --card-status and I could even use the > authentication key for an SSH connection. > > For SSH connections gpg-agent looks at tha smartcard by default but it does > not for normal key lookup. I just get an error message (something like "no > private key found") if I delete the private keys. > > Is there an "official" way to tell gpg to use the smartcard? Anything except > copying the keys to the card again (executing keytocard on all systems)? Yes. If I understand what you are asking, the easiest way to do this is to delete the secret key on those systems, then insert the card, and do a 'gpg --card-status'. That recreates the secret key stub so GPG knows to look at the card for that key. David From expires2010 at ymail.com Tue Mar 23 14:10:03 2010 From: expires2010 at ymail.com (MFPA) Date: Tue, 23 Mar 2010 13:10:03 +0000 Subject: 2.0.14 --gen-key interface nit In-Reply-To: References: <4BA5801A.1000500@dougbarton.us> <648460228.20100322124830@my_localhost> Message-ID: <141100391.20100323131003@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 22 March 2010 at 2:30:36 PM, in , David Shaw wrote: > On Mar 22, 2010, at 8:48 AM, MFPA wrote: >> The thing that stands out to me is the lack of an >> option to toggle the certify capability. > That is by design, though the reason why is different > for primary keys and subkeys. For primary keys, > OpenPGP requires this. All primary keys must be able > to certify. Fair enough. I was thinking about the "special case" of users who maintain a "personal master key" to collect and issue web of trust signatures and to sign the "production" keys they actually use for encryption and signing files or email. That set-up would be well-served by the production keys being unable to certify. Of course, a certify-only primary key with subkeys for signing and encryption is the more standard way to achieve essentially the same thing. > For subkeys, the web of trust is built > between signatures on primary keys, so a certifying > subkey would not actually serve any purpose (signatures > from it would be ignored). Note there is no official > standard web of trust document that defines this, but > it is the convention that all current programs that use > the web of trust adhere to. I never thought a certifying subkey would make a lot of sense. Any way I thought about it, a signature from such a beast would mean exactly the same as a signature from the primary key or, in certain situations, add confusion/ambiguity with no discernible benefit. - -- Best regards MFPA mailto:expires2010 at ymail.com A bird in the hand makes it awfully hard to blow your nose -----BEGIN PGP SIGNATURE----- iQCVAwUBS6i9raipC46tDG5pAQqFjQQAnXIV/KcgDjPct4QsNFwcawIg21fsZmLr yAO+uXViQ4Mu3GbJI4oI449sIOq+Paod2UJ3PP4Sy82jZ2+WjtZwQDy84vnpw3RR pG/0PSkMqBajM4TEsrGNYTb3MR4RBruBFNtPf96lV3gyFOuTQJ8iYSw73rwxOS47 II+a94cPGHc= =iB64 -----END PGP SIGNATURE----- From vedaal at hush.com Tue Mar 23 15:18:48 2010 From: vedaal at hush.com (vedaal at hush.com) Date: Tue, 23 Mar 2010 10:18:48 -0400 Subject: Delete secret key without public key Message-ID: <20100323141848.672972803F@smtp.hushmail.com> Andr?_Ludwig wrote on 2010-03-20 14:17:55 >I've got a secret key which is useless (ID AB756AEB) and I want to >delete it from my keyring. This secret key has no associated public key. It's not useless. Gnupg secret keys already include the public key and automatically extract it when only the secret key is imported. Try this: [1] export your secret key [2] re-import it Gnupg will automatically extract the public key and add it to your keyring. (hope it's not too late, and you can still do it from your keyring or a backup ;-) ) vedaal From dshaw at jabberwocky.com Tue Mar 23 15:27:10 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 23 Mar 2010 10:27:10 -0400 Subject: 2.0.14 --gen-key interface nit In-Reply-To: <141100391.20100323131003@my_localhost> References: <4BA5801A.1000500@dougbarton.us> <648460228.20100322124830@my_localhost> <141100391.20100323131003@my_localhost> Message-ID: <208676D2-157A-4733-B4AC-62662FDA0562@jabberwocky.com> On Mar 23, 2010, at 9:10 AM, MFPA wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Monday 22 March 2010 at 2:30:36 PM, in > , David Shaw > wrote: > >> On Mar 22, 2010, at 8:48 AM, MFPA wrote: >>> The thing that stands out to me is the lack of an >>> option to toggle the certify capability. > >> That is by design, though the reason why is different >> for primary keys and subkeys. For primary keys, >> OpenPGP requires this. All primary keys must be able >> to certify. > > Fair enough. I was thinking about the "special case" of users who > maintain a "personal master key" to collect and issue web of trust > signatures and to sign the "production" keys they actually use for > encryption and signing files or email. That set-up would be > well-served by the production keys being unable to certify. Issuing a web of trust signature or signing production keys *are* certifications. If key couldn't certify, it couldn't even make self-sigs on itself (so no user IDs, or subkeys either) David From Rhiannon at viva.org.uk Tue Mar 23 17:09:24 2010 From: Rhiannon at viva.org.uk (Rhiannon Buck) Date: Tue, 23 Mar 2010 16:09:24 +0000 Subject: PHP website Message-ID: Hello After moving servers I was having trouble with GnuPG so I generated a new set of keys in my own name. They work in the command line: gpg --encrypt -ao encrypteddata -r rhiannon at viva.org.uk data But not in my PHP code. Are there any PHP geniuses out there? This is the bit that doesn't work at all (errors listed below). ---------------------------------------------------------------------------------------------------------------------------------------------- //invoke PGP to encrypt file contents system("/usr/bin/gpg --encrypt -ao $crypted -r 'Rhiannon ' $plainTxt"); //open file and read encrypted contents into var $fd = fopen($crypted, "r"); $encrypted_stuff = fread($fd, filesize($crypted)); fclose($fd); ---------------------------------------------------------------------------------------------------------------------------------------------- If I make the fopen "w+" it does create the file, but it is empty at 0 bytes. As I said, it works beautifully from the command line - my new user is able to encrypt and decrypt. Many Thanks Rhiannon ---------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------------------------------------------------------------- Errors: Warning: fopen(/services/webpages/t/i/timetogoveggie.com/90bfb3b11eb247df93c4a7470e058b96pgpdata) [function.fopen]: failed to open stream: No such file or directory in /services4/webpages/util/v/i/vivacaa.site.aplus.net/public/vvfshop/processform2.php on line 137 Warning: filesize() [function.filesize]: stat failed for /services/webpages/t/i/timetogoveggie.com/90bfb3b11eb247df93c4a7470e058b96pgpdata in /services4/webpages/util/v/i/vivacaa.site.aplus.net/public/vvfshop/processform2.php on line 138 Warning: fread(): supplied argument is not a valid stream resource in /services4/webpages/util/v/i/vivacaa.site.aplus.net/public/vvfshop/processform2.php on line 138 Warning: fclose(): supplied argument is not a valid stream resource in /services4/webpages/util/v/i/vivacaa.site.aplus.net/public/vvfshop/processform2.php on line 139 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eggled at gmail.com Tue Mar 23 18:11:15 2010 From: eggled at gmail.com (eggled at gmail.com) Date: Tue, 23 Mar 2010 12:11:15 -0500 Subject: PHP website In-Reply-To: References: Message-ID: <20100323171115.GE21181@pokeserver.eggled.dyndns.org> On Tue, Mar 23, 2010 at 04:09:24PM +0000, Rhiannon Buck wrote: > Hello > > > > After moving servers I was having trouble with GnuPG so I generated a new > set of keys in my own name. They work in the command line: > > gpg --encrypt -ao encrypteddata -r rhiannon at viva.org.uk data > > > > But not in my PHP code. > > Are there any PHP geniuses out there? > > This is the bit that doesn't work at all (errors listed below). > > ---------------------------------------------------------------------------------------------------------------------------------------------- > > //invoke PGP to encrypt file contents > > system("/usr/bin/gpg --encrypt -ao $crypted -r 'Rhiannon > ' $plainTxt"); > > > > //open file and read encrypted contents into var > > $fd = fopen($crypted, "r"); > > $encrypted_stuff = fread($fd, filesize($crypted)); > > fclose($fd); > > ---------------------------------------------------------------------------------------------------------------------------------------------- > > > > If I make the fopen "w+" it does create the file, but it is empty at 0 > bytes. > > > > As I said, it works beautifully from the command line - my new user is > able to encrypt and decrypt. > > > > Many Thanks > > > > Rhiannon > > > > ---------------------------------------------------------------------------------------------------------------------------------------------- > > ---------------------------------------------------------------------------------------------------------------------------------------------- > > ---------------------------------------------------------------------------------------------------------------------------------------------- > > > > Errors: > > > > Warning: > fopen(/services/webpages/t/i/timetogoveggie.com/90bfb3b11eb247df93c4a7470e058b96pgpdata) > [[1]function.fopen]: failed to open stream: No such file or directory in > /services4/webpages/util/v/i/vivacaa.site.aplus.net/public/vvfshop/processform2.php > on line 137 > > Warning: filesize() [[2]function.filesize]: stat failed for > /services/webpages/t/i/timetogoveggie.com/90bfb3b11eb247df93c4a7470e058b96pgpdata > in > /services4/webpages/util/v/i/vivacaa.site.aplus.net/public/vvfshop/processform2.php > on line 138 > > Warning: fread(): supplied argument is not a valid stream resource in > /services4/webpages/util/v/i/vivacaa.site.aplus.net/public/vvfshop/processform2.php > on line 138 > > Warning: fclose(): supplied argument is not a valid stream resource in > /services4/webpages/util/v/i/vivacaa.site.aplus.net/public/vvfshop/processform2.php > on line 139 > > > > > > . > > References > > Visible links > 1. https://secure40.securewebsession.com/timetogoveggie.com/vvfshop/function.fopen > 2. https://secure40.securewebsession.com/timetogoveggie.com/vvfshop/function.filesize > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users php is probably running as a different user. Try running system("id -u") or system("whoami") and compare that to the output from your login. You will probably need to create a keyring for whichever user owns the php process and fetch the necessary keys to encrypt the data. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From expires2010 at ymail.com Tue Mar 23 19:09:44 2010 From: expires2010 at ymail.com (MFPA) Date: Tue, 23 Mar 2010 18:09:44 +0000 Subject: 2.0.14 --gen-key interface nit In-Reply-To: <208676D2-157A-4733-B4AC-62662FDA0562@jabberwocky.com> References: <4BA5801A.1000500@dougbarton.us> <648460228.20100322124830@my_localhost> <141100391.20100323131003@my_localhost> <208676D2-157A-4733-B4AC-62662FDA0562@jabberwocky.com> Message-ID: <1231438755.20100323180944@my_localhost> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Tuesday 23 March 2010 at 2:27:10 PM, in , David Shaw wrote: >>> On Mar 22, 2010, at 8:48 AM, MFPA wrote: >> I was thinking about the "special case" >> of users who maintain a "personal master key" to >> collect and issue web of trust signatures and to sign >> the "production" keys they actually use for encryption >> and signing files or email. That set-up would be >> well-served by the production keys being unable to >> certify. > Issuing a web of trust signature or signing production > keys *are* certifications. Yes. That's why I said "the production keys being unable to certify," since such a user would perform these tasks with their "master" key. > If key couldn't certify, it > couldn't even make self-sigs on itself Even though I knew that a key or UID should be considered suspect if not self-signed, the penny hadn't dropped that the self-sig was a "certification" in the same way as a web of trust signature. > (so no user IDs, or subkeys either) What happens if somebody converts a subkey into a primary key? Can they then create UIDs and subkeys for it? - -- Best regards MFPA mailto:expires2010 at ymail.com Versifiers write poems for it. -----BEGIN PGP SIGNATURE----- iQCVAwUBS6kD76ipC46tDG5pAQpUbQQAtoGwY6SJG7WzYc7XPp/4nrvw5janoIoC YVuW5HIfNXPROUGAp4S0WrfxQtQwADN93FbAEGIEpLkEn5sp3il/ByvHU4axydDz AOqG2EpWf0isHIMvfPXtxWRAtbGfZ80MsgV5e9/XwNjy6mWyU8yQqswscnb5W/dC 1NjOHaqY9jk= =664R -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Tue Mar 23 19:13:53 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 23 Mar 2010 14:13:53 -0400 Subject: 2.0.14 --gen-key interface nit In-Reply-To: <1231438755.20100323180944@my_localhost> References: <4BA5801A.1000500@dougbarton.us> <648460228.20100322124830@my_localhost> <141100391.20100323131003@my_localhost> <208676D2-157A-4733-B4AC-62662FDA0562@jabberwocky.com> <1231438755.20100323180944@my_localhost> Message-ID: On Mar 23, 2010, at 2:09 PM, MFPA wrote: >> (so no user IDs, or subkeys either) > > What happens if somebody converts a subkey into a primary key? > Can they then create UIDs and subkeys for it? Sure, a key is a key. What you can do with it (i.e. the concepts of "primary" or "subkey") is defined by the protocol, not by something inherent in the key itself. If a subkey is changed into a primary key, it can do whatever a primary key can do. David From faramir.cl at gmail.com Tue Mar 23 23:50:38 2010 From: faramir.cl at gmail.com (Faramir) Date: Tue, 23 Mar 2010 19:50:38 -0300 Subject: Generating a new key In-Reply-To: <4BA696D2.3000203@gmail.com> References: <4BA571DC.5050205@dougbarton.us> <4BA59518.8000904@gmail.com> <4BA696D2.3000203@gmail.com> Message-ID: <4BA945BE.5090905@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Paul Richard Ramer escribi?: > On Sun, 21 Mar 2010 00:40:08 -0300 Faramir wrote: >> Another thing to consider, is SHA is not as safe as it used to be, and >> it it becomes easily crackeable, signatures issued using SHA can become >> unsafe. So maybe you'd like to use SHA-256 instead of SHA-128. If I'm > > I believe that you meant SHA-1 and not SHA-128, because there isn't a > hash called SHA-128. Also SHA-1 is a 160 bit hash. Right, I was referring to SHA-1, and I confused the bit length of SHA-1 with key length of AES. I saw another message, from Robert J. Hansen, saying indeed there is a "SHA-128" unofficial denomination. Maybe I saw "SHA-128" while browsing documents about SHA, and that contributed to my confusion. But anyway, I was referring to the "normal" SHA algorithm. ... >> idea is to replace SHA-1 with SHA-256, it can be useful. (I have a bad >> feeling about telling other people to use that line). > > In addition to what David said, the passphrase mangling uses iterations > of the hash algorithm to slow down a brute force attack on the > passphrase. So for a fictional example, GnuPG will hash the word "dog" > and produce "0123456789". Then it will iterate by taking the output of > the hash algorithm and use it as input to another instance of hashing. > So in this example it would take the output of "0123456789" and hash it > to produce "9876543210". Good, now I know what is "password mangling" about. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBCAAGBQJLqUW+AAoJEMV4f6PvczxA5vMH/2O6iSWqRINIz3mqUG5PXjce CKHyBeBPx5qmjUB7t1ze2q1Ke0+jtH5tPVy3vGbiDjnlMmHjCerzMTkTJnGkQa7F fStgLvzSuVRUdTg5szPzrdXYdG3s4riDDnMSd577EAWEepAn2KH29AE8rwoEWwn6 V6EUsOMI48gqRbdwnSRaYJJkYWcF+GZkY/dc0hspnk3JXCfleh1Qrel5zcGHTRdg Y0yf/86n7pdKc8i7i0y6/0EXzJ5Jv5Tbh40UgEicoI8U6e9qqkQil/oYj0N3OFRC 5TXZdMFnzr/PP2W69fEjBScqotZWHDgaqrt5zo4ZY6GJ5mtAcVlZ6p6Y/SOsoro= =XfT4 -----END PGP SIGNATURE----- From awolff at newbreed.com Wed Mar 24 14:09:05 2010 From: awolff at newbreed.com (Wolff, Alex) Date: Wed, 24 Mar 2010 09:09:05 -0400 Subject: gnupg 1.4.7 vs. pgp 6.5.3 In-Reply-To: References: Message-ID: Company 1 is using gnupg 1.4.7 on SunOS. Company2 is using PGP 6.5.3 on Win2003. Company1 encrypts using Company2's public key and ftp's file in ascii mode to Company2. Company2 tries to decrypt file and receives error : "bad session keys" or "1 unknown key(s)" To encrypt we are using command: gpg -r Charlie.Camut at company.com --output TEST.txt.pgp --encrypt OUTFILE.go Is this incompatibility issue between gnupg and pgp or a bonehead mistake? Thanks. From dshaw at jabberwocky.com Wed Mar 24 14:53:40 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 24 Mar 2010 09:53:40 -0400 Subject: gnupg 1.4.7 vs. pgp 6.5.3 In-Reply-To: References: Message-ID: On Mar 24, 2010, at 9:09 AM, Wolff, Alex wrote: > Company 1 is using gnupg 1.4.7 on SunOS. Company2 is using PGP 6.5.3 on > Win2003. > > Company1 encrypts using Company2's public key and ftp's file in ascii > mode to Company2. > > Company2 tries to decrypt file and receives error : > > "bad session keys" or "1 unknown key(s)" > > To encrypt we are using command: gpg -r Charlie.Camut at company.com > --output TEST.txt.pgp --encrypt OUTFILE.go > > Is this incompatibility issue between gnupg and pgp or a bonehead > mistake? PGP 6.5.3 is really, really old now, and predates a good amount of stuff that is now part of the OpenPGP standard, including some things that were added for security reasons. The real answer here is to get company 2 to upgrade to something newer. It doesn't have to be GPG - any recent PGP would be fine as well. Since that may not be under your control (I assume you are "company 1" in the above), you can try adding the "--pgp6" option to your GPG command line. This tells GPG to internally "backdate" itself, so it won't generate any messages using features or algorithms that were added to the standard after PGP 6. Even so, note that the --pgp6 option backdates to PGP 6.5.8, and company 2 is using a version even older than *that*. David From laurent.jumet at skynet.be Wed Mar 24 14:57:35 2010 From: laurent.jumet at skynet.be (Laurent Jumet) Date: Wed, 24 Mar 2010 15:57:35 +0200 Subject: gnupg 1.4.7 vs. pgp 6.5.3 In-Reply-To: Message-ID: Hello Wolff, ! "Wolff, Alex" wrote: > Company 1 is using gnupg 1.4.7 on SunOS. Company2 is using PGP 6.5.3 on > Win2003. > Company1 encrypts using Company2's public key and ftp's file in ascii > mode to Company2. > Company2 tries to decrypt file and receives error : > "bad session keys" or "1 unknown key(s)" > To encrypt we are using command: gpg -r Charlie.Camut at company.com > --output TEST.txt.pgp --encrypt OUTFILE.go > Is this incompatibility issue between gnupg and pgp or a bonehead > mistake? PGP6 is able to use IDEA for encrypting and GPG doesn't decrypt it by default; try load-extension IDEA.DLL in GPG. You said "ascii transfer" but the pgp file is a binary one? -- Laurent Jumet KeyID: 0xCFAF704C From vedaal at hush.com Wed Mar 24 19:24:26 2010 From: vedaal at hush.com (vedaal at hush.com) Date: Wed, 24 Mar 2010 14:24:26 -0400 Subject: gnupg 1.4.7 vs. pgp 6.5.3 Message-ID: <20100324182426.F369411803D@smtp.hushmail.com> "Laurent Jumet" wrote on 2010-03-24 13:57:35: >PGP6 is able to use IDEA for encrypting and GPG doesn't decrypt it by > default; \ try load-extension IDEA.DLL in GPG. The problem was on the PGP end. The company using PGP6.x couldn't decrypt, and the error message, "bad session keys" indicates that the it didn't recognize the algorithm used, (probably AES or another one that came after PGP 6.x. ) David's advice of using the option of --PGP6 on the GnuPG side will make everything work again on the PGP end. vedaal From jpboard2 at yahoo.com Wed Mar 24 23:56:48 2010 From: jpboard2 at yahoo.com (James Board) Date: Wed, 24 Mar 2010 15:56:48 -0700 (PDT) Subject: Corrupted File In-Reply-To: <4BA1B0A4.1040403@gmail.com> Message-ID: <605201.14926.qm@web45906.mail.sp1.yahoo.com> > Have you tried decrypting the file with either PGP or > GnuPG?? Also, > where in the file is the corruption? The file is corrupted (a 4096-byte page full of zereos), at seemingly random places, but not near the front of the file. The file was encrypted with PGP 5.0. I tried to decrypt with PGP 5.0 and that didn't work. Should I try with gpg? Does gpg behave gracefully if the input file is corrupted? I don't normally use gpg: can I decrypt a file with gpg that was originally encrypted with pgp 5.0? From free10pro at gmail.com Thu Mar 25 01:50:27 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Wed, 24 Mar 2010 17:50:27 -0700 Subject: Corrupted File In-Reply-To: <605201.14926.qm@web45906.mail.sp1.yahoo.com> References: <605201.14926.qm@web45906.mail.sp1.yahoo.com> Message-ID: <4BAAB353.6060705@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 24 Mar 2010 15:56:48 -0700 (PDT), James Board wrote: >> Have you tried decrypting the file with either PGP or >> GnuPG? Also, >> where in the file is the corruption? > > The file is corrupted (a 4096-byte page full of zereos), at seemingly random places, but not near the front of the file. > > The file was encrypted with PGP 5.0. I tried to decrypt with PGP 5.0 and that didn't work. [...] I haven't used PGP 5.0, but does it give an error message when you try to decrypt the file. If it does, please let us know what the error message is. It could be helpful. > [...] Should I try with gpg? Does gpg behave gracefully if the input file is corrupted? [...] It wouldn't hurt to try. As for the second question, I don't know. I don't have the knowledge or experience with these situations to answer that. > [...] I don't normally use gpg: can I decrypt a file with gpg that was originally encrypted with pgp 5.0? To the best of my knowledge, GnuPG can work with old versions of PGP going back to PGP 2.x. So I think that it may. If you do use GnuPG to decrypt your file, let us know whether it works or not. And if it doesn't work, post the error message so that we can further diagnose. - -Paul - -- You wouldn't send all of your mail written on the back of postcards would you? Then why would you send your e-mail the same way? +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- iQGcBAEBCAAGBQJLqrLVAAoJEJhBiuhgbQLInbEL/iU8azdfLK6tH2/CiNDjBtq9 PCzDDf7vFCZqChkNeNJJLJ1qPmhpjDPnakZLCHmhTiPhlA/AKlHOP2H6HhgReNmR Lr7rLP0OYRcUj5VgWmFod7624qdwrqK05zS70may15fCRpi7z/VssGNNbf9FMVyT GsPZm2KFUC++ZHCjFYo6qKVKltNuMHiH7SuNzACuOOSkASkdoBR+uQoUcUvL3ngF XZuzgtfi4m13r+q8IfKBqh/sMI61qQs7f6Ky+Ji4PHom4mSDoVBT9cw5lbt1fUeZ Z3w+W9HdxmFsoh+qH/qRvyut9szyPvVdZvB2+K4/Mcd8+vbq3Hk/CPwfI3UOjtKj voxpAdgz6qageCSRGvGAg0vFbt/0CoJdAFanxKa7LJP8hounFY/uy87x9R5ktw7c +uVRDdGatPC4Jv5fxKI5xkf1vuWv4BFtuLaExt6kelHnwwH4k+gmLsWTJfgNvHkx 6DhRIjXA/HegJOvDIyq6ZJas0XQHL/0MvNccT+xSPg== =rjHb -----END PGP SIGNATURE----- From tony at darkstorm.co.uk Thu Mar 25 16:41:10 2010 From: tony at darkstorm.co.uk (Tony Evans) Date: Thu, 25 Mar 2010 15:41:10 +0000 Subject: Issue with GnuPG -> PGP, self signature, new key Message-ID: I create a new key yesterday using gpg (GnuPG) 1.4.9 (Ubuntu 9.10), selecting all the defaults, without changing my preferences file first. I exported the public key (ascii armored), no other options, and mailed it to a contact. They checked the key with PGP (sorry, don't know what version), and got this output, % pgpk -ll 'Tony Evans' Type Bits KeyID Created Expires Algorithm Use pub 1024 0x4250AA8D 2010-03-24 ---------- DSS Sign & Encrypt f20 Fingerprint20 = 73F0 396D 7EC5 0FBE CEB9 B1D0 1E90 79EB 4250 AA8D sub 2048 0x9CCCB946 2010-03-24 ---------- Diffie-Hellman f20 Fingerprint20 = 7B88 74DE C64A 98B1 22E8 8FE4 28EA B0A5 9CCC B946 uid Tony Evans sig 0x00000000 2010-03-24 (Unknown signator, can't be checked) 1 matching key found The Unknown signator bit is the worrying part. I've checked my key with gpg and it believes it to be self-signed correctly. Did I get something wrong, should I have done something different on the export, or is it just a compatibility issue with PGP (I know, hard to comment without knowing exactly which version). Command> check uid Tony Evans sig!3 4250AA8D 2010-03-24 [self-signature] -- Tony Evans Saving trees and wasting electrons since 1993 blog -> http://perceptionistruth.com/ books -> http://www.bookthing.co.uk/ [ anything below this line wasn't written by me ] From rjh at sixdemonbag.org Thu Mar 25 18:06:36 2010 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 25 Mar 2010 13:06:36 -0400 Subject: Issue with GnuPG -> PGP, self signature, new key In-Reply-To: References: Message-ID: <4BAB981C.5020608@sixdemonbag.org> On 3/25/2010 11:41 AM, Tony Evans wrote: > The Unknown signator bit is the worrying part. I've checked my key > with gpg and it believes it to be self-signed correctly. Did I get > something wrong, should I have done something different on the export, > or is it just a compatibility issue with PGP (I know, hard to comment > without knowing exactly which version). It is most likely a compatibility issue. PGP 6.5.8 is well over a decade old; PGP 5 is even older. Those versions are not especially compatible with RFC4880, which is the IETF standard which defines the OpenPGP protocol. You may want to consider adding "pgp5" to your gpg.conf file, which you can find in your .gnupg directory. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: S/MIME Cryptographic Signature URL: From andre at bluesalamand.de Tue Mar 23 20:12:09 2010 From: andre at bluesalamand.de (=?iso-8859-1?Q?Andr=E9_Ludwig?=) Date: Tue, 23 Mar 2010 20:12:09 +0100 Subject: Delete secret key without public key In-Reply-To: <20100323141848.672972803F@smtp.hushmail.com> References: <20100323141848.672972803F@smtp.hushmail.com> Message-ID: <1A1C12FF-A594-4200-964F-AC10A356A151@bluesalamand.de> Thank you very much. Exporting my public keys from my secret keyring with gpgsplit and reimporting these public keys helped me deleting it "the usual way". Andr? Am 23.03.2010 um 15:18 schrieb vedaal at hush.com: > Try this: > > [1] export your secret key > [2] re-import it > > Gnupg will automatically extract the public key and add it to your > keyring. From david at dcbarry.com Thu Mar 25 22:09:40 2010 From: david at dcbarry.com (dcbarry) Date: Thu, 25 Mar 2010 14:09:40 -0700 (PDT) Subject: Possible to sign &/or encrypt without importing to keyring Message-ID: <28034931.post@talk.nabble.com> I'm fairly certain the answer is "NO", or at least "impractical". I've researched the man pages and FAQ, and tried searching on what I thought were relevant terms. For reference, I am utilizing GnuPG 2.0.12. Is it possible to encrypt a file to a public key (and/or sign with a private key) without first importing into the pub key into a keyring using a stand alone file containing the key(s). For clarity, I would like to be able to do something like: gpg --localuser [somepath]\myprivatekey.asc -recipient [somepath]\joes_pub_key.asc --sign --encrypt thisoldfile.txt (being prompted for the pass-phrase assuming the pvt key was some protected.) This would be particularly useful for use in cases where the recipient is very likely to be a one-shot deal. I do recognize there are some serious tradeoffs for this, for the purposes here, I would consider them acceptable. Again, I've gone thru the man, and the section "HOW TO SPECIFY A USERID" doesn't leave me much hope that I missed something elsewhere. Additionally, I don't recall which option I read it under,but there was an indirect statement to the effect that GPG will NOT run without either a default or manually specified keyring(s). As I said, I'm pretty sure my answer is no, but I'm hoping I've missed something obvious that in fact, makes it possible. As always, my gratitude to those who respond, and those who contribute to the community. d. -- View this message in context: http://old.nabble.com/Possible-to-sign---or-encrypt-without-importing-to-keyring-tp28034931p28034931.html Sent from the GnuPG - User mailing list archive at Nabble.com. From dougb at dougbarton.us Thu Mar 25 22:59:45 2010 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 25 Mar 2010 14:59:45 -0700 Subject: Possible to sign &/or encrypt without importing to keyring In-Reply-To: <28034931.post@talk.nabble.com> References: <28034931.post@talk.nabble.com> Message-ID: <4BABDCD1.8040007@dougbarton.us> On 3/25/2010 2:09 PM, dcbarry wrote: > > Is it possible to encrypt a file to a public key (and/or sign with a private > key) without first importing into the pub key into a keyring using a stand > alone file containing the key(s). I don't believe it's possible, but in any case there are at least two solutions that are simpler. One would be to import the key, use it, then delete it (no harm done to what's left behind) and the other, slightly more complicated but still doable is to create a new keyring file for the purpose and import the key into it. In general the concept of "keyring management" is one area (with all due respect to the developers) that I think gnupg does not make things very easy. I like to keep keys related to different responsibilities on their own keyrings, and to further complicate matters I like to keep my personal public keys on yet another ring. The primary reason I like to do this is that it allows me to enable the auto-key-retrieve option. I allow all the automatically retrieved keys to go into pubring.gpg, and then I periodically delete that ring when it gets too large. In order to facilitate this in my gpg.conf file I have a section where I list the active keyrings. Then I copy my conf file to "nokeyrings.conf" and replace the list of keyrings with no-default-keyring. Then I can use the following alias: alias gpgk='gpg --options ~/.gnupg/nokeyrings.conf --keyring' Assuming you set up something similar you could then do the following: gpgk onetime-ring.gpg --import You'll get a warning about your ultimately trusted keys not being found but once you've got the key imported you can then use it as you normally would (assuming you either specify that keyring on the command line, or include it in gpg.conf). I keep meaning to write up something in more detail about how I manage my keys and include some feature requests, but for better or worse I haven't found the time yet. I will probably do it this week though since I went to a key signing on Tuesday and it's all fresh in my mind. hope this helps, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From harakiri_23 at yahoo.com Fri Mar 26 22:03:54 2010 From: harakiri_23 at yahoo.com (Harakiri) Date: Fri, 26 Mar 2010 14:03:54 -0700 (PDT) Subject: Possible to sign &/or encrypt without importing to keyring In-Reply-To: <28034931.post@talk.nabble.com> Message-ID: <649736.19479.qm@web52203.mail.re2.yahoo.com> --- On Thu, 3/25/10, dcbarry wrote: > From: dcbarry > Subject: Possible to sign &/or encrypt without importing to keyring > To: gnupg-users at gnupg.org > Date: Thursday, March 25, 2010, 5:09 PM > As I said, I'm pretty sure my answer is no, but I'm hoping > I've missed > something obvious that in fact, makes it possible. > > if you are using bash to encrypt when not do (pseudo syntax) gpg --public-keyring tmp_keyring --import key.asc && gpg --public-keyring tmp_keyring --encrypt myfile.txt && tmp_keyring you can even define an alias for this in your bash.rc or either simly convert all those single public keys to single keyrings however as already said, the keymanagement is horrible, sadly From Aarthi.Kannan at gs.com Fri Mar 26 07:05:39 2010 From: Aarthi.Kannan at gs.com (Kannan, Aarthi [Tech]) Date: Fri, 26 Mar 2010 02:05:39 -0400 Subject: URGENT: GNuPG 1.2.1 - secret keys help Message-ID: Hi, I am using gpg1.2.1. I created a key using gen-key. When I do a -list-keys, it lists my public key fine. When I do a -list-secret-key, I get the following error: gpg: keyring_get_keyblock: read error: invalid packet gpg: keydb_get_keyblock failed: invalid keyring I have read & write access to pubring.gpg, secring.gpg, trustdb.gpg & random_seed. Am I missing something here? Can you please help, it's urgent - am stuck on this for a while now! Thanks, Aarthi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Aarthi.Kannan at gs.com Fri Mar 26 07:12:00 2010 From: Aarthi.Kannan at gs.com (Kannan, Aarthi [Tech]) Date: Fri, 26 Mar 2010 02:12:00 -0400 Subject: URGENT: GNuPG 1.2.1 - secret keys help In-Reply-To: References: Message-ID: Here is the command I use: gpg --home /home/gpgfiles --keyring /home/gpgfiles/pubring.gpg --list-secret-keys From: Kannan, Aarthi [Tech] Sent: Friday, March 26, 2010 11:36 AM To: 'gnupg-users at gnupg.org' Subject: URGENT: GNuPG 1.2.1 - secret keys help Hi, I am using gpg1.2.1. I created a key using gen-key. When I do a -list-keys, it lists my public key fine. When I do a -list-secret-key, I get the following error: gpg: keyring_get_keyblock: read error: invalid packet gpg: keydb_get_keyblock failed: invalid keyring I have read & write access to pubring.gpg, secring.gpg, trustdb.gpg & random_seed. Am I missing something here? Can you please help, it's urgent - am stuck on this for a while now! Thanks, Aarthi -------------- next part -------------- An HTML attachment was scrubbed... URL: From free10pro at gmail.com Mon Mar 29 03:06:41 2010 From: free10pro at gmail.com (Paul Richard Ramer) Date: Sun, 28 Mar 2010 18:06:41 -0700 Subject: URGENT: GNuPG 1.2.1 - secret keys help In-Reply-To: References: Message-ID: <4BAFFD21.1080109@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On Fri, 26 Mar 2010 02:12:00 -0400, Kannan, Aarthi [Tech] wrote: > Here is the command I use: > gpg --home /home/gpgfiles --keyring /home/gpgfiles/pubring.gpg --list-secret-keys > > From: Kannan, Aarthi [Tech] > Sent: Friday, March 26, 2010 11:36 AM > To: 'gnupg-users at gnupg.org' > Subject: URGENT: GNuPG 1.2.1 - secret keys help > > Hi, > I am using gpg1.2.1. > I created a key using gen-key. > When I do a -list-keys, it lists my public key fine. > > When I do a -list-secret-key, I get the following error: > gpg: keyring_get_keyblock: read error: invalid packet > gpg: keydb_get_keyblock failed: invalid keyring > > I have read & write access to pubring.gpg, secring.gpg, trustdb.gpg & random_seed. > > Am I missing something here? Can you please help, it's urgent - am stuck on this for a while now! I think that it means that your secret keyring is corrupted. - -Paul - -- New Windows 7: Double the DRM, Double the fun! Learn more: +---------------------------------------------------------------------+ | PGP Key ID: 0x3DB6D884 | | PGP Fingerprint: EBA7 88B3 6D98 2D4A E045 A9F7 C7C6 6ADF 3DB6 D884 | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- iQGcBAEBCAAGBQJLr/zvAAoJEJhBiuhgbQLInBwL+QGgH1dZ3Y5cu9lrLzqVCG3S Paa7ODFdHgCJYjwAtM4WBB/WDphWFwzLgUiPJb6mHTZY0RpqJFeguSBoXFfS2m0S jxXCfgTREYlKUG05H60xQFJyj11DAoHKWvyMf0UjTUig03tAStjSAoQ2PYaZ3+Cn wlnhyGC1KRo4Luh4dz2PcMsIT1TxLJRQBggbKr+CnYQFdz98GoTzBYntVlcBrjQJ JCz2I2O7HLbMylLK0U1t6IdFpm2SmgQKbcoLON7FE91bZEhAAsZKpVNtzlSAVHZC q5irY7/aTwNr3ctW56HSlK1P4nmm6RbNbGodAE4uWhaWa0hbRiS0kGovryKi1OxI kC2DeL6CK2j+Jg22K7P2V8kPlP8YRZQxpb4AtSRPdItsvmPugslpSu8Cf8tYKnV7 +duXd+1ZQM5z230MMDsSHfAGBZqY/e5ztwYzo39f832LLpmzYTmGbcAv83C17Qgm r1EFM9xGecDDVPZJs6YKeUjtnG48AdRD2s7FbxlhQw== =Z3rp -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Mon Mar 29 03:26:22 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Sun, 28 Mar 2010 21:26:22 -0400 Subject: URGENT: GNuPG 1.2.1 - secret keys help In-Reply-To: References: Message-ID: On Mar 26, 2010, at 2:05 AM, Kannan, Aarthi [Tech] wrote: > Hi, > I am using gpg1.2.1. > I created a key using gen-key. > When I do a ?list-keys, it lists my public key fine. > > When I do a ?list-secret-key, I get the following error: > gpg: keyring_get_keyblock: read error: invalid packet > gpg: keydb_get_keyblock failed: invalid keyring > > I have read & write access to pubring.gpg, secring.gpg, trustdb.gpg & random_seed. > > Am I missing something here? Can you please help, it?s urgent ? am stuck on this for a while now! Based on the error, it looks like your secret keyring is corrupt. Do you have a backup of it? David From fabrice.rafart at efs.sante.fr Mon Mar 29 10:04:13 2010 From: fabrice.rafart at efs.sante.fr (Fabrice RAFART) Date: Mon, 29 Mar 2010 10:04:13 +0200 Subject: gpg on open file Message-ID: <631E8BE18C924DB8A02916A70A886686@adidf.efs.sante.fr> Hello, I have a question, I'm not sure it be related to gpg or general to linux : Can I prevent gpg to encrypt open file ? I explain my situation : I have file dropped to filesystem by Windows program with samba share. I take (with a script launch by cron) the file and encrypt it. It may append that gpg take the file during the Windows programm copy it. For the now, I looking to use fuser to check this before encrypt the file but it may be a better way to prevent this. Regards, Fabrice. From Aarthi.Kannan at gs.com Mon Mar 29 07:16:18 2010 From: Aarthi.Kannan at gs.com (Kannan, Aarthi [Tech]) Date: Mon, 29 Mar 2010 01:16:18 -0400 Subject: URGENT: GNuPG 1.2.1 - secret keys help In-Reply-To: References: Message-ID: I do have a backup. When I run on a particular directory, the secret key gets listed. I had to cvs it to the server and then I try listing secret keys on the server folder - it fails with the invalid packet error message! I see the file there in the directory, with the same size. It also has read/write permissions on all the files and also the dir. Is there any other permission that I need? -----Original Message----- From: David Shaw [mailto:dshaw at jabberwocky.com] Sent: Monday, March 29, 2010 6:56 AM To: Kannan, Aarthi [Tech] Cc: 'gnupg-users at gnupg.org' Subject: Re: URGENT: GNuPG 1.2.1 - secret keys help On Mar 26, 2010, at 2:05 AM, Kannan, Aarthi [Tech] wrote: > Hi, > I am using gpg1.2.1. > I created a key using gen-key. > When I do a -list-keys, it lists my public key fine. > > When I do a -list-secret-key, I get the following error: > gpg: keyring_get_keyblock: read error: invalid packet > gpg: keydb_get_keyblock failed: invalid keyring > > I have read & write access to pubring.gpg, secring.gpg, trustdb.gpg & random_seed. > > Am I missing something here? Can you please help, it's urgent - am stuck on this for a while now! Based on the error, it looks like your secret keyring is corrupt. Do you have a backup of it? David From mailinglisten at hauke-laging.de Mon Mar 29 13:57:58 2010 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Mon, 29 Mar 2010 13:57:58 +0200 Subject: gpg on open file In-Reply-To: <631E8BE18C924DB8A02916A70A886686@adidf.efs.sante.fr> References: <631E8BE18C924DB8A02916A70A886686@adidf.efs.sante.fr> Message-ID: <201003291358.10221.mailinglisten@hauke-laging.de> Am Montag 29 M?rz 2010 10:04:13 schrieb Fabrice RAFART: > Can I prevent gpg to encrypt open file ? > > I explain my situation : I have file dropped to filesystem by Windows > program with samba share. I take (with a script launch by cron) the file > and encrypt it. It may append that gpg take the file during the Windows > programm copy it. > > For the now, I looking to use fuser to check this before encrypt the file > but it may be a better way to prevent this. I don't think that there is any solution within gpg, simply because gpg cannot (easily) prevent other processes from modifying the file while it reads it. I see two solutions, a usable one and the perfect one: a) Use mandatory locks. That's what I wanted to suggest first. But a short look at the documentation make me think that this may easily become terrible. So better look at b) Create a snapshot volume This requires the file's filesystem to reside on a block device that is handled by the device mapper. Locking a whole volume in order to emulate a reliable file lock looks a bit like overkill but without better solutions... This requires superuser privilege, of course (in contrast to (a)). c) One more comes to my mind: Given that the file resides on a suitables file system (like ext{2,3,4} and probably more) you could make the file immutable (chattr), execute the next step and remove the i bit then. Again: Superuser only. The snapshot's advantage is that is causes the shortest block (if the file has a relevant size) and that applications do not notice this action. If an application is not prepared for being denied access due to mandatory locking or the immutable bit, additional problems may arise. CU Hauke -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Mar 29 14:19:52 2010 From: wk at gnupg.org (Werner Koch) Date: Mon, 29 Mar 2010 14:19:52 +0200 Subject: gpg symmetric to Java JCA decryption In-Reply-To: <1964cfb61003211409x1ab9d369kb4e099d782b2e455@mail.gmail.com> (Juergen Weber's message of "Sun, 21 Mar 2010 22:09:25 +0100") References: <1964cfb61003191351g7e60b59bx2402f3fb621abc99@mail.gmail.com> <5DD47BBD-D3EA-4AE7-968C-09CEA926D39F@jabberwocky.com> <1964cfb61003211409x1ab9d369kb4e099d782b2e455@mail.gmail.com> Message-ID: <87y6hbl3pz.fsf@vigenere.g10code.de> On Sun, 21 Mar 2010 22:09, weberjn at gmail.com said: > No, I don't need OpenPGP, just need symmetric encryption done by a > standard command line Unix tool and decryption by means of the Java You still need to define which standard you want to use. The most popular encryption standards are 1. OpenPGP - A command line tool for this is gpg 2. CMS (aka PKCS#7) - A command line too for this is gpgsm. > Guess I'll take openssl, looks like this works with Java: Openssl implements several sprotocols, you need to specify which protocol of openssl you use. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kgo at grant-olson.net Mon Mar 29 14:22:45 2010 From: kgo at grant-olson.net (Grant Olson) Date: Mon, 29 Mar 2010 08:22:45 -0400 Subject: URGENT: GNuPG 1.2.1 - secret keys help In-Reply-To: References: Message-ID: <4BB09B95.4070300@grant-olson.net> On 3/29/2010 1:16 AM, Kannan, Aarthi [Tech] wrote: > I do have a backup. When I run on a particular directory, the secret key gets listed. I had to cvs it to the server and then I try listing secret keys on the server folder - it fails with the invalid packet error message! > I see the file there in the directory, with the same size. It also has read/write permissions on all the files and also the dir. Is there any other permission that I need? > > Did you set the file type to binary in cvs? CVS might be 'fixing' linefeeds or doing some keyword expansion if you didn't. Do the files have the same checksums on your local machine and the server if you run something like "md5 file" or "sha256sum file"? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From CONNIE.RODRIGUEZ at childrens.com Tue Mar 30 00:14:15 2010 From: CONNIE.RODRIGUEZ at childrens.com (CONNIE RODRIGUEZ) Date: Mon, 29 Mar 2010 17:14:15 -0500 Subject: Secret key without public key Message-ID: <4BB0DFE7.632C.0028.0@childrens.com> Help!! Just last week I was able to decrypt files for our Vendor. I tried this morning and now I get the message below. The only changes that occurred was that another vendor key was added last week. The ELG-E Key is the same the message was encrypted with. Any insight to this message is appreciated. I read a few articles and it stated to delete secret key but I am not comfortable with deleting any key without some kind of guidance since I am a rookie at gpg. Anyway I am confused as to why I would need to delete the secret key when nothing has changed for this vendor. gpg: key 9EDEB618: secret key without public key - skipped gpg: encrypted with ELG-E key, ID BEA2D168 gpg: decryption failed: secret key not available Thank you in advance for any help that you can provide Connie Please consider the environment before printing this e-mail

This e-mail, facsimile, or letter and any files or attachments transmitted with it contains
information that is confidential and privileged. This information is intended only for the use of the
individual(s) and entity(ies) to whom it is addressed. If you are the intended recipient, further
disclosures are prohibited without proper authorization. If you are not the intended recipient, any
disclosure, copying, printing, or use of this information is strictly prohibited and possibly a
violation of federal or state law and regulations. If you have received this information in error,
please notify Children's Medical Center Dallas immediately at 214-456-4444 or via e-mail at
privacy at childrens.com. Children's Medical Center Dallas and its affiliates hereby claim all
applicable privileges related to this information.


-------------- next part -------------- An HTML attachment was scrubbed... URL: From CONNIE.RODRIGUEZ at childrens.com Tue Mar 30 02:03:53 2010 From: CONNIE.RODRIGUEZ at childrens.com (CONNIE RODRIGUEZ) Date: Mon, 29 Mar 2010 19:03:53 -0500 Subject: Secret key without public key In-Reply-To: <4BB13EDC.8060000@maxqe.com> References: <4BB0DFE7.632C.0028.0@childrens.com> <4BB13EDC.8060000@maxqe.com> Message-ID: <4BB0F999.632C.0028.0@childrens.com> Sorry forgot to mention this is in unix. Also, I do not have a backup to re-import. >>> Larry Brower 3/29/2010 6:59 PM >>> CONNIE RODRIGUEZ wrote: > Help!! Just last week I was able to decrypt files for our Vendor. I > tried this morning and now I get the message below. The only changes > that occurred was that another vendor key was added last week. The > ELG-E Key is the same the message was encrypted with. Any insight to > this message is appreciated. I read a few articles and it stated to > delete secret key but I am not comfortable with deleting any key without > some kind of guidance since I am a rookie at gpg. Anyway I am confused > as to why I would need to delete the secret key when nothing has changed > for this vendor. > > gpg: key 9EDEB618: secret key without public key - skipped > gpg: encrypted with ELG-E key, ID BEA2D168 > gpg: decryption failed: secret key not available > > Thank you in advance for any help that you can provide > > Connie The actual error is: gpg: encrypted with ELG-E key, ID BEA2D168 gpg: decryption failed: secret key not available It appears that another key being added was not the only thing that occurred and someone has deleted the secret key the message was encrypted to. Do you have a backup to re-import? Please consider the environment before printing this e-mail

This e-mail, facsimile, or letter and any files or attachments transmitted with it contains
information that is confidential and privileged. This information is intended only for the use of the
individual(s) and entity(ies) to whom it is addressed. If you are the intended recipient, further
disclosures are prohibited without proper authorization. If you are not the intended recipient, any
disclosure, copying, printing, or use of this information is strictly prohibited and possibly a
violation of federal or state law and regulations. If you have received this information in error,
please notify Children's Medical Center Dallas immediately at 214-456-4444 or via e-mail at
privacy at childrens.com. Children's Medical Center Dallas and its affiliates hereby claim all
applicable privileges related to this information.


-------------- next part -------------- An HTML attachment was scrubbed... URL: From CONNIE.RODRIGUEZ at childrens.com Tue Mar 30 02:10:35 2010 From: CONNIE.RODRIGUEZ at childrens.com (CONNIE RODRIGUEZ) Date: Mon, 29 Mar 2010 19:10:35 -0500 Subject: Secret key without public key In-Reply-To: <4BB140A1.8070708@maxqe.com> References: <4BB0DFE7.632C.0028.0@childrens.com> <4BB13EDC.8060000@maxqe.com> <4BB0F999.632C.0028.0@childrens.com> <4BB140A1.8070708@maxqe.com> Message-ID: <4BB0FB2B.632C.0028.0@childrens.com> This is a development box..no backup. Can I copy from the another environment? >>> Larry Brower 3/29/2010 7:06 PM >>> CONNIE RODRIGUEZ wrote: > Sorry forgot to mention this is in unix. Also, I do not have a backup > to re-import. > I figured is was Unix. Without a backup you wont be able to decrypt the file. Are you certain there is no backup? No backup of the system which could have the .gnupg directory? Tape perhaps? Please consider the environment before printing this e-mail

This e-mail, facsimile, or letter and any files or attachments transmitted with it contains
information that is confidential and privileged. This information is intended only for the use of the
individual(s) and entity(ies) to whom it is addressed. If you are the intended recipient, further
disclosures are prohibited without proper authorization. If you are not the intended recipient, any
disclosure, copying, printing, or use of this information is strictly prohibited and possibly a
violation of federal or state law and regulations. If you have received this information in error,
please notify Children's Medical Center Dallas immediately at 214-456-4444 or via e-mail at
privacy at childrens.com. Children's Medical Center Dallas and its affiliates hereby claim all
applicable privileges related to this information.


-------------- next part -------------- An HTML attachment was scrubbed... URL: From CONNIE.RODRIGUEZ at childrens.com Tue Mar 30 02:17:30 2010 From: CONNIE.RODRIGUEZ at childrens.com (CONNIE RODRIGUEZ) Date: Mon, 29 Mar 2010 19:17:30 -0500 Subject: Secret key without public key In-Reply-To: <4BB14289.9030007@maxqe.com> References: <4BB0DFE7.632C.0028.0@childrens.com> <4BB13EDC.8060000@maxqe.com> <4BB0F999.632C.0028.0@childrens.com> <4BB140A1.8070708@maxqe.com> <4BB0FB2B.632C.0028.0@childrens.com> <4BB14289.9030007@maxqe.com> Message-ID: <4BB0FCCA.632C.0028.0@childrens.com> Great!! Thank you for your help. I will post on how it went. >>> Larry Brower 3/29/2010 7:15 PM >>> CONNIE RODRIGUEZ wrote: > This is a development box..no backup. Can I copy from the another > environment? > yes if you have the key on another server such as a production box. gpg --export-secret-key -a > a-filename-here copy it to the dev box with something like scp then on the dev box gpg --import a-filename-here make sure to remove the file you generated exporting the key. You don't want someone to see copy it ;) shred -f -n 1000 -z -v -u a-filename-here Please consider the environment before printing this e-mail

This e-mail, facsimile, or letter and any files or attachments transmitted with it contains
information that is confidential and privileged. This information is intended only for the use of the
individual(s) and entity(ies) to whom it is addressed. If you are the intended recipient, further
disclosures are prohibited without proper authorization. If you are not the intended recipient, any
disclosure, copying, printing, or use of this information is strictly prohibited and possibly a
violation of federal or state law and regulations. If you have received this information in error,
please notify Children's Medical Center Dallas immediately at 214-456-4444 or via e-mail at
privacy at childrens.com. Children's Medical Center Dallas and its affiliates hereby claim all
applicable privileges related to this information.


-------------- next part -------------- An HTML attachment was scrubbed... URL: From larry-lists at maxqe.com Tue Mar 30 01:59:24 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Mon, 29 Mar 2010 18:59:24 -0500 Subject: Secret key without public key In-Reply-To: <4BB0DFE7.632C.0028.0@childrens.com> References: <4BB0DFE7.632C.0028.0@childrens.com> Message-ID: <4BB13EDC.8060000@maxqe.com> CONNIE RODRIGUEZ wrote: > Help!! Just last week I was able to decrypt files for our Vendor. I > tried this morning and now I get the message below. The only changes > that occurred was that another vendor key was added last week. The > ELG-E Key is the same the message was encrypted with. Any insight to > this message is appreciated. I read a few articles and it stated to > delete secret key but I am not comfortable with deleting any key without > some kind of guidance since I am a rookie at gpg. Anyway I am confused > as to why I would need to delete the secret key when nothing has changed > for this vendor. > > gpg: key 9EDEB618: secret key without public key - skipped > gpg: encrypted with ELG-E key, ID BEA2D168 > gpg: decryption failed: secret key not available > > Thank you in advance for any help that you can provide > > Connie The actual error is: gpg: encrypted with ELG-E key, ID BEA2D168 gpg: decryption failed: secret key not available It appears that another key being added was not the only thing that occurred and someone has deleted the secret key the message was encrypted to. Do you have a backup to re-import? From larry-lists at maxqe.com Tue Mar 30 02:06:57 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Mon, 29 Mar 2010 19:06:57 -0500 Subject: Secret key without public key In-Reply-To: <4BB0F999.632C.0028.0@childrens.com> References: <4BB0DFE7.632C.0028.0@childrens.com> <4BB13EDC.8060000@maxqe.com> <4BB0F999.632C.0028.0@childrens.com> Message-ID: <4BB140A1.8070708@maxqe.com> CONNIE RODRIGUEZ wrote: > Sorry forgot to mention this is in unix. Also, I do not have a backup > to re-import. > I figured is was Unix. Without a backup you wont be able to decrypt the file. Are you certain there is no backup? No backup of the system which could have the .gnupg directory? Tape perhaps? From larry-lists at maxqe.com Tue Mar 30 02:15:05 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Mon, 29 Mar 2010 19:15:05 -0500 Subject: Secret key without public key In-Reply-To: <4BB0FB2B.632C.0028.0@childrens.com> References: <4BB0DFE7.632C.0028.0@childrens.com> <4BB13EDC.8060000@maxqe.com> <4BB0F999.632C.0028.0@childrens.com> <4BB140A1.8070708@maxqe.com> <4BB0FB2B.632C.0028.0@childrens.com> Message-ID: <4BB14289.9030007@maxqe.com> CONNIE RODRIGUEZ wrote: > This is a development box..no backup. Can I copy from the another > environment? > yes if you have the key on another server such as a production box. gpg --export-secret-key -a > a-filename-here copy it to the dev box with something like scp then on the dev box gpg --import a-filename-here make sure to remove the file you generated exporting the key. You don't want someone to see copy it ;) shred -f -n 1000 -z -v -u a-filename-here From larry-lists at maxqe.com Tue Mar 30 02:20:45 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Mon, 29 Mar 2010 19:20:45 -0500 Subject: Secret key without public key In-Reply-To: <4BB0FCCA.632C.0028.0@childrens.com> References: <4BB0DFE7.632C.0028.0@childrens.com> <4BB13EDC.8060000@maxqe.com> <4BB0F999.632C.0028.0@childrens.com> <4BB140A1.8070708@maxqe.com> <4BB0FB2B.632C.0028.0@childrens.com> <4BB14289.9030007@maxqe.com> <4BB0FCCA.632C.0028.0@childrens.com> Message-ID: <4BB143DD.1040607@maxqe.com> CONNIE RODRIGUEZ wrote: > Great!! Thank you for your help. I will post on how it went. > Welcome ;) Just let us know if you have any questions on anything. From tspivey at pcdesk.net Tue Mar 30 04:01:59 2010 From: tspivey at pcdesk.net (Tyler Spivey) Date: Mon, 29 Mar 2010 19:01:59 -0700 Subject: Secret key without public key In-Reply-To: <4BB0FCCA.632C.0028.0@childrens.com> References: <4BB0DFE7.632C.0028.0@childrens.com> <4BB13EDC.8060000@maxqe.com> <4BB0F999.632C.0028.0@childrens.com> <4BB140A1.8070708@maxqe.com> <4BB0FB2B.632C.0028.0@childrens.com> <4BB14289.9030007@maxqe.com> <4BB0FCCA.632C.0028.0@childrens.com> Message-ID: <4BB15B97.1060609@pcdesk.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I ran a brief test, and was able to recover from this. Before you do anything, I recommend making a backup of ~/.gnupg so you can easily restore it. Here are my results, where 0xae742aaf is my key: #backup ~/.gnupg cp -a ~/.gnupg ~/.gnupg.orig #make and encrypt a test file touch test gpg -e -r 0xae742aaf test That worked fine. Then I moved the public keyring to break things: mv ~/.gnupg/pubring.gpg ~/.gnupg/pubring.gpg.orig gpg test.gpg and it said: gpg: keyring `/home/tyler/.gnupg/pubring.gpg' created gpg: key AE742AAF: secret key without public key - skipped gpg: encrypted with RSA key, ID C6570DCB gpg: decryption failed: secret key not available #export the secret key, because exporting public won't work gpg --export-secret-key -o secret.key 0xae742aaf #delete it so we can re-import gpg --delete-secret-key 0xae742aaf (answer yes to the prompts) gpg --import secret.key The output included: gpg: key AE742AAF: secret key imported gpg: key AE742AAF: public key "Tyler Spivey " imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: secret keys read: 1 gpg: secret keys imported: 1 once done, the decryption of test.gpg worked fine. Hope this helps. CONNIE RODRIGUEZ wrote: > Great!! Thank you for your help. I will post on how it went. > >>>> Larry Brower 3/29/2010 7:15 PM >>> > CONNIE RODRIGUEZ wrote: >> This is a development box..no backup. Can I copy from the another >> environment? >> > > yes if you have the key on another server such as a production box. > > gpg --export-secret-key -a > a-filename-here > > copy it to the dev box with something like scp > > then on the dev box > > gpg --import a-filename-here > > make sure to remove the file you generated exporting the key. You > don't want someone to see copy it ;) > > shred -f -n 1000 -z -v -u a-filename-here > > > Please consider the environment before printing this e-mail
>
> > This e-mail, facsimile, or letter and any files or attachments transmitted with it contains
> information that is confidential and privileged. This information is intended only for the use of the
> individual(s) and entity(ies) to whom it is addressed. If you are the intended recipient, further
> > disclosures are prohibited without proper authorization. If you are not the intended recipient, any
> disclosure, copying, printing, or use of this information is strictly prohibited and possibly a
> violation of federal or state law and regulations. If you have received this information in error,
> please notify Children's Medical Center Dallas immediately at 214-456-4444 or via e-mail at
> privacy at childrens.com. Children's Medical Center Dallas and its affiliates hereby claim all
> applicable privileges related to this information.

> >
> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users - -- Tyler Spivey - PGP Key ID: 0xae742aaf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJLsVuWAAoJEPb0SlyudCqv0gUQAIXn8/K4MhgYikjtDodY6GyI 8/Ge07rWrTYcGuxFRAMBhMpRfJ41rTn69WvCJB03QYtIGuunASNGWFvFwnBLvfQ5 ms9A3XJMd4qx0sLyvcOhfJKaQcR26MSHmmuw5n6WxxC9Oc5IhVnEgt+YOn68ye0r rtM2q5VzZwU3cFdwgyfF0nsUPFVVA9e7/RKncURy2qPy8tlDMJCde+c3DCYcPwfi 5fDrHjfzXk6tEdiKeZYpwtNEksOvOdiuolFzwbg8d2i0vvsndzz2GwZgdgRGWg0R pWcRNYss4YRScwwhg4Xpe9w/b0lDAOeqZFT/IzdUIkWDo+gsiil5+t3OBwxWfKtq lSjNZ3Dp4PvAP0Qxfq0XmP6OV4M0oTH8WzLSl7QN47wVRVa9IBw8hyvo0oMsPp04 mC5cKKruaB9EG/sDU7AJ9mjJSF2DE46RzkH3nGGXySacJi+CvUym7mawS3Nqh1Sl DJTIkheTbQ+Mfy+QPHPXY5+g98GXBT0sMVXUCAcYW3ECkIWY+WRRsOKOVcbFVwXp AbwZp6U7x6qw/puP1mAMuYakvoq+d2biE729SY6+dLY8lWIat+ANgEu+KyBsGnS7 ddP8BnrTzHnDSQtSHnk7vCznuhHUhC3w/VKi6knjRJzXp7pwuIHzuSkDS2ue0hcC eOoBBAbNg61BpsLazyma =gVix -----END PGP SIGNATURE----- From gnupg.user at seibercom.net Tue Mar 30 11:25:37 2010 From: gnupg.user at seibercom.net (Jerry) Date: Tue, 30 Mar 2010 05:25:37 -0400 Subject: Secret key without public key In-Reply-To: <4BB0FCCA.632C.0028.0@childrens.com> References: <4BB0DFE7.632C.0028.0@childrens.com> <4BB13EDC.8060000@maxqe.com> <4BB0F999.632C.0028.0@childrens.com> <4BB140A1.8070708@maxqe.com> <4BB0FB2B.632C.0028.0@childrens.com> <4BB14289.9030007@maxqe.com> <4BB0FCCA.632C.0028.0@childrens.com> Message-ID: <20100330052537.53c7a327@scorpio.seibercom.net> On Mon, 29 Mar 2010 19:17:30 -0500, CONNIE RODRIGUEZ articulated: > Please consider the environment before printing this e-mail > > This e-mail, facsimile, or letter and any files or attachments > transmitted with it contains information that is confidential and > privileged. This information is intended only for the use of the > individual(s) and entity(ies) to whom it is addressed. If you are the > intended recipient, further disclosures are prohibited without proper > authorization. If you are not the intended recipient, any disclosure, > copying, printing, or use of this information is strictly prohibited > and possibly a violation of federal or state law and regulations. If > you have received this information in error, please notify Children's > Medical Center Dallas immediately at 214-456-4444 or via e-mail at > privacy at childrens.com. Children's Medical Center Dallas and its > affiliates hereby claim all applicable privileges related to this > information. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient of this transmission, please delete it immediately. Obviously, I am the idiot who sent it to you by mistake. Furthermore, there is no way I can force you to delete it. Worse, by the time you have reached this disclaimer you have all ready read the document. Telling you to forget it would seem absurd. In any event, I have no legal right to force you to take any action upon this email anyway. This entire disclaimer is just a waste of everyone's time and bandwidth. Therefore, let us just forget the whole thing and enjoy a cold been instead. NOTE: If you are still insistent upon putting an offensive and legally unenforceable disclaimer in your e-mail, thereby wasting precious bandwidth and possibly putting tiny electrons in peril, at least have the decency to precede it with a "sig delimiter". Posting in plain text, as opposed to HTML would be appreciated also. -- Jerry GNUPG.user at seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ Today's scientific question is: What in the world is electricity? And where does it go after it leaves the toaster? Dave Barry, "What is Electricity?" From Ed.Greshko at greshko.com Tue Mar 30 17:03:15 2010 From: Ed.Greshko at greshko.com (Ed Greshko) Date: Tue, 30 Mar 2010 23:03:15 +0800 Subject: gpg-agent hosed for one user.... Message-ID: <4BB212B3.8080101@greshko.com> This is F11 (Fedora 11), KDE. Seems gpg-agent is hosed for one user. I think it may have to do with the cache for the private key pass phrase. I get the following.... egreshko at meimei .gnupg]$ /usr/bin/gpg --charset utf8 --batch --no-tty --status-fd 2 -t --clearsign -u \ --use-agent [GNUPG:] USERID_HINT E099CA8D56C206FA Ed Greshko [GNUPG:] NEED_PASSPHRASE E099CA8D56C206FA E099CA8D56C206FA 17 0 [GNUPG:] MISSING_PASSPHRASE [GNUPG:] BAD_PASSPHRASE E099CA8D56C206FA gpg: Invalid passphrase; please try again ... [GNUPG:] USERID_HINT E099CA8D56C206FA Ed Greshko [GNUPG:] NEED_PASSPHRASE E099CA8D56C206FA E099CA8D56C206FA 17 0 [GNUPG:] MISSING_PASSPHRASE [GNUPG:] BAD_PASSPHRASE E099CA8D56C206FA gpg: Invalid passphrase; please try again ... [GNUPG:] USERID_HINT E099CA8D56C206FA Ed Greshko [GNUPG:] NEED_PASSPHRASE E099CA8D56C206FA E099CA8D56C206FA 17 0 [GNUPG:] MISSING_PASSPHRASE [GNUPG:] BAD_PASSPHRASE E099CA8D56C206FA gpg: skipped "": bad passphrase gpg: [stdin]: clearsign failed: bad passphrase The dialog to type in the passphrase pops up but goes away in an instant. If I move the .gnupg directory to another user's area I have no problem. I get the feeling there is a corrupt file...or stuck file....from what I can tell gpg-agent interfaces with pinentry but don't know what else to do... Any ideas? From Ed.Greshko at greshko.com Wed Mar 31 04:46:48 2010 From: Ed.Greshko at greshko.com (Ed Greshko) Date: Wed, 31 Mar 2010 10:46:48 +0800 Subject: gpg-agent hosed for one user....[SOLVED] In-Reply-To: <4BB212B3.8080101@greshko.com> References: <4BB212B3.8080101@greshko.com> Message-ID: <4BB2B798.4090709@greshko.com> On 03/30/2010 11:03 PM, Ed Greshko wrote: > > I get the feeling there is a corrupt file...or stuck file....from what I > can tell gpg-agent interfaces with pinentry but don't know what else to > do... > > Any ideas? > Turns out the problem is related to the ibus input method, or one of its components.... From fab.furnari at gmail.com Wed Mar 31 16:08:06 2010 From: fab.furnari at gmail.com (Fabrizio Furnari) Date: Wed, 31 Mar 2010 16:08:06 +0200 Subject: simple newbie software Message-ID: Hi all, I'm a little bit in trouble because I'd like to sync all my data (secring, pubring, and so on) between my home pc and my work laptop. I tried to make a symbolic link for pubring.gpg (secring.gpg isn't a big issue, is not modified so often) to a DropBox folder, or an USB key but seems that seahorse mess up everything creating a pubring.gpg~ file and a new keyring. So I'm looking for another front-end that allows me to use two pc, and that can "support" seahorse, firegpg and so on. If you have any suggestions, are all welcomed, otherwise I'll start to create a little program (I always want to learn gtk) to do this. Cheers, Fabrizio -- @P=split//,".URRUU\c8R";@d=split//,"\niranruF oizirbaF";sub p{ @p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f^ord ($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&& close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print -------------- next part -------------- An HTML attachment was scrubbed... URL: