Re: How to give the keywork from command line.

[Laurent Jumet]

Hello Mario !

"Mario Castel n Castro"  wrote:

> Hi, I'm doing a bash script for pack (Tar), compress (lzip or bzip2)
> and encrypt (GPG with Rijndael 128) very important files, but is
> supposed to be non interactive, shouldn't ask the user for password
> when executed, please can you tellme how I can give it from the
> command line arguments?.

Using
--passphrase-file FILE
means that the first line of FILE will be used as passphrase.

--passphrase STRING
uses STRING as the passphrase.

Additionnaly, you'll probably need all or some of the switches:
--batch
--no-tty
--yes
to suppress console interaction.

-- 
Laurent Jumet
  KeyID: 0xCFAF704C


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Re[2]: key question

[Robert J. Hansen]

> Kind of "let's agree to disagree?"

More like, "since you are reacting emotionally and refuse to even entertain the 
possibility of being persuaded, there is no point in continuing this 
conversation."

I wish you a pleasant day.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[Paul Richard Ramer]

I think that MFPA has succinctly summed up his point of view in these
two quotes.

On Sun, 2010-02-28 at 04:33 +, MFPA wrote:
> > What you're saying here is, "even if the advice were sound for one
> > million users, and destructive to the privacy of just one, I still
> > would not change because any key I encounter could be that one."
> 
> That is exactly what I am saying. Neutral for a million but
> destructive for one, so let's all protect the one.

On Sat, 2010-02-27 at 20:39:57 +, MFPA wrote:
> >> It seems (and I could be utterly wrong), that MFPA is
> >> saying "Not  everyone wants their key on the
> >> keyservers, so please don't  automatically send other
> >> people's keys there.  If the key owner wants the key
> >> on the keyservers, he'll send it himself."
> 
> That is exactly what I am saying. Most peoples keys contain personal
> contact details and the decision to place that information in the
> public domain rests solely with the person whose details they are.


-Paul

-- 
Got PGP?

+-+
| PGP Key ID: 0x3DB6D884  |
| PGP Fingerprint: EBA7 88B3 6D98 2D4A E045  A9F7 C7C6 6ADF 3DB6 D884 |
+-+


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[Paul Richard Ramer]

On Sun, 2010-02-28 at 04:33 +, MFPA wrote:
> > Speculation is great, but speculation isn't fact -- and we need to
> > change the way we do things based on facts, not on speculations.  We
> > can agree on facts, but our speculations will likely not overlap very much 
> > at all.
> 
> I'm sure anybody reading this can find multiple examples where speculation
> has informed progress.

Speculation isn't any more progress than an idea is action.  Speculation
buttressed with facts leads, in time, to progress.  But speculation,
like an idea, is only the germ of what it is intended to create.


-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 |
+-+


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re[2]: key question

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Paul


On Saturday 27 February 2010 at 11:19:43 PM, you wrote:



> GnuPG doesn't, at least as of 1.4.10, force you to include an e-mail
> address in your user ID.  It merely requests an e-mail address, and you
> can just press enter and ignore the request.

In my opinion that's a step forward.

I'm convinced 1.4.9 would only do that in "expert" mode.



- --
Best regards

MFPAmailto:expires2...@ymail.com

Two wrongs don't make a right. But three lefts do.
-BEGIN PGP SIGNATURE-

iQCVAwUBS4oFJ6ipC46tDG5pAQoUHwP9EPBFa/ALcfsUFR/p7+cFkuwdtcj0E2Hj
ZSckxY6TCyE0zQsjghXWsVL/IcFHb5jv7/NNrhPKva12MPgxxtSCCOMvnCm167J2
aHyr/0gXBiclANe1Z6yvkUFOF+zND9zujjceG5QUJA1HVG1IIXHUWdZdPKp28Rbr
71SgEk9Xm3A=
=ZyWM
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Fwd: Re: key question

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Grant


On Saturday 27 February 2010 at 9:54:56 PM, you wrote:



> It sounds like you're using the software to do the opposite thing that
> many people do.  I think digital signatures are utilized much more than
> encrypted communication.

I don't know; I have not seen any purported volumes ofeither



> And digital signatures are about authenticating to a real person,
> and not anonymity.

Even with a "persona" on a forum, the digital signature provides a
measure of reassurance that those posts bearing the same moniker
actually do come from the same person.



> If you don't want to publish your email for the anonymity/privacy
> reasons you've outlined, then you probably don't want to use your legal
> name either.  And it looks like you don't.  Which is fine for encrypting
> documents.  But it renders two key features of digital signatures
> meaningless.  Authentication and Non-repudiation go out the window.

I'm not convinced that non-repudiation does go out of the window much
more than for a key claiming to represent a person with a name backed
up by government-issued ID, unless you know more about the person.

Say an individual has a key saying he's John Smith. He's found a few
people he doesn't know, who have checked his passport or driving
licence and signed his key to attest to his identity. He stops using
his key, stops communicating with you and closes the email account. A
very common name; which John Smith was it? Is it much easier to track
a random John Smith than a random MFPA?



> How
> do I authenticate that an anonymous entity is really an anonymous
> entity?

I'm not anonymous: I'm MFPA. Various people who know me personally
could attest to that.

For all anybody reading this knows, I could have renounced my previous
identity and now have official ID declaring that I am MFPA.



> That doesn't make any sense.  How do I get into a dispute with
> an anonymous entity about whether he really agreed to do X?

