Re: Unattended signing

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Tuesday 24 February 2015 at 10:16:20 PM, in
, Daniel Kahn Gillmor
wrote:

> That is, only a malicious person who manages to
> compromise that key material can make signatures with
> it.  So why are you keeping it around?


To verify existing signatures?

- --
Best regards

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

Two rights do not make a wrong. They make an airplane.
-BEGIN PGP SIGNATURE-

iQF8BAEBCgBmBQJU8CXQXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCM0FFN0VDQTlBOEM4QjMwMjZBNUEwRjU2
QjdDNzRDRUIzMUYyNUYwAAoJEGt8dM6zHyXw0HsH/1+lwgL/jBJ6LeVaRbSKhopG
+kZ6Wer0LxLWxMhde6hNrGfvwAf+j6y5MtLsnREZCK2wOFuLrLCZc4VjJGBX33zs
NMxX0ws2/b+oskJ+tpB6TvaENsnYKdjCfA+QQ00143gNHhvoOaMeMgLw/Lhuyigp
uc6k9l0Gcp8wV6BfnGXHnk6xPQnx9sRBtN5as1x+0Taf1BCfqNEhAfsNfhPxWU10
wD3GhSelvv4FkY/BuBgCfDNptrxsMPQhAGeT3nWHB+Xk+lApUNrAgmORRvemh+w2
BY6pEykRjqUScb/SXwVbItxuA9GgbBVYdWiW9oHsAMseIqxGScQ4upy6oRhDwuOI
vgQBFgoAZgUCVPAl118UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNBQ0VENEVFOTEzNEVFQkRFNkE4NTA2MTcx
MkJDNDYxQUY3NzhFNAAKCRAXErxGGvd45OG5AQD4w0b7WHumsaehjxkpwJwUM998
dLs1pQrWZ7IVqXmM7QEAT5M9hA8LUgW1bgfnq1Ka5v9AbEh5VzSc7id62zQACQU=
=aKz3
-END PGP SIGNATURE-


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

Re: Can't Encrypt in Freebsd 10.1

[Werner Koch]

On Wed, 25 Feb 2015 14:07, michard.anto...@gmail.com said:

> #gpg -r 6349E5E0 -e test.txt
> Abort

You should run it under a gdb to see the reason for the abort.  This
should not happen.

  $ gdb gpg
  gdb> run -r 6349E5E0 -e test.txt
[...]
  gdb> bt



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

German ct magazine postulates death of pgp encryption

[gnupgpacker]

Hello,

there is a discussion ongoing regarding future of pgp/gpg encryption.

German ct magazine has postulated in their last edition that our pgp
handling seems to be too difficult for mass usage, keyserver infrastructure
seems to be vulnerable for faked keys, published mail addresses are
collected from keyservers and so on...

Pls refer to:
Massentaugliche E-Mail-Verschlüsselung gesucht
http://heise.de/-2557237 

Editorial: Lasst PGP sterben!
http://heise.de/-2551008 

M.Marlinspike Blog: GPG And Me
http://www.thoughtcrime.org/blog/gpg-and-me/ 

I am a little bit unhappy about this discussion because pgp still offers
secure end-to-end encryption without the need of a superior CA, no
compromising had been detected so far.

Your positions to this ct approach?

Regards, Chris



___
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

[Hauke Laging]

Am Fr 27.02.2015, 09:45:36 schrieb gnupgpacker:

> German ct magazine has postulated in their last edition that our pgp
> handling seems to be too difficult for mass usage, keyserver
> infrastructure seems to be vulnerable for faked keys, published mail
> addresses are collected from keyservers and so on...

Werner has replied to that (on gnupg...@gnupg.org and here):

http://rem.eifzilla.de/archives/2015/02/24/re-die-schlssel-falle

-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


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

[Peter Lebbing]

On 27/02/15 09:45, gnupgpacker wrote:
> German ct magazine has postulated [...] published mail addresses are 
> collected from keyservers

They are?

I can read German, but it is veeerr slooo. So I'll probably not do that.

But I have a honeypot key on the keyservers that has a computer-generated random
e-mail address that does however exist. Anybody who looks at the name thinks
"huh?" but the purpose is to not catch spammers that simply address kathy@
peter@ john@ and variations on that, because they would be false positives for
the experiment.

Because the experiment is: does having an e-mail address on the keyserver
attract spam?

I reckoned that there's a good chance e-mail harvesters don't do any filtering
on unlikely local parts in the e-mail address; I think they'd rather not spend
effort on that and simply mail any and all addresses you find. That's insanely
cheap to do (since you use a botnet), and filtering might remove actual spam
targets.

So what did this key attract, being on the keyserver for four years now?

22 Nigerian 419 scams. That's it. Twenty-two! They came in batches; I haven't
seen anything since March last year.

I've kept this little experiment (which admittedly is rather small) secret for a
year, to avoid people with an agenda biassing the results. By then I had only
had one 419 scam. Even after I talked about it just a 419 scam every few months.
The latest one will celebrate its first birthday in 3 weeks! Hmmm I think
they might have stopped spamming that address.

I wonder if it says anything that all spams are 419 scams. Do they as a group
collect addresses differently than other spammers? Or is it simply that there is
only one person who harvests keys from keyservers, and his only customers are
419 scammers? Hell, the harvester could be the spammer; just one person.

So.. back to c't. Since they were writing an article, since they're
journalists, they should do some fact checking, right? Do they have proof, or a
strong indication that spammers use the keyservers?

Or is it the crystal ball "yes, but if more people start to use the keyservers,
then it will surely happen"? I've gazed in there and thought the same, but it's
not a fact and neither is the current keyserver network necessary for widespread
OpenPGP usage, IMHO.

Also, I've said it before: instead of saying "Let OpenPGP die", put effort in
getting something accepted by the mainstream that deserves to live! I think
right now we need an alternative for the e-mail infrastructure more than we need
an alternative to OpenPGP for our current e-mail. Work your way from the ground
up with security and privacy as a goal right from the outset. You could keep
legacy interfaces to the end-user (IMAP, SMTP), but the core should be replaced.
Upon this renewed core, we can build security and privacy.

When your housekeeper, mister Jones, is in his 70's and you need a new
housekeeper because the good man is simply getting too old for the job, what do
you say? "Wanted: good housekeeper, for two days a week, ..." etcetera?

Or "Let mister Jones die"?

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

[Hans-Christoph Steiner]

Bjarni Runar Einarsson wrote:
> Hello GnuPG users!
> 
> I just published a follow-up to Smári's blog post about the Mailpile
> team's frustration while working with GnuPG. The post is here:
> 
>
> https://www.mailpile.is/blog/2015-02-26_Revisiting_the_GnuPG_discussion.html
> 
> As it's rather long, I won't paste the whole thing in here, but I do
> welcome any and all feedback. The gist of it is: the GnuPG CLI is not
> very well suited for automation and the 2.x design appears to make some
> things we want to do almost impossible.
> 
> Corrections (if I made any factual errors) will be posted to the web
> ASAP, and I'll link back to this thread in the archives so webby people
> can see your replies. I hope this qualifies as constructive critism!
> 
> As I said on our IRC channel: If we're lucky it'll be a humiliating
> "you're just doing it wrong, here is the solution". ;-)
> 
> Cheers,
>  - Bjarni
> 
> -- 
> Sent using Mailpile, Free Software from www.mailpile.is

As the lead dev on the Android port of GnuPG, I definitely can share your pain
on working with the GnuPG suite.  For example, GnuPG is built heavily around
UNIX assumptions, and Android is not UNIX at all, and it is much further from
UNIX than Windows is.  We ultimately got pinentry working on Android, with
much struggle.  After going through that, I also had lots of grips, which I
probably should have written up like you did.

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.  I think
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 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.

Now all that said, we definitely need to be debating how to improve working
with GnuPG so that we can build software that is intuitive and private by
design, on top of the solid GnuPG track record.  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).

Another possibility is making ASSUAN, the internal protocol between GnuPG
components, the API instead of `gpg --json`. This only works on GnuPG 2.1, as
far as I understand it, since in 2.1, even commands like gpg communicate with
gpg-agent using ASSUAN, and it is actually gpg-agent that does all the work.
Contrary to the mailpile write-ups, I think that having all the work happen in
gpg-agent makes sense, as long as there is a good API to it.

.hc


-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81

___
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

[gnupgpacker]

Thx.

Maybe implementation with an opt-in could preserve publishing of faked keys on 
public keyservers?

So if new key is uploaded an email with verification link is sent from 
keyserver to issuer.

If embedded link is verified by issuer in 10 Minutes => uploaded public key is 
published
If embedded link is NOT verified by issuer in 10 Minutes => uploaded public key 
is deleted

Forums are working with this technique since years.

Regards, Chris

> -Original Message-
> From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of
> Hauke Laging
> Sent: Friday, February 27, 2015 11:59 AM
> Werner has replied to that (on gnupg...@gnupg.org and here):
> http://rem.eifzilla.de/archives/2015/02/24/re-die-schlssel-falle 


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

Re: Can't Encrypt in Freebsd 10.1

[Antoine Michard]

Here the result:

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols
found)...
(gdb) run -r 6349E5E0 -e test.txt
Starting program: /usr/local/bin/gpg -r 6349E5E0 -e test.txt
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...
Program received signal SIGABRT, Aborted.
0x000801981a1a in kill () from /lib/libc.so.7
(gdb) bt
#0  0x000801981a1a in kill () from /lib/libc.so.7
#1  0x0008019181c0 in __stack_chk_fail () from /lib/libc.so.7
#2  0x000801918130 in __stack_chk_fail () from /lib/libc.so.7
#3  0x000801179e43 in _gcry_cast5_amd64_cfb_dec () from
/usr/local/lib/libgcrypt.so.20
#4  0x83e930ecf32ef05e in ?? ()
#5  0x855e231630c0d67c in ?? ()
#6  0xd9ee116bdf79d00b in ?? ()
#7  0x35cac9fc3c713545 in ?? ()
#8  0xf615ffe477355a91 in ?? ()
#9  0x1d49d410956f71f6 in ?? ()
#10 0xc2aeceae9c748a44 in ?? ()
#11 0xa8ba383b702ace6e in ?? ()
#12 0xc190ca44a082735d in ?? ()
#13 0x in ?? ()

