Circumvention Tech Summit in Valencia

[Hans of Guardian]

Are any GnuPG dev people at the Circumvention Tech Summit in Valencia, that is 
now until Saturaday?  I'm arriving today. It could be useful to have a little 
GnuPG chat in person.

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

Re: Circumvention Tech Summit in Valencia

[Robert J. Hansen]

> Are any GnuPG dev people at the Circumvention Tech Summit in
> Valencia, that is now until Saturaday?  I'm arriving today. It could
> be useful to have a little GnuPG chat in person.

Daniel Kahn Gillmor and I are both here.  (And in fact, we met briefly,
and much to the surprise of many people here but not to either dkg or
myself, there was mutual respect, goodwill, and a stunning lack of
bloodshed.)  :)

Admittedly, "the GnuPG dev people" is really a one-element list
containing Werner.  But there are certainly people active in the GnuPG
community here.

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

Re: Circumvention Tech Summit in Valencia

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/03/2015 12:51 PM, Robert J. Hansen wrote:
>> Are any GnuPG dev people at the Circumvention Tech Summit in 
>> Valencia, that is now until Saturaday?  I'm arriving today. It
>> could be useful to have a little GnuPG chat in person.
> 
> Daniel Kahn Gillmor and I are both here.  (And in fact, we met
> briefly, and much to the surprise of many people here but not to
> either dkg or myself, there was mutual respect, goodwill, and a
> stunning lack of bloodshed.)  :)
> 

Hope you guys have a great time! (and remember to sign each other's
OpenPGP keys) :)


- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Nosce te ipsum!
Know thyself!
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU9ao0AAoJEP7VAChXwav6pAwIAKEN1XVB/PpHe/L3FVsurCZi
BMDJrk7gszoIRzu8xJ+2wqUgmStdE1IZ/owQHZnBsF+PSF+OA0C0cfPy1ibCPj3Z
K2GjayAx923SmaPsdaCnhqU/gn6hfeQsEYrBP5HXsa9KPMmFukW88SibxRNl5QAF
WxRjKXS2aMNOxh+96xixgAynLeu72Mgdfogth2G8Z1daM6503t7fYtsIFjBITH9X
yKjq1ItuNi8SvK7mimJWFfY+ngh/NSB5SKFHP0YpABI6vRihr7SgTJ8/Gwqj1Exq
11WMMkk36WIO6uRmpdBn5aqseniCEnNyUklP4Uwfgqxe6LDxgtklpnPsOH+MkVY=
=Z2uc
-END PGP SIGNATURE-

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

Fwd: Re: German ct magazine postulates death of pgp encryption

[Stephan Beck]

Hi Peter,

as your message hasn't reached the list inspite of being addressed to it, I
resend it.

Thanks

Stephan


 Weitergeleitete Nachricht 
Betreff: Re: German ct magazine postulates death of pgp encryption
Datum: Mon, 02 Mar 2015 18:53:57 +0100
Von: Peter Lebbing 
An: Stephan Beck , gnupg-users@gnupg.org

On 02/03/15 11:35, Stephan Beck wrote:
> Sticking to that "perfect position argument", in what kind of position are 
> (would be) the people that control (packaging of) your distro? (Just
> curious.)

I think they basically completely control my system. For individual Debian
Developers, it might need some ingenuity to get something sneaky on my
computer, since they generally only provide source, and the binaries are built
on the Debian infrastructure. Mind you, I say they need some ingenuity, that
is a far shot from "it's difficult". But the keys that the package manager
checks? If you have those, and can get my package manager to download your
stuff, it's trivial to change any file, any binary, any program on my computer.

It has occured to me that I probably could simply local-sign and fully trust
all OpenPGP keys of Debian Developers, since if the holder of said key wanted,
they could simply hardwire my GnuPG installation to effectively do the same
without my consent. But still, I haven't done it :).

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 







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

Re: Fwd: Re: German ct magazine postulates death of pgp encryption

[Ville Määttä]

On 03.03.15 14:54, Stephan Beck wrote:
> as your message hasn't reached the list inspite of being addressed to it

It did :).

-- 
Ville



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

Re: Fwd: Re: German ct magazine postulates death of pgp encryption

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/03/2015 01:54 PM, Stephan Beck wrote:
> Hi Peter,
> 
> as your message hasn't reached the list inspite of being addressed
> to it, I resend it.


Fwiw, it reached the list just fine:
http://lists.gnupg.org/pipermail/gnupg-users/2015-March/052931.html
- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Audaces fortuna iuvat
Fortune favors the brave
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU9bBFAAoJEP7VAChXwav67NgIAI5R8vDx6cH/X7mtOVz3MdFi
9gT59pDxc+PD3ru3er0gF7k6Y0SGqRBHC9wparTyw/IuVIleziuQPVtMKqAU/sz5
htq9lsjVwRcLtzqSzjAOpF811yx2hpwxz7V5OrXkYinpXx6orfZVFCFSz143lVLX
Kv6a96rsGVbOrEMrepHbCkqzayX1qpj+IHAmO+jKHUXeICporhky2VTTQKQ488Sb
Id1xmEznig/9kUDBmqzGtEQPiNYGXh7Z3X9SWrdT7168ZiT4StnJeGzPjP7W+9gt
pPubbh4R2GKX5tAeYxJfSN+6eHNrOwLtwimHI/SP/PWPzmtxpcMXGtbtkqCReuE=
=wuAX
-END PGP SIGNATURE-

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

Re: Decrypting PGP/MIME on the command line

[Brian Minton]

Mailpile may be useful.  https://mailpile.is

It lets you scan in a bunch of messages, and decrypt them, and indexes
them, keeping the index and message store encrypted.  It has command
line as well as a gui.

On Sun, Mar 1, 2015 at 9:32 AM, René Puls  wrote:
> Hi,
>
> is there a command line utility that takes a PGP/MIME encrypted message
> (a plain RFC 2822 text file) and outputs an unencrypted copy? The
> secret key is available and GnuPG is configured correctly. It is okay
> if the process is somewhat lossy; signatures or attachments do not need
> to be preserved, although I would not mind that either. :-)
>
> Background: I would like to decrypt e-mails permanently for archiving
> and searching, and run this utility over hundreds of e-mails in a
> single batch.
>
> Alternatively, if there is a way to permanently decrypt an e-mail in
> Claws Mail, that would help me as well. It seems that Enigmail has such
> a feature[1] (or will have it soon), but I have not found anything
> similar for Claws Mail and would prefer a general-purpose utility which
> I can just run as a filter, independent of my e-mail client.
>
> René
>
> [1] http://sourceforge.net/p/enigmail/bugs/1/
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

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

Re: Fwd: Re: German ct magazine postulates death of pgp encryption

[Stephan Beck]

Am 03.03.2015 um 14:00 schrieb Ville Määttä:
> On 03.03.15 14:54, Stephan Beck wrote:
>> as your message hasn't reached the list inspite of being addressed to it
> 
> It did :).
> 
Strange, I did only receive the PM, not the listmail, so I thought it might be
useful to resend it. In that case, sorry for the duplication.

Regards

Stephan





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

Re: Circumvention Tech Summit in Valencia

[Samir Nassar]

On Tuesday, March 03, 2015 01:34:01 PM Kristian Fiskerstrand wrote:
> On 03/03/2015 12:51 PM, Robert J. Hansen wrote:
> > Daniel Kahn Gillmor and I are both here.  (And in fact, we met
> > briefly, and much to the surprise of many people here but not to
> > either dkg or myself, there was mutual respect, goodwill, and a
> > stunning lack of bloodshed.)  :)

> Hope you guys have a great time! (and remember to sign each other's
> OpenPGP keys) :)