I wasn't planning to get into a dispute. *If* I said I'll do it, I
will. OK (-;



> And
> although it does prove message integrity, that, in and of itself,
> doesn't mean much for an anonymous entity.

A message to a mailing list from somebody you do not know who calls
himself MFPA. A message to the same mailing list from somebody I do
not know who calls himself Grant Olsen. Both are signed and the
signature checks both indicate no tampering. In what way does one
digital signature mean less than the other?



> So a few examples to elaborate.  I'm going to use MFPA as the anonymous
> user who doesn't have a real ID for clarity sake.  It's better than
> "anonymous entity".  Just to be clear, I'm not really talking about you
> or making any personal attacks in the examples.  You're just the generic
> guy with the non-identifiable key.

Thanks, I think (-:



> Farfetched example.  An email from MFPA pops up on the list.  "My house
> burnt down.  Lost my key.  Lost my rev certificate.  Here's my new
> info."  Five minutes later, another email from MFPA.  "That dude
> generated a fake key.  Keep using the old one.  The new one is bad!"  A
> third email from MFPA.  "That last dude is lying.  Turns out he stole my
> laptop before burning my house down."  Who do we trust?  Which key do we
> use?  We have no way of knowing who the real MFPA is, because he was
> anonymous to begin with.

My posting style, turn of phrase, and opinions suddenly taking a
step-change could be a clue. Although, depending on how I suffered in
the fire, that could happen.


If I used the name John Smith, how would this example be different?
(BTW I'm NOT John Smith)



> How could I sign your key?  It sounds like you don't want anyone to sign
> it anyway, plenty of other people want to sign keys and build the web of
> trust.  I can't verify your key in any way.  You're anonymous.  There's
> no way to prove you're MFPA.  So I can't sign your key.

If you knew me personally, you could.

And as I already said, do you know MFPA's not my legal identity?
There used to be somebody in my town who had officially changed his
name to FREFF. (Never did understand why.)



> Lets assume among your circle of friends, who know each other personally
> in real life, you sign off on each others keys.  And I somehow know one
> of your friends, and we sign each others keys.  To me, it's a
> meaningless assertion for someone to claim that they've verified that
> you're the real MFPA.  That doesn't mean anything to me because you're
> anonymous to me.  It also doesn't mean anything if you've signed off on
> someone's key.  What does it mean to me that MFPA vouched for someone
> else's identity?  Another meaningless assertion.

If you replace each instance of "MFPA" in the above paragraph with
"John Smith," how does it alter the sense of your point?

If your friend, who you have known for decades, asked you to sign their
key, would you check their documents just in case their legal identity
d

Re[2]: key question

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Robert


On Saturday 27 February 2010 at 8:03:15 PM, you wrote:


> On Feb 27, 2010, at 2:21 PM, MFPA wrote:
>> I have always been taught to challenge the status quo. "Because that's
>> the way we do it" is *never* a good reason to continue doing something
>> in a particular way.

> The status quo has something going for it: it works.

Otherwise stated (with a deal of wisdom) as "if it ain't broke, don't
fix it.



> 95% of all new ideas are awful and should be discarded. New ideas
> are how the status quo changes for the better, but that doesn't mean
> we should throw out the status quo just because an idea comes along
> which happens to be new.

Firstly, it seems unlikely I have presented any new ideas.

Secondly, that does not look like a reason to resist reanalysing the
status quo.



>> My
>> contention is that the de facto standard of revealing email addresses
>> in key UIDs could actually be mitigating *against* the use of
>> encrypted mail, by discouraging people from publishing keys or even
>> from using openPGP in the first place.

> It's an interesting idea,

But not new to you. After I wrote on here, I found
http://marc.info/?t=12547125491&r=1&w=2 which hypothesised
essentially the same issue and proposed one possible solution.



> but I don't see any facts to back it up.
> How many users are dissuaded?

I have no idea how I could conduct a survey to answer that question.
If you know, please advise me.

A change to *not* telling new users they should publish their email
addresses would be expected to give some clues as to the validity of
this theory.



> Is this a major concern, or not a concern?

Personal privacy is a major concern, in this age where governments and
companies constantly seek to undermine it. Else, governments would not
have been forced to make concessions such as introducing privacy and
data protection laws.



> What does the published literature say about it?  And so on, and so on.

Specifically on the subject of concern over email addresses on PGP
keyservers, I have been able to find the thread I linked to above and
nothing else. You could hypothesise that there is no such concern,
that I have consistently used inadequate search terms over several
years, that people who are concerned about this do not adopt openPGP,
that people who adopt openPGP quickly realise this is not a concern,
or probably a dozen other things.


More broadly, there are any number of sources discussing concern about
exposing your email address publicly on the internet.



> Speculation is great, but speculation isn't fact -- and we need to
> change the way we do things based on facts, not on speculations.  We
> can agree on facts, but our speculations will likely not overlap very much at 
> all.

I'm sure anybody reading this can find multiple examples where speculation
has informed progress.



>> That advice, coupled with the
>> default configuration's enforcement of including an email address (or
>> something that appears to be one) clearly has the potential to scare
>> potential users from experimenting with openPGP in the first place.

> The same way the shotgun in my closet clearly has the potential to be used as 
> a murder weapon.

Would making it clear that including an email address was not
compulsory (but encouraged for anybody who felt comfortable including
one) increase the take-up of openPGP?

Would removing your shotgun prevent a would-be murderer from killing
you?



> Potential != actuality.  All manner of potential things do not come
> to pass.  Before we change the way we do business, I'd like to know
> that we're changing to address a real problem, not merely a
> potential problem where no one really knows if it's a real problem or not.

Usually, the only way to establish if something *really* was an
impediment to people adopting a particular course of action is to
remove that could-be impediment, and make sure everybody knows you
have.



> The world has enough interesting problems to solve without us having to go 
> off chasing ghosts.

Our opinions differ, but I do not see addressing legitimate concerns
about email security as "chasing ghosts."



>> Because you suggested in an earlier post in this thread that it was
>> somehow acceptable to publish somebody's key to a server without their
>> consent.

> I don't think I said it was "acceptable."  I would find it to be in
> poor taste, myself, if it were done deliberately.  However, I don't
> think it would amount to a moral or ethical failing.

Six quotes below, unless I've made a mistake, all are from yourself.
Whilst none includes the word "acceptable," each indicates that
opinion.

'If someone asks me nicely, "please do not upload this key," I will
probably say yes. But it is a *huge* leap to go from there to "do not
upload keys without the owners' permission."'

'The key says "public" right at the very top, and I think it's
unreasonable to expect people to infer that 

How to give the keywork from command line.

[Mario Castelán Castro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

February 27th 2010 in gnupg-users@gnupg.org thread "Hot to give the
keyword from the command line".

Hi, I'm doing a bash script for pack (Tar), compress (lzip or bzip2)
and encrypt (GPG with Rijndael 128) very important files, but is
supposed to be non interactive, shouldn't ask the user for password
when executed, please can you tellme how I can give it from the
command line arguments?.

Thanks in advance.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREIAAYFAkuJ3qcACgkQZ4DA0TLic4jAFwCdF4dw5dH3JstLYfPV5I0HHjDM
NogAoI2n3PJZ6b2h67Y7T1UTaEEQrd/v
=CxjD
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[Doug Barton]

On 02/27/10 14:21, John Clizbe wrote:
> Nor have we seen compelling arguments for their omission as a general rule

I think it would be more accurate to say that we haven't seen any
arguments that will sway those with strongly held beliefs on either
side. Since we're not likely to see them any time in the future, I guess
the question at this point is, has everyone had their say yet?


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/


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[John Clizbe]

MFPA wrote:
> Hi
> On Saturday 27 February 2010 at 6:11:29 AM, in 
> , Robert J. Hansen wrote:

>>> In any case, I've never seen a convincing argument *for* including  email
>>> addresses in the UID of a PGP key.

Nor have we seen compelling arguments for their omission as a general rule

>> First, the status quo doesn't need arguments in its favor.  The status quo
>> exists.  *Changing* the status quo is what requires arguments in its
>> favor.
> 
> I have always been taught to challenge the status quo. "Because that's the
> way we do it" is *never* a good reason to continue doing something in a
> particular way.

It is never a good reason when it is the sole justification. It's a perfectly
valid reason when it has evolved from the ideas of a lot of Very Smart People™.

> I understand that showing your email address in the UID makes it easier for
> people to find your key, the perceived advantage being that this makes it
> more likely you will receive encrypted mail. My contention is that the de
> facto standard of revealing email addresses in key UIDs could actually be
> mitigating *against* the use of encrypted mail, by discouraging people from
> publishing keys or even from using openPGP in the first place.

An /interesting/ thesis, However, to be taken seriously you need to back it up
with more than conjecture. There are plenty of obstacles to the widespread use
of encryption in the computing literature without grasping at straws to create 
more.

> There is a widespread perception (rightly or wrongly) that exposing your
> email address publicly on the internet will lead to that email address being
> spammed into oblivion. The new openPGP user is exhorted to create a key pair
> using their name and email address as the UID, and to upload this key to a
> server. That advice, coupled with the default configuration's enforcement of
> including an email address (or something that appears to be one) clearly has
> the potential to scare potential users from experimenting with openPGP in the
> first place.

Widespread perception? Indeed? Please quantify. There are over 2.8 million keys
on the SKS keyservers with an average of just under 350 new keys added every
day.[0] The "keyserver SPAM" discussion surfaces maybe three to four times per
year across three lists. Odds on users will get more SPAM from asking a question
on a public mailing list such as this one than they will from that attributable
to keyservers.

"(rightly or wrongly)" Or imaginary? Rather than trying to convince us of new
"obstacles" without providing any evidence, you may wish to review what the HCI
folks say are the obstacles: "Why Johnny Can't Encrypt"[1], "Why Johnny Still
Can't Encrypt"[2], "How to Make Secure Email Easier to Use"[3], and a personal
favorite, "Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted
E-Mail"[4].



>>> If their key lived at their own website or on an email responder, for
>>> example, you could still do this - except the note of the fingerprint and
>>> key-id would also need to contain a URL.
> 
>> In which case you're still hosting it publicly, so why not use the
>> keyservers?
> 
> Because by hosting it yourself, you have control over what signatures and
> UIDs appear on the published key. Or is that just an illusion?

Mostly Illusion. You only control the copy you publish or make available. You
have control over what signatures appear /until/ someone else has a copy of the
key. After that, you rely on their manners and ability to not make mistakes.

>>> OK OK, the post I was replying to when I started this stated "It is  also
>>> a good idea to send your key to the keyservers." I do not see  this
>>> statement as any kind of self-evident truth, yet I have been thoroughly
>>> taken to task for questioning it.
> 
>> This is not "taking you to task."  This is listening to your claims, and
>> giving strong arguments against them.
>
> Many of the replies I've read in this thread have that character. Others have
> tended more towards criticising me for holding a different opinion and/or
> dismissing anything I said. Maybe I'm just being over-sensitive, but I got
> the impression I had touched some raw nerves somewhere along the way.

Many of the points you argue in this thread have been exhaustively discussed on
the list. You could compare this to a novel reading of law taking on a mountain
of precedent. It takes more than just the presentation of a case to convince
this body.

I've seen errant ideas criticized, not any person. The only irritant for me was
a breach of email etiquette.

>> That said, it is broadly true that it's a good idea to send keys to the
>> keyserver network.  The reasons why have already been well-explained. Your
>> reasons why not are either unfounded or debunked.
> 
> The collective response on this thread has indeed debunked a few myths for
> me. The main issue I'll never be converted on is the potential privacy
> problem of publishing somebody else's key to the servers.

I t

Re: key question

[Paul Richard Ramer]

On Sat, 2010-02-27 at 19:21 +, MFPA wrote:
> There is a widespread perception (rightly or wrongly) that exposing
> your email address publicly on the internet will lead to that email
> address being spammed into oblivion. The new openPGP user is exhorted
> to create a key pair using their name and email address as the UID,
> and to upload this key to a server. That advice, coupled with the
> default configuration's enforcement of including an email address (or
> something that appears to be one) clearly has the potential to scare
> potential users from experimenting with openPGP in the first place.

GnuPG doesn't, at least as of 1.4.10, force you to include an e-mail
address in your user ID.  It merely requests an e-mail address, and you
can just press enter and ignore the request.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[John Clizbe]

This may be a dup - I think the original went out with the wrong From addr
MFPA wrote:
> Hi
> On Saturday 27 February 2010 at 6:11:29 AM, in 
> , Robert J. Hansen wrote:

>>> In any case, I've never seen a convincing argument *for* including  email
>>> addresses in the UID of a PGP key.

Nor have we seen compelling arguments for their omission as a general rule

>> First, the status quo doesn't need arguments in its favor.  The status quo
>> exists.  *Changing* the status quo is what requires arguments in its
>> favor.
> 
> I have always been taught to challenge the status quo. "Because that's the
> way we do it" is *never* a good reason to continue doing something in a
> particular way.

It is never a good reason when it is the sole justification. It's a perfectly
valid reason when it has evolved from the ideas of a lot of Very Smart People™.

> I understand that showing your email address in the UID makes it easier for
> people to find your key, the perceived advantage being that this makes it
> more likely you will receive encrypted mail. My contention is that the de
> facto standard of revealing email addresses in key UIDs could actually be
> mitigating *against* the use of encrypted mail, by discouraging people from
> publishing keys or even from using openPGP in the first place.

An /interesting/ thesis, However, to be taken seriously you need to back it up
with more than conjecture. There are plenty of obstacles to the widespread use
of encryption in the computing literature without grasping at straws to create 
more.

> There is a widespread perception (rightly or wrongly) that exposing your
> email address publicly on the internet will lead to that email address being
> spammed into oblivion. The new openPGP user is exhorted to create a key pair
> using their name and email address as the UID, and to upload this key to a
> server. That advice, coupled with the default configuration's enforcement of
> including an email address (or something that appears to be one) clearly has
> the potential to scare potential users from experimenting with openPGP in the
> first place.

Widespread perception? Indeed? Please quantify. There are over 2.8 million keys
on the SKS keyservers with an average of just under 350 new keys added every
day.[0] The "keyserver SPAM" discussion surfaces maybe three to four times per
year across three lists. Odds on users will get more SPAM from asking a question
on a public mailing list such as this one than they will from that attributable
to keyservers.

"(rightly or wrongly)" Or imaginary? Rather than trying to convince us of new
"obstacles" without providing any evidence, you may wish to review what the HCI
folks say are the obstacles: "Why Johnny Can't Encrypt"[1], "Why Johnny Still
Can't Encrypt"[2], "How to Make Secure Email Easier to Use"[3], and a personal
favorite, "Secrecy, Flagging, and Paranoia: Adoption Criteria in Encrypted
E-Mail"[4].



>>> If their key lived at their own website or on an email responder, for
>>> example, you could still do this - except the note of the fingerprint and
>>> key-id would also need to contain a URL.
> 
>> In which case you're still hosting it publicly, so why not use the
>> keyservers?
> 
> Because by hosting it yourself, you have control over what signatures and
> UIDs appear on the published key. Or is that just an illusion?

Mostly Illusion. You only control the copy you publish or make available. You
have control over what signatures appear /until/ someone else has a copy of the
key. After that, you rely on their manners and ability to not make mistakes.

>>> OK OK, the post I was replying to when I started this stated "It is  also
>>> a good idea to send your key to the keyservers." I do not see  this
>>> statement as any kind of self-evident truth, yet I have been thoroughly
>>> taken to task for questioning it.
> 
>> This is not "taking you to task."  This is listening to your claims, and
>> giving strong arguments against them.
>
> Many of the replies I've read in this thread have that character. Others have
> tended more towards criticising me for holding a different opinion and/or
> dismissing anything I said. Maybe I'm just being over-sensitive, but I got
> the impression I had touched some raw nerves somewhere along the way.

Many of the points you argue in this thread have been exhaustively discussed on
the list. You could compare this to a novel reading of law taking on a mountain
of precedent. It takes more than just the presentation of a case to convince
this body.

I've seen errant ideas criticized, not any person. The only irritant for me was
a breach of email etiquette.

>> That said, it is broadly true that it's a good idea to send keys to the
>> keyserver network.  The reasons why have already been well-explained. Your
>> reasons why not are either unfounded or debunked.
> 
> The collective response on this thread has indeed debunked a few myths for
> me. The main issue I'll never be converted on is the potenti

Fwd: Re: key question

[Grant Olson]

Doh!  Originally sent off list...  Maybe Robert got a psychic vibe...

On 2/27/2010 2:21 PM, MFPA wrote:
> 
> I don't want such a vote. Whether somebody chooses to include an email
> address in their UID is up to the individual. I have not seen anything
> that convinces me it is better for me to include one.
> 
> 

It sounds like you're using the software to do the opposite thing that
many people do.  I think digital signatures are utilized much more than
encrypted communication.  And digital signatures are about
authenticating to a real person, and not anonymity.

If you don't want to publish your email for the anonymity/privacy
reasons you've outlined, then you probably don't want to use your legal
name either.  And it looks like you don't.  Which is fine for encrypting
documents.  But it renders two key features of digital signatures
meaningless.  Authentication and Non-repudiation go out the window.  How
do I authenticate that an anonymous entity is really an anonymous
entity?  That doesn't make any sense.  How do I get into a dispute with
an anonymous entity about whether he really agreed to do X?  And
although it does prove message integrity, that, in and of itself,
doesn't mean much for an anonymous entity.

So a few examples to elaborate.  I'm going to use MFPA as the anonymous
user who doesn't have a real ID for clarity sake.  It's better than
"anonymous entity".  Just to be clear, I'm not really talking about you
or making any personal attacks in the examples.  You're just the generic
guy with the non-identifiable key.

Farfetched example.  An email from MFPA pops up on the list.  "My house
burnt down.  Lost my key.  Lost my rev certificate.  Here's my new
info."  Five minutes later, another email from MFPA.  "That dude
generated a fake key.  Keep using the old one.  The new one is bad!"  A
third email from MFPA.  "That last dude is lying.  Turns out he stole my
laptop before burning my house down."  Who do we trust?  Which key do we
use?  We have no way of knowing who the real MFPA is, because he was
anonymous to begin with.

How could I sign your key?  It sounds like you don't want anyone to sign
it anyway, plenty of other people want to sign keys and build the web of
trust.  I can't verify your key in any way.  You're anonymous.  There's
no way to prove you're MFPA.  So I can't sign your key.

Lets assume among your circle of friends, who know each other personally
in real life, you sign off on each others keys.  And I somehow know one
of your friends, and we sign each others keys.  To me, it's a
meaningless assertion for someone to claim that they've verified that
you're the real MFPA.  That doesn't mean anything to me because you're
anonymous to me.  It also doesn't mean anything if you've signed off on
someone's key.  What does it mean to me that MFPA vouched for someone
else's identity?  Another meaningless assertion.

I'm not really using OpenPGP encryption at all.  I may never need to
send an encrypted email.  None of my real-life friends, family,
co-workers use it.  Not Cuban, Iranian, or in the Falun Gong.  I use it
for two things, (1) to post on computer geek mailing lists, and (2) to
verify software packages.  For (1), I guess I'm not too concerned about
digital signatures.  The PGP Global Directory is good enough
authentication for me.  For (2), I actually am.  It'd be nice to have
the software packages signed by a validated key.  If people don't use
personally identifying information, the web of trust breaks.  The only
way for me to actually validate a key is to meet with the software
packager personally.

And I think many people fall into that camp.  Authentication is more
important to them than anonymity and encryption.





signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: OFF LIST

[MFPA]

Hi Charly


On Saturday 27 February 2010 at 1:29:22 PM, you wrote:



> I have also e-mailed Faramir directly, trying to have news.

Farimir has just posted on PGPNET that he is fine, his house resisted 
the quake, his family are OK. Phones down so he has been unable to 
contact some friends.


-- 
Best regards

MFPAmailto:expires2...@ymail.com

Reality is nothing but a collective hunch.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Re[2]: key question

[Robert J. Hansen]

On Feb 27, 2010, at 4:10 PM, Robert J. Hansen wrote:
> Keep it on the list, please, and not in private mail.

Oh, ack.  I completely misread the To- line, and didn't see the cc: to 
gnupg-users.  My error, and my apologies to MFPA.  :)


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Re[2]: key question

[Robert J. Hansen]

> And whist you have stated that you check first, you have advocated
> that it's OK not to. Somebody following your advice could land this
> hypothetical Cuban in a whole lot of trouble.

The hypothetical Cuban had a lot bigger problems the instant he shared his 
public key with people he shouldn't have trusted to keep it secret.

Keep it on the list, please, and not in private mail.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re[2]: key question

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Robert


On Saturday 27 February 2010 at 8:23:25 PM, you wrote:


> On Feb 27, 2010, at 3:02 PM, David Shaw wrote:


>> With regards to the second statement, you give a great reason
>> yourself a few paragraphs up: "If you live in Cuba and you're using
>> GnuPG, then you should not have your key on the servers and you
>> have a perfectly reasonable fear about people uploading your key
>> there". Is that not a good reason to request that a key stay off
>> the keyservers?

> I think it's a great example of a clear exception to a general rule.

And whist you have stated that you check first, you have advocated
that it's OK not to. Somebody following your advice could land this
hypothetical Cuban in a whole lot of trouble.


- --
Best regards

MFPAmailto:expires2...@ymail.com

Don't ask me, I'm making this up as I go!
-BEGIN PGP SIGNATURE-

iQCVAwUBS4mIuKipC46tDG5pAQqD9AQAs+WD9zZdoAg2H0brYrqFqzOq8jrqqtVP
3KXfJiHfBD37V95yK5J1APLUjVpjZ3hxmepxcNn1YBIVKZafEkejBZNKsKWhWOeZ
0y4vH0hJWN+zFhxfv2DJZ4aBvAWSJnWZHigoca71qkFxU4M05IWUG1Wwm8d7nzC2
0GwLiicbx2c=
=gl+x
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Saturday 27 February 2010 at 4:22:27 PM, in
, Robert J. Hansen wrote:



> His position seems to have shifted.

As the thread has progressed, the posts I'm replying to have shifted
from "It is a good idea to send your key to the keyservers," to an
assertion that it's also a good idea to publish other people's keys
whether they want them published or not.


> At some points he's said,

> "What's not to agree with in my statement that not
> everybody wants to put their keys on the keyservers?"

> I fully agree with this.  However, he also seems to be
> advocating the advice of "generally speaking, it's a
> good idea to put keys on the keyservers" be changed to
> "generally speaking, it's not a good idea to share
> public keys without the key owner's explicit
> permission."

> This is a pretty big change in the conventional wisdom.
> Before I'll sign on to that I'll have to see some
> strong reasoning, and I haven't.

>> It seems (and I could be utterly wrong), that MFPA is
>> saying "Not  everyone wants their key on the
>> keyservers, so please don't  automatically send other
>> people's keys there.  If the key owner wants the key
>> on the keyservers, he'll send it himself."

That is exactly what I am saying. Most peoples keys contain personal
contact details and the decision to place that information in the
public domain rests solely with the person whose details they are.



> MFPA has made it clear his objection applies to any
> kind of sharing of public keys without the owner's
> consent.  It's not limited to the keyserver network.
> He considers it the equivalent of passing on someone's
> home address to a complete stranger.  ("I would no more
> deliberately publish somebody's key without their
> consent than I would pass on their phone number or
> address.")

Pretty much, yes. Not forgetting the possible legal implications under
data protection legislation in the EU and other places.



> "the keyservers are generally a good idea, and
> generally speaking they should be used, and people
> should expect their public keys will wind up on them
> sooner or later, either through their direct action or
> through the accidents of others."

> It is not universally applicable advice, but I think
> that as far as general advice goes it's pretty good.

I don't think it is bad advice when put like that. Maybe the person
being advised could be pointed to a summary discussion of pros and
cons, and of alternatives to keyservers - but that would probably be
information overload.

It is definitely good advice to bear in mind that your key may well
end up on a keyserver whether you want it to or not. That will feed
into the decision of what information to include in your UIDs.

I find the attitude that it is OK to publicise somebody else's details
without consent abhorrent, and suggestive of a disregard for other
people's privacy.

Given the importance of personal privacy, it seems to me that it's too
easy to accidentally upload the wrong key to a server. I'm not sure if
anything could usefully be changed to address this; even if people
read confirmations before pressing "y" when using GnuPG, such mistakes
are all-too-easy in other packages and front-ends as well.


- --
Best regards

MFPAmailto:expires2...@ymail.com

The problem is not that we're paranoid;
it's that we're not paranoid enough.
-BEGIN PGP SIGNATURE-

iQCVAwUBS4mDJqipC46tDG5pAQoYzgP/WP6E+qDRzfdwTVCXrcvXgONsVvXhCAQ8
3FJVYb/TeoLVcm26J88IBQvhECsoI+4RBcMgRVBwXTn0KU8E5PUF+4Or5d3NpuNp
RkmuPPOlNUfj6xqMRkylm5pe9kYI8UvDnEGlEOy0XonDJ1Mfq/4aZHpJvy5NHmaK
P+aRJ+1cjaE=
=NiBO
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re[2]: key generation: email-address necessary?

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Martin


On Saturday 27 February 2010 at 10:50:13 AM, you wrote:



> that was my expectation as well. But what do the email clients do then?
> Do they say "no key available" or do the look for the name? What are
> your experiences?

I use The Bat! which matches on email address only. If there is more
than one match, earlier versions of The Bat! pick one to use whilst
later versions allow the user to choose. If there is no match, the
encryption fails. This can be overcome by creating a group in
gpg.conf, named as the email address and containing the key ID for
that email address.


- --
Best regards

MFPAmailto:expires2...@ymail.com

Change is inevitable except from a vending machine
-BEGIN PGP SIGNATURE-

iQCVAwUBS4mF6KipC46tDG5pAQrg3wQAq7tFOvu5NpAhVtrVIyfUjmwN1Sa6Cz8l
IMQMf/3mDlyih7iQ92mU6+JXT4HzDx3YHgWsfxgqPJio+qha1oVxiPIovFH5BD+w
rBbNDXzTe+UXEQa7Xn0rzQjCO2oHM5g4O/cwVoP12Qpi22sn0v9WSKf/KrA5sb7Z
U0tTBK1YJQo=
=yq0L
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[Robert J. Hansen]

On Feb 27, 2010, at 3:02 PM, David Shaw wrote:

> Much as the email headers do in your example.  If the mail is not encrypted, 
> the headers just show that it might be.  In practice, headers won't show much 
> as the majority of modern mail programs have the capability for encryption of 
> one sort or another, even without add-ons.  It's rarely exercised, of course.

Yes and no.  I think the presence of an Enigmail header, for instance, is 
probably more indicative of encrypted traffic than just someone's key being 
present on a server.  Still, this is kind of a side show.  What started this 
was MFPA's contention that just by having your key on the keyserver network you 
could be bringing yourself to the attention of government investigators.

When a murder victim is found, the police start looking for the murder weapon.  
They don't start by looking at all possible murder weapons and hope to find a 
murder victim nearby.  Likewise, if the police find encrypted traffic on a 
suspect's laptop they will begin to search for the originator of the traffic.  
They're not likely to start by rounding up the usual suspects found by 
harvesting the key server.

There are exceptions to this rule.  I mentioned Cuba, where possession of 
crypto is itself a crime (or was, last I heard: if there are any Cubans on the 
list, I would love to know if this is still true).  That said, exceptions to a 
rule are expected -- there are few rules so general they do not admit 
exceptions.

> 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.)

However, on the scale of conventional wisdom, where on one end there's "never 
get involved in a land war in Asia" and "never go against a Sicilian when death 
is on the line," [1] and on the other there's "the signatures on a key tell you 
a lot about a person", I think the conventional wisdom of "generally speaking, 
it's a good idea to put keys on the keyservers" is closer to the former 
category than the latter.  :)

