Re: Security doubts on 3DES default

2017-03-16 Thread Werner Koch 
On Thu, 16 Mar 2017 15:55, pe...@digitalbrains.com said:

> Perhaps we should either retire ciphers with a 64-bit block length or
> make OpenPGP mandatorily rekey after a few gigabytes of data, so it's no
> longer up to the user to be prudent with large amounts of data.

Those who have large amounts of data to encrypt will anyway use a fast
cipher and this means AES.  Thus the 64 bit block length is in practice
only a theoretical problem.  A more practical problem is how to protect
against arbitrary I/O or storage errors.  Thus in the end you will store
the data anyway in chunks.


Shalom-Salam,

   Werner

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


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

2017-03-16 Thread Robert J. Hansen 
> Perhaps we should either retire ciphers with a 64-bit block length or make
> OpenPGP mandatorily rekey after a few gigabytes of data, so it's no longer
> up to the user to be prudent with large amounts of data.

In the next draft of the RFC, I'd like to see 64-bit-block ciphers go the way 
of the dodo. 



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

Re: Security doubts on 3DES default

2017-03-16 Thread Peter Lebbing 
On 16/03/17 15:21, Robert J. Hansen wrote:
> -- but I'm unaware of any reason why we should not permit using 3DES as a
> symmetric cipher.

Perhaps we should either retire ciphers with a 64-bit block length or
make OpenPGP mandatorily rekey after a few gigabytes of data, so it's no
longer up to the user to be prudent with large amounts of data.

In this stage of the game, it might make more sense to just retire those
ciphers.

Peter.

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



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

RE: Security doubts on 3DES default

2017-03-16 Thread Robert J. Hansen 
> take rjh's caveat with a grain of salt -- GnuPG's interest is in
protecting its
> users.  If the project knows something is bad, we're going to try to
protect
> users from it.

In my defense, I never said GnuPG wasn't going to try to protect users from
dangerous things.  I said that until the RFC changes, 3DES and SHA1 will
remain in the codebase -- which is, I think, the correct position to take.

> probably not,
> but it should probably decline to generate such a thing, in the way that
it
> defaults to generating signatures using SHA256 these days.

Why?  What's the reasoning for refusing to encrypt using 3DES?

I can see "we should refuse to put 3DES in any non-final position in key or
cipher preferences" -- that would make sense: it's the cipher of last
resort, and putting it in non-final position kind of breaks that guideline
-- but I'm unaware of any reason why we should not permit using 3DES as a
symmetric cipher.

3DES is slow and obnoxious but it's not unsafe.  At 168 bits of key material
it's actually stronger than AES128.  (I'm discounting the theoretical
attacks on 3DES, as they require many orders of magnitude more memory than
exist in the entire world.)


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

Re: Security doubts on 3DES default

2017-03-16 Thread Daniel Kahn Gillmor 
On Wed 2017-03-15 07:13:18 -0400, Werner Koch wrote:
> On Tue, 14 Mar 2017 21:54, r...@sixdemonbag.org said:
>
>> So long as you understand GnuPG will not make any changes that break RFC
>> conformance... and dropping SHA1/3DES breaks RFC conformance.
>
> Well, it is possible to use
>
>   --weak-digest SHA1 --disable-cipher-algo 3DES
>
> with gpg.

and some of us have experimented with running this kind of configuration
(at the very least with --weak-digest SHA1) for quite some time now.

take rjh's caveat with a grain of salt -- GnuPG's interest is in
protecting its users.  If the project knows something is bad, we're
going to try to protect users from it.

that said, data in a store-and-forward format (or for persistent
backups) makes it tricky to fully remove something.  Should GnuPG refuse
to decrypt a symmetrically-encrypted message that uses 3DES ?  probably
not, but it should probably decline to generate such a thing, in the way
that it defaults to generating signatures using SHA256 these days.

 --dkg

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

Re: Security doubts on 3DES default

2017-03-15 Thread Robert J. Hansen 
> --weak-digest SHA1 --disable-cipher-algo 3DES

Yeah, but that's ... *bad*.  Breaks most of the Web of Trust, makes most
cert sigs meaningless, removes the fallback cipher ... I think this is a
great example of a cure worse than the disease.  :)

Phil Pennock made a post a bit ago detailing his experiment with
disabling SHA1.  It was informative, to say the least.




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

2017-03-15 Thread Werner Koch 
On Tue, 14 Mar 2017 21:54, r...@sixdemonbag.org said:

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

Well, it is possible to use

  --weak-digest SHA1 --disable-cipher-algo 3DES

with gpg.


Shalom-Salam,

   Werner

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


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

2017-03-14 Thread 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

2017-03-14 Thread 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

Re: Security doubts on 3DES default

2017-03-13 Thread 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

2017-03-13 Thread 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

2017-03-13 Thread 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: Security doubts on 3DES default

2017-03-13 Thread 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

2017-03-13 Thread 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

2017-03-13 Thread 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