Non developers are also here and happy to verify OpenPGP certificates as well.

Samir



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: Circumvention Tech Summit in Valencia

[Robert J. Hansen]

> Non developers are also here and happy to verify OpenPGP certificates
> as well.

And happy to buy people beer.  Thanks again, Samir.  :)



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

Re: German ct magazine postulates death of pgp encryption

[Hans of Guardian]

On Feb 27, 2015, at 8:56 PM, Werner Koch wrote:

> On Fri, 27 Feb 2015 17:26, patr...@enigmail.net said:
> 
>> that anyone can upload _every_ key to a keyserver is an issue. If
>> keyservers would do some sort of verification (e.g. confirmation of
>> the email addresses) then this would lead to much more reliable data.
> 
> We have such a system. It is called S/MIME.
> 
> Ever tried to find an S/MIME (X.509) key (aka certificate) for an
> arbitrary mail address?  The only working solution to get such a key is
> by sending a mail and asking for the key.  You can do the very same with
> PGP of course.  Keyservers along with visting cards are much nicer.
> 
> So, why is there no public service to distribute X.509 keys?  Because
> nobody want to be legally responsible for such a key unless you push a
> stack of money over the table for a qualified signature certificate.
> 
> BTW, even the DFN PGP keyserver (blackhole.pca.dfn.de) had to be shut
> down for similar legal reasons.  However, it is not a problem, we can
> use other keyservers.
> 
>> believe that this would make keyservers more trustworthy than today.
> 
> There is no trust in keyservers by design.  As soon as you start
> changing this you are turning PGP into a centralized system.

Services like keybase.io with poor security practices are going to rapidly take 
over from the PGP keyserver pool because they address side of the human 
interaction, unlike the PGP keyservers.  They are easy to use and the follow 
the very common interaction patterns that basically all web services these days 
use. That must also be considered when thinking about security.  The PGP 
keyservers need email validation not as a way to provide any kind of "trusted" 
status of that key, but rather so enable people to delete keys that should no 
longer be there, and to prevent keyserver spam and vandalism.  For a good 
example, search for Richard Stallman and you will see how badly the PGP 
keyservers are failing.

Another common scenario is that people make mistakes when learning how to use 
PGP.  There is a common mistake of generating a key to play with, publishing to 
the keyserver, then deleting.  That key will then be on the keyserver forever 
with no way to delete it.  That is terrible both security-wise because it is 
confusing for people who are searching for keys, and it is terrible 
human-interaction-wise because it adds pointless noise when searching for keys.

.hc


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

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Feb 27, 2015, at 3:09 PM, Peter Lebbing wrote:

> On 27/02/15 12:02, Hans-Christoph Steiner wrote:
>> For example, I think that
>> `gpg --json` is great idea.  I ended up using a Java wrapper of GPGME, which
>> is in turn a wrapper of GnuPG.  I think it makes a lot more sense to have 
>> `gpg
>> --json` as the parseble interface, then implement a GPGME-style framework in
>> each language (Python, Java, etc).
> 
> I'd say the JSON interface could just be an additional set of functions in
> GPGME; and GPGME simply talks the old colon-separated protocol to the gpg
> binary. You can't just take out the colon-separated protocol, and that 
> protocol
> has all the information. You could simply have GPGME reformat the output.
> 
> Unless you mean that you want to speak to the gpg binary yourself, without 
> GPGME
> in between. In that, case, I simply think you might be on the wrong track, and
> should use a library. If GPGME itself is a problem because you don't know what
> platform you should compile for, like in Python, then the library could be
> re-implemented in pure Python instead of using a foreign function interface.
> 
> The old calling conventions of the binary cannot change, otherwise you'd break
> everything that already depends on it. And adding multiple ways of doing the
> same thing in the gpg binary seems the wrong place; more code, more chance of
> bugs, etcetera. This is where libraries come in, to save you the burden of
> working with the gpg binary.

It is actually more difficult to wrap GPGME in Java than to have just rewritten 
GPGME in Java.  GPGME is a fine API for C/C++, it is a bad API for other 
languages.  You end up with an API that feels like a C API forced into the 
language, e.g. Java, python, etc.  That makes for more coding mistakes because 
it feels foreign to the programmer.  More mistakes means more security issues.

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

Re: Circumvention Tech Summit in Valencia

[Samir Nassar]

On Tuesday, March 03, 2015 03:49:41 PM Robert J. Hansen wrote:
> > Non developers are also here and happy to verify OpenPGP certificates
> > as well.
> 
> And happy to buy people beer.  Thanks again, Samir.  :)

It is in the constitution; if you are a FOSS developer the least I can do is 
provide $beverage.

Samir

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: German ct magazine postulates death of pgp encryption

[Hans of Guardian]

On Feb 27, 2015, at 1:11 PM, Kristian Fiskerstrand wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 02/27/2015 12:43 PM, Hauke Laging wrote:
>> Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker:
>> 
>>> Maybe implementation with an opt-in could preserve publishing of
>>> faked keys on public keyservers?
>> 
>> We need keyservers which are a lot better that today's. IMHO that
>> also means that a keyserver should tell a client for each offered
>> certificate whether it (or a trusted keyserver) has made such an
>> email verification.
> 
> The keyservers have no role in this, they are pure data store and can
> never act as a CA. That would bring up a can of worm of issues, both
> politically and legally, I wouldn't want to see the first case where a
> keyserver operator was sued for permitting a "fake key" (the term
> itself is very misleading, the key itself isn't fake at all, but a
> fully valid key where the UID has not been mated to its holder through
> proper validation).


The standard PGP keyserver pool is a mess with racist spam, lost keys that will 
be there forever, etc.  The concept of email validation is very very common and 
proven in internet service providers.  It is time for OpenPGP keyservers to 
join the rest of the internet.

Keyservers should not be located in jurisdictions where they could be sued for 
merely acting as a conduit for data.  There are many countries that meet this 
criteria.  The US is one good example there: internet service providers are not 
liable for what their users do.

.hc


> Another way this is being handled in some systems is dedicated
> keyservers for an organization (standard is keys.[domain] in the cases
> I've seen) that looks up key using LDAP. This is a read-only store
> that is connected to the Domain Controller / Active Directory in the
> system I'm thinking of. So at least Symantec Encryption Server checks
> for the existence of such a keyserver when sending and asking it for
> it. The keys are automatically maintained with a short time to expiry
> requiring frequent refreshes. I understand the rationale, but would
> rather see a CA involved in this (i.e a Company Employee CA).
> 
> People need to understand that operational security is critical for
> any security of a system and validate the key through secondary
> channel (fingerprint, algorithm type, key length etc verifiable
> directly or through probabilistic measures e.g. based on historical
> postings on mailing lists over a long time for a project etc).
> 
> - -- 
> - 
> Kristian Fiskerstrand
> Blog: http://blog.sumptuouscapital.com
> Twitter: @krifisk
> - 
> Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
> - 
> Ubi mel ibi apes
> Where there's honey, there are bees
> -BEGIN PGP SIGNATURE-
> 
> iQEcBAEBCgAGBQJU8F7vAAoJEP7VAChXwav6yrwIAI95x/GZrq+5gCYhHjDuCWhv
> a2FB1ki5c5unMzN6gtBjwY0Tf8SfAicnR2NpRn2VUkb68/hVG5H3JEhQcVsLt6Je
> 5LUFR9gjyN8VGoDnMl0g1khxfNcakYh6f1vPmLihfiP4Yh6Pf6PebIkurqhvhwkf
> NnwtIipSipDeXuQgJBMmN9fMXUqkO1uA2tt0tewtIaJy2y+BMmzVbRkpqZocl2z6
> VcwBT/7FUUv4ePdV16xTuim9DvmbsCoPmwl+1XRauEeJsN3AOyE0X/Y/gKYX4QX0
> RWUaCu2b7YRqMYyaYs053EsH+XEAPVOVDnBHUFst/c6j4hIJV7T4zB2mpi5+VKw=
> =IZT3
> -END PGP SIGNATURE-
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

Re: Circumvention Tech Summit in Valencia

[Robert J. Hansen]

> It is in the constitution; if you are a FOSS developer the least I
> can do is provide $beverage.

I'm glad I contribute code to a couple of small FOSS digital forensics
projects, then.  Because I've never contributed a single line of code to
GnuPG or Enigmail.  :)





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