Admittedly, I am no arbiter of what's conventional wisdom.  The preceding is 
just my own personal interpretation of what prevailing CW is.

[1] http://www.imdb.com/title/tt0093779/quotes

> With regards to the second statement, you give a great reason yourself a few 
> paragraphs up: "If you live in Cuba and you're using GnuPG, then you should 
> not have your key on the servers and you have a perfectly reasonable fear 
> about people uploading your key there".  Is that not a good reason to request 
> that a key stay off the keyservers?

I think it's a great example of a clear exception to a general rule.

> So you are saying "I do not do this".  And MFPA is saying "I think nobody 
> should do this" ?

Not really.  That's a side issue.

The real question is this:

"The status quo is that new users are routinely told, 'generally speaking, it 
is a good idea to upload your key to the keyservers.'  Does this need to 
change?"

> Where's the problem?

He says "yes and here's why," and I say, "your arguments do not appear sound, 
and here's why."


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[Robert J. Hansen]

On Feb 27, 2010, at 2:21 PM, MFPA wrote:
> I have always been taught to challenge the status quo. "Because that's
> the way we do it" is *never* a good reason to continue doing something
> in a particular way.

The status quo has something going for it: it works.  95% of all new ideas are 
awful and should be discarded.  New ideas are how the status quo changes for 
the better, but that doesn't mean we should throw out the status quo just 
because an idea comes along which happens to be new.

