Re: A Quick Supplement

[Robert J. Hansen]

> Ah, you got me ;-) So you are a developer?

In my day job I'm a developer, among other things.  However, due to my
taking research funding from the U.S. government in the past, I do not
contribute code to either GnuPG or Enigmail.  I find other, non-code,
ways to help the GnuPG and Enigmail teams.

> Thank you for all you do for the computing community and for taking
> the time to answer my emails in a very amicable manner.

You're quite welcome.  :)


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

Re: A Quick Supplement

[Daniel Villarreal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/18/17 08:36, Robert J. Hansen wrote:
>> ... shouldn't the focus of GnuPG be on security?
> 
> This *is* a security issue.

Since you put it that way, I agree.


> Some ... GnuPG use a ... "random_seed"... must not be backed up or
>  shared ...

And thanks for pointing that out.


> ... Click Enigmail -> About and see if you spot any familiar names
>  there. Maybe Enigmail's usability guy, who's had to wrestle with 
> the problems of importing and exporting keyrings, will have some 
> interesting thoughts.  :)

Enigmail is developed by the Enigmail Team:
...
Usability: Robert J. Hansen

Ah, you got me ;-) So you are a developer?


> Yep [...] [Re: GnuPG FAQ] It's a pretty good FAQ ...

"GNUPG FREQUENTLY ASKED QUESTIONS
Robert J. Hansen et al."

You got me, again !

BTW, Mozilla Firefox on multiple OS's mangled gnupg-faq.txt (was
showing some garbled characters) until I did this modification ...

View -> Text Encoding -> Western
changed to Unicode
and everything shows properly.

> I do not contribute code to GnuPG -- once upon a time I worked on 
> U.S. government contracts, so it's best for the GnuPG project if I
>  don't contribute code.  I still find other ways to contribute, 
> whether that means non-core code contributions (Sherpa), 
> documentation (the FAQ), usability issues (Enigmail), etc.

Thank you for all you do for the computing community and for taking
the time to answer my emails in a very amicable manner.

- -- 
Daniel Villarreal
http://www.youcanlinux.org
youcanlinux at gmail.com
PGP key 2F6E 0DC3 85E2 5EC0 DA03  3F5B F251 8938 A83E 7B49
https://pgp.mit.edu/pks/lookup?op=get=0xF2518938A83E7B49
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJZbqyjAAoJEPJRiTioPntJXGQH/21aD65Z+EiS1g/L1x8K9Cni
38p96LX7dedjizMBC9JMHl5+imE+jhYQ+bEqbC2A85Qo4FdtRQ49nl9JJyUAKq/Y
tVA68SlOTqiX4SxYI+tJ/FvPVK10LT3j5bFsH0Lfi6IyTjAM3Xne2cxEbvQmnLw/
KykKYGiiXhrFp7ne854/J4ka1VdRPezJBAfssmgtrh7s26WSF9GQ9kj/B4q5dHGZ
xiiZkncgm1B0RQo5ya1/wMvHIRzBXcj9BFtA/rcFONjd1QVHMn9R9zpfBrlToPEj
qzN66OdNBMeVRKiYmkm2BU2NzGt1vGUpevZnHkrFnemmZcFG9hWL5Byhbnogyd0=
=jBO6
-END PGP SIGNATURE-

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

How to NOT gnutar files during encryption?

[helices]

We have a simple process that has worked for thousands of files over the
years:
1) Client ZIPs up a bunch of files
2) Client GPG/PGP encrypts that ZIP file
3) Client uploads that encrypted file to us
4) Our production server automatically decrypts the file
5) Our production server automatically unzips that file
6) Our production server automatically distributes those files

Today, we have a new wrinkle.  A new client is using Kleopatra to encrypt
the zip file.

Once we decrypt the file via GPG on Linux, we cannot unzip the file.

After many hours troubleshooting, I discovered that the decrypted "zip"
file is actually inside a TAR file!

Further investigation reveals that Kleopatra is gnuTARring the ZIP file
prior to encryption.

We must have many clients using GPG4WIN, and we have never had this problem
before.

How can this new client NOT gnutar files, and still properly encrypt the
ZIP file?

What are we missing?

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

Re: Changing PINs of German bank card

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Saturday 15 July 2017 at 3:54:07 PM, in
, Brad Rogers
wrote:-

> Card no. CVV & expiry date.


Sorry, tired when I wrote that. On the shopping website, the customer
keys in the long card number, the **expiry date** and the last three
digits from the signature strip. The chip on the card is not involved.



- --
Best regards

MFPA  