Re: German ct magazine postulates death of pgp encryption

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/03/2015 01:50 PM, Hans of Guardian wrote:
> 
> On Feb 27, 2015, at 1:11 PM, Kristian Fiskerstrand wrote:
> 
> On 02/27/2015 12:43 PM, Hauke Laging wrote:
 Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker:
 
> Maybe implementation with an opt-in could preserve
> publishing of faked keys on public keyservers?
 
 We need keyservers which are a lot better that today's. IMHO 
 that also means that a keyserver should tell a client for
 each offered certificate whether it (or a trusted keyserver)
 has made such an email verification.
> 
> The keyservers have no role in this, they are pure data store and 
> can never act as a CA. That would bring up a can of worm of
> issues, both politically and legally, I wouldn't want to see the
> first case where a keyserver operator was sued for permitting a
> "fake key" (the term itself is very misleading, the key itself
> isn't fake at all, but a fully valid key where the UID has not been
> mated to its holder through proper validation).
> 
> 
>> The standard PGP keyserver pool is a mess with racist spam, lost 
>> keys that will be there forever, etc.  The concept of email 
>> validation is very very common and proven in internet service 
>> providers.

And anyone is free to set up a CA that performs this validation and
signs the returned key.

>> It is time for OpenPGP keyservers to join the rest of the
>> internet.
> 

They are already quite up to date, SKS 1.1.5+ (development master)
even supports the experimental Ed25519 draft used by GnuPG. What you
are proposing here isn't about joining the rest of the internet, it is
about subverting the security by introducing a false sense of security
and even worse, that opens up well known attack vectors.

By the way, an OpenPGP key is fully valid without any email address as
part of any UID.

- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Acta est fabula
So ends the story
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU9dE9AAoJEP7VAChXwav6ThcH/iTlxKZA9VQoExj8BEueXx61
hC1vCYwozu03+D1NnEjaR4M60i3M+rGz47NNQ3CXGgSkMNP1jp5WYt2V1TZ9maWO
Ho5O1XEqXAW0KGmoKUCmRFPstAWjySpa1fOc/4Zx6N9Ay4WqzPxu7OyJwK174AKz
LKahw+LRntlbj7NrgJqFwQfXzbqKO23oFD9bd4Z9dX4UuM7lWnSk55AKw7K3R2gW
UnTt4DAdBEDjz3IwClFCArY87MiW+i2F7sSmg6MkH4A6LkSQRjvSgUa0+tUO+4SR
yHC9KVV1Ru+JxJsxcqM9gOjU1i5Pq9qc7/z5+oNvgju7ltPAKLB6MJjOz4RK1BM=
=7Z2B
-END PGP SIGNATURE-

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

Re: Thoughts on GnuPG and automation

[Brian Minton]

It breaks mailpile because gpg-agent is not session aware.  A user could
be logged in locally, using mailpile, and a remote attacker could access
the web interface of that locally running mailpile instance, which since
it is talking to the same gpg-agent, would think the remote user is
logged in (or more precisely, has the private key).

I think that one solution would be to have mailpile use a per-session
gpg home dir.



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

Re: German ct magazine postulates death of pgp encryption

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/03/2015 04:20 PM, Kristian Fiskerstrand wrote:
> On 03/03/2015 01:50 PM, Hans of Guardian wrote:
> 
>> On Feb 27, 2015, at 1:11 PM, Kristian Fiskerstrand wrote:
> 


...

> 
>>> The standard PGP keyserver pool is a mess with racist spam,
>>> lost keys that will be there forever, etc.  The concept of
>>> email validation is very very common and proven in internet
>>> service providers.
> 
> And anyone is free to set up a CA that performs this validation
> and signs the returned key.
> 
>>> It is time for OpenPGP keyservers to join the rest of the 
>>> internet.
> 
> 
> They are already quite up to date, SKS 1.1.5+ (development master) 
> even supports the experimental Ed25519 draft used by GnuPG. What
> you are proposing here isn't about joining the rest of the
> internet, it is about subverting the security by introducing a
> false sense of security and even worse, that opens up well known
> attack vectors.
> 
> By the way, an OpenPGP key is fully valid without any email address
> as part of any UID.

For completeness, going to include some of the template for my
response to delete key requests;

But your situation is a good example of why one should never trust
a key based on email address in UID alone, but need to verify
fingerprint, creation type, key algorithm etc with the perceived
owner and certify/sign the key.

If you google you'll find some more detailed explanations as to
why you can't delete a key from a keyserver.

Long story short, even if it was technically possible the social
protocol is missing. Speaking more generally, there might've been
two (or more) people sharing the same name, and email addresses
change over time, if the previous user deleted his email, it
wouldn't make the key any less valid that someone else take over
the email address.

This is why one should never trust email address alone, but always
verify keys through other means (mainly fpr, creation date, algo,
size). That several keys exists for a single address is, from a
cryptographical and security point of view irrelevant, as it is
only applicable as a potential issue if people don't follow proper
procedure for due dilligence.


- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Aquila non capit muscas
The eagle does not hunt flies
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU9dHLAAoJEP7VAChXwav6CmwH/AhHo8DYGxagxwESb6o1LlHm
oDHv/W4tWF5tcp7gOW4bQfjHglgIIVJqAZoroyRIYfmK4amrX1kGqWDHG2aJ80Rr
IoQwJjAyhQkUhea+lIZ+w3JaY80gtZ2ZaFZ1Dj88OAg5qX02Dy5ip2e0SunzA/91
jPjqFyUuuXDt5ThUblaTS4DgrlDEXWtYacaalE/nCZhdtlwVE4eBbma5Fp7LTLfU
nBIzPtZNe64gXz9h9BWZmDgLLXWvrlj1CuUCe6KKkxZoDUUgsWZBszwW+tv9HlPq
x3Gc8e2A5aIc4UooJlMnlvS/78AQ6nDieTBcgMiYKyxuyC7fP3bWEf9Xrhv6SKE=
=Z4Ie
-END PGP SIGNATURE-

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

Re: German ct magazine postulates death of pgp encryption

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 03/03/2015 02:00 PM, Hans of Guardian wrote:
> 
> On Feb 27, 2015, at 8:56 PM, Werner Koch wrote:
> 


...

> 
> Services like keybase.io with poor security practices are going to 
> rapidly take over from the PGP keyserver pool because they address 
> side of the human interaction, unlike the PGP keyservers.  They
> are easy to use and the follow the very common interaction patterns
> that basically all web services these days use. That must also be 
> considered when thinking about security.  The PGP keyservers need 
> email validation not as a way to provide any kind of "trusted"
> status of that key, but rather so enable people to delete keys that
> should no longer be there, and to prevent keyserver spam and
> vandalism.  For a good example, search for Richard Stallman and you
> will see how badly the PGP keyservers are failing.

I fail to see how this is a failure on the side of the keyservers, it
is part of the expected practise and a fully understood scenario,
which is why it is mandated to conduct key verification through secure
channels.