So, it's libc problem ???


2015-02-27 8:53 GMT+01:00 Werner Koch :

> On Wed, 25 Feb 2015 14:07, michard.anto...@gmail.com said:
>
> > #gpg -r 6349E5E0 -e test.txt
> > Abort
>
> You should run it under a gdb to see the reason for the abort.  This
> should not happen.
>
>   $ gdb gpg
>   gdb> run -r 6349E5E0 -e test.txt
> [...]
>   gdb> bt
>
>
>
> Shalom-Salam,
>
>Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>


-- 
Antoine Michard
___
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

[Hauke Laging]

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.

Work in progress by me about that (in German):
http://www.crypto-fuer-alle.de/wishlist/keyserver/

In addition to that I will soon publish a description of my idea how 
crypto life can become much easier (especially for those non-cryotp 
loving people) by using a keyserver proxy (one software suitable for all 
clients instead of improving all clients separately or GnuPG itself 
which is rather not going to happen) which can be configured for key 
selection policies.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


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

[Julian H. Stacey]

Hi, Reference:
> From: "gnupgpacker" 
> Date: Fri, 27 Feb 2015 09:45:36 +0100

"gnupgpacker" wrote:
> Hello,
> 
> there is a discussion ongoing regarding future of pgp/gpg encryption.
> 
> German ct magazine has postulated in their last edition that our pgp
> handling seems to be too difficult for mass usage, keyserver infrastructure
> seems to be vulnerable for faked keys, published mail addresses are
> collected from keyservers and so on...
> 
> Pls refer to:
> Massentaugliche E-Mail-Verschlüsselung gesucht
> http://heise.de/-2557237 
> 
> Editorial: Lasst PGP sterben!
> http://heise.de/-2551008 
> 
> M.Marlinspike Blog: GPG And Me
> http://www.thoughtcrime.org/blog/gpg-and-me/ 
> 
> I am a little bit unhappy about this discussion because pgp still offers
> secure end-to-end encryption without the need of a superior CA, no
> compromising had been detected so far.
> 
> Your positions to this ct approach?
> 
> Regards, Chris

CT is usually a good mag. for technical articles; however back in the 1980s 
other UK wind bag journalists regularly sold columns with "Unix about to die!"

PS Some translator engine links:  http://berklix.com/~jhs/trans/

Cheers,
Julian
--
Julian Stacey, BSD Linux Unix C Sys Eng Consultant Munich http://berklix.com
Indent previous with "> ".  Reply Below as a play script.
Send plain text, Not quoted-printable, HTML, or base64.

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

Re: How to send a key to a keyserver?

[Helmut Waitzmann]

Xavier Maillard  writes:

>Helmut Waitzmann  writes:

>> gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net --send-keys -- 
>> 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1
>
>try without the -- stuff:
>
>gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net --send-keys 
>72ABFF0923A87CF22D0ED7C4FDEE765D017077F1

Same error as before.  What else could I do?

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

Re: Thoughts on GnuPG and automation

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/2015 12:02 PM, Hans-Christoph Steiner wrote:
> 
> Bjarni Runar Einarsson wrote:
>> Hello GnuPG users!

..

> 
> 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.  I think 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.
> 

Hear hear, you can't have proper security without proper operational
security surrounding it, and that require an educated population to
use it.

Security is not something that can be solved technically (alone). What
we would need are better ways to educate people, and get it into
school earlier, like the algorithm classes in kindergarden in britain
teching kids algos through games (i.e physical games)

- -- 
- 
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
- 
Manus manum lavat
One hand washes the other
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU8F0yAAoJEP7VAChXwav6UrsH+wWhafqn1fDjW3SE789jdsRm
/9M3e8ZPmueNB4CDadig3/4nFrl5WTcMrXfDMC62xXLTwftu2mSe8K8t7QX2CDRn
VgdTU07gARqnkwEcV+I82Y9SKeUaDfGRmoWUgh0+T3Z4MozXvp23BlFoqcHrKK5H
9ld/Sj5Ncd63JfUQKlEi4kakyGIShctoJ+P0gDje31pqVP65znWw+xi4F06sW0dm
FYPtogg73vtpJkQI6is9Luw7BFR+dE+pWGrxP6166igu1Mwn8I5bg05tqxjFe7dL
weIZffLCd8+iRsNnsr29xbKahsvvfyIrimKZX0nXvuflHftMC2uYARKdx+q8eUw=
=Xs+E
-END PGP SIGNATURE-

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

Re: How to send a key to a keyserver?

[Philip Jackson]

On 26/02/15 18:15, Helmut Waitzmann wrote:
> I tried
> 
> gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net --send-keys -- 
> 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1
> 
> and got the message
> 
> gpg: sending key FDEE765D017077F1 to hkp server pool.sks-keyservers.net
> gpgkeys: HTTP post error 22: The requested URL returned error: 417
> gpg: keyserver internal error
> gpg: keyserver send failed: Keyserver error
> 
> What's wrong here?  Does the problem sit in front of the keyboard?
> 
> Any help will be appreciated.

I cut and pasted your command string and then substituted my key identity for
yours.  It worked ok.  I tried the long id version like you  used and also the
short id version.  All worked ok.

So maybe it was just a keyserver glitch ?

Philip




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

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

Re: How to send a key to a keyserver?

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/2015 12:57 PM, Philip Jackson wrote:
> On 26/02/15 18:15, Helmut Waitzmann wrote:
>> I tried
>> 
>> gpg2 --verbose --keyserver hkp://pool.sks-keyservers.net
>> --send-keys -- 72ABFF0923A87CF22D0ED7C4FDEE765D017077F1
>> 
>> and got the message
>> 
>> gpg: sending key FDEE765D017077F1 to hkp server
>> pool.sks-keyservers.net gpgkeys: HTTP post error 22: The
>> requested URL returned error: 417 gpg: keyserver internal error 
>> gpg: keyserver send failed: Keyserver error
>> 

...

> So maybe it was just a keyserver glitch ?
> 

417 really shouldn't happen for any of the servers in the pool, as it
is explicitly checked that this return code should not be used. What
is the DNS SOA of the response?

For 1.4/2.0, please use --keyserver-options debug,verbose to get more
information about the interaction from the curl helpers, this will be
useful for debugging.

- -- 
- 
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
- 
"Money is better than poverty, if only for financial reasons."
(Woody Allen)
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU8F/dAAoJEP7VAChXwav6RH4IAJyVhZ8mukMrweBggwM6dZbi
qdiU59AOEc2Z3J2r2FX+/CxNW0H44nqoFIJb6UEf1nOKrFqVqy2T6F2CstZ5RgE4
MtT3GQIu3ci/YtwjA0PcXfrhwKvszvPU6UMaCXY5qa2bplNJAumX9dSsMub/JYc8
/wX6BS6IaXyq5g45CousumnK/7PDeJGOVy23+S7QI51pwFQ2Izr0AExGTZX3QnUc
JihmNkBuwGDeoTXhkbWtxpTq8x8dyf0J/TylbDe4DeG2CJHsMmebFcN1MvFqkdi+
n288LmwpCLT4RxASrYfjTfouJBWAxz8vV7RxhiuPFvLSXC+YS9cUz9fj7zmyGiQ=
=1H7l
-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

[Hans-Christoph Steiner]

First, most of these "let PGP die" rants only really apply to OpenPGP email.
GPG does a wonderful job of signing and verifying packages for Debian, Ubuntu,
Fedora, etc.

Second, OpenPGP email exists now, can be installed and used right now, and
provides proven protection for the body of an email message.  Millions of
people know how to use it, and can teach others.

That said, yes, I agree that OpenPGP email is a very flawed system, and we
should also be working on a modern replacement.  But that does not exist, not
really even close.  So if you need privacy in email now, OpenPGP email is the
main realistic choice.

.hc

gnupgpacker:
> Hello,
> 
> there is a discussion ongoing regarding future of pgp/gpg encryption.
> 
> German ct magazine has postulated in their last edition that our pgp
> handling seems to be too difficult for mass usage, keyserver infrastructure
> seems to be vulnerable for faked keys, published mail addresses are
> collected from keyservers and so on...
> 
> Pls refer to:
> Massentaugliche E-Mail-Verschlüsselung gesucht
> http://heise.de/-2557237 
> 
> Editorial: Lasst PGP sterben!
> http://heise.de/-2551008 
> 
> M.Marlinspike Blog: GPG And Me
> http://www.thoughtcrime.org/blog/gpg-and-me/ 
> 
> I am a little bit unhappy about this discussion because pgp still offers
> secure end-to-end encryption without the need of a superior CA, no
> compromising had been detected so far.
> 
> Your positions to this ct approach?
> 
> Regards, Chris
> 
> 
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
> 

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81

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

Re: Re: Thoughts on GnuPG and automation

[Bjarni Runar Einarsson]

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

However, having done the work, I can now state with confidence that the
complexity of our library is not because GnuPG is doing complex things.
It is because the GnuPG command line interfaces for automation are
incomplete and very hard to work with. Libraries might be able to hide
this fact, but that doesn't make the problem go away - sysadmins and
scripters everywhere have to deal with this all the time. It's a real
burden and the source of many, many posts to this list and others.

It's easy for developers to lose sight of the fact that no matter how
many libraries exist, most people first encounter gpg at the command
line. Slowly expanding on that and automating what you have learned is
the Unix way, and it's a wonderful thing. Whatever the reason, GnuPG is
not very good at this today.

