Re: private-keys-v1.d

[Daniel Kahn Gillmor]

On Thu 2017-03-09 13:44:19 -0500, Long Si wrote:

> Before migrating to a new system, I exported my GPG secret keys and
> then imported them.

what version of gpg did you have on the old system?  what version on the
new system?

the steps you took sound reasonable to me, as long as the new system had
gpg 2.1.x, so i'm a bit puzzled as to why the import failed for you.

with a bit more info, maybe we can get to the bottom of things,

--dkg

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

Re: Security doubts on 3DES default

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Monday 13 March 2017 at 11:02:48 PM, in
, Robert J.
Hansen wrote:-

> I don't
> know how you'd
> come up with a real-world case where you'd need a
> common hash algorithm
> set for signing purposes.

GnuPG presumably has a reason for defaulting to SHA-1 signatures on a
lot of the messages encrypted to the 30 members' keys on PGPNET. Some
people whose PGPNET group messages have SHA-1 signatures report that
non-group messages they sign and encrypt have SHA-256 signatures.

For what its worth, forcing SHA-256 signatures with a "digest-algo"
line in gpg.conf doesn't cause anybody to shout that there is a
problem. But GnuPG says "gpg: WARNING: forcing digest algorithm
SHA512 (10) violates recipient preferences".

- --
Best regards

MFPA  

After all is said and done, a lot more will be said than done.
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWMcx3V8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5IjuAP9TeNXQReTgAda3IoJYh4b5RzgZMcRR3oILvKAlVo0RFQEA2safGRSwmmHg
b9JMcHEtCHNmR25N1JFouT+Oyj3YIQ2JAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWMcx3V8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8ObICACA4cPYiqk9XkUIy0CNV5BMo4yr
lLw6O9zYh2CQnC5k0A1xnVPDg3ZQLZKufuTP2DUuglKk7f5aEosGkDgm7ukQm8Il
Xkx1Nm7kULTDSZwW0YAXu3IswI8pyUZIyztHps3RYzT2iRVJp2p0P3OJjHTCdfIe
+nLImyOKHV442nd7ylIqbFZ0431O/KWqwFF+OSsg0VJZo0x+mAm0IY6RQuvf3DIO
90BMdh9KmPPeMd2Hm2/x5qN/p/gQhW9xWs1PH1vkDp7dM0OPUMlR4WZCbECPmLuD
MewuH8XK9nG478Z1TFjH8sS2XuDWp0H32C77tkrERAMX3WM/snH7k30pQN+u
=HUGl
-END PGP SIGNATURE-


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

Re: Security doubts on 3DES default

[Robert J. Hansen]

>> Again, required per the spec, and this can be
>> prevented by having one person
>> on the list use a DSA-2048/-3072 key, which forbids
>> SHA-1 usage.
> 
> Really? many of the messages to the PGPNET discussion group [0] have
> SHA-1 signatures. Messages are signed and encrypted to about 30 keys,
> one of which is DSA-2048. Showpref on that DSA-2048 key gives
> Digest: SHA1, SHA256, RIPEMD160.

I was speaking a bit too glibly; I'm sorry about that.

If I'm sending to 30 people it's quite likely I'll wind up using CAST or
3DES, since that's the lowest common denominator.  Cipher preferences
have a complex find-the-best-option algorithm that finds what all
recipients can use, then chooses one from among them -- so finding a
"common denominator" of algorithms is important.

But lowest common denominator for signatures is ... it's uncommon to
encounter such a situation; in fact, in 25 years of using PGP I don't
think I've ever encountered it.  If I sign a message with TIGER192 and
you can't verify it, tough luck.  Given this, I don't know how you'd
come up with a real-world case where you'd need a common hash algorithm
set for signing purposes.

But if there were such a case where there was a lowest common
denominator hash algorithm, DSA-2048 requires a 224-bit hash (and -3072
requires 256), so inclusion of either of those would preclude any
160-bit hash being used; they could not appear in a common algorithm set.



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

Re: Security doubts on 3DES default

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On Monday 13 March 2017 at 3:17:07 PM, in
, Robert J.
Hansen wrote:-