> My
> contention is that the de facto standard of revealing email addresses
> in key UIDs could actually be mitigating *against* the use of
> encrypted mail, by discouraging people from publishing keys or even
> from using openPGP in the first place.

It's an interesting idea, but I don't see any facts to back it up.  How many 
users are dissuaded?  Is this a major concern, or not a concern?  What does the 
published literature say about it?  And so on, and so on.

Speculation is great, but speculation isn't fact -- and we need to change the 
way we do things based on facts, not on speculations.  We can agree on facts, 
but our speculations will likely not overlap very much at all.

> That advice, coupled with the
> default configuration's enforcement of including an email address (or
> something that appears to be one) clearly has the potential to scare
> potential users from experimenting with openPGP in the first place.

The same way the shotgun in my closet clearly has the potential to be used as a 
murder weapon.

Potential != actuality.  All manner of potential things do not come to pass.  
Before we change the way we do business, I'd like to know that we're changing 
to address a real problem, not merely a potential problem where no one really 
knows if it's a real problem or not.

The world has enough interesting problems to solve without us having to go off 
chasing ghosts.

> Because you suggested in an earlier post in this thread that it was
> somehow acceptable to publish somebody's key to a server without their
> consent.

I don't think I said it was "acceptable."  I would find it to be in poor taste, 
myself, if it were done deliberately.  However, I don't think it would amount 
to a moral or ethical failing.