Unfortunately lots of existing code depends on these things staying
unchanged, quirks and all. So it may be too late to fix, realistically
speaking. Missing flags could be added, but cleaning up the stuff that
already exists may be impossible. If that's Werner's verdict, then I
totally understand and promise to stop complaining about it.

> Another possibility is making ASSUAN, the internal protocol between GnuPG
> components, the API instead of `gpg --json`. This only works on GnuPG 2.1, as
> far as I understand it, since in 2.1, even commands like gpg communicate with
> gpg-agent using ASSUAN, and it is actually gpg-agent that does all the work.

FWIW, I took a lok at Assuan a while back, and I really like it.
Replacing Assuan with JSON might help the project interface with the
rest of the world, but that's the only argument in its favour; Assuan is
definitely more suited to the things that GPG has to do. There is also a
nice little Python library for interacting with it, so if gpg-agent ends
up exposing an Assuan interface which can do all the stuff people do
with GPGME, then I'll be very happy to switch to that.

Very happy! :-)

> Contrary to the mailpile w

Re: German ct magazine postulates death of pgp encryption

[Ralph Seichter]

> Your positions to this ct approach?

The c't magazine is mostly well respected in Germany and the editors
have some valid points; the latest articles are by no means mindless
rants or PGP-bashing. The thought of letting PGP die as an e-mail
encryption mechanism for the "masses" (the non-tech-savvy average users)
and to have it replaced with something my mother could use is valid. The
c't editorial also clearly states that PGP works perfectly well and is
secure as long as keys are verified, but fake keys and people not
verifying fingerprints are a reality. Alice can't just send an e-mail to
Bob, she needs to acquire and verify Bob's public key first. Compare
this to transparent encryption like Apple's iMessage service uses and it
is not hard to answer which mechanism has better usability. I like and
use PGP like probably every subscriber on this mailing list, but the
number of people I can exchange PGP-encrypted data with is very low when
compared to the total number of my e-mail contacts.

-Ralph

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

HTH,

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

[Johan Wevers]

On 27-02-2015 12:15, Peter Lebbing wrote:

> So.. back to c't. Since they were writing an article,

Isn't this just an article that started with the article of Moxie
Marlinspike about GnuPG that was also on Slashdot yesterday?

(Its at http://www.thoughtcrime.org/blog/gpg-and-me/).

-- 
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html


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

Re: Can't Encrypt in Freebsd 10.1

[Werner Koch]

On Fri, 27 Feb 2015 12:34, michard.anto...@gmail.com said:

> #2  0x000801918130 in __stack_chk_fail () from /lib/libc.so.7
> #3  0x000801179e43 in _gcry_cast5_amd64_cfb_dec () from

I would try to build libgcrypt 1.6.3, which I just released, and check
if that problem still exists.  There used to be a problem when using an
older as(1).  If that still does not work, rebuild libgcrypt with the
configure options --disable-asm and test again.


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

[Werner Koch]

On Fri, 27 Feb 2015 13:23, gnupg...@seichter.de said:

> have some valid points; the latest articles are by no means mindless
> rants or PGP-bashing. The thought of letting PGP die as an e-mail

The article has two problems:

 - It compares an offline system (mail) with online systems (chat
   systems).  You can't compare them unless you also change the headline
   to "Let mail die!".

 - It claims that the protocol is responsible for the problem instead of
   pin-pointing that the mail providers do not take up on it.

Back in the good all days where everyone ran their own MTA and had full
control over their DNS zones, fixing the problems would have been very
easy.  Today virtually everyone uses a large mail provider and thus has
no more control over the own mail address including the zone.

Given this, it is important to convince the mail providers to support
their users doing end-to-end encryption.  It would really be simple.  I
am not calling for a high-end security solution; just for a simple way
to get authoritative information on the key associated with the mail
address.  A few scripts and an optional entry field in the user's mail
account management is all what is required.  With that in place we can
easily fine tune the long existing mechanisms in gpg for key retrieval
and then Jürgen Schmidt would not anymore get mails accidentally
encrypted so someone else.


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

[Steven M. Sawczyn]

It saddens me, but I have to agree.  Raising interest around PGP encryption
is easy, but when it comes to actually using it, that's when people seem to
back off quickly.  I'm not a developer, so have no idea what would be
required, but it seems to me that more focus is needed on making the
experience as seamless and user friendly as possible.  

Steve


-Original Message-
From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Ralph
Seichter
Sent: Friday, February 27, 2015 6:23 AM
To: gnupg-users@gnupg.org
Subject: Re: German ct magazine postulates death of pgp encryption

> Your positions to this ct approach?

The c't magazine is mostly well respected in Germany and the editors
have some valid points; the latest articles are by no means mindless
rants or PGP-bashing. The thought of letting PGP die as an e-mail
encryption mechanism for the "masses" (the non-tech-savvy average users)
and to have it replaced with something my mother could use is valid. The
c't editorial also clearly states that PGP works perfectly well and is
secure as long as keys are verified, but fake keys and people not
verifying fingerprints are a reality. Alice can't just send an e-mail to
Bob, she needs to acquire and verify Bob's public key first. Compare
this to transparent encryption like Apple's iMessage service uses and it
is not hard to answer which mechanism has better usability. I like and
use PGP like probably every subscriber on this mailing list, but the
number of people I can exchange PGP-encrypted data with is very low when
compared to the total number of my e-mail contacts.

-Ralph

___
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: Unattended signing

[Daniel Kahn Gillmor]

On Fri 2015-02-27 03:07:39 -0500, MFPA wrote:
> On Tuesday 24 February 2015 at 10:16:20 PM, in
> , Daniel Kahn Gillmor wrote:
>
>> That is, only a malicious person who manages to
>> compromise that key material can make signatures with
>> it.  So why are you keeping it around?
>
> To verify existing signatures?

Signatures are verified with the public part of the key.  I was only
suggesting to destroy the secret part of the key.

   --dkg

___
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

[Marco Zehe]

Hi everyone!

> Am 27.02.2015 um 13:11 schrieb Kristian Fiskerstrand 
> :
> 
> 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).

Perhaps new emerging services like https://keybase.io can help with better key 
verification if clients like Enigmail and GPGMail (and others) integrate it 
into their workflows. Keybase works in a way that one creates an account, 
uploads one’s public key, and adds verification through at least one other 
means. Those include access to an account on Twitter, Github, Reddit or 
HackerNews, or a proof of domain ownership either by a DNS TXT entry or a file 
on the web server that follows a certain format. That way, the owner of a key 
can stipulate that they are able to access these accounts as well and are 
probably not fake. Of course, the valid point remains that not only the tweet, 
gist or other postings that are proof of ownership should be checked, but also 
other activity on relevant accounts, similar to what Kristian suggested for 
looking up activity on e-mail addresses.

If you’d like to see an example, my profile can be viewed here: 
https://keybase.io/marcozehe.

Marco



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Mark H. Wood]

On Fri, Feb 27, 2015 at 09:45:36AM +0100, gnupgpacker wrote:
> German ct magazine has postulated in their last edition that our pgp
> handling seems to be too difficult for mass usage, keyserver infrastructure
> seems to be vulnerable for faked keys, published mail addresses are
> collected from keyservers and so on...

Whenever someone says that X is too complex for people to use, I
always remember something attributed to Albert Einstein:

   In physics, everything should be made as simple as possible.
   But not simpler.

I think it may be more widely applied.  Some problems are inherently
difficult.  Any successful attempt to remove *inherent* complexity
means that you are now solving a different problem which, while it may
be interesting, might not model reality in a particularly useful way.

It's always good to look for patterns that lead to useful
simplification.  But there comes a point at which no further
simplfication can be done without making the system less useful.

So: how well does PGP model the problems that people face in
communicating securely?  Does that model decompose neatly into
smaller, simpler models that fit well to distinct communities of
communicators?  *Are* there useful clusterings of communication needs,
w.r.t. security, within the community of communicators?

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: 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

[Robert J. Hansen]

> Back in the good all days where everyone ran their own MTA and had
> full control over their DNS zones...

Ah, yes, back when men were men and sheep were scared.  :)

(It's an old American joke about the Old West: "when men were men and
sheep were scared," mostly due to a shortage of women.  I imagine the
Australians probably have their own version of it.)

> Given this, it is important to convince the mail providers to
> support their users doing end-to-end encryption.  It would really be
> simple.

With great respect, Werner, one thing twenty years of watching Classic
PGP and OpenPGP not succeed has taught me is that there is nothing
simple about increasing our user numbers.

In some sense I see GnuPG as a quite successful failure.  For the
original purpose of PGP -- email security -- OpenPGP has turned out to
be a dismal failure.  When used correctly by knowledgeable people it
offers a remarkable degree of protection, but it's condemned to forever
be a niche player.  Yet, in places where PGP was never imagined (signing
operating system packages, for instance), OpenPGP has turned out to be
incredibly important.



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

[Brian Minton]

Yes, but the colon protocol doesn't support things like passphrase entry, etc.

On Fri, Feb 27, 2015 at 9:09 AM, 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.
>
> HTH,
>
> 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

___
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

[Patrick Brunschwig]

On 27.02.15 13:11, 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).

But that's the main primary reason of the article at all. The fact
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.
Furthermore, we need a feature to allow keys to be removed in case the
true owner of an email address requests it.

I know that this collides with today's keyservers and it also collides
with keyservers exchanging keys between each other, but I strongly
believe that this would make keyservers more trustworthy than today.

-Patrick

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

How would Massachusetts College of Pharmacy and Health Sciences Ask The Pharmacist program setup things?...

[Don Warer Saklad]

-Enquiry

Massachusetts College of Pharmacy indicated an interest for the
Ask The Pharmacist program
at
http://www.mcphs.edu/impact/community%20service%20programs/pharmacy%20outreach%20program