> Again, required per the spec, and this can be
> prevented by having one person
> on the list use a DSA-2048/-3072 key, which forbids
> SHA-1 usage.

Really? many of the messages to the PGPNET discussion group [0] have
SHA-1 signatures. Messages are signed and encrypted to about 30 keys,
one of which is DSA-2048. Showpref on that DSA-2048 key gives
Digest: SHA1, SHA256, RIPEMD160.

[0]  or
.


- --
Best regards

MFPA  

During an eruption - move away from the volcano - not towards it
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQQzrO1O6RNO695qhQYXErxGGvd45AUCWMciEF8UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MzNB
Q0VENEVFOTEzNEVFQkRFNkE4NTA2MTcxMkJDNDYxQUY3NzhFNAAKCRAXErxGGvd4
5FpqAP4oLgKKg22wPXEDbTwkb6VzPgxjU4TL0lHcvT6usOBJUwEA9Ao6k4c55mVf
YwCI3RL3YEnIWC5whHeq0wmJwdSgTQmJAZMEAQEKAH0WIQSzrn7KmoyLMCaloPVr
fHTOsx8l8AUCWMciEF8UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0QjNBRTdFQ0E5QThDOEIzMDI2QTVBMEY1NkI3
Qzc0Q0VCMzFGMjVGMAAKCRBrfHTOsx8l8G5yCACI+IwB8NmwMamZx1ZSnIbXLKLL
fweWhnqvXIy8IKHc51h/sAYFbEu7S8XvHCXjDKJWeUJJja/jfhQG62BzYmhMOSYZ
OLd0op3Cthk9sHBQ/FO2gVkJM88c0M8MqemK7dGtenIHOV23ahjQbQrXr0pXqDfj
9vctTPmCnoGQhp5D+En7E3hiH5a6qdfFa4CCLSeCbs+j7scur55R6IRQCiLSEAXL
QoKJ8+fFecqlSScpgv5o75JvXxmJOmUcuXKfK5LDH0ZGt3C3tJbYHOQFAfZUua6D
XO7jpxLo7N4XOhkCv9H/XVAb5y17w/7RVNv0xuBij7hkr7ac9gxakBgRXB5c
=/wO3
-END PGP SIGNATURE-


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

Re: Interleaving issue

[Werner Koch]

On Sun, 12 Mar 2017 17:36, r...@sixdemonbag.org said:

> sig!31DCBDC01B44427C7 2015-07-16  Robert J. Hansen  14 good signatures

This is a diagnostic which goes to stderr.

The former is fully buffered, the latter is line buffered.  From a
technical view this is all correct but I agree that it is a bit
annoying.  I'll add a fflush right before the stats output which solves
it for this case.  In the meantime you may run

  stdbuf -oL gpg GPGARGS

to also line buffer stdout.


Shalom-Salam,

   Werner


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


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

Re: Security doubts on 3DES default

[Kristian Fiskerstrand]

On 03/13/2017 01:47 PM, Ryru wrote:
> Is my understanding correct or do I miss an important fact? What are
> your thoughts about this behaviour?

See section 13.2 of RFC4880, fyi the behavior changes in the context of
RFC6637.

My thoughts; concerns about 3DES are premature. The focus on algorithms
in general likely so, the likelihood of operational security being the
issue is far greater

-- 

Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk

Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

Qui audet vincit
Who dares wins



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

RE: Security doubts on 3DES default

[Robert J. Hansen]

> According to the gpg2 man page, 3DES is added always as kind of least
> common denominator:

This is required behavior per RFC4880.  Your concern should be addressed to
the IETF OpenPGP working group, not to GnuPG.

> In my opinion this design decision can lead to serious security troubles.
If
> someone, knowingly or not, removed all his/her symmetric encryption
> algorithms in his/her public key, our conversation would only be 3DES
> encrypted.

There is no security risk with 3DES unless you (foolishly) choose to encrypt
vast quantities of data (multiple gigabytes) with the same key.

RFC4880 requires 3DES be used with three independent subkeys, giving it a
technical keyspace of 192 bits, the same as AES192.  However, 24 of those
bits are used for parity and contribute nothing to the security of the
system, meaning it comes in at 168 bits of effective key.  This is a
keyspace about a trillion times larger than AES128's.