> 
> Another common scenario is that people make mistakes when learning 
> how to use PGP.  There is a common mistake of generating a key to 
> play with, publishing to the keyserver, then deleting.  That key
> will then be on the keyserver forever with no way to delete it.
> That is terrible both security-wise because it is confusing for
> people who are searching for keys, and it is terrible
> human-interaction-wise because it adds pointless noise when
> searching for keys.

It doesn't affect neither security nor the user at all, the first
because the key anyways needs to be verified, the second because the
key anyways needs to be verified.

- -- 
- 
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- 
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- 
Aquila non capit muscas
The eagle does not hunt flies
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU9dQVAAoJEP7VAChXwav6BuoH/0IT/ihPi4ImnOGrKDId8xNg
9s17GVVjIZJQrWSCWLH35YhgtXNVxCeyhzSuIps6C1V5V7joRdHMAmDFq7XKtptf
FKvysceQ97Vd1eLILyLJi/IEQbR52x0Kp+HcqCtk1TuiqVEtQKXfPtaobVDNxbxQ
eUhigPi0ep7IiO6udE8cZ+3tWqzqzVWPEyyeP5kOucHdfE6UuCVqFd8XgP4sDYHT
nuvXn/LGXrKcG40LhFSjDaHHX2xx5Mow/dGNKWDH+GIAuIy2yJN/TaZw+vohXGy8
3bjlyeoFJQeBPu7O8BjVT20OK6jnJPFZywMdd09U/SX1lDqKVt4zPcyPwSNPHZc=
=VSei
-END PGP SIGNATURE-

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

Re: Circumvention Tech Summit in Valencia

[Werner Koch]

On Tue,  3 Mar 2015 12:51, r...@sixdemonbag.org said:

> Admittedly, "the GnuPG dev people" is really a one-element list
> containing Werner.  But there are certainly people active in the GnuPG

The web page lists more and several more have write access to
git.gnupg.org.  I considered to affend but the number of open bugs keeps
me working here.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Fwd: Re: German ct magazine postulates death of pgp encryption

[MichaelQuigley]

"Gnupg-users"  wrote on 03/03/2015 09:41:25 
AM:
> - Message from Stephan Beck  on Tue, 03 Mar 
> 2015 15:40:45 +0100 -
> 
> To: gnupg-users@gnupg.org
> 
> Subject: Re: Fwd: Re: German ct magazine postulates death of pgp 
encryption
> 
> Am 03.03.2015 um 14:00 schrieb Ville Määttä:
> > On 03.03.15 14:54, Stephan Beck wrote:
> >> as your message hasn't reached the list inspite of being addressed to 
it
> > 
> > It did :).
> > 
> Strange, I did only receive the PM, not the listmail, so I thought it 
might be
> useful to resend it. In that case, sorry for the duplication.
> 
> Regards
> 
> Stephan

I believe if you are personally addressed, the list management software 
doesn't send you a duplicate copy of the message.___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Peter Lebbing]

On 03/03/15 14:29, Hans of Guardian wrote:
> It is actually more difficult to wrap GPGME in Java than to have just
> rewritten GPGME in Java.

In my opinion, if this is the case, then that is indeed the proper
solution: write a general-purpose library à la GPGME, but don't call gpg
directly from your application.

Calling the gpg binary is indeed an API, as was said here. It's the API
GPGME uses, for instance. GPGME does not somehow load gpg in its address
space or something; it simply invokes gpg, in a separate process.

That calling the gpg binary is an API doesn't make it the right API for
other programs to use. The right API in general would be GPGME or an
alternative to GPGME.

Just like libc is the proper API for a program to use instead of
directly issuing syscalls to the Linux kernel. The syscall interface is
an API; it's just not the right one in many cases.

At least, this is my view of it.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: German ct magazine postulates death of pgp encryption

[Christoph Anton Mitterer]

On Tue, 2015-03-03 at 14:00 +0100, Hans of Guardian wrote:
> The PGP keyservers need email validation
no it's pretty useless from a security POV and they don't need it.