How would you inform the MCPHS Ask The Pharmacist program in a way that
they can understand clearly the steps for setting up things?...  all in
all it appears really complicated for most folks !

___
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 02/27/2015 05:26 PM, Patrick Brunschwig wrote:
> On 27.02.15 13:11, 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).
> 
> But that's the main primary reason of the article at all. The fact 
> that anyone can upload _every_ key to a keyserver is an issue. If

No, it is not, it has always been very clear no to rely on the
existence of a key on either a keyserver or on a local keyring without
proper verification and certification

> keyservers would do some sort of verification (e.g. confirmation
> of the email addresses) then this would lead to much more reliable
> data. Furthermore, we need a feature to allow keys to be removed in
> case the true owner of an email address requests it.

Again, no it wont, a key could still be valid even though a second
user adopts a domain name, what should happen to the first key on the
keyserver in such an event, in particular if this is revoked, any
activity from the keyservers on this could lead to misappropriation.
This would be bad for the overall security of the network, it is a
reason the keyservers are add only and should continue to remain so.

> 
> I know that this collides with today's keyservers and it also
> collides with keyservers exchanging keys between each other, but I
> strongly believe that this would make keyservers more trustworthy
> than today.

It collides with security and is a bad idea.


- -- 
- 
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
- 
Nomina stultorum scribuntur ubique locorum
Fools have the habit of writing their names everywhere
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU8JvcAAoJEP7VAChXwav6qyEH/RtQlf3Y/hS02TByKbC/fYxt
LunKjBEucWb06V3H+rU2og0SWwsnXhNq+LxHZsm8X6YaCKDT/zXjtUYyQzuqTbfH
e6lBlXWJK/XyauXWi4RPNX2LhZkx8z+bRpMA6EcFvlZu/+jmWUDLXTCsypzpr77O
Ex+G4Y6yJG4d/atJEMtjqeKPBwhvWCpDBA1Ar4SR5xiXDa3FtNQ/dYxCxDsGuwad
Yk82YHSjeH1CMwmk1rLB1q/btaFwr7ZKeAR1ox8M9xBukfiCeYF09A3RtDPP/yHQ
KTsFg5aaU0IksqJnsiVXOTbX1VRi4e6rho9O762nwbZSw7hfRHoDKOjWIyHsSQU=
=vv+O
-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

[Marco Zehe]

Hi Kristian,

> Am 27.02.2015 um 17:31 schrieb Kristian Fiskerstrand 
> :
> 
> On 02/27/2015 05:26 PM, Patrick Brunschwig wrote:
> > On 27.02.15 13:11, 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).
> >
> > But that's the main primary reason of the article at all. The fact
> > that anyone can upload _every_ key to a keyserver is an issue. If
> 
> No, it is not, it has always been very clear no to rely on the
> existence of a key on either a keyserver or on a local keyring without
> proper verification and certification

And here’s the other problem the main article in c’t mentions: Those keys, 
although faked, were certified. They were certified by equally faked keys which 
resemble keys that are quite well-known. So unless someone had the *real* 
certifying keys installed and could see that those weren’t the same 
certifications as on the forged keys, there was no first and even second glance 
way of recognising these as being faked.

I agree with Patrick’s point that the problem, indeed, lies in the way keys can 
be uploaded to key servers without at least some basic verification of key 
ownership. Something needs to change, and there *must* be put a mechanism into 
place that allows at least some assurance that the person I think the key 
belongs to, is actually the owner. It is not always feasible to verify a whole 
key finger print with the recipient first-hand, except for insecure plain text 
e-mail. For example, if I wanted to have sent that journalist encrypted e-mail 
with some important information, according to the current model, I would have 
had to find out a phone number to reach him, have a business card with his 
key’s finger print on, or met him in person to verify each other’s keys first. 
That’s a damn high entry level, and I think it’s time to re-think some aspects 
of that and integrate some means of ownership verification that avoids at least 
some of the above mentioned problems.

Marco



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Whishlist for next-gen card

[Peter Lebbing]

On 21/02/15 19:54, NdK wrote:
>>> 4 - HOTP PINs for signature/certification keys
>> What generates the HOTP then? Do you type a PIN on the HOTP device to get 
>> the HOTP?
> No need. Just an applet on the phone could do. At least if you aren't
> using the same phone to do the crypto.

I don't understand the practical difference between HOTP and the button
to confirm an action.

As it is now, it is the case that malware can sniff your PIN and use
that to use the card. When you add a button, it knows the PIN, but can't
push the button, so you're back in the loop. The malware needs an action
by you, the user.

If you use HOTP, the malware doesn't know the next HOTP to do an action,
which means it once again relies on you to enter the HOTP.

In the former, the user pushes the button. In the latter, the user
enters the HOTP.

What does the HOTP prevent that the button doesn't? And then I don't
mean "learning the PIN", but something that is a goal of an attacker.
Getting the PIN is only the means, their goal is, for instance, to
decrypt or sign. What goal can an attacker achieve when only the button
is there, not the HOTP?

> Maybe its addition to the security is marginal, but can be *way* more
> practical than having to reenter a complex PIN every time.

I think the security benefit from having to enter your PIN on every
access is already very marginal, and outweighed by the burden of
entering the PIN. In other words, have the card remain unlocked and
ready for use with a single PIN entry. If you're working on a
compromised PC, you're already so screwed that your forced entry of the
PIN each and every time isn't going to help.

To me, the benefit of the button is that it is out-of-band. Re-entering
your PIN every time is in-band, and in my eyes, not worth it.

> If that info is embedded in the signature packet, it could add something
> to the signature value (if the receiving party sees that signature is
> about a txt file and the presented object is a doc, there's something
> wrong and suspect).

Are you proposing that the internal hash state after the hashing of the
document is handed over to the smartcard, after which the smartcard
computes the hash over the signature subpackets that you want protected
this way? It's unclear to me how you see such a thing be implemented
without passing all data to the smartcard.

> That's the fingerprint ssh shows you. It should be computed from the
> complete public key.

I wasn't talking about what it shows me, I was talking about what is in
the challenge that is signed.

I've had a quick look in RFC 4252, with public key user authentication
for SSH2. I don't think there's anything that you can show on a display
that would help the user decide if it were what they wanted to see.
After a really quick glance in the RFC, I see just the username and the
session identifier. The username is hardly unique (I usually use peter),
and the session identifier is a unique number computed for the SSH
session. It's the bit that prevents signature replay attacks but is not
useful to show on a display, since the user can't tell whether it's good
or not: it's just the output of a hash function.

All this is based on a really quick read of documentation I hadn't
consulted before. It could be glaringly wrong. But when you said "it is
the fingerprint", I wondered if you misunderstood or that the
fingerprint is actually part of the challenge. I don't think it is.

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

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/2015 07:37 PM, Marco Zehe wrote:
> Hi Kristian,
> 
>> Am 27.02.2015 um 17:31 schrieb Kristian Fiskerstrand 
>> :
>> 
>> On 02/27/2015 05:26 PM, Patrick Brunschwig wrote:
>>> On 27.02.15 13:11, Kristian Fiskerstrand wrote:
 On 02/27/2015 12:43 PM, Hauke Laging wrote:
> Am Fr 27.02.2015, 12:27:40 schrieb gnupgpacker:

...

>>> 
>>> But that's the main primary reason of the article at all. The 
>>> fact that anyone can upload _every_ key to a keyserver is an 
>>> issue. If
>> 
>> No, it is not, it has always been very clear no to rely on the 
>> existence of a key on either a keyserver or on a local keyring 
>> without proper verification and certification
> 
> And here’s the other problem the main article in c’t mentions:
> Those keys, although faked, were certified. They were certified by
> equally faked keys which resemble keys that are quite well-known.
> So unless someone had the *real* certifying keys installed and
> could see that those weren’t the same certifications as on the
> forged keys, there was no first and even second glance way of
> recognising these as being faked.

This doesn't make much sense, if you don't have a trust path to any of
those other keys their existence is irrelevant, and that is before
taking ownertrust into considerations in the first place (only a dozen
of the keys I've certified have ever been assigned an ownertrust of
marginal and much fewer as full)

What is needed is better education and an increased consciousness in
society at large in considering security and privacy. I will concede
that we have a way to go on making the concepts better understood,
which is increasingly getting difficult due to diffusion from things
like discussions on algorithms and key preferences, that plays a
marginal role in the overall consideration of security (including opsec).

- -- 
- 
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
- 
"I never worry about action, but only inaction."
(Winston Churchill)
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU8MVjAAoJEP7VAChXwav6u+cH/2N+9jRongWuNnRVuoAtWv8l
942GmWX9bTiLrX7BMHLyVyQ3MwEA/nqvHA5g4wGCL2TbJ5IiUvMwEr772YlSbsXH
nMpEV4OVtdaZpCjvoCNtnNxHVG0IHI5PaPoCcAHMxOq3Ed2GIJjCvS/CQjP0XpSy
X96eyqg+IamEQzXF+ON90xstqLG704lFgkE7PI6hkRAzs+wi5mz54sN6YgmSKAUj
A4KS3/1ZORWLG/P0bGYChrtipoXAlW74K3gjG2eLLtFuiqlqG38HEBDYLYPISkyC
iwecqXSbKoq1R8e9c1Xox9bwVyqEDXz+lLahmwMgGtshQEhXkjylVPQ9uHkw8/w=
=gwGH
-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

[Christoph Anton Mitterer]

Hey.

I really cannot understand why ct/heise and some others run these
Anti-OpenPGP campaigns recently, while at the same time hypocritically
claiming they'd be in favour of cryptography for people.


- Per se, users will need to have at least some basic understanding of
cryptography - otherwise anyone could trick them into doing anything.
I'm talking about things like "don't blindly sign others keys", or that
one cannot securely communicated with a peer unless one has more or less
directly exchanged some credentials (e.g. fingerprints) with that.