> Because by hosting it yourself, you have control over what signatures
> and UIDs appear on the published key. Or is that just an illusion?

Illusion.

Let's say that Joe downloads your key from the web page.  Joe then syncs his 
entire keyring with the keyserver.  (This is a feature in PGP; you can also do 
the same thing with GnuPG, if you don't mind getting a little crazy with awk 
and sed scripts.)  Your key then gets on the server, and... etc.  Maybe Joe is 
doing it deliberately.  Maybe he has a misconfigured installation.  Maybe he 
thinks he's doing you a favor.  Whatever.  The point is, the world is full of 
Joes, and sooner or later your key will wind up on the server.

Once you make any public release of your key, it is only a matter of time until 
that key winds up on the keyserver network.  You can either keep your public 
key very secret and only give it to people who have need-to-know and make them 
sign a nondisclosure agreement written in the blood of their children, or you 
can accept the fact that it will be put on the keyserver and take appropriate 
steps.

> The collective response on this thread has indeed debunked a few myths
> for me. The main issue I'll never be converted on is the potential
> privacy problem of publishing somebody else's key to the servers.

This is an argument from emotional conviction.  That doesn't mean it's invalid 
or inappropriate or that you shouldn't have this response -- don't get me 
wrong.  I like emotions; emotions are pretty cool things.  I just don't like 
arguing from emotional conviction, because I either share in the response or I 
don't.  If I do, then you don't need to say anything because I'm already on 
your side.  If I don't, then you don't need to say anything because you can't 
persuade me into having that particular emotional response.  I either have it 
or I don't.

But just like there's nothing you can say to *me*, there's nothing I can say to 
*you*.  The instant you say "I will never be converted!", well, okay: thanks 
for letting me know.  I won't try to persuade you, because you've made it clear 
you won't be persuaded.

> If I was able to show that, those who need/want such privacy would be
> making a poor job of trying to enforce it.

So the lack of evidence is, itself, evidence?  That sounds more like a 
conspiracy theory.

> I don't care how many users
> this affects. For me, what matters is that any key I encounter *could*
> relate to one of them.

This is an idealistic view of the world.  I like idealism.  I admire idealism.  
I just think it's impractical and destructive.

What you're saying here is, "even if the advice were sound for one million 
users, and destructive to the privacy of just one, I still would not c

Re: key question

[David Shaw]

On Feb 27, 2010, at 11:22 AM, Robert J. Hansen wrote:

> On 2/27/10 9:58 AM, David Shaw wrote:
>> Do you really mean to suggest that a US authority getting email 
>> headers - even without a warrant - is easier than typing a name into 
>> a search box on a keyserver?
> 
> No.  You're right, that's clearly easier.  However, that only tells you
> whether someone has the technical capability to use encryption -- much
> the same way that a shotgun in my closet tells you I have the technical
> capability to commit murder.

Much as the email headers do in your example.  If the mail is not encrypted, 
the headers just show that it might be.  In practice, headers won't show much 
as the majority of modern mail programs have the capability for encryption of 
one sort or another, even without add-ons.  It's rarely exercised, of course.

> As a result, the possibility of law-enforcement officers checking the
> keyserver network doesn't seem to be a strong argument against the use
> of the keyserver network.
> 
> The major exception is if you live in a jurisdiction where possession of
> crypto is itself a criminal offense.  If you live in Cuba and you're
> using GnuPG, then you should not have your key on the servers and you
> have a perfectly reasonable fear about people uploading your key there.
> 
>> In any event, Rob, could you do me a huge favor and clarify what 
>> statement you are trying to make here?  Jumping into a mail thread 
>> late is always fraught with misunderstanding, but, I've re-skimmed 
>> the thread, and I'm honestly still not sure what you're trying to 
>> say.
> 
> His position seems to have shifted.  At some points he's said,
> 
> "What's not to agree with in my statement that not everybody wants to
> put their keys on the keyservers?"
> 
> I fully agree with this.  However, he also seems to be advocating the
> advice of "generally speaking, it's a good idea to put keys on the
> keyservers" be changed to "generally speaking, it's not a good idea to
> share public keys without the key owner's explicit permission."
> 
> This is a pretty big change in the conventional wisdom.  Before I'll
> sign on to that I'll have to see some strong reasoning, and I haven't.

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.  If you want encrypted mail, putting your key on a 
keyserver is very helpful in reaching that goal. The word "generally" takes 
care of the exceptions (as there always exceptions for one reason or another).  
So basically, yes, if you're using OpenPGP, keyservers are great.

With regards to the second statement, you give a great reason yourself a few 
paragraphs up: "If you live in Cuba and you're using GnuPG, then you should not 
have your key on the servers and you have a perfectly reasonable fear about 
people uploading your key there".  Is that not a good reason to request that a 
key stay off the keyservers?  I don't find the behavior *behind* this reason 
very good, as if someone lived in a place where encryption was banned, they'd 
be foolish and naive to think that their key would stay off the keyservers 
merely because they requested it - one accident, and it's published, and no way 
to withdraw it.  People who live in places where encryption is illegal need to 
do a lot more than simply not send their keys to a keyserver if they want to 
remain safe.

