GnuPG 2.1.19 crashing when listing keys, if tofu-default-policy is "ask"

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


I have been having GnuPG crash with the following message when listing
keys:-

gpg --list-keys
gpg: O j: Assertion "conflict_set" in get_trust failed
(/home/wk/b-w32/speedo/PLAY-release/gnupg-w32-2.1.19/g10/tofu.c:2787)
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.



An internet search on the message leads me to a Debian bug report [0].

I am using GnuPG version 2.1.19 on Windows, running the pre-compiled 
Windows binaries linked from the release announcement.

I have the "with-fingerprint" option in gpg.conf; commenting it out 
makes no difference. 

I also have "tofu-default-policy ask"; changing "ask" to "unknown" 
makes the problem go away.




[0] 



- -- 
Best regards

MFPA  

Something must be done. This is something. Therefore, we must do it.
-BEGIN PGP SIGNATURE-

iQGTBAEBCgB9FiEEs65+ypqMizAmpaD1a3x0zrMfJfAFAljIjO9fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEIz
QUU3RUNBOUE4QzhCMzAyNkE1QTBGNTZCN0M3NENFQjMxRjI1RjAACgkQa3x0zrMf
JfBeeQgAggZsNk8f1fXFkPM0qrhg7j8pMWfBP5UFUCXE5iom01jwwCx57gzITcOl
fMHEWLkW7acCqfWDxrevEpAyiQ+K9dpbOUIgimf8YhhlnF9XUytcHEGopgNq9C5/
h2XeD2UcjY51WPS2Qr+KxMKGZ5QAUEgQuqhoLF4kEzDC4RySg3xU7mfRccah7Qdd
tmZwiAfe8Jjd3CgmWQJhBbBz+OTEt3kQ/D/sLJQl54SO4sy+Wmyx62QR8bK1YXQZ
Q0MMadgMXV0p6EtE71JDuVNctptmFFyEIQwLJownLzoaVC1SXSJLcc+h3Q1oz1k+
03r2DoEdEepo+Prx0iN9m9WZQ2xH1ojVBAEWCgB9FiEEM6ztTukTTuveaoUGFxK8
Rhr3eOQFAljIjPZfFIAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBn
cC5maWZ0aGhvcnNlbWFuLm5ldDMzQUNFRDRFRTkxMzRFRUJERTZBODUwNjE3MTJC
QzQ2MUFGNzc4RTQACgkQFxK8Rhr3eOSBvgEAl+FP34lKrWqeuNBar/fYEdUEIHsu
3hwLbB5gfOXXS3oA/1AHZ4ULp2/YVsyeYSZDsU0O1DSyxRP1+j1Eq92eCQMA
=SXiX
-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]

> Apart from that, as GnuPG is in a kind of symbiosis with
> OpenPGP/RFC4880, I think it's important to discuss this on this mailing
> list (as well).

So long as you understand GnuPG will not make any changes that break RFC
conformance... and dropping SHA1/3DES breaks RFC conformance.

> I agree with you, we have better options than 3DES so we should switch
> to better ciphers as soon as possible.

Everyone agrees.  GnuPG for many years has defaulted to AES.  3DES
exists for RFC conformance.  We've migrated away from 3DES as far as we
can; any further requires a change to the RFC.

> I think it's a question of time till 3DES is broken

This opinion is not shared by the cryptanalytic community as a whole.
We are nowhere near a break in 3DES.

> As mentioned, I'll try to reach them. The support from the GnuPG
> community, on this topic, would be appreciated.

We're already in the working group trying to push this forward.

> Where have you found this information? I only found this draft[0] which
> still contains 3DES and SHA-1.

The WG has a mailing list where these things are discussed.  Also, many
WG members have private asides with other WG members.



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

Re: Security doubts on 3DES default

[Ryru]

Thank you Robert for your response and point of view.

On 03/13/2017 04:17 PM, Robert J. Hansen wrote:
>> 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.

Just because it's required behaviour doesn't mean it's (still) good. ;-)
But I will try contact them.

Apart from that, as GnuPG is in a kind of symbiosis with
OpenPGP/RFC4880, I think it's important to discuss this on this mailing
list (as well).

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

I agree with you, we have better options than 3DES so we should switch
to better ciphers as soon as possible.

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

I think it's a question of time till 3DES is broken, like it was with
SHA-1. To be at least one step ahead of such a mess should be the goal.

> 
>> What are your thoughts about this behaviour?
> 
> Take it up with the IETF OpenPGP working group, not GnuPG.  Get them to
> change the RFC.

As mentioned, I'll try to reach them. The support from the GnuPG
community, on this topic, would be appreciated.

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

Where have you found this information? I only found this draft[0] which
still contains 3DES and SHA-1.

Thanks in advance and best regards
Pascal

[0] https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-01


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