- Apart from that, OpenPGP isn't that complicated, there are many
front-ends which allow the end user to use gnupg in an easy manner.

- If one wants real security, one will never get around that mutual
authentication / credential-exchange ... and THIS is the actual thing
that makes OpenPGP (in contrast to X.509 and friends) "complicated".


And this is also why I'd call ct/heise anti-cryptographers:

For some months now they demand "cryptography made easy" and to kick
everything else into the can.
They basically demand stuff like "TextSecure" which they advertise as
the best secure messenger out there - while it actually doesn't even
demand users to mutually verify any credentials at all. And even if they
do one hasn't even a way to mark a contact as validated or not (bug open
for ages now).
This is basically what they want: Anonymous cryptography, whose complete
security is based on some good luck whether you've communicated with the
right peer the first time.

But instead of just advertising that crap, they seem to also have went
on some stupid anti-OpenPGP campaign... o.O


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

[Werner Koch]

On Fri, 27 Feb 2015 19:37, marcozehe...@mailbox.org said:

> And here’s the other problem the main article in c’t mentions: Those
> keys, although faked, were certified. They were certified by equally
> faked keys which resemble keys that are quite well-known. So unless

Nope.  According to the questions the author sent me prior to publishing
this article, he only looked at listing presented by the keyserver and
concluded that if the web pages tells self-signature the user id must be
valid (e.g. that second user id on the c't PGP CA).  Now we all know
that keyservers don't do crypto.  As soon as you import that key the
user ids with the faked self-signature are simply ignored and a listing
by gpg won't show them.

To avoid that in the future, the signature listing from the keyservers
may add a note about this.


Salam-Shalom,

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

[Werner Koch]

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.


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

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/2015 08:42 PM, Werner Koch wrote:
> On Fri, 27 Feb 2015 19:37, marcozehe...@mailbox.org said:
> 
>> And here’s the other problem the main article in c’t mentions:
>> Those keys, although faked, were certified. They were certified
>> by equally faked keys which resemble keys that are quite
>> well-known. So unless
> 
> Nope.  According to the questions the author sent me prior to
> publishing this article, he only looked at listing presented by the
> keyserver and concluded that if the web pages tells self-signature
> the user id must be valid (e.g. that second user id on the c't PGP
> CA).  Now we all know that keyservers don't do crypto.  As soon as
> you import that key the user ids with the faked self-signature are
> simply ignored and a listing by gpg won't show them.

the author was fully aware of this, he contacted me back in May 2014
already regarding these keys and asked me to provide a list of keys
that had been signed by some specific keys (the fake CA keys). That
list was provided after a quick lookup - there were 7 keys in total
that had been signed with them.

> 
> To avoid that in the future, the signature listing from the
> keyservers may add a note about this.

Increasing the information on keyservers like this, in particular in
the descriptive parts can be considered, would it suffice to be part
of the standard web interface for keyserver intro, or would it have to
be added on each individual index page?


- -- 
- 
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
- 
Veni vidi velcro
I came, I saw, I got stuck
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU8M5dAAoJEP7VAChXwav6okgIAKEMDKEh4mcd++SWPpCdhlr/
3Uyrz2E3Ifer3QuSBp4nav8XRx43HcvNkCja+RqdGue3RmRYadMUW2FwjLe/lX04
BKZ48/NOXBOC3/JJUQUr5/HkWXLII+rSf13jDu1GixnPUUI7gtECTPJQDevBrQLF
cA5L/hgrNH1Te1y4iZLrzmlEtr95Az8MlwkBmSf+sLCnmG7gW7suKHXsC7JrcRA7
siApTYVqk7PLBq8iMcs40A33+BbYZ1eXUwe3NuNGaPJV/4UjnGaKO4zjvcsk/uY5
YdtW63jtNYtN51lpL67mEMsIzTGfN3FM0L/RC0ud83TeoBbWaaloAufJQJARem0=
=nGok
-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

[Andreas Schwier]

>> But that's the main primary reason of the article at all. The fact 
>> that anyone can upload _every_ key to a keyserver is an issue. If
> 
> No, it is not, it has always been very clear no to rely on the
> existence of a key on either a keyserver or on a local keyring without
> proper verification and certification
So what exactly is the purpose of the keyserver then ? If you expect me
to still verify fingerprints out of band, why would I grab a - probably
bogus key - from a keyserver first place ? I could immediately ask my
peer to send it by mail.

The keyserver would make sense, if my mail client would automatically
fetch the public key from a server, based on the e-mail address of the
sender and some identity data (e.g. fingerprint) in the mail signature.

It would them prompt me, if I want to add that key to my keyring and
optionally perform some additional out-of-band checks.

Because normally I exchange keys in the context of establishing a
relationship with the sender of the e-mail. The context (mail arrived
expectedly, had a phone call just before, answers my request) allows to
me to make a cautious decision about the level of trust I have in the key.

I have been using GNUPG for ages now, but I verified fingerprints only a
hand-full of time. Most of the time, I ask my peer for his public key
and wait for the mail to arrive. For me web-of-trust and key signing
parties don't make any sense, because I'd rather start a communication
with a bogus key and establish trust in my genuine peer from the
conversation we are having.

I like the way Threema does it: I can immediately start a secure
communication and if I need I can elevate the trust I have in the key.
But most of the time I'm communicating with people I know anyway.


-- 

-CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#   #|   Schülerweg 38
   |#   #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
-http://www.cardcontact.de
 http://www.tscons.de
 http://www.openscdp.org
 http://www.smartcard-hsm.com


___
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 Fri, 2015-02-27 at 20:56 +0100, Werner Koch wrote: 
> There is no trust in keyservers by design.  As soon as you start
> changing this you are turning PGP into a centralized system.
Well not necessarily - at least not in the sense of exactly one power
having control over the whole key network (as it would be the case in
X.509).

IMHO the current situation with keyservers isn't perfect:
- Usually (AFAIK), only one of them is used for queries/submissions...
  if that one is evil, that you have a problem (at least until the next
  submission/query).
- Nothing is authenticated (well there is hkps, but the problem here is,
  that one single person holds the control over the effectively only
  used CA... and while I don't think that Kristian is evil ;-) ... it's
  a conceptual problem).
  => thus an attacker can easily do downgrade/blocking attacks... like
  filtering out any revocation certs.
- Nothing is encrypted (so everyone eavesdropping will know that I just
  downloaded the key for nsa-whistleblow...@wikileaks.org... and five
  minutes later I'd be beaten to death).


Ideally, every keyserver would sign his responses (with OpenPGP of
course ;) )... and GnuPG/etc. would ship the keys of (at least some of)
these servers.
This is of course some effort to collect/verify and even then Werner&Co
wouldn't know whether can for example trust me as a keyserver operator
or whether I'm secretly paid by the BND.
But(!) when each request (queries / submissions) would be made to a
handful of randomly chosen keyservers (say 20?), there are good chances
that at least some of them are not evil and any forgery would be at
least noted.

Ideally, gnupg.org would then also run a keyserver, which is always
included in the list.
Why? Well most people don't audit the code of GnuPG, so when they trust
them already with respect to that, they can also trust them with respect
to a keyserver.
And people should be able to specify additional always-in-the-list
keyservers,.. like I would specify my own or ubuntu employees would
specify the one from canonical - if it's running ;) ).


As for the privacy component: The above schema obviously makes
encryption for privacy useless... (an other issues, like keyservers
doing caching, could also make it defeatable).
So I think the way to go here would be Tor.



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

[Announce] GnuPG 1.4.19 released (with SCA fix)

[Werner Koch]

Hello!

We are pleased to announce the availability of a new GnuPG classic
release: Version 1.4.19.  This release mitigates two new side channel
attacks.

Updating any GnuPG 1.4 version to 1.4.19 is suggested!

To update a GnuPG 2.0 or 2.1 version you need to update the shared
library Libgcrypt to version 1.6.3.


What is GnuPG
=

The GNU Privacy Guard (GnuPG) is a complete and free implementation of
the OpenPGP standard as defined by RFC-4880 and better known as PGP.

GnuPG, also known as GPG, allows to encrypt and sign data and
communication, features a versatile key management system as well as
access modules for public key directories.  GnuPG itself is a command
line tool with features for easy integration with other applications.
A wealth of frontend applications and libraries making use of GnuPG
are available.

GnuPG is Free Software (meaning that it respects your freedom). It can
be freely used, modified and distributed under the terms of the GNU
General Public License.

Three different versions of GnuPG are actively maintained:

- GnuPG "modern" (2.1) is the latest development with a lot of new
  features.  

- GnuPG "stable" (2.0) is the current stable version for general use.
  This is what most users are currently using.

- GnuPG "classic" (1.4) is the old standalone version which is most
  suitable for older or embedded platforms.  This announcement is about
  a release of this version.

You may not install "modern" (2.1) and "stable" (2.0) at the same
time.  However, it is possible to install "classic" (1.4) along with
any of the other versions.


What's New in GnuPG 1.4.19
==

 * Use ciphertext blinding for Elgamal decryption [CVE-2014-3591].
   See http://www.cs.tau.ac.il/~tromer/radioexp/ for details.

 * Fixed data-dependent timing variations in modular exponentiation
   [related to CVE-2015-0837, Last-Level Cache Side-Channel Attacks
   are Practical].

 * Detect faulty use of --verify on detached signatures.

 * Changed the PKA method to use CERT records and hashed names.

 * New import option "keep-ownertrust".

 * Support algorithm names when generating keys using the --command-fd
   method.

 * Updated many translations.

 * Updated build system.

 * Fixed a regression in keyserver import

 * Fixed argument parsing for option --debug-level.

 * Fixed DoS based on bogus and overlong key packets.

 * Fixed bugs related to bogus keyrings.

 * The usual minor minor bug fixes.


Getting the Software


Please follow the instructions found at https://gnupg.org/download/ or
read on:

GnuPG 1.4.19 may be downloaded from one of the GnuPG mirror sites or
direct from its primary FTP server.  The list of mirrors can be found
at https://gnupg.org/mirrors.html .  Note that GnuPG is not available
at ftp.gnu.org.

On ftp.gnupg.org you find these files:

 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.bz2  (3627k)
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.bz2.sig

This is the GnuPG 1.4.19 source code compressed using BZIP2 and its
OpenPGP signature.

 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.gz  (5020k)
 ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.gz.sig

This is the same GnuPG 1.4.19 source code compressed using GZIP and its
OpenPGP signature.

 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.19.exe (1586k)
 ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.19.exe.sig

This is GnuPG 1.4.19 compiled for Microsoft Windows and its OpenPGP
signature.  This is a command line only version; the source files are
the same as above.  Note, that this is a minimal installer and unless
you are only in need for the simple the gpg binary, you are better off
using the full featured installer at https://www.gpg4win.org .


Checking the Integrity
==

In order to check that the version of GnuPG which you are going to
install is an original and unmodified one, you can do it in one of
the following ways:

 * If you already have a version of GnuPG installed, you can simply
   verify the supplied signature.  For example to verify the signature
   of the file gnupg-1.4.19.tar.bz2 you would use this command:

 gpg --verify gnupg-1.4.19.tar.bz2.sig gnupg-1.4.19.tar.bz2

   This checks whether the signature file matches the source file.
   You should see a message indicating that the signature is good and
   made by one or more of the release signing keys.  Make sure that
   this is a valid key, either by matching the shown fingerprint
   against a trustworthy list of valid release signing keys or by
   checking that the key has been signed by trustworthy other keys.
   See below for information on the signing keys.

 * If you are not able to use an existing version of GnuPG, you have
   to verify the SHA-1 checksum.  On Unix systems the command to do
   this is either "sha1sum" or "shasum".  Assuming you downloaded the
   file gnupg-1.4.19.tar.bz2, you would run the command like this:

 sha1sum gnupg-1.4.19.tar.bz

[Announce] Libgcrypt 1.6.3 released (with SCA fix)

[Werner Koch]

Hello!

The GNU project is pleased to announce the availability of Libgcrypt
version 1.6.3.  This is a security fix release to mitigate two new side
channel attacks.

Libgcrypt is a general purpose library of cryptographic building blocks.
It does not provide any implementation of OpenPGP or other protocols.
Thorough understanding of applied cryptography is required for proper
use Libgcrypt.


Noteworthy changes in version 1.6.3 
===

 * Use ciphertext blinding for Elgamal decryption [CVE-2014-3591].
   See http://www.cs.tau.ac.il/~tromer/radioexp/ for details.

 * Fixed data-dependent timing variations in modular exponentiation
   [related to CVE-2015-0837, Last-Level Cache Side-Channel Attacks
   are Practical].

 * Improved asm support for older toolchains.


Download


Source code is hosted at the GnuPG FTP server and its mirrors as listed
at http://www.gnupg.org/download/mirrors.html .  On the primary server
the source tarball and its digital signature are:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.bz2 (2436k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.bz2.sig

That file is bzip2 compressed.  A gzip compressed version is here:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.gz (2893k)
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.gz.sig

In order to check that the version of Libgcrypt you are going to build
is an original and unmodified one, you can do it in one of the following
ways:

 * Check the supplied OpenPGP signature.  For example to check the
   signature of the file libgcrypt-1.6.3.tar.bz2 you would use this
   command:

 gpg --verify libgcrypt-1.6.3.tar.bz2.sig libgcrypt-1.6.3.tar.bz2

   This checks whether the signature file matches the source file.  You
   should see a message indicating that the signature is good and made
   by one of the release signing keys. 
   See https://gnupg.org/signature_key.html .

 * If you are not able to use GnuPG, you have to verify the SHA-1
   checksum:

 sha1sum libgcrypt-1.6.3.tar.bz2

   and check that the output matches the first line from the
   following list:

9456e7b64db9df8360a1407a38c8c958da80bbf1  libgcrypt-1.6.3.tar.bz2
4d56b5d754d39acae239f876537672e1dc8298e3  libgcrypt-1.6.3.tar.gz


Copying
===

Libgcrypt is distributed under the terms of the GNU Lesser General
Public License (LGPLv2.1+).  The helper programs as well as the
documentation are distributed under the terms of the GNU General Public
License (GPLv2+).  The file LICENSES has notices about contributions
that require these additional notices are distributed.


Support
===

For help on developing with Libgcrypt you should read the included
manual and optional ask on the gcrypt-devel mailing list [1].  A
listing with commercial support offers for Libgcrypt and related
software is available at the GnuPG web site [2].

If you are a developer and you may need a certain feature for your
project, please do not hesitate to bring it to the gcrypt-devel mailing
list for discussion.


Thanks
==

We have to thank all the people who helped with this release, be it
testing, coding, translating, suggesting, auditing, administering the
servers, spreading the word, and answering questions on the mailing
lists.  Niibe Yutaka did most of the work on fixing the side channel
attacks.  Special thanks to
 a) Daniel Genkin and his team for working with us on the fix for the
"radioexp" attack,
 b) Yuval Yarum and its team for advance information on their new cache