Personally, I don't find most don't-publish arguments (spam, traffic analysis, 
etc) compelling, and I correspondingly do send my key to the keyservers (in my 
case, it would be particularly silly not to).  However, I never send anything 
to the keyservers (or publish otherwise) if it isn't mine.  I don't know what 
their situation is, and it's not up to me to decide it for them.  Even if I did 
know their situation, as in the Cuba example above, and disagreed with them on 
how to handle their key, it still is not my key, and not my decision to make. I 
don't know if that makes it conventional wisdom, but I have acted that way 
since I became involved in the OpenPGP world many years ago.  Whether it's wise 
or not, I'd at least hope it's common politeness.

Keys ending up on keyservers contrary to the desires of the key owner has been 
a problem for a long time.  Note the addition of the no-modify flag when 
OpenPGP was first published as an RFC in 1998.  That was added after experience 
with PGP 2.  The whole point of that flag is to only allow the owner to publish 
their key.  Similarly, note that the PGP Global Directory only allows key 
uploads from the key owner, avoiding this problem.  The earlier PGP 
"certserver" had the capability, though I don't believe it was always turned 
on.  Clearly this is enough of a problem that work was done to avoid it.

> For myself, I do not send keys up to servers without first checking it
> with the 

Re: key question

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Saturday 27 February 2010 at 6:11:29 AM, in
, Robert J. Hansen wrote:



> There is a perceived need for $150 bowls of soup, as
> evidenced by dozens of high-priced gourmet restaurants
> in major cities.  The existence of a market for a
> service is not evidence that the service is generally
> useful or needed.

Point taken.



>> In any case, I've never seen a convincing argument
>> *for* including  email addresses in the UID of a PGP
>> key.

> First, the status quo doesn't need arguments in its
> favor.  The status quo exists.  *Changing* the status
> quo is what requires arguments in its favor.

I have always been taught to challenge the status quo. "Because that's
the way we do it" is *never* a good reason to continue doing something
in a particular way.

I understand that showing your email address in the UID makes it
easier for people to find your key, the perceived advantage being that
this makes it more likely you will receive encrypted mail. My
contention is that the de facto standard of revealing email addresses
in key UIDs could actually be mitigating *against* the use of
encrypted mail, by discouraging people from publishing keys or even
from using openPGP in the first place.

There is a widespread perception (rightly or wrongly) that exposing
your email address publicly on the internet will lead to that email
address being spammed into oblivion. The new openPGP user is exhorted
to create a key pair using their name and email address as the UID,
and to upload this key to a server. That advice, coupled with the
default configuration's enforcement of including an email address (or
something that appears to be one) clearly has the potential to scare
potential users from experimenting with openPGP in the first place.



> Second, then you don't have to include it in yours.
> Why are you bringing this up?

Because you suggested in an earlier post in this thread that it was
somehow acceptable to publish somebody's key to a server without their
consent. To me, wantonly publishing other people's contact details
appears contrary to the desire to protect personal privacy.



> I don't care what your
> UID is, and I don't want you to have a vote in whether
> I put an email address in mine.

I don't want such a vote. Whether somebody chooses to include an email
address in their UID is up to the individual. I have not seen anything
that convinces me it is better for me to include one.



>> If their key lived at their own website or on an email
>> responder, for example, you could still do this -
>> except the note of the fingerprint and key-id would
>> also need to contain a URL.

> In which case you're still hosting it publicly, so why
> not use the keyservers?

Because by hosting it yourself, you have control over what signatures
and UIDs appear on the published key. Or is that just an illusion?



>> OK OK, the post I was replying to when I started this
>> stated "It is  also a good idea to send your key to
>> the keyservers." I do not see  this statement as any
>> kind of self-evident truth, yet I have been
>> thoroughly taken to task for questioning it.

> This is not "taking you to task."  This is listening to
> your claims, and giving strong arguments against them.

Many of the replies I've read in this thread have that character.
Others have tended more towards criticising me for holding a different
opinion and/or dismissing anything I said. Maybe I'm just being
over-sensitive, but I got the impression I had touched some raw nerves
somewhere along the way.



> That said, it is broadly true that it's a good idea to
> send keys to the keyserver network.  The reasons why
> have already been well-explained. Your reasons why not
> are either unfounded or debunked.

The collective response on this thread has indeed debunked a few myths
for me. The main issue I'll never be converted on is the potential
privacy problem of publishing somebody else's key to the servers.



> In your voluminous defense of privacy rights, you've
> not given any numbers for what fraction of users need
> or want to keep their public keys private.  If you're
> arguing that the "good idea" we've advocated is not a
> good idea, you need to show there are substantial
> numbers of users who will be negatively impacted.  You
> haven't.

If I was able to show that, those who need/want such privacy would be
making a poor job of trying to enforce it. I don't care how many users
this affects. For me, what matters is that any key I encounter *could*
relate to one of them.

Whoever's details may on a key (or in the body of an email, or
anywhere else), I have no business publishing them.



> You've talked about the danger of reputation being
> slandered by implication of association: but as David
> Shaw has pointed out, if someone wants to do that there
> are much easier ways to do it than with keys.

True. I only mentioned it because a contact experienced business
problems as a res

Re: key generation: email-address necessary?

[Doug Barton]

On 02/26/10 10:34, Martin Bretschneider wrote:
> Hi,
> 
> I want to recreate my GnuPG keys. My question is if I can omit the email 
> address? Since I do not want my email addresses to appear on the 
> keyservers because of spammers and so on. 

1. It's been repeated many times on the list that those who have
investigated the issue have determined that the amount of spam to
addresses harvested from keyservers is negligible at worst.

2. You're far more likely to get spam to an address by using it to post
to a public mailing list.

3. The whole idea of taking any kind of steps to hide your address from
spammers has been overtaken by events. They will get your address. They
will send you spam. That's just how the world works now, and pretending
that you can do anything about it by "hiding" your e-mail address is
just foolishness.

4. The proper place to deal with spam is on the receiving end. First
your mail server, and second your MUA. "Smart clients" like Thunderbird
have built in spam fighting. Unix command line tools have access to
things like bogofilter.

5. And finally something germane to the list, the amount of trouble you
will cause for yourself and others by omitting your e-mail address will
far exceed any benefit you may get from "hiding" your address from the
spammers.


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/


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key generation: email-address necessary?

[Ingo Klöcker]

On Saturday 27 February 2010, Martin Bretschneider wrote:
> Am Samstag 27 Februar 2010 schrieb Laurent Jumet:
> 
> Hi Laurent,
> 
> > Martin Bretschneider  wrote:
> > > I want to recreate my GnuPG keys. My question is if I can omit
> > > the email address? Since I do not want my email addresses to
> > > appear on the keyservers because of spammers and so on. I only
> > > want to put my name and maybe my toplevel domain in the comment
> > > field.
> > > Is the some kind of problem with this behavoir? Can email clients
> > > find out what key to use if there is no known email address?
> > > What do you think?
> > > 
> > You can use whatever you want to identify your key.
> > But in some cases, mail programs expect to find your e-mail.
> 
> that was my expectation as well. But what do the email clients do
> then? Do they say "no key available" or do the look for the name?
> What are your experiences?

When you want to send an encrypted messages with KMail/Kontact then 
KMail/Kontact first checks whether there is a key specified in the 
address book. If the address book entry does not specify a key then 
KMail/Kontact tries to look up the keys based on the email addresses. If 
it does not find keys for all recipients then it shows a dialog were you 
can specify which keys to use.


Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key generation: email-address necessary?

[Laurent Jumet]

Hello Martin !

Martin Bretschneider  wrote:

>> It's not easy to answer that question, as it depends on your own
>>  system. When you read a signed message, GPG provides a way to call
>>  automatically the sender's public key on your designed servers, when
>>  it doesn't find it in your PubRing; it goes on the Net, retrieves
>>  the key, incorporates it in your KeyRing and than verifyes the
>>  signature on the message. This process can abort if ID's doesn't
>>  match.

> Let's break down the problem: A and B have public keys on some
> keyserver. A has no email address in his public key, B does.

I didn't test all events.
I only noticed that in some cases, the e-mailer fails, or GPG fails, in 
getting the right key.
Anyway, if this happens, you can examine manually the message and get 
manually the key.

-- 
Laurent Jumet
  KeyID: 0xCFAF704C

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key generation: email-address necessary?