> not as a way to provide any kind of "trusted" status of that key, but
> rather so enable people to delete keys that should no longer be there,
> and to prevent keyserver spam and vandalism.
Unfortunately it seems that you miss(understand) some of the basic
paradigms of security here:
Actually the opposite is the case - removing keys from the keyservers
(even if they're allegedly spam) would be a big security compromise of
the whole system, as potentially important information (revocation
certs, valid keys, etc.) would be removed as well.

And who should in the end decide which key respectively which identity
is valid?
For there may be many Richard Stallmans, and if even such famous person
uses an address like stall...@gmail.com, he could later give it up and
someone else takes it (or vice-versa).
If such keys would then considered spam,... then good night.


> Another common scenario is that people make mistakes when learning how
> to use PGP.  There is a common mistake of generating a key to play
> with, publishing to the keyserver, then deleting.
While that's unfortunate... it's part of the game and as long as you
aren't a keyserver operator/developer this shouldn't make you any
concerns - unless of course you use the keyservers to authenticate (i.e.
only one Richard Stallman -> that must be him) ... but then you're
doomed anyway and no one will, should or could help you.

> That is terrible both security-wise because
Actually the contrary as laid out above.

For that reasons the keyserver used to generally refuse removal of keys
for years, and exceptions where only made on selective servers and then
only to obey some stupid laws which actually degrade security here.


Cheers,
Chris.



smime.p7s
Description: S/MIME cryptographic signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Feb 27, 2015, at 1:19 PM, Bjarni Runar Einarsson wrote:

> Hi Hans-Christoph!
> 
> Hans-Christoph Steiner  wrote:
>> With all the recent attention to GnuPG and Werner's work, I have begun to
>> think about things differently.  GnuPG has an amazing security track record.
>> It has had few serious security bugs, nothing even close to heartbleed that I
>> know of, and yet it is core to providing security to GNU/Linux distros, as
>> well as protecting people like Laura Poitras and Edward Snowden. So instead
>> of complaining about the difficulties, I now try to think about whether such
>> difficulties might actually be related to what makes GnuPG so solid.
> 
> Some of the more jaded will call this Stockholm syndrome. :-P
> 
> I don't agree with the voices that want to discard PGP and start from
> scratch. There is valuable experience and maturity in this project,
> which is why we care enough to complain when it is hard to work with.
> 
>> anyone interested in providing usable security needs to think hard about 
>> this.
>> Sure we can make things easier to use, but it is a very slippery slope
>> towards reducing security.
> 
> I really disagree with this. If a security tool is too hard to
> understand, whether for a developer or user, then insecurity will be the
> inevitable result: people will use it wrong. This is only in part
> GnuPG's resposibility, most of the complexity is inherited from OpenPGP
> and the fact that public/private key crypto and key management are just
> very complex topics.
> 
> This is the one point where I agree with the voices calling for
> abandoning OpenPGP entirely. It can well be argued that the whole
> cryptoscheme has been field tested and proven too complex for humans to
> use correctly. That's not exactly GnuPG's problem either, but these
> voices are becoming louder and, increasingly, there is finally
> competition in this space. The project will get marginalized if
> usability is ignored completely.
> 
> Mailpile's attempt to make OpenPGP easy to use is us stubbornly trying
> to prove that it can be done. But I'm only somewhat optimistic that
> we'll succeed, and we'll only do so if we face reality and drop a large
> number of the features that make PGP what it is - in particular the web
> of trust and default trust model, and who knows what else. I don't mind
> if that code exists inside GnuPG, but Mailpile is absolutely not going
> to be using it.

I think if you actually disagree, you are missing my essential point.  But my 
guess is that we agree more than disagree.  Of course, I entirely agree that 
bad usability can also make a technically secure system actually very insecure. 
 This point is not mutually exclusive with what I said, and indeed both must be 
taken fully into account.

So for example, we could make PGP email really easy if we consider only a mass 
surveillance threat model.  Just make all the processes transparent in the 
background: passphrases, key generation, downloading public keys, etc.  But 
that would produce a system that would not work for the highly targeted threat 
models like Edward Snowden and Laura Poitras.  They would need to use a 
specialized system, and that specialized system might then be a marker of 
suspicion (for example, lots of governments, including the NSA, already mark 
all PGP messages as suspicious).  That then makes it a lot harder for people 
who suddenly realize that they might be under scrutiny.

There is a big tide of thinking about usability of security tools.  This is a 
great thing, and we need lots of contributions. But what it happening far too 
often these days is that the new generation are trumpeting "ease of use" above 
all else.  We are seeing systems like keybase.io that make things really easy, 
but also expect users to upload their _private_ key to some alpha web service.  
That is terrible security practice.

I've also been arguing that we need to make encryption much easier to do.  But 
we are failing as UX designers if we do not deeply understand the systems that 
are trying to make easier to use.  And that is why I advocate thinking long and 
hard about GnuPG, and what makes it hard to use, and what makes it secure.  
Only then can we really make solid security usable.


>> I also have to call out that part of the problem that mailpile is continuing:
>> it is generally more fun to write code, rather than figure out someone else's
>> library. That is especially true when its a complicated thing like GnuPG.
>> But in order to have shared maintenance and work, we all need to take
>> responsibility and try to build upon the work of others whenever possible.
>> Mailpile did not do that, and instead wrote yet another incomplete
>> python API for GnuPG.
> 
> Fair enough. We were in a hurry, and we probably did make a mistake
> here. There is a reason why we haven't broken our library out and
> published separately though: we do hope to tear it out and replace it
> with something more standard down the li

Re: German ct magazine postulates death of pgp encryption

[Robert J. Hansen]

>> Services like keybase.io with poor security practices...
> 
> I fail to see how this is a failure on the side of the keyservers...

I fully agree with Kristian.

I further don't see how keybase.io amounts to "poor security practice".
 The Web of Trust is, itself, a poor practice because it's
rarely-if-ever used in practice; even something like TOFU is far
superior to the Web of Trust in most real-world environments.



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

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

Hans, please trim your quoted material.

> They would need to use a specialized system, and that specialized
> system might then be a marker of suspicion (for example, lots of
> governments, including the NSA, already mark all PGP messages as
> suspicious).

Unless you've got a desk somewhere deep inside Fort Meade and you're
sitting in on briefings the rest of us aren't, you don't know this.

There's a lot of panic and paranoia in the air already without people
making it worse by treating what they *think* is true as if they *know*
it's true.

(I don't know if what he's claiming is true or false... but I *do* know
that I don't believe his certainty, and I wouldn't believe anyone else
who claimed to be certain, either!)

> trumpeting "ease of use" above all else.  We are seeing systems like 
> keybase.io that make things really easy, but also expect users to 
> upload their _private_ key to some alpha web service.

keybase doesn't expect users to upload the private key.  It works just
fine if you don't, and in fact you have to go through an extra couple of
steps to put the private key on the keybase servers.

For some use cases this is a good practice.  For many more it's a bad
practice.  But it's way too facile to simply say,

> That is terrible security practice.

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

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

Yeah, mailpile has a very unusual architecture, so its no surprise it'll need 
some unusual tricks.  Unusual tricks in software that aims to be secure 
generally make me nervous since it is important to keep code readable and 
understandable for both the core devs, but also contributors, auditors, etc.

.hc

On Mar 3, 2015, at 4:23 PM, Brian Minton wrote:

> It breaks mailpile because gpg-agent is not session aware.  A user could
> be logged in locally, using mailpile, and a remote attacker could access
> the web interface of that locally running mailpile instance, which since
> it is talking to the same gpg-agent, would think the remote user is
> logged in (or more precisely, has the private key).
> 
> I think that one solution would be to have mailpile use a per-session
> gpg home dir.
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users


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

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 4:43 PM, Peter Lebbing wrote:

> On 03/03/15 14:29, Hans of Guardian wrote:
>> It is actually more difficult to wrap GPGME in Java than to have just
>> rewritten GPGME in Java.
> 
> In my opinion, if this is the case, then that is indeed the proper
> solution: write a general-purpose library à la GPGME, but don't call gpg
> directly from your application.
> 
> Calling the gpg binary is indeed an API, as was said here. It's the API
> GPGME uses, for instance. GPGME does not somehow load gpg in its address
> space or something; it simply invokes gpg, in a separate process.
> 
> That calling the gpg binary is an API doesn't make it the right API for
> other programs to use. The right API in general would be GPGME or an
> alternative to GPGME.
> 
> Just like libc is the proper API for a program to use instead of
> directly issuing syscalls to the Linux kernel. The syscall interface is
> an API; it's just not the right one in many cases.
> 
> At least, this is my view of it.
> 
> Peter.

Different programming languages and operating systems can have very different 
ways of launching and handling external processes.  By forcing them all to 
launch GPG in the UNIX way makes for complicated and weird software.  For 
example, Android works very differently than any UNIX or even Windows, 
especially when it comes to launching and managing processes.

At the risk of being repetitive: Android runs the Linux kernel, but is it far 
far far from being UNIX or GNU/Linux.

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

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> Different programming languages and operating systems can have very 
> different ways of launching and handling external processes.

Eh.  Different operating systems, sure: that's the nature of kernels.
They provide different syscalls, and that's at root how you launch an
external process -- by making syscalls.

But different programming languages can have very different ways of
launching and handling external processes?  I've never seen that to be
true.  C#'s Process, C's fork/exec, Python's subprocess, Go's
syscall.StartProcess()... it's all pretty much identical.  There are a
couple of exotics, but they're exotic.

> By forcing them all to launch GPG in the UNIX way makes for
> complicated and weird software.

It *can* make for complicated and weird software.  I don't doubt that
GnuPG doesn't fit well into the Android model, but this isn't a reason
to do GPGME differently.

If I'm Count Rugen, I'm not going to complain that glovemakers need to
change the way they do things to accommodate my six fingers.  I'm going
to acknowledge that my hands are quite a lot different from the
glovemakers' models, and rather than tell the glovemakers how
five-fingered gloves are a mistake because they don't account for the
possibility of six, I'm just going to hire a tailor to make my gloves.

(Count Rugen: the six-fingered villain from _The Princess Bride_.)

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

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 5:01 PM, Robert J. Hansen wrote:

> Hans, please trim your quoted material.
> 
>> They would need to use a specialized system, and that specialized
>> system might then be a marker of suspicion (for example, lots of
>> governments, including the NSA, already mark all PGP messages as
>> suspicious).
> 
> Unless you've got a desk somewhere deep inside Fort Meade and you're
> sitting in on briefings the rest of us aren't, you don't know this.
> 
> There's a lot of panic and paranoia in the air already without people
> making it worse by treating what they *think* is true as if they *know*
> it's true.
> 
> (I don't know if what he's claiming is true or false... but I *do* know
> that I don't believe his certainty, and I wouldn't believe anyone else
> who claimed to be certain, either!)

This is definitely public information from the Snowden leaks.  There is also 
quite a bit of information about other governments doing similar things.  
Here's one example article:

http://www.forbes.com/sites/andygreenberg/2013/06/20/leaked-nsa-doc-says-it-can-collect-and-keep-your-encrypted-data-as-long-as-it-takes-to-crack-it/

> 
>> trumpeting "ease of use" above all else.  We are seeing systems like 
>> keybase.io that make things really easy, but also expect users to 
>> upload their _private_ key to some alpha web service.
> 
> keybase doesn't expect users to upload the private key.  It works just
> fine if you don't, and in fact you have to go through an extra couple of
> steps to put the private key on the keybase servers.
> 
> For some use cases this is a good practice.  For many more it's a bad
> practice.  But it's way too facile to simply say,
> 
>> That is terrible security practice.

keybase has started to downplay the private key stuff.  When it started, you 
had to upload your private key to use the service.

Uploading your private key to keybase sets people up for a centralized system 
with terrible security. It'll be an obvious target, and they are a startup 
doing webby things, which also has a terrible security track record.  There are 
so many exploits in ruby, javascript, etc.  The fact that they even considered 
this an option just shows that they only care about easy, not about secure.

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

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 5:49 PM, Robert J. Hansen wrote:

>> Different programming languages and operating systems can have very 
>> different ways of launching and handling external processes.
> 
> Eh.  Different operating systems, sure: that's the nature of kernels.
> They provide different syscalls, and that's at root how you launch an
> external process -- by making syscalls.
> 
> But different programming languages can have very different ways of
> launching and handling external processes?  I've never seen that to be
> true.  C#'s Process, C's fork/exec, Python's subprocess, Go's
> syscall.StartProcess()... it's all pretty much identical.  There are a
> couple of exotics, but they're exotic.
> 
>> By forcing them all to launch GPG in the UNIX way makes for
>> complicated and weird software.
> 
> It *can* make for complicated and weird software.  I don't doubt that
> GnuPG doesn't fit well into the Android model, but this isn't a reason
> to do GPGME differently.
> 
> If I'm Count Rugen, I'm not going to complain that glovemakers need to
> change the way they do things to accommodate my six fingers.  I'm going
> to acknowledge that my hands are quite a lot different from the
> glovemakers' models, and rather than tell the glovemakers how
> five-fingered gloves are a mistake because they don't account for the
> possibility of six, I'm just going to hire a tailor to make my gloves.
> 
> (Count Rugen: the six-fingered villain from _The Princess Bride_.)

Android has an installed base of hundreds of millions.  Desktop UNIX is the 
exotic system here as compared to Windows, Android, etc.

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

Re: Thoughts on GnuPG and automation

[Peter Lebbing]

On 03/03/15 18:29, Hans of Guardian wrote:
> Android has an installed base of hundreds of millions.  Desktop UNIX
> is the exotic system here as compared to Windows, Android, etc.

I have no idea about how difficult it is to launch the gpg binary with a
few pipes attached to a few file descriptors and perhaps anything else
you need.

But I fail to see why you brought it up.

I thought we were discussing two alternatives:

- Call gpg directly
- Use a library such as GPGME that calls gpg for you

In both cases, the gpg binary is executed as a separate process. So it
seems to me any issues with this are the same in both cases. In fact, if
it indeed is tricky as you say, you're better off if you have a library
do this for you, so you don't have to get it right in each and every
application.

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

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

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> This is definitely public information from the Snowden leaks.  There 
> is also quite a bit of information about other governments doing 
> similar things.  Here's one example article:

If all encrypted traffic is deemed suspicious, then 99.999% of the
suspicious set -- Amazon transactions, Google searches, SMTP transfers,
instant messaging, OkCupid profiles, iTunes purchases, and more -- is
totally clean.  You'd have statistically better odds by arresting random
people on suspicion of murder.  The policy would be completely
pants-on-head absurd.

This leads to a different question: "Is it more likely that this is the
real pants-on-head absurd policy, or that the _Forbes_ journo has
profoundly misunderstood the subject?"

Just because something's been published doesn't mean it should be
trusted.  Bring your brain -- and when someone tells you something that
supports your worldview, look at that thing hard and twice.

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

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> Android has an installed base of hundreds of millions.

So?

GnuPG and GPGME are products of their birth, just like anything else.
It was built for desktop operating systems.  If you want to make it live
in the mobile space, go with God and I wish you all the luck in the
world -- but if GPGME isn't working well for you, the burden is on you
to do something better.  The burden isn't on GPGME to totally change how
it does things.

I really don't understand what you're getting at here.

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

Re: Thoughts on GnuPG and automation

[Werner Koch]

On Tue,  3 Mar 2015 14:29, h...@guardianproject.info said:

> It is actually more difficult to wrap GPGME in Java than to have just
> rewritten GPGME in Java.  GPGME is a fine API for C/C++, it is a bad

Sorry, but that is not your problem.  The problem on Android seems to be
that it is not easy to install anything else than plain Java apps.

We have GPGME bindings for all kind of languages from Ada over Java to
Scheme.  Thus I can't see the problem - need another kind of data object
to be handled in GPGME?  No problem, it can easily be done.  Is the
event loop the problem?  That is somewhat harder to get right but that
is always the case if you use a library.

I don't really understand your complaints given that we worked together
to port GnuPG to Android.  GPGME is just a small thing on top of it and
way easier than GnuPG itself.  It has nothing to do with fork+exec -
GnuPG uses that itself a lot.

In 2010 we ported GnuPG and GPGME and Kontact (includes KMail) to
Windows Mobile 6.5.  I can tell you, that was a task but we finally did
it.  And the problems were not due to GnuPG (even that it ate up many of
the scarce process slots) but due to the shear amount of memory KDE
stuff required.  Consider as an example this: On Windows CE (the kernel
of Windows Mobile), you don't have stdout and stdin, nor is there a way
to inherit or pass on file descriptors.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:

> On 03/03/15 18:29, Hans of Guardian wrote:
>> Android has an installed base of hundreds of millions.  Desktop UNIX
>> is the exotic system here as compared to Windows, Android, etc.
> 
> I have no idea about how difficult it is to launch the gpg binary with a
> few pipes attached to a few file descriptors and perhaps anything else
> you need.
> 
> But I fail to see why you brought it up.
> 
> I thought we were discussing two alternatives:
> 
> - Call gpg directly
> - Use a library such as GPGME that calls gpg for you
> 
> In both cases, the gpg binary is executed as a separate process. So it
> seems to me any issues with this are the same in both cases. In fact, if
> it indeed is tricky as you say, you're better off if you have a library
> do this for you, so you don't have to get it right in each and every
> application.
> 
> Peter.

GPGME is that library that wraps gpg execution, and I've spent weeks of my life 
working GPGME on Android.  The way that GPGME wraps gpg is built entirely on 
UNIX assumptions, which is turns out that Windows works actually pretty close 
to that.  Android, on the other hand is a very different story. Some key 
differences:

* Android will kill apps when it needs to, app lifecycle is automatically 
managed,
 the app has no control over it, and often zero warning is given

* Android was not meant to support launching processes from a shell/terminal,
 it was there for core debugging, then opened up on demand from devs, but it
 is very much a second class citizen to a Java Android app.

* all apps are child processes of 'zygote'

* there is no way to install shared libraries to be shared by apps

There are other differences as well.  And iOS actually works a lot like 
Android, but also blends some UNIX stuff in.  I think we can also find similar 
issues when looking at how to make a proper Python API for GnuPG (though 
probably not as extreme).

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

Duplicate copies of list messages when you are also addressed personally [Was: Re: Fwd: Re: German ct magazine postulates death of pgp encryption]

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Tuesday 3 March 2015 at 3:02:43 PM, in
,
michaelquig...@theway.org wrote:



> I believe if you are personally addressed, the list
> management software doesn't send you a duplicate copy
> of the message.

The option is set at
.

"Avoid duplicate copies of messages?

When you are listed explicitly in the To: or Cc: headers of a
list message, you can opt to not receive another copy from the
mailing list. Select Yes to avoid receiving copies from the
mailing list; select No to receive copies. "






- --
Best regards

MFPAmailto:2014-667rhzu3dc-lists-gro...@riseup.net

War is a matter of vital importance to the State.
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJU9hqQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXwKz0IAKi63hONqYt0dkU2/hJaCAa+
KQmg9oYgtZsuBa/z1on4TCJc+hvJuoXwW383zMkC8uaTkhMXMnpoLwYcI7466nal
plSSRdtn28hJ/DZSKzpFwZ2fKOwTP7EW7Yjp4d/mWNa/3yzxSdK7Tpq+p3G7VYg9
67FYsV56yp75aTOSGa4AjPkrcoBvUME2H5VC/quUxcjF6XgrlOvLZGnszoTYuek7
HhhUF5SKUTJ9HGWJ2i0bUr44nL2+ximj3BkuBGxsrT9e40EZ0/6+O6Vc71DBiWIw
RNj3ni9emQwD8WQi+VvBwUaf7knHX99hW2Q7xmNcy0Ff+n8NEPFaptJT1jwUCwqI
vgQBFgoAZgUCVPYall8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45CYPAQAXEgORb3g660Ii+KH/6Ziv+z/f
p3KnJN2+i0d8pUiX8gEA5uE52W7xqw4/2TxJPV/7v+fYFSDoIS69vWnHlL9gUQs=
=QKwF
-END PGP SIGNATURE-


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

Re: Thoughts on GnuPG and automation

[Ingo Klöcker]

On Tuesday 03 March 2015 19:31:14 Robert J. Hansen wrote:
> > This is definitely public information from the Snowden leaks.  There
> > is also quite a bit of information about other governments doing
> 
> > similar things.  Here's one example article:
> If all encrypted traffic is deemed suspicious, then 99.999% of the
> suspicious set -- Amazon transactions, Google searches, SMTP transfers,
> instant messaging, OkCupid profiles, iTunes purchases, and more -- is
> totally clean.  You'd have statistically better odds by arresting random
> people on suspicion of murder.  The policy would be completely
> pants-on-head absurd.

After the recent terrorist attacks in Paris and Brussels some German 
politicians are again arguing that we need Vorratsdatenspeicherung (data 
retention, i.e. storage of all communication meta data for 6 months) in 
Germany to prevent such attacks. Obviously, 99.999 % of this data will be 
completely unrelated to terrorist attacks, i.e. totally clean as you put it. 
You'd have statistically better odds by arresting random people on suspicion 
of terror. Still this completely pants-on-head absurd policy will become 
reality if those German politicians get what they want.


> This leads to a different question: "Is it more likely that this is the
> real pants-on-head absurd policy, or that the _Forbes_ journo has
> profoundly misunderstood the subject?"

Well, the Guardian wrote

"However, alongside those provisions [to minimise data collected from US 
persons; I.K.], the Fisa court-approved policies allow the NSA to:

[...]

• Retain and make use of "inadvertently acquired" domestic communications if 
they contain usable intelligence, information on criminal activity, threat of 
harm to people or property, are encrypted, or are believed to contain any 
information relevant to cybersecurity;"

Full article: 
http://www.theguardian.com/world/2013/jun/20/fisa-court-nsa-without-warrant

Specifically, see Exhibit B, Section 5 (3) a.
http://www.theguardian.com/world/interactive/2013/jun/20/exhibit-b-nsa-procedures-document


Moreover, see the recent article

http://justsecurity.org/19308/congress-latest-rules-long-spies-hold-encrypted-data-familiar/

which claims

"The Intelligence Authorization Act of 2015, which passed Congress this last 
December, should bring the question back to the fore. It established retention 
guidelines for communications collected under Executive Order 12333 and 
included an exception that allows NSA to keep ‘incidentally’ collected 
encrypted communications for an indefinite period of time."


So, you are right, that the articles do not claim that the NSA collects and 
keeps all encrypted communication forever.


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: Thoughts on GnuPG and automation

[Brad Rogers]

On Tue, 3 Mar 2015 21:24:15 +0100
Ingo Klöcker  wrote:

Hello Ingo,

>of terror. Still this completely pants-on-head absurd policy will
>become reality if those German politicians get what they want.