There are a couple of *theoretical* attacks on 3DES that reduce it to about
a "mere" 112 bits (still unassailable, but less strong than we'd like).  The
best known attack requires a billion known plaintexts and
100,000,000,000,000,000 gigabytes of RAM.

3DES is even somewhat resistant to quantum computation, as a 168-bit
keyspace is still an 84-bit keyspace even after hitting it with Grover's
algorithm and a large quantum computer.  An 84-bit keyspace can be
brute-forced by people willing to throw huge amounts of resources at the
problem, but it'd be tremendously annoying.  A few years ago when
distributed.net tackled RC5-64 (with a keyspace a millionth the size of a
quantum-attacked 3DES) it took them a large distributed cracking effort and
eighteen months of time.

I don't know who told you that 3DES was insecure.  They misled you.  It is
not insecure.  It is slow, it is ungainly, it has all the aesthetics of a
Soviet worker's housing bloc, and we have better ciphers available to us.

But 3DES has also been turning brilliant cryptanalysts into burned-out
alcoholic wrecks for 40 years.

> I think the same goes for the hashing algorithm SHA1.

Again, required per the spec, and this can be prevented by having one person
on the list use a DSA-2048/-3072 key, which forbids SHA-1 usage.

> Is my understanding correct or do I miss an important fact?

You're missing the boat on the security of 3DES.  You're correct that SHA-1
is unsuitable for use as a hashing algorithm and that usage of it may be
mandated in certain situations.

> What are your thoughts about this behaviour?

Take it up with the IETF OpenPGP working group, not GnuPG.  Get them to
change the RFC.
 
> Wouldn't it be great to raise the minimum encryption and hashing level to
a
> more secure cipher?

The current opinion in the IETF OpenPGP working group is the next iteration
of the standard will probably settle on AES256 and SHA256 as replacement
MUSTs for the current 3DES/SHA-1.  (Other hashes, such as BLAKE2, SHA512,
and SHA-3/Keccak, are also being discussed as optionals.)

However, when this next iteration will be released is anyone's guess.  The
group works painfully slowly.



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

Security doubts on 3DES default

[Ryru]

Hello List

I'm new to this list and joined because I have some security doubts
regarding encryption preferences (setpref/showpref).

According to the gpg2 man page, 3DES is added always as kind of least
common denominator:
8<---
When setting preferences, you should list the algorithms in the order
which you'd like to see them used by someone else when encrypting a
message to your key.  If you don't include 3DES, it will be
automatically added at the end.  Note that there are  many  factors that
go into choosing an algorithm (for example, your key may not be the only
recipient), and so the remote OpenPGP application being used to send to
you may or may not follow your exact chosen order for a given message.
It will, however, only  choose  an  algorithm that  is  present  on  the
preference list of every recipient key.  See also the INTEROPERABILITY
WITH OTHER OPENPGP PROGRAMS section below.
--->8

In my opinion this design decision can lead to serious security
troubles. If someone, knowingly or not, removed all his/her symmetric
encryption algorithms in his/her public key, our conversation would only
be 3DES encrypted.
In a situation in which there are several recipients, e.g. a encrypted
mailing list, one participating public key/person can downgrade the
whole encrypted conversation to every recipient to 3DES instead of lets
say AES256.

I think the same goes for the hashing algorithm SHA1.

Is my understanding correct or do I miss an important fact? What are
your thoughts about this behaviour?

Wouldn't it be great to raise the minimum encryption and hashing level
to a more secure cipher?

Thanks in advance and best regards
Pascal

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

[Solved] Re: Error searching key from keyserver in gpg 2.1.19

[Alexander Strobel]

Am 11.03.2017 um 12:40 schrieb Werner Koch:
> On Fri, 10 Mar 2017 10:26, alexander.stro...@giepa.de said:
> 
>> What's the problem here?
> 
> [Troubleshooting advisory]

D'oh
The problem was sitting before the monitor. GnuPG 2.1 was blocked by my
firewall. GnuPG returns the key from "subset.pool.sks-keyservers.net"
and "pool.sks-keyservers.net".
Thank you for your help!

Best regards
 Alex Strobel



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