[Grant Olson]

On 2/27/2010 5:50 AM, Martin Bretschneider wrote:
> 
> that was my expectation as well. But what do the email clients do then? 
> Do they say "no key available" or do the look for the name? What are 
> your experiences?
> 
> TIA  Martin

Enigmail will lookup the key by key ID (0xDEADBEEF) when you tell it to
retrieve the public key.  So that will work.  When you send someone an
encrypted email and it doesn't match an email address from the key-ring,
it will prompt you to select which key you want to use for that user for
encryption.  Pretty painless.

Not sure what other clients do.



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[Robert J. Hansen]

On 2/27/10 9:58 AM, David Shaw wrote:
> Do you really mean to suggest that a US authority getting email 
> headers - even without a warrant - is easier than typing a name into 
> a search box on a keyserver?

No.  You're right, that's clearly easier.  However, that only tells you
whether someone has the technical capability to use encryption -- much
the same way that a shotgun in my closet tells you I have the technical
capability to commit murder.

Generally speaking, law-enforcement is much more interested in whether a
capability is exercised than if a capability exists.  Checking the
keyserver network reveals the capability; it doesn't reveal if it's been
exercised.

As a result, the possibility of law-enforcement officers checking the
keyserver network doesn't seem to be a strong argument against the use
of the keyserver network.

The major exception is if you live in a jurisdiction where possession of
crypto is itself a criminal offense.  If you live in Cuba and you're
using GnuPG, then you should not have your key on the servers and you
have a perfectly reasonable fear about people uploading your key there.

> In any event, Rob, could you do me a huge favor and clarify what 
> statement you are trying to make here?  Jumping into a mail thread 
> late is always fraught with misunderstanding, but, I've re-skimmed 
> the thread, and I'm honestly still not sure what you're trying to 
> say.

His position seems to have shifted.  At some points he's said,

"What's not to agree with in my statement that not everybody wants to
put their keys on the keyservers?"

I fully agree with this.  However, he also seems to be advocating the
advice of "generally speaking, it's a good idea to put keys on the
keyservers" be changed to "generally speaking, it's not a good idea to
share public keys without the key owner's explicit permission."

This is a pretty big change in the conventional wisdom.  Before I'll
sign on to that I'll have to see some strong reasoning, and I haven't.

> It seems (and I could be utterly wrong), that MFPA is saying "Not 
> everyone wants their key on the keyservers, so please don't 
> automatically send other people's keys there.  If the key owner
> wants the key on the keyservers, he'll send it himself."

MFPA has made it clear his objection applies to any kind of sharing of
public keys without the owner's consent.  It's not limited to the
keyserver network.  He considers it the equivalent of passing on
someone's home address to a complete stranger.  ("I would no more
deliberately publish somebody's key without their consent than I would
pass on their phone number or address.")

For myself, I do not send keys up to servers without first checking it
with the recipient.  This seems like good manners to me.  However, I
don't view it as mandatory and I don't think we should view it as the
appalling breach of morality that MFPA seems to.

> "This is not based on good logic as I see it, and therefore
> (something)."   What's the "(something)"?

That the status quo ante is upheld.  Status quo ante being, "the
keyservers are generally a good idea, and generally speaking they should
be used, and people should expect their public keys will wind up on them
sooner or later, either through their direct action or through the
accidents of others."

It is not universally applicable advice, but I think that as far as
general advice goes it's pretty good.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key generation: email-address necessary?

[Martin Bretschneider]

Am Samstag 27 Februar 2010 schrieb Laurent Jumet:
> Hello Martin !
> 
> Martin Bretschneider  wrote:
> >> You can use whatever you want to identify your key.
> >> But in some cases, mail programs expect to find your e-mail.
> >
> > that was my expectation as well. But what do the email clients do
> > then? Do they say "no key available" or do the look for the name?
> > What are your experiences?
> 
> They can call another key with a similar name. :-)
> 
> It's not easy to answer that question, as it depends on your own
>  system. When you read a signed message, GPG provides a way to call
>  automatically the sender's public key on your designed servers, when
>  it doesn't find it in your PubRing; it goes on the Net, retrieves
>  the key, incorporates it in your KeyRing and than verifyes the
>  signature on the message. This process can abort if ID's doesn't
>  match.

I know that it depends on the system; this is why I wrote the email 
since I think that here are people that know GnuPG in combination with 
several email clients...

Let's break down the problem: A and B have public keys on some 
keyserver. A has no email address in his public key, B does.

AFAIK there are these four use cases concering emails and OpenPGP:

1: A sends a signed email to B. 
2: A sends a (signed and) encrypted email to B. 
3: B sends a signed email to A. 
4: B sends a (signed and) encrypted email to A. 

Use case 1 and 2 should be no problem. Based on the key information 
saved in the signature the email client of B should get the public key 
of A. The email adress does not matter.

Use case 3 should also be no problem since it does not deals with A 
public key.

Use case 4 is the problematic one, B's email client does not know 
anything about A. B's email client could search for A fore- and surename 
on a keyserver...

What do you think?

TIA  Martin



-- 
http://www.bretschneidernet.de/OpenPGP-key: 0x4EA52583
   _o)(o_ Sallust:
 -./\\//\.-  Nam idem velle atque idem
  _\_VV_/_  nolle, ea demum firma amicitia est.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[David Shaw]

On Feb 26, 2010, at 12:04 PM, Robert J. Hansen wrote:

>> In some cases, the authorities knowing an individual used encryption
>> could be a problem.
> 
> Why?  Because they have a key on the keyservers?  If this is what you're
> worried about, rest easy: there are so many easier ways to learn whether
> someone uses encrypted email that I can't imagine competent
> law-enforcement searching the keyservers.
> 
> For instance, in the United States the authorities can get your email
> headers without a warrant.  That means to, from, subject, routing
> information, and all the kluges.  Check the kluges on this email and I'm
> pretty sure you'll see kluges related to Enigmail.  Presto, at that
> point people know I'm using a crypto-aware MTA.

Do you really mean to suggest that a US authority getting email headers - even 
without a warrant - is easier than typing a name into a search box on a 
keyserver?  No question that the authority *can* get such headers, but I 
question the "easier".  Have you read the various (leaked) guides the ISPs have 
for delivery of such materials?  They are fascinating, but in no way speedy.  
I'd expect a truly competent law-enforcement agent would get both - order the 
requested material from the ISP, and while he's waiting for delivery, take the 
20 seconds to search a keyserver.  (Of course, all this assumes that we're 
presuming guilt-by-encryption, or at least suspicion-by-encryption, which I 
don't really buy in any event).

In any event, Rob, could you do me a huge favor and clarify what statement you 
are trying to make here?  Jumping into a mail thread late is always fraught 
with misunderstanding, but, I've re-skimmed the thread, and I'm honestly still 
not sure what you're trying to say.

It seems (and I could be utterly wrong), that MFPA is saying "Not everyone 
wants their key on the keyservers, so please don't automatically send other 
people's keys there.  If the key owner wants the key on the keyservers, he'll 
send it himself."  You seem to be saying "This is not based on good logic as I 
see it, and therefore  (something)."   What's the "(something)"?  That you 
reserve the right to send other people's keys to the keyserver?  That it's 
foolish to request that other people don't send them?  Something else?  Or 
perhaps I mischaracterize both your and MFPA's positions.

What am I missing here?

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key generation: email-address necessary?

[Laurent Jumet]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


Hello Martin !

Martin Bretschneider  wrote:

>> You can use whatever you want to identify your key.
>> But in some cases, mail programs expect to find your e-mail.

> that was my expectation as well. But what do the email clients do then?
> Do they say "no key available" or do the look for the name? What are
> your experiences?

They can call another key with a similar name. :-)

It's not easy to answer that question, as it depends on your own system.
When you read a signed message, GPG provides a way to call automatically 
the sender's public key on your designed servers, when it doesn't find it in 
your PubRing; it goes on the Net, retrieves the key, incorporates it in your 
KeyRing and than verifyes the signature on the message. This process can abort 
if ID's doesn't match.

- -- 
Laurent Jumet
  KeyID: 0xCFAF704C
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)