It's not just in Germany:  Politicians across the world utilise similar
scaremongering tactics to justify their paranoid, and xenophobic, vision
of society.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Just coz they do it in the movies, don't mean to say that it's cool
Keep It Clean - The Vibrators


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

Newspeek, (was: Re: Thoughts on GnuPG and automation)

[Matthias Mansfeld]

On 3 Mar 2015 at 21:24, Ingo Klöcker wrote:

[..]
> After the recent terrorist attacks in Paris and Brussels some German
> politicians are again arguing that we need Vorratsdatenspeicherung
> (data retention, i.e. storage of all communication meta data for 6
> months) in Germany to prevent such attacks. 

We here in Germany use newspeek and call this now "Digitale 
Spurensicherung" = "digital forensics"

See https://www.youtube.com/watch?v=ZCSei796yHA
made by our CSU here in Bavaria. Only in German language, but there 
is no difference with or without text. Simplification beyond 
recognition, and everything is fine, just fine and easy... :-/

Regards
Matthias
--
OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc
Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF



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

Re: Thoughts on GnuPG and automation

[Sandeep Murthy]

> On 4 Mar 2015, at 07:24, Ingo Klöcker  wrote:

> After the recent terrorist attacks in Paris and Brussels some German
> politicians are again arguing that we need Vorratsdatenspeicherung (data
> retention, i.e. storage of all communication meta data for 6 months) in
> Germany to prevent such attacks. Obviously, 99.999 % of this data will be
> completely unrelated to terrorist attacks, i.e. totally clean as you put it.
> You'd have statistically better odds by arresting random people on suspicion
> of terror. Still this completely pants-on-head absurd policy will become
> reality if those German politicians get what they want.
> 

In Australia this idea, unfortunately, may become reality - a proposed
change to existing laws to require companies to retain metadata is being
debated in parliament, although public opinion is against data retention.
Hopefully this change will fail.

Once such a data retention law is in place it is dangerous because inevitably
there is a “mission creep” that sets in - it is not hard to imagine one day that
encryption software users, maybe GPG users, will be required to disclose
information about the way they use it.  I think in the UK recently the PM
made some ambiguous comments which can be interpreted as seeking a
ban on end-to-end encryption software by private users on the grounds that
terrorists benefit just as much as ordinary law-abiding citizens from using
encryption.  Of course this shows he just does not understand the issues
involved and this idea will not go anywhere.

Sandeep Murthy
s.mur...@mykolab.com


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

Re: Thoughts on GnuPG and automation

[Matthias Mansfeld]

On 4 Mar 2015 at 7:47, Sandeep Murthy wrote:

[...]
> Once such a data retention law is in place it is dangerous because
> inevitably there is a "mission creep" that sets in - it is not
> hard to imagine one day that encryption software users, maybe GPG
> users, will be required to disclose information about the way they use
> it.  I think in the UK recently the PM made some ambiguous comments
> which can be interpreted as seeking a ban on end-to-end encryption
> software by private users on the grounds that terrorists benefit just
> as much as ordinary law-abiding citizens from using encryption.  Of
> course this shows he just does not understand the issues involved and
> this idea will not go anywhere.

I assume everybody here knows http://xkcd.com/538/

... and stuff like this is law in some countries. Coercive 
detention, or (if we just forget "law, what the f*** is law") some 
fine ideas used against unlawful combatants..

Today in paranoid mode
Matthias