attack and sample code on how to fix it.

Since the start of the GnuPG funding campaign in December several
thousand people have been kind enough to donate a total of 25 Euro
to support this project.  In addition the Linux Foundation gave a grant
of $ 6 for 2015, Stripe.com and Facebook.com each pledged $ 5
per year.

I am amazed by this superb and unexpected support for the GnuPG project.
This will not only allow us to continue the project and hire a second
full time developer but gives us also the resources to improve things
which have been delayed for too long.

*Thank you all !*


Happy hacking,

  Werner


[1] http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
[2] https://www.gnupg.org/service.html

p.s.
This is a announcement only mailing list.  Please send replies only to
the gcrypt-devel at gnupg.org mailing lists.
-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp2avYiYJmeC.pgp
Description: PGP signature
___
Gnupg-announce mailing list
gnupg-annou...@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-announce___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Whishlist for next-gen card

[NdK]

Il 27/02/2015 19:43, Peter Lebbing ha scritto:

> I don't understand the practical difference between HOTP and the button
> to confirm an action.
That the HOTP doesn't need HW support so it can be implemented in
standard smartcards.

>> If that info is embedded in the signature packet, it could add something
>> to the signature value (if the receiving party sees that signature is
>> about a txt file and the presented object is a doc, there's something
>> wrong and suspect).
> Are you proposing that the internal hash state after the hashing of the
> document is handed over to the smartcard, after which the smartcard
> computes the hash over the signature subpackets that you want protected
> this way? It's unclear to me how you see such a thing be implemented
> without passing all data to the smartcard.
Well, IIRC there are cards that require you to compute all but the last
round of the hash, then pass the last block of data and the current
state to let them compute the result (and maybe do the padding before
signing). Something similar could be used for this: the last block will
include the shown data just before the file len.

> I've had a quick look in RFC 4252, with public key user authentication
> for SSH2. I don't think there's anything that you can show on a display
> that would help the user decide if it were what they wanted to see.
> After a really quick glance in the RFC, I see just the username and the
> session identifier. The username is hardly unique (I usually use peter),
> and the session identifier is a unique number computed for the SSH
> session. It's the bit that prevents signature replay attacks but is not
> useful to show on a display, since the user can't tell whether it's good
> or not: it's just the output of a hash function.
For auth it should be the hash of the host's pub key, the same SSH shows
you the first time you connect to that host.

> All this is based on a really quick read of documentation I hadn't
> consulted before. It could be glaringly wrong. But when you said "it is
> the fingerprint", I wondered if you misunderstood or that the
> fingerprint is actually part of the challenge. I don't think it is.
Since the challenge have to be encrypted to the host's pub key, you can
display its hash. I'll have another look at the RFC tomorrow morning...

BYtE,
 Diego.

___
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

[Werner Koch]

On Fri, 27 Feb 2015 21:07, kristian.fiskerstr...@sumptuouscapital.com
said:

> Increasing the information on keyservers like this, in particular in
> the descriptive parts can be considered, would it suffice to be part
> of the standard web interface for keyserver intro, or would it have to
> be added on each individual index page?

I would put it on each index page - at least a link.

"this key listing may harm you - we reject all resonsibility for
 improper use of this device" ;-)


Salam-Shalom,

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

[Christoph Anton Mitterer]

On Fri, 2015-02-27 at 21:12 +0100, Andreas Schwier wrote: 
> So what exactly is the purpose of the keyserver then ?
Find trust paths, signature updates, self signature updates, key
revocation certs (but beware of the issues I've described in my mail a
few seconds before)...

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

[Werner Koch]

On Fri, 27 Feb 2015 21:24, cales...@scientia.net said:

> - Nothing is encrypted (so everyone eavesdropping will know that I just
>   downloaded the key for nsa-whistleblow...@wikileaks.org... and five

Which he will anyway see as soon as you send the mail.  Iff we have an
anonymous network both problems will vanish. 

> Why? Well most people don't audit the code of GnuPG, so when they trust
> them already with respect to that, they can also trust them with respect

Most people run Windows or Android (or use Lenovo stuff) and thus have
anyway no control over their boxes.

> So I think the way to go here would be Tor.

Or a real anonymous overlay network.


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: trust paths (was: German ct magazine postulates death of pgp encryption)

[Hauke Laging]

Am Fr 27.02.2015, 21:25:40 schrieb Christoph Anton Mitterer:
> On Fri, 2015-02-27 at 21:12 +0100, Andreas Schwier wrote:
> > So what exactly is the purpose of the keyserver then ?
> 
> Find trust paths

What could that be good for? If you do not make very strange assumptions 
that could be of any use only if you assign certification trust to 
unknown keys which would be completely crazy.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


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

[Christoph Anton Mitterer]

On Fri, 2015-02-27 at 22:15 +0100, Werner Koch wrote: 
> Most people run Windows or Android (or use Lenovo stuff) and thus have
> anyway no control over their boxes.
To be honest, I don't think that anyone using Windows, Android, MacOS or
any other [semi-]proprietary system actually wants to be secure -
neither do I think that we should waste our resource on securing them
which is per se not possible.


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: trust paths (was: German ct magazine postulates death of pgp encryption)

[Christoph Anton Mitterer]

On Fri, 2015-02-27 at 22:25 +0100, Hauke Laging wrote: 
> > Find trust paths
> What could that be good for? If you do not make very strange assumptions 
> that could be of any use only if you assign certification trust to 
> unknown keys which would be completely crazy.

I meant in the sense that I want to trust e.g. Werner's key but haven't
met him in person yet,... but I might have an indirect trustpath to him
via some other persons (which I do trust).
Obviously I'll need any intermediate keys (and enough of them that I
personally decide it's trustworthy).


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: trust paths

[Hauke Laging]

Am Fr 27.02.2015, 22:30:41 schrieb Christoph Anton Mitterer:

> Obviously I'll need any intermediate keys (and enough of them that I
> personally decide it's trustworthy).

Once more we see the term that confuses nearly everyone:

You personally decide to trust a key – for it's certifications. That is 
not in any way related to the intermediate certifications for this key.

The WoT makes a key *valid*. What is needed for that is your personal 
decision, too, but on another level: That is configured in GnuPG (with 
--completes-needed and --marginals-needed). Unless you decide not to use 
the WoT and make your own signature based on the ones you see.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


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

[Peter Lebbing]

On 27/02/15 21:12, Andreas Schwier wrote:
> I'd rather start a communication
> with a bogus key and establish trust in my genuine peer from the
> conversation we are having.

But what about that Man in the Middle who does nothing more than receive
your message encrypted to their key and forward it to the real recipient
you are building a trust relationship with? That MITM is following and
logging your interesting conversation without either of you noticing...

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

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/2015 09:56 PM, Werner Koch wrote:
> On Fri, 27 Feb 2015 21:07,
> kristian.fiskerstr...@sumptuouscapital.com said:
> 
>> Increasing the information on keyservers like this, in particular
>> in the descriptive parts can be considered, would it suffice to
>> be part of the standard web interface for keyserver intro, or
>> would it have to be added on each individual index page?
> 
> I would put it on each index page - at least a link.
> 
> "this key listing may harm you - we reject all resonsibility for 
> improper use of this device" ;-)

I might use a slightly different wording :) But adding something of
the sort to my TODO list for SKS.

- -- 
- 
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
- 
"Expect the best. Prepare for the worst. Capitalize on what comes."
(Zig Ziglar)
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU8OosAAoJEP7VAChXwav6MxgH/2NMrQwew4ISRGJcrWLiLWyH
Xt/m9euxfkj7DeMRRgGvMVW9ilUZM4q6jZ3dbncBjaMy3mAZv5ct1hbEgqSqWNxg
GlyTyrLXBAC8p+/wSpeNzJGl2j9a5shmV8nxv3SEl7sxoYkbLhWdVUn7Kgph14xE
mJe7VCn7NlqPt9b9YgbfRnI0VsD7aQ8eTwwqSCef5xMi5wdEUHirjkf5BMCV/uLQ
wE7RUGkrV6YkX7H69MjOfrhpdglv0oU4QxQx0qnOCFvY20AIVo3N9jJzt5h+CNvz
YO56foiCQ5+uQcA/4uIpSUXJXUEQlKZunmE3CF6LjL6jStK5F/NF3sraYuL663I=
=krnn
-END PGP SIGNATURE-

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

Re: Whishlist for next-gen card

[Peter Lebbing]

On 27/02/15 21:59, NdK wrote:
> For auth it should be the hash of the host's pub key, the same SSH shows
> you the first time you connect to that host.

I think you're confusing /host/ authentication and /user/
authentication. I was talking about using the auth key on your OpenPGP
card to do user authentication.

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

[Hauke Laging]

Am Fr 27.02.2015, 20:56:00 schrieb Werner Koch:
> 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.

> There is no trust in keyservers by design.  As soon as you start
> changing this you are turning PGP into a centralized system.

That is not true. The main difference between the two is not that OpenPGP 
keyservers must be irrelevant for certificate assessment. The IMHO most 
important difference is that OpenPGP is well prepared for keys being 
certified by several keys. As a result you can configure how a certificate 
becomes valid.

Taking information into account which is generated by keyservers would 
not change this paradigm. Of course, such a feature could be used in a 
wrong way. But what change would that be? From my observation the 
majority of OpenPGP users uses it wrongly. And even the current official 
version of the Windows world's "model implementation" Enigmail makes it 
a pain to use it correctly. (The development version finally got that 
right, incredible...) The GPGTools plugin doesn't even offer you (at 
least not via the normal configuration interface) to do it right.

The right way to select a certificate is:

1) Have a look at one or (if necessary) more (non-synced) keyservers and 
try to find a signature which makes one of the found certificates valid.

2) What now? If there is only one certificate on the keyservers then 
people will use it. Even if it is a fake because the address owner 
either doesn't use OpenPGP at all or wants to avoid the keyservers (as 
spam or privacy protection) and offers his certificate on his web site.

If there are two non-valid certificates left the only question (in 
reality!) is "Use one of them or send unencrypted?" There is no reason 
to ignore additional information like "this entity (which happens to be 
a keyserver) claims to have verified the email address". Of course, this 
information becomes useful only if there is reason to trust this 
particular keyserver (which does not look promising with a DNS round-
robin pool).

You could even do that today by manually checking the pool for a 
validated certificate first and in case of failure one ore more keyservers 
which you happen to know that they verify the email address (like the 
PGP company's one). I don't understand anyway why gpg cannot be 
configured to use several keyservers at once (especially if the first one 
has no match).


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


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

[Hauke Laging]

Am Fr 27.02.2015, 23:05:07 schrieb Peter Lebbing:

> But what about that Man in the Middle who does nothing more than
> receive your message encrypted to their key and forward it to the
> real recipient you are building a trust relationship with?

He does have to do more: He has to intercept the messages or deceive you 
about the email address to use. Both is possible, both are non-triviasl 
tasks so that you also have to ask: If he can to that why assume that he 
doesn't just hack your system?


> That MITM
> is following and logging your interesting conversation without either
> of you noticing...

So would he with unencrypted messages. Certificate validation does not 
appear from nowhere. Either you have it or you don't. And in reality you 
usually have to send the message anyway.

IMHO we especially need education for the masses that they become aware 
that different messages require different security levels (in all areas: 
key security, authentication security and system security). OpenPGP is 
not a model technology in that regard, too.

As you can read German, at least slowly... ;-)
http://www.crypto-fuer-alle.de/wishlist/securitylevel/


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


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

[Kristian Fiskerstrand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/27/2015 11:21 PM, Hauke Laging wrote:
> Am Fr 27.02.2015, 23:05:07 schrieb Peter Lebbing:
> 
>> But what about that Man in the Middle who does nothing more than 
>> receive your message encrypted to their key and forward it to
>> the real recipient you are building a trust relationship with?
> 
> He does have to do more: He has to intercept the messages or
> deceive you about the email address to use. Both is possible, both
> are non-triviasl tasks so that you also have to ask: If he can to
> that why assume that he doesn't just hack your system?
> 
> 

_cracking_ the system (I hack my system every day..) would leave
traces, the same would not necessarily be true for DNS poisioning or
BGP hijacking on the network layer.

- -- 
- 
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
- 
"I have always wished that my computer would be as easy to use as my
telephone.
My wish has come true -- I no longer know how to use my telephone"
(Bjarne Stroustrup, April 1999)
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJU8O7TAAoJEP7VAChXwav6hxkIAI6qRHP4D2aFp9y+BB25CXGD
RU3q4+F4qe0UPjOQP5NRdywxQIzzOwGEjAKwQ8V3ruQo087+Ion+rI81QQ3RUHsn
NFRSOmkxdvEWzyj5zF8exegfJFnGxm0p5kAywIfWKxaZMngMC7TgLSZo7b0HTvcC
1Tl7BcbkNXICFS7yJ0hlQvbnxIe4gzmrALG2EyG+TvGIHk9O6Ks6VqafayXSQw7H
XzMXNQJpjULIpcT/EhfQIr4GrjDDrE6AqImovqKIi9TkdnNHfiI1WTszDjUEwH6c
qhEYPCM29LFcX9mTIpQnONUqacjHieF0TLeJfgISD7j8QTmSOMwXsVOOoB/ijtc=
=d2VX
-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

[Martin Behrendt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 27.02.2015 um 22:28 schrieb Christoph Anton Mitterer:
> On Fri, 2015-02-27 at 22:15 +0100, Werner Koch wrote:
>> Most people run Windows or Android (or use Lenovo stuff) and thus
>> have anyway no control over their boxes.
> To be honest, I don't think that anyone using Windows, Android,
> MacOS or any other [semi-]proprietary system actually wants to be
> secure - neither do I think that we should waste our resource on
> securing them which is per se not possible.

At what point is a system a [semi-]proprietary system?
How many computers are out there where not even a single part of the
hardware (and firmware) is proprietary?
Where do you draw the line? If I would have to guess, I would say, the
device you wrote that sentence with, falls in the category
semi-proprietary...

greetings
Martin

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlTw5C4ACgkQ/6vdZgk46sggswCgyXjGYnul/yxgMoDb7Astu1e+
u4wAnR9JqtMXTAy6MGo3HvzQSBV08m/U
=g1qf
-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

[Hauke Laging]

Am Fr 27.02.2015, 13:11:33 schrieb Kristian Fiskerstrand:

> > 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 is not a higher truth which must not be breached. The other way 
round it is correct, though: It must be possible to run a keyserver 
without making any statements about the certificates.


> 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

I would consider taking that to court ridiculous (for several reasons, 
one being the (also ridiculous) class 1 X.509 certifications) but it 
makes obviously little sense for us to make a mandatory assessment for 
the whole world. That is a decision which everyone who runs a keyserver 
(or intends to) should make himself.

This need not be implemented by the keyserver making signatures. It 
would be enough if there were certificate attributes in the keyserver 
answer. That way these certificates could not easily become valid by some 
not so clever user giving full certification trust to the keyserver's own 
certificate.


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

I could hardly agree more but it is easy to join the "People need to 
understand" game if you are on a mailing list. This becomes much harder 
if you have been working on spreading OpenPGP usage in the nasty real 
world for a while. Like I have. For more than two years I have been 
teaching people myself, seen what is done (and what isn't) at 
Cryptoparties, have tried to use universities and schools for gaining 
new users. So what do we talk about here if in good approximation nobody 
outside this mailing list gives a^W^W cares about that?

We are going to lose this if we don't make usable offers. And in case it 
is not already well known here: I am at the security extremist end of 
the spectrum. I think both OpenPGP and GnuPG are not good enough yet in 
supporting high level security. I am just not willing to ignore the 
other 99.3%.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5


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

[Christoph Anton Mitterer]

On Fri, 2015-02-27 at 22:40 +0100, Martin Behrendt wrote: 
> At what point is a system a [semi-]proprietary system?
> How many computers are out there where not even a single part of the
> hardware (and firmware) is proprietary?
I rather meant Android here, which may have an open source core, but in
fact most people use a binary only installation from a not trustworthy
vendor.


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

[Hugo Osvaldo Barrera]

On 2015-02-27 13:23, Ralph Seichter wrote:
> > Your positions to this ct approach?
> 
> The c't magazine is mostly well respected in Germany and the editors
> have some valid points; the latest articles are by no means mindless
> rants or PGP-bashing. The thought of letting PGP die as an e-mail
> encryption mechanism for the "masses" (the non-tech-savvy average users)
> and to have it replaced with something my mother could use is valid. The
> c't editorial also clearly states that PGP works perfectly well and is
> secure as long as keys are verified, but fake keys and people not
> verifying fingerprints are a reality. Alice can't just send an e-mail to
> Bob, she needs to acquire and verify Bob's public key first. Compare
> this to transparent encryption like Apple's iMessage service uses and it
> is not hard to answer which mechanism has better usability. I like and
> use PGP like probably every subscriber on this mailing list, but the
> number of people I can exchange PGP-encrypted data with is very low when
> compared to the total number of my e-mail contacts.
> 
> -Ralph

iMessages model offers way less security than GPG, and a centrail authority
that all of humanity needs to trust in charge of everything is incredibly
naive.

What if I work for Apple's competition and need to send an extremely
confidential message to my coworkers? I can't possibly trust Apple with
handling my keys transparently for me.

Encryption is clumbersome because that's the price of security and privacy. I
hate having to put the key on the lock every day to open it, but if I don't,
anyone can get in.

Sure, I've heard the arguments like:

* Let's use a globally trusted authority instead: There's no such thing and
  never will be. Someone will always have a valid reason to distrust it.
* Set up your own keyexchange server: Ok, so we're back to GPG and keyrings
  where users need to manually retrieve keys from different places and
  determine if they're the right one or not.

Please, stop spreading the iMessage falacy, it's system offers privacy only
from *some* parties, but not from everyone.

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?


signature.asc
Description: 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

[Mirimir]

On 02/27/2015 01:12 PM, Andreas Schwier wrote:



> So what exactly is the purpose of the keyserver then ? If you expect me
> to still verify fingerprints out of band, why would I grab a - probably
> bogus key - from a keyserver first place ? I could immediately ask my
> peer to send it by mail.

I find keyservers most useful when I receive a signed (and typically
encrypted) email from someone whose public key I don't have. Enigmail
reports an untrusted signature. So I hit Details, and accept its offer
to get the requisite key from (by default) .

If I need the public key of someone new, I first look on .
If it's not there, or on their website or blog, I typically just request
it by email.




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

A forgotten patch?

[Alexander E. Fischer]

Hello,

I recently came to know that Felix von Leitner (Fefe) did a code audit
of GnuPG in 2009. According to him, the patch fixes lots of problems
that might be usable as in attack vectors on GnuPG. It seems however, as
if this patch was never included into upstream GnuPG. Because of that,
he keeps maintaining his patch and offers it freely on his personal
website [1].

Although I don't know him personally, as far I know, Felix von Leitner
is a professional code security auditor and a reputable member of the
Chaos Computer Club. In earlier releases of GnuPG he was even mentioned
for supporting the project [2].

What are the reasons which lead to the patch never being applied?
Is there any archived discussion available about that topic?
Have the problems addressed by the patch been fixed otherwise?

[1]: https://www.fefe.de/
[2]:
http://article.gmane.org/gmane.comp.encryption.gpg.devel/10425/match=felix+von+leitner

Kind regards

Alexander E. Fischer


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

[Marco Zehe]

Hi Chris,

> Am 27.02.2015 um 19:16 schrieb Christoph Anton Mitterer 
> :
> 
> This is basically what they want: Anonymous cryptography, whose complete
> security is based on some good luck whether you've communicated with the
> right peer the first time.
> 
> But instead of just advertising that crap, they seem to also have went
> on some stupid anti-OpenPGP campaign… o.O

I agree! I actually took them up on their offer to contact them for signing my 
public key with their C’t PGPCA key they advertise at the end of the actual 
article (not the editorial) in c’t 6/2015, page 160. But because I had a 
question, I wrote to them first. Took a couple of days before I got a reply, 
and I couldn’t help but ask if they’ve already ditched OpenPGP completely. I 
was sarcastic, and got a very honest reply from another c’t journalist saying 
that that very topic has been heatedly debated at Heise, and that by far not 
everyone agrees with Mr. Schmidt. Their crypto campaign is still in full force 
despite the editorial. So like everywhere, different opinions, and that one 
journalist’s opinion definitely doesn’t speak for all of the folks at c’t or 
Heise in General.

Marco



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Best practice to make one's key known, was Re: German ct magazine postulates death of pgp encryption

[Marco Zehe]

Hi Werner et al,

> Am 27.02.2015 um 20:56 schrieb Werner Koch :
> 
> There is no trust in keyservers by design.  As soon as you start
> changing this you are turning PGP into a centralized system.

OK, then I have a very practical question: Even though this is my fourth or 
fifth attempt at establishing OpenPGP in my daily routine since the mid 1990s, 
I am still confused by what the best way is to make my public key known. So if, 
as you say, key servers are not trusted by design, if I want to spread word 
around my available public key, which source should I put in a signature? While 
reading this list, I have seen quite a number of different approaches. Some put 
their key ID along with the finger print and the URL of a key server. Others 
put a link to the key file on a web server, others just quote their key ID and 
finger print, or only either of those.

I have my key uploaded (and kept current) on key servers as well as on my web 
site(s), and my Impressum links to the copy on my web site rather than the key 
server URL.

So: What’s the best practice advice? (and yes, I looked in the FAQ, but that 
didn’t prove conclusive to me.)

Marco



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 Sat, 2015-02-28 at 07:01 +0100, Marco Zehe wrote:
> So like everywhere, different opinions, and that one journalist’s
> opinion definitely doesn’t speak for all of the folks at c’t or Heise
> in General.
Well, that might be... but with respect to this question, there is only
one correct opinion - at least as long as we have no crypto system that
can do without mutual authentication and still provide mutually
authenticated identities ;-)

And whether or not there are journalists at heise who don't agree, their
current voice seem to be that of an ignorant... and people will read
these articles and the seed of the though that crypto "must be easier"
will be laid :-(





smime.p7s
Description: S/MIME cryptographic 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

[Marco Zehe]

Hi Andreas,

> Am 27.02.2015 um 21:12 schrieb Andreas Schwier 
> :
> The keyserver would make sense, if my mail client would automatically
> fetch the public key from a server, based on the e-mail address of the
> sender and some identity data (e.g. fingerprint) in the mail signature.

FWIW, that’s how GPGMail, the Apple Mail plug-in on OS X, does it, or *can* do 
it (the feature can be disabled). It will fetch keys based on the e-mail 
address and signature. So only if it finds a key on the key server that can 
verify the signature, will it add it to the local key ring. I believe you can 
also do that with Enigmail by editing something on the Key Servers page of the 
*advanced* Enigmail settings dialog. So the Mail plugin doesn’t just add keys 
based on the e-mail address, but needs additional clues that the sender is 
OpenPGP-capable. And so far, I think I’ve only seen it do that with signatures.

> 
> I have been using GNUPG for ages now, but I verified fingerprints only a
> hand-full of time. Most of the time, I ask my peer for his public key
> and wait for the mail to arrive. For me web-of-trust and key signing
> parties don't make any sense, because I'd rather start a communication
> with a bogus key and establish trust in my genuine peer from the
> conversation we are having.

That’s how things have developed for me over the past year since I started 
using GnuPG again.

> I like the way Threema does it: I can immediately start a secure
> communication and if I need I can elevate the trust I have in the key.
> But most of the time I'm communicating with people I know anyway.

Yes, and Threema itself even offers a few levels of potential trust through 
verification of the phone number and/or e-mail address, indicating that the 
other party has established it has access to one or both of these means, 
without actually giving away the phone number or e-mail address. And if one has 
that Threema contact in one’s own address book and chose to look them up on the 
Threema servers, that is also indicated. This is a level of proof of ownership 
I was also referring to earlier, where one can do a bit more to tell others 
„hey, this is really me!“.

Marco



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users