iHEEAREDADEFAkuJLJoqGGh0dHA6Ly93d3cucG9pbnRkZWNoYXQubmV0LzB4Q0ZB
RjcwNEMuYXNjAAoJEPUdbaDPr3BMRQgAnRkeHmnE/EI3kHwqWvgK7x8qN3j9AJsE
LM/iV7sUasdYum08JlMDg7C+rA==
=TRjg
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

OT: key question

[Jerry]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 27 Feb 2010 08:24:07 -0500
John W. Moore III  articulated:

> UAV & Missile Operators don't need to know what the message said; just
> where You are at the time it is Sent.  Radio transmissions are
> targeted using "Huff-Duff" & GPS; Email is 'targeted' from the
> kludges.  True enemies in 'hot combat' don't care what You're saying;
> only that You never 'speak' again.  ♂

I spent a great deal of time with HF/DF and its aerial variants. Fun
but boring. However, the sender is usually not the target of said
search, but rather the recipient. Locating the location of an enemy
combatant when the transmission is CQ is a whole new ball game.

- -- 
Jerry
ges...@yahoo.com

|===
|===
|===
|===
|

I kissed my first girl and smoked my first cigarette on the same day.
I haven't had time for tobacco since.

Arturo Toscanini

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)

iQEcBAEBAgAGBQJLiSuKAAoJEGnxpuiKsj5SMD0H/jdLjbvEImszwpR5n5zNz+hL
A5SFgrmTMD5Q0RUk4G6gEo8z+lxSWyJ1V0qTMFs/fPM12yrxSgVjq0BWHdzhO9X7
66RM6p2vBC8FusqXUh5J5gR8RqZNyoUL/hwp2dXtFf9ALXdw891q0uN2PkrsyBCT
GXVfYQaCVzW3qHqLGGp/uPzVrZBHIMhdRl+qLJT7h0sN3LTTLSC+yTKpM5IpaReV
gG1Q7tRvaxv4WpJZiMELuRd51sgU5NFc1TUP5vAVnK6RmXSMKNFffu3eUFEIotjM
ReprZvShopBmnymiqCtWDFG8pMxUd3WyXR2gpPT+hyuIA+QswMohoCVA8fHMUWY=
=0L+o
-END PGP SIGNATURE-
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

OFF LIST

[Charly Avital]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

news of the 8.8, or 8.3 earthquake that has stricken Chile have been
posted in many on-line dailies.

I have tried unsuccessfully to access a few portals in Chile (e.g. White
Pages, the dailies) they seem to be down.

I have also tried unsuccessfully to phone to some very close friends who
live in Chile, not in the affected areas.

I have also e-mailed Faramir directly, trying to have news.

It is probable that the Telecom infrastructure that has not been
affected by the earthquake is swamped with access attempts.

I apologize for this intrusion, and thank in advance any information
that subscribers to this list may have on the situation in the capital
(Santiago), and in coastal resorts like Viña del Mar, Cachagua,
Algarrobo (it's summer time in Chile now).

Charly

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: GnuPG for Privacy
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJLiR4wAAoJEM3GMi2FW4PveLAH/iqi2n4gOh33zkrLgdSoH0pC
iVuOLlAlt00LcD7X3FnP6naLsFov/Lvv/CGYqedYieOl9lHJbJjY7m3IOq04unn4
3yhcGrZB+FjLw5CWHx+FxhI7Lvl4uUChPWiYrBqaLqJMXFxLAKQpys1DqyijzfCx
ecNVbNe8PQmjg6azLJLnL0C26nVLxSI3tvgsXRHr/oDrBPT394il4tWFItch2+uO
a1YEIzdH5q66aqN3dLURtoxk2iduKtrkelJIC0SddzH27DgIarxwO53ay8KhMIsw
KcfbyeFfShmnDOJsJhRp9wYeFSvJw6h6woE+mlsJy0YfsQEf5w0YmSGKZBdnhAE=
=OdLZ
-END PGP SIGNATURE-


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[John W. Moore III]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jerry wrote:

> Maybe not totally apropos to this discussion; however, I worked in
> "traffic analysis" for several years. If given enough leeway, you would
> be amazed at the information you can gather about an individual, and at
> its astonishing accuracy rate.
> 
> Just listening on various mail forums, I have been able to learn more
> about certain individuals than they would believe possible, or want
> known. Its all in knowing (and having the proper equipment and
> authority) in where to look.

UAV & Missile Operators don't need to know what the message said; just
where You are at the time it is Sent.  Radio transmissions are targeted
using "Huff-Duff" & GPS; Email is 'targeted' from the kludges.  True
enemies in 'hot combat' don't care what You're saying; only that You
never 'speak' again.  ♂

JOHN ;)
Timestamp: Saturday 27 Feb 2010, 08:23  --500 (Eastern Standard Time)
- -- 
"There are two kinds of people, those who do the work and those who take
the credit. Try to be in the first group; there is less competition there."
- --Indira Ghandi
-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

iQEcBAEBCgAGBQJLiRz1AAoJEBCGy9eAtCsPTrMIAKF3pduOatVIePKgJxkKKAR7
HymACsEHjfs5gkgXzRcbqpHEtyqGy1TiAoJjAGM6FWVvo7SFvI5yJ2rojIceuv5d
uAaUDc6sx7bAgNTFZ+GZJPYBy4kxb6mLbDmutvhChXPaIxPEt+SFhBqqCbD7DICK
iXIBpYeNWBWL+w12g6uWGLVF5kgM3IwwSn5VPxbRPyv9uvLng5tAbib+wlUhY+ln
DcVihZv3PMHeRqeMS2nqjURlZh4FeLUZoqc7ck3j0oCM8xIG38Aa2Ob7SJdqIXyq
rGd3nxrTtUconL8x9Sdd/nZSTar/AuWTdEhgOWZX/eC6i6qUGpOBRXRo5qSy1SU=
=0q7a
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key question

[Jerry]

On Fri, 26 Feb 2010 12:04:36 -0500
Robert J. Hansen  articulated:

> Investigators also don't develop very many leads based on "gee, this
> person uses crypto."  Many more leads are developed based on kludge
> investigation -- what security geeks call "traffic analysis."  If they
> nab a child pornographer and discover that you always emailed him
> between one and three days before the child pornographer uploaded a
> new set of images, well... that's the kind of interesting coincidence
> which will start a federal investigation.  The fact you have a crypto
> key, not so much.

Maybe not totally apropos to this discussion; however, I worked in
"traffic analysis" for several years. If given enough leeway, you would
be amazed at the information you can gather about an individual, and at
its astonishing accuracy rate.

Just listening on various mail forums, I have been able to learn more
about certain individuals than they would believe possible, or want
known. Its all in knowing (and having the proper equipment and
authority) in where to look.

-- 
Jerry
ges...@yahoo.com

|===
|===
|===
|===
|



tomorrow you may no longer feel guilty.


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key generation: email-address necessary?

[Martin Bretschneider]

Am Samstag 27 Februar 2010 schrieb Laurent Jumet:

Hi Laurent,

> Martin Bretschneider  wrote:
> > I want to recreate my GnuPG keys. My question is if I can omit the
> > email address? Since I do not want my email addresses to appear on
> > the keyservers because of spammers and so on. I only want to put my
> > name and maybe my toplevel domain in the comment field.
> > Is the some kind of problem with this behavoir? Can email clients
> > find out what key to use if there is no known email address?
> > What do you think?
> 
> You can use whatever you want to identify your key.
> But in some cases, mail programs expect to find your e-mail.

that was my expectation as well. But what do the email clients do then? 
Do they say "no key available" or do the look for the name? What are 
your experiences?

TIA  Martin
-- 
http://www.bretschneidernet.de/OpenPGP-key: 0x4EA52583
 (o__o)  Ernest Hemingway:
 //\/\\I like to listen. I have learned a great deal
 V_/\_V from listening carefully. Most people never listen.

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: key generation: email-address necessary?

[Laurent Jumet]

Hello Martin !

Martin Bretschneider  wrote:

> I want to recreate my GnuPG keys. My question is if I can omit the email
> address? Since I do not want my email addresses to appear on the
> keyservers because of spammers and so on. I only want to put my name and
> maybe my toplevel domain in the comment field.
> Is the some kind of problem with this behavoir? Can email clients find
> out what key to use if there is no known email address?
> What do you think?

You can use whatever you want to identify your key.
But in some cases, mail programs expect to find your e-mail.

-- 
Laurent Jumet
  KeyID: 0xCFAF704C

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users