--
Unsere Korrespondenz kann mitgelesen werden. Wollen Sie das 
erschweren, mailen wir uns gerne mit (Open)PGP verschlüsselt.
-- 
Matthias Mansfeld Elektronik * Leiterplattenlayout
Neithardtstr. 3, 85540 Haar; Tel.: 089/4620 093-7, Fax: -8
Internet: http://www.mansfeld-elektronik.de
OpenPGP: http://www.mansfeld-elektronik.de/gnupgkey/mansfeld.asc
Fingerprint: 6563 057D E6B8 9105 1CE4 18D0 4056 1F54 8B59 40EF


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

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 7:31 PM, Robert J. Hansen wrote:

>> This is definitely public information from the Snowden leaks.  There 
>> is also quite a bit of information about other governments doing 
>> similar things.  Here's one example article:
> 
> If all encrypted traffic is deemed suspicious, then 99.999% of the
> suspicious set -- Amazon transactions, Google searches, SMTP transfers,
> instant messaging, OkCupid profiles, iTunes purchases, and more -- is
> totally clean.  You'd have statistically better odds by arresting random
> people on suspicion of murder.  The policy would be completely
> pants-on-head absurd.
> 
> This leads to a different question: "Is it more likely that this is the
> real pants-on-head absurd policy, or that the _Forbes_ journo has
> profoundly misunderstood the subject?"
> 
> Just because something's been published doesn't mean it should be
> trusted.  Bring your brain -- and when someone tells you something that
> supports your worldview, look at that thing hard and twice.

If you are interested, you should read the details.  Because you are missing 
some key details here.  I believe they log all PGP encrypted communication.  
That would be easy for them to do.  I don't know about HTTPS.

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

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:

> On 03/03/15 18:29, Hans of Guardian wrote:
>> Android has an installed base of hundreds of millions.  Desktop UNIX
>> is the exotic system here as compared to Windows, Android, etc.
> 
> I have no idea about how difficult it is to launch the gpg binary with a
> few pipes attached to a few file descriptors and perhaps anything else
> you need.
> 
> But I fail to see why you brought it up.
> 
> I thought we were discussing two alternatives:
> 
> - Call gpg directly
> - Use a library such as GPGME that calls gpg for you
> 
> In both cases, the gpg binary is executed as a separate process. So it
> seems to me any issues with this are the same in both cases. In fact, if
> it indeed is tricky as you say, you're better off if you have a library
> do this for you, so you don't have to get it right in each and every
> application.
> 
> Peter.

In Android, you can't really have shared libraries.  Apps share functionality 
at a higher level (aka Activities and Services).  So GnuPG-for-Android _is_ the 
shared library in effect, since it provides OpenPGP via Activities.

No one is saying that each app should have a custom wrapper for GnuPG.  What I 
think mailpile is saying, and what I'm trying to say is that for programming 
environments where GPGME does not make sense, there should be the ability to 
easily make a native version of what GPGME is doing.

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

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> If you are interested, you should read the details.

Did.  Have.

> Because you are missing some key details here.

In other words, "you're wrong, but I'm not going to present any evidence
or reasoning, I'm just going to make vague statements about how you're
missing details which I am privy to."

> I believe they log all PGP encrypted communication.

At this point, you saying that you believe something -- without
supporting evidence -- no longer carries any weight with me.  If you're
going to present this without evidence, I'm going to reject it without
comment.

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

RE: Thoughts on GnuPG and automation

[Bob (Robert) Cavanaugh]

Native to what? Processor, OS?
I think Peter and the group already adequately answered this: If GPGME is not 
providing an interface that meets Android requirements, then look into how 
GPGME interfaces to GPG and emulate that interface.
For you to request that the interface be changed can be likened to someone 
requesting that I2C be changed because you have a hard time implementing it. 
This is pretty much a non-starter IMHO. Implementing interfaces to existing 
infrastructures is bread-and-butter to software development. Stop asking for 
fundamental infrastructure changes and start solving your problem. The group 
has literally hundreds of m-y that can be used productively to help you do 
this, but harness the group's power in a constructive manner.

Bob Cavanaugh



-Original Message-
From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Hans of 
Guardian
Sent: Tuesday, March 03, 2015 3:55 PM
To: Peter Lebbing
Cc: gnupg
Subject: Re: Thoughts on GnuPG and automation


On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:


In Android, you can't really have shared libraries.  Apps share functionality 
at a higher level (aka Activities and Services).  So GnuPG-for-Android _is_ the 
shared library in effect, since it provides OpenPGP via Activities.

No one is saying that each app should have a custom wrapper for GnuPG.  What I 
think mailpile is saying, and what I'm trying to say is that for programming 
environments where GPGME does not make sense, there should be the ability to 
easily make a native version of what GPGME is doing.

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

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

Re: Thoughts on GnuPG and automation

[Hans of Guardian]

On Mar 3, 2015, at 8:52 PM, Werner Koch wrote:

> On Tue,  3 Mar 2015 14:29, h...@guardianproject.info said:
> 
>> It is actually more difficult to wrap GPGME in Java than to have just
>> rewritten GPGME in Java.  GPGME is a fine API for C/C++, it is a bad
> 
> Sorry, but that is not your problem.  The problem on Android seems to be
> that it is not easy to install anything else than plain Java apps.
> 
> We have GPGME bindings for all kind of languages from Ada over Java to
> Scheme.  Thus I can't see the problem - need another kind of data object
> to be handled in GPGME?  No problem, it can easily be done.  Is the
> event loop the problem?  That is somewhat harder to get right but that
> is always the case if you use a library.
> 
> I don't really understand your complaints given that we worked together
> to port GnuPG to Android.  GPGME is just a small thing on top of it and
> way easier than GnuPG itself.  It has nothing to do with fork+exec -
> GnuPG uses that itself a lot.
> 
> In 2010 we ported GnuPG and GPGME and Kontact (includes KMail) to
> Windows Mobile 6.5.  I can tell you, that was a task but we finally did
> it.  And the problems were not due to GnuPG (even that it ate up many of
> the scarce process slots) but due to the shear amount of memory KDE
> stuff required.  Consider as an example this: On Windows CE (the kernel
> of Windows Mobile), you don't have stdout and stdin, nor is there a way
> to inherit or pass on file descriptors.

And that is why this thread is going on, so hopefully we can come to an 
agreement that there are many areas where GnuPG can be used but GPGME is a bad 
solution to do it.  That is all I ask really from this thread at this point.  
The bizarre Java wrapper of GPGME was not the biggest part of the problem of 
the GnuPG-for-Android port, but it was nonetheless a real problem.   Sure it is 
possible to use GPGME with Java, but it is not good, and ill-fitting APIs make 
for bad software, which in turn often leads to bad security.  It also took a 
lot of time.  In retrospect, I think it would have been quicker to write a 
native GPGME in Java on Android than to continue the work on the gnupg-for-java 
wrapper.

Now I'm trying to convey my experience of what I learned by actually getting 
GPGME working on Android, and how the situation can be improved.  It turns out 
that I came to some quite similar conclusions to the mailpile team: there needs 
to be a shared interface for native frameworks, GPGME is not the way for many 
popular environments.

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

Re: Thoughts on GnuPG and automation

[Robert J. Hansen]

> And that is why this thread is going on, so hopefully we can come to 
> an agreement that there are many areas where GnuPG can be used but 
> GPGME is a bad solution to do it.

Maybe I'm a little irritable here, but -- pretty much everyone who's
ever hacked on GnuPG has found situations where GPGME isn't a good
solution, sometimes for architectural reasons and sometimes for API
reasons and sometimes for language binding reasons and sometimes for
licensing reasons and... etc.

No one has ever said GPGME is the all-purpose, all-in-one solution.  No
one.  So why are we having this discussion?  What was the point in even
bringing it up?

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