If you are afraid to speak against tyranny, then you are already a slave.
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWW6NjV8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5Od/AP9s4+XdlWRPv0NnmZkf7GGAX0qtOJwHy7SQkpdt+IuFnQEAnSj3pv+3TtSq
nUbqtEu1uIcUvUDVAHJxlPKAiU1dPQWJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWW6NoV8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8PRBB/9y/RVTQzuCCyh1jdhcRRXiOaNq
Ua0q5rJ/QRO1Vn2IQmBoXr0KkeJteugIEQ/RvCu9oelwc6LowmjCJ4dug1uSNkkI
huVCKBk1g5uLt4UFH9wCG7LucIZ8UNsEGuL7iwBlfvz1aP3xEw17jMgQgKdZeo/j
En3uhMdBuWuyBLh9qVW0i+ZJ5GPlGYWxiRz0Qcvge1TArZZYcHfLMb9TywHVn+h4
o3v9HZ9+46ccZwAsoTRFQuThqYAc0RX3t611bg1jez51w2c2qq/pcRjEr9q0tvQZ
eQ8I84DXzsjlYbItriqlPs+ZdKikudbFQ9tYHs5PmzM0yL/PSZUhgJWkG/Dx
=igDE
-END PGP SIGNATURE-


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

Re: gpg-agent/pinentry: How to verify calling application

[Hartmut Knaack]

Werner Koch schrieb am 16.07.2017 um 21:17:
> On Sun, 16 Jul 2017 09:30, d...@fifthhorseman.net said:
> 
>> I don't think there's currently any plan to do anything like this, but
> 
> Actually this is implemented since GnuPG 2.1.19 (Debian has 2.1.18,
> though) when used withwith a pinentry from Git after 2017-02-03.  There
> you will see in the titlebar something like
> 
>   [PID]@HOSTNAME (gpg --clearsign)
> 

I hope not to get too far off topic, but I encountered that suspicious
request of pinentry right after loggin into KDE, again. So, with the PID it
provided, I checked with ps aux:

me2486  0.0  0.0  34028  3940 ?SL   21:46   0:00 gpg2 
--enable-special-filenames --batch --no-sk-comments --status-fd 11 --no-tty 
--charset utf8 --enable-progress-filter --exit-on-status-write-error --display 
:0 --ttyname kein Terminal --ttytype xterm --decrypt --output - -- -&14

And pstree outputs:

systemd---systemd---gpg2

When hitting cancel on that pinentry window, I get another window, stating
that kwallet wants to get access to my private key.
Any idea why this is happening or how I should proceed analysing? The only
legit process I would see should be my e-mail client.
Thanks,

Hartmut



0xFAC89148.asc
Description: application/pgp-keys


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

[Announce] Libgcrypt 1.8.0 released

[Werner Koch]

Hello!

The GnuPG Project is pleased to announce the availability of Libgcrypt
version 1.8.0.  This is a new stable version of Libgcrypt with full API
and ABI compatibility to the 1.7 series.  Its main features are support
Blake-2, XTS mode, an improved RNG, and performance improvements for the
ARM architecture.

Libgcrypt is a general purpose library of cryptographic building blocks.
It is originally based on code used by GnuPG.  It does not provide any
implementation of OpenPGP or other protocols.  Thorough understanding of
applied cryptography is required to use Libgcrypt.


Noteworthy changes between version 1.7.0 and 1.8.0:
===

 * New interfaces:

   - New cipher mode XTS
   - New hash function Blake-2
   - New function gcry_mpi_point_copy.
   - New function gcry_get_config.
   - GCRYCTL_REINIT_SYSCALL_CLAMP allows to init nPth after Libgcrypt.
   - New gobal configuration file /etc/gcrypt/random.conf.

 * Extended interfaces:

   - GCRYCTL_PRINT_CONFIG does now also print build information for
 libgpg-error and the used compiler version.
   - GCRY_CIPHER_MODE_CFB8 is now supported.
   - Add Stribog OIDs.  [also in 1.7.4]

 * Performance:

   - A jitter based entropy collector is now used in addition to the
 other entropy collectors.
   - Optimized gcry_md_hash_buffers for SHA-256 and SHA-512.
   - More ARMv8/AArch32 improvements for AES, GCM, SHA-256, and SHA-1.
 [also in 1.7.4]
   - Add ARMv8/AArch32 assembly implementation for Twofish and
 Camellia.  [also in 1.7.4]
   - Add bulk processing implementation for ARMv8/AArch32.
 [also in 1.7.4]
   - Improve the DRBG performance and sync the code with the Linux
 version.  [also in 1.7.4]

 * Internal changes:

   - Libgpg-error 1.25 is now required.  This avoids stalling of nPth
 threads due to contention on internal Libgcrypt locks (e.g. the
 random pool lock).
   - The system call clamp of libgpg-error is now used to wrap the
 blocking read of /dev/random.  This allows other nPth threads to
 run while Libgcrypt is gathering entropy.
   - When secure memory is requested by the MPI functions or by
 gcry_xmalloc_secure, they do not anymore lead to a fatal error if
 the secure memory pool is used up.  Instead new pools are
 allocated as needed.  These new pools are not protected against
 being swapped out (mlock can't be used).  However, these days
 this is considered a minor issue and can easily be mitigated by
 using encrypted swap space.  [also in 1.7.4]

 * Bug fixes:

   - Fix AES CTR self-check detected failure in the SSSE3 based
 implementation.  [also in 1.7.6]
   - Remove gratuitous select before the getrandom syscall.
 [also in 1.7.6]
   - Fix regression in mlock detection.  [bug#2870] [also in 1.7.5]
   - Fix GOST 28147 CryptoPro-B S-box.   [also in 1.7.4]
   - Fix error code handling of mlock calls.  [also in 1.7.4]
   - Fix possible timing attack on EdDSA session key. [also in 1.7.7]
   - Fix long standing bug in secure memory implementation which could
 lead to a segv on free. [bug#3027] [also in 1.7.7]
   - Mitigate a flush+reload side-channel attack on RSA secret keys
 dubbed "Sliding right into disaster".  For details see
 .  [CVE-2017-7526] [also in 1.7.8]

For a list of interface changes relative to the 1.7.0 release see [4].


Download


Source code is hosted at the GnuPG FTP server and its mirrors as listed
at .  On the primary server
the source tarball and its digital signature are:

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.bz2
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.bz2.sig

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

 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.gz
 ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.gz.sig

The same files are also available via HTTP:

 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.bz2
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.0tar.bz2.sig
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.gz
 https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.0.tar.gz.sig

In order to check that the version of Libgcrypt you downloaded is an
original and unmodified file please follow the instructions found at
.  In short, you may
use one of the following methods:

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

 gpg --verify libgcrypt-1.8.0.tar.bz2.sig libgcrypt-1.8.0.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
 

Re: A Quick Supplement

[Robert J. Hansen]

> Sorry if I'm asking dumb questions

Not a dumb question.

> what would be wrong with sync'ing the whole gnupg directory (or the
> whole user profile / home directory) with rsync/duplicity/whatever ?

There are a number of lockfiles, sockets, etc., that live in the
~/.gnupg directory which shouldn't be copied.

> Also, can you point me to a more in-depth explanation on the security
> implications of re-using random_seed? I can imagine what you mean, but
> I'd like to know more.

No, because GnuPG has a ton of different pseudorandom number generators
that it can use.  An in-depth explanation would require knowing specific
versions of your operating system, possibly even which chipsets you're
using (hardware accelerators, etc.) -- and at that point I'm going to
start charging you my consulting rates.  :)

In a nutshell, though: a pseudorandom number generator has some internal
data that it uses to generate the sequences.  If you restore the PRNG to
an earlier state, it'll generate the same numbers over again... at which
point, they're really not random any more.

random_seed is internal data belonging to the PRNG.

Don't share it.  :)


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

Re: A Quick Supplement

[Andreas Heinlein]

Am 18.07.2017 um 15:36 schrieb Robert J. Hansen:
>
>> While it would be nice if it were easier to be able to back up easily
>> as you're suggesting, shouldn't the focus of GnuPG be on security?
> This *is* a security issue.
>
> Some versions of GnuPG use a file called "random_seed", for instance.
> This file contains material for seeding a random number generator, and
> for that reason it must not be backed up or shared between computers: if
> the file doesn't exist it'll be recreated, but if it does... then you've
> just reused RNG seeds on two different computers, which has the
> potential to dramatically reduce the cryptographic security of the code.
>
> If you don't make it easy to back up keys, people won't back up their
> keys.  Then, any minor disaster has the possibility of irreparably
> wrecking their keys and the Web of Trust connections they've carefully
> created.  Disaster recovery is an important part of security, too.
Sorry if I'm asking dumb questions, but given that a) I am using the
same GnuPG version on all machines and b) I am excluding random_seed,
what would be wrong with sync'ing the whole gnupg directory (or the
whole user profile / home directory) with rsync/duplicity/whatever ?

Also, can you point me to a more in-depth explanation on the security
implications of re-using random_seed? I can imagine what you mean, but
I'd like to know more.

Thanks,
Andreas



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

Re: A Quick Supplement

[NdK]

Il 18/07/2017 14:23, Daniel Villarreal ha scritto:

> Have you ever asked Werner about what he thinks about "ease" of
> backing up?"
Security = confidentiality + integrity + availability

If you're not considering availability, you only can have partial security.

BYtE,
 Diego

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

Re: A Quick Supplement

[Robert J. Hansen]

> Have you ever asked Werner about what he thinks about "ease" of
> backing up?"

I have made these observations before, yes.

> While it would be nice if it were easier to be able to back up easily
> as you're suggesting, shouldn't the focus of GnuPG be on security?

This *is* a security issue.

Some versions of GnuPG use a file called "random_seed", for instance.
This file contains material for seeding a random number generator, and
for that reason it must not be backed up or shared between computers: if
the file doesn't exist it'll be recreated, but if it does... then you've
just reused RNG seeds on two different computers, which has the
potential to dramatically reduce the cryptographic security of the code.

If you don't make it easy to back up keys, people won't back up their
keys.  Then, any minor disaster has the possibility of irreparably
wrecking their keys and the Web of Trust connections they've carefully
created.  Disaster recovery is an important part of security, too.

> Werner's company has working for it someone working on Enigmail, which
> lets you do key management, including importing and exporting.

Click Enigmail -> About and see if you spot any familiar names there.
Maybe Enigmail's usability guy, who's had to wrestle with the problems
of importing and exporting keyrings, will have some interesting
thoughts.  :)

> Werner Koch co-founded Free Software Foundation Europe.

So?  He could've been the first man to walk on Mars: it would have no
bearing on whether the difficulty of backing up keyrings is a problem
that needs to be addressed.

> Everyone has the opportunity to make GnuPG better, see the following
> link...

Yep.  Sections 3.8, 3.9, and 3.10 of the FAQ mention this.  You might
also want to check out section 1.2.  It's a pretty good FAQ; someone
clearly put a lot of work into it.  :)

https://www.gnupg.org/faq/gnupg-faq.html

I do not contribute code to GnuPG -- I could: I'm a fairly good C
cryptographic engineer with a strong security background.  However, once
upon a time I worked on U.S. government contracts, so it's best for the
GnuPG project if I don't contribute code.  I still find other ways to
contribute, whether that means non-core code contributions (Sherpa),
documentation (the FAQ), usability issues (Enigmail), etc.

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

Re: A Quick Supplement

[Daniel Villarreal]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/17/17 08:54, Robert J. Hansen wrote:
>> I'm not sure if Rob's routine actually backs up local 
>> signatures... I couldn't see anything explicit about it with a 
>> quick glance at the code. That's fine if you don't use local 
>> signatures at all.
> 
> The step-by-step process I posted last year didn't, because I
> don't use them in my own local policy and thus didn't think about
> them (oops).
> 
> Sherpa doesn't, because GPGME doesn't support the exporting of 
> local signatures.
> 
> It is infuriatingly difficult to come up with a backup method that
>  applies across GnuPG 1.4 - 2.1, is crossplatform, is safe
> (doesn't copy random_seed, etc.), and so on.  Ease of backing up
> has never been a high priority for the GnuPG devs, and it shows.

Have you ever asked Werner about what he thinks about "ease" of
backing up?" He is very accessible on this list, and he often points
out nuances of the coding, versions, etc., and he's very good about
clarifying what people bring up on the list.

While it would be nice if it were easier to be able to back up easily
as you're suggesting, shouldn't the focus of GnuPG be on security?

Werner's company has working for it someone working on Enigmail, which
lets you do key management, including importing and exporting.

Werner Koch co-founded Free Software Foundation Europe.
Everyone has the opportunity to make GnuPG better, see the following
link...
http://fsfe.org/about/basics/freesoftware.en.html

My experience with customer support for German speakers is that the
customers actually study their user documentation very thoroughly
before calling in for help. Let that sink in for a moment.

- -- 
Daniel Villarreal
http://www.youcanlinux.org
youcanlinux at gmail.com
PGP key 2F6E 0DC3 85E2 5EC0 DA03  3F5B F251 8938 A83E 7B49
https://pgp.mit.edu/pks/lookup?op=get=0xF2518938A83E7B49
-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJZbf23AAoJEPJRiTioPntJGXMH/iiCs9EgndE8bKtLMUmvIW0O
1NkHYZ+RaDQuBs1fkVGN8jSoIKR9rBipJIuCpGm+CIQQzVyjHCaTc+oGZI/ILpSY
8t1jAmWkgoWWDHICokGSSC6HAxV3inbHEqGwq6LHNavTg2jVuo2UbZmDbjhFJUmD
DOOKOMAeeDaENiJRCWddx416rG/PqeHnzN1ZZmeYI/RJNzCIbR7XSq1NRlYkf4q4
HmT854z0tyndQ2KzDAXK9XHCnA80Elcs4L7nMGqlwKV0cPaBpits9PutsuZps4Yb
qM38aTB5KXPIOfls43cpsEfOhh2ixFUpQDNgk11q9OzWK2eJhQoENIe6KK/t4gU=
=j5pt
-END PGP SIGNATURE-

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