Breaking changes

[Robert J. Hansen]

Here's my own set of suggestions for breaking changes to GnuPG:

1.  End-of-life 1.4 already.

Yes, it's the only option for PGP 2.6.  Yes, it's the only option for
old and out-of-date stuff.  Yes, there will be people who need to
decrypt this stuff.  All of that is true, but *we* don't need to be the
people who cater to their needs.  At this point if you need pre-Web
crypto (which, I remind people, is pretty much what PGP 2.6 is), you
have a specialized need and you need to talk to someone about a custom
solution.  There are companies that specialize in this sort of thing
(like, say, g10 Code).

We should keep the 1.4 source code available, but wash our hands of it
and say it will receive *no* future fixes, not even for security issues
-- and we need to stand on that when people start screaming.

Rationale: as long as we keep GnuPG 1.4 around and even semi-supported,
people will insist on not upgrading.

2.  End-of-life 2.0.

2.2 is the replacement branch for 2.0, and it's been around for ten
months.  Yes, some major distros have incorporated 2.0 into their
long-term support releases.  That's on them, *not* us.  State, "we're
going to continue to give security fixes to 2.0 but that will end
December 31, 2018."

Rationale: 2.3 will be coming out soon.  I can understand supporting 2.2
and 2.3 simultaneously, but 2.0, 2.2, and 2.3 simultaneously seems like
we're dropping 1.4 just to pick up another boat anchor.

3.  In 2.3, make RFC4880bis04 the default.

There's a lot of good stuff in bis04.  Unfortunately, until the WG
restarts there's little in the way of implementations of it.  But it
still exists, and it's the safest thing we've got so far, so let's make
the cutover.  Include an --rfc4880 option for interoperability with
clients that aren't -bis04 compliant.

Rationale: we may only get one chance to make serious breaking changes,
so let's go big or go home.


Let me make it clear: these changes are extreme.  Some knowledgeable
people will say they're too extreme.  I disagree.  Let's get all the
breaking pain over at once, and put GnuPG on track for the future.  And
if defaulting to -bis04 puts pressure on other implementations to
support it, and/or puts pressure on the WG to approve it, well -- I'm
fine with that.

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

Re: Break backwards compatibility

[Jochen Schüttler]

And that is my opinion, too.

Some people have the necessity to decrypt old data, so there should be a
separate tool for them to do exactly that. It's the only way to start
off fresh.

But I believe many people shouting out against the developers really
have no such reason. They are described very well with the word "hater"
and can be disregarded.



Am 21.05.2018 um 05:19 schrieb Mark Rousell:
> On 21/05/2018 02:12, Jochen Schüttler wrote:
>> I'm all for breaking backwards compatibility.
>>
>> What's the worst the haters can do? Turn their back on GnuPG? Shout out
>> really loud once more? I think they should get a life!
> I rather suspect they do have a life supporting scenarios that they
> cannot change that require legacy-decryption capability.
>
> If legacy-decryption was removed entirely from current versions of GnuPG
> then they would simply have to continue using old, unsupported, and
> potentially vulnerable versions. I do not think it is reasonable to just
> cut them off entirely.
>
> As Philipp Klaus Krause [1] and Dirk Gottschalk [2] pointed out above,
> breaking backward compatibility does not have to be (and should not be
> in my opinion) absolute. The ability to decrypt old, legacy-encrypted
> data is, like it or not, still present in the real world and it is
> therefore surely proper for GnuPG to retain the ability to decrypt such
> data in maintained code (albeit whilst requiring users to take action to
> make changes to their configuration to be able to continue decrypting
> such data using GnuPG).
>
> I agree with those who say that there is no need for mail clients to be
> able to decrypt legacy-encrypted data.
>
>
>
>
> [1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060473.html
> [2] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060474.html
>
>
>
> ___
> 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: Break backwards compatibility already: it’s time. Ignore the haters. I trust you.

[Jean-David Beyer]

On 05/20/2018 08:51 PM, Jeremy Davis wrote:
> I just read the awesome article "Efail: A Postmortem" by Robert Hansen.
> 
> Thanks for this Robert. Great work!
> 
> As suggested by Robert, I've signed up to say:
> 
> Break backwards compatibility already: it’s time. Ignore the haters. I
> trust you! :)
> 

One of the problems with Windows is that they preserved the backwards
compatibility for far too long, so they could never clean it up enough
to make it any good. I admit that Windows 7 is better than Windows XP
that was much better than Windows 95.

I wonder just how much complexity there is in my FiOS box to convert the
fiber-optic to plain old telephone service that must still be compatible
with my old rotary dial telephone that requires 90 volt 20 cycle power
to ring the bell. And all my electronic telephones with electronic
ringers that must be protected from that 90 volt ringing current.

Can you imagine the redesign that would be required so I could start the
gasoline engine in my Prius with a hand crank in the front?

-- 
  .~.  Jean-David Beyer  Registered Linux User 85642.
  /V\  PGP-Key:166D840A 0C610C8B Registered Machine  1935521.
 /( )\ Shrewsbury, New Jerseyhttp://linuxcounter.net
 ^^-^^ 23:05:01 up 4 days, 6:55, 1 user, load average: 4.04, 4.05, 4.07

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

Re: Break backwards compatibility

[Mark Rousell]

On 21/05/2018 02:12, Jochen Schüttler wrote:
> I'm all for breaking backwards compatibility.
>
> What's the worst the haters can do? Turn their back on GnuPG? Shout out
> really loud once more? I think they should get a life!

I rather suspect they do have a life supporting scenarios that they
cannot change that require legacy-decryption capability.

If legacy-decryption was removed entirely from current versions of GnuPG
then they would simply have to continue using old, unsupported, and
potentially vulnerable versions. I do not think it is reasonable to just
cut them off entirely.

As Philipp Klaus Krause [1] and Dirk Gottschalk [2] pointed out above,
breaking backward compatibility does not have to be (and should not be
in my opinion) absolute. The ability to decrypt old, legacy-encrypted
data is, like it or not, still present in the real world and it is
therefore surely proper for GnuPG to retain the ability to decrypt such
data in maintained code (albeit whilst requiring users to take action to
make changes to their configuration to be able to continue decrypting
such data using GnuPG).

I agree with those who say that there is no need for mail clients to be
able to decrypt legacy-encrypted data.




[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060473.html
[2] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060474.html

-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162
 
 
 

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

Re: A postmortem on Efail

[Mark Rousell]

On 20/05/2018 21:32, Damien Goutte-Gattat via Gnupg-users wrote:
> On 05/20/2018 08:45 PM, Mark Rousell wrote:
>> I think it is important that they can still do this with a maintained
>> (2.x.y) code base.
>
> Support for PGP 2 has already been dropped from the current stable
> branch, I don't think it will ever be brought back. But the 1.4.x
> branch *is* maintained, even if only for critical bugfixes.

I think you mean that support for 2.0.y has been dropped, surely? When I
wrote "2.x.y" above I meant that users should be able to continue
decrypting legacy-encrypted data (albeit with a change of
commands/options compared to the present) with whatever the
currently-supported version of 2.something is at any point in the future.


-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162
 
 
 

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

Break backwards compatibility

[Jochen Schüttler]

I'm all for breaking backwards compatibility.

What's the worst the haters can do? Turn their back on GnuPG? Shout out
really loud once more? I think they should get a life!


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

Break backwards compatibility already: it’s time. Ignore the haters. I trust you.

[Jeremy Davis]

I just read the awesome article "Efail: A Postmortem" by Robert Hansen.

Thanks for this Robert. Great work!

As suggested by Robert, I've signed up to say:

Break backwards compatibility already: it’s time. Ignore the haters. I 
trust you! :)


Cheers,
Jeremy

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

Re: A postmortem on Efail

[Mirimir]

On 05/19/2018 11:44 PM, Aleksandar Lazic wrote:
> Hi Robert.
> 
> On 20/05/2018 02:26, Robert J. Hansen wrote:
>> Writing just for myself -- not for GnuPG and not for Enigmail and
>> definitely not for my employer -- I put together a postmortem on Efail.
>> You may find it worth reading.  You may also not.  Your mileage will
>> probably vary.  :)
>>
>> https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08
> 
> As a long time reader and partly gpg user I would like to thank you for
> the post.
> 
>>From my point of view must be something more behind the curtain.
> 
> I do not want to create a conspiracy theory but it's wiggy that
> EFF favors *NO* security ,pgp or s/mime, instead to fix the current
> possibilities and promote signal.

I read the EFF warning as a temporary measure, to prevent adversaries
from sending cyphertext, and getting plaintext back. Until these
exploits were blocked. And if necessary, to use Signal in the interim.



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

Re: A postmortem on Efail

[mick crane]

On 2018-05-20 07:26, Robert J. Hansen wrote:

Writing just for myself -- not for GnuPG and not for Enigmail and
definitely not for my employer -- I put together a postmortem on Efail.
You may find it worth reading.  You may also not.  Your mileage will
probably vary.  :)

https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08


I do applause here because I needed to sign up or something to applaud 
on the link.


mick

--
Key ID4BFEBB31

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

Re: A postmortem on Efail

[MFPA]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi


On Sunday 20 May 2018 at 2:51:40 PM, in
,
Dirk Gottschalk via Gnupg-users wrote:-


> I think the backwards compatiblity should be broken
> to improve things.

Backwards compatibility was already broken when support for old-style
keys was dropped.

- --
Best regards

MFPA  

Act normal and the crowd will accept you.
Act deranged and they will make you their leader.
-BEGIN PGP SIGNATURE-

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCWwIMi18UgAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+kbJAQC0LoNl/BRkjw5j64djAI/nf5ACSXHgBrYgITWQ82E8xQEAyfdBkG1hSheZ
qGNWPBW6UGvMurH63ToMLKZFk5rG0g6JApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCWwIMi18UgAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/6bAD/4ojk4qRSK8VWWmwvo3YDa8kckE
fQc2rJl2WT+ff5J9yhFFtHKzGjADjurmKjKv7qnzTOdYROxYm4k4wt0ZJ8vbmf2L
X5DvKol/Y2mxAHUINpu3DmiJyPGUU3cwW7Fh5S/syj/QYUhXrQwb3rFAm9wo+IAK
ja8R5yDWAbKzOKGIVtD17Na7lwq4rH+GXoqakJO3ZfizrS16plfUOf00DSc04Jpg
oiRiA1b8O3ngxP2ly+wpP1OHngNm8X4/T12GWv4IpngTRnAM5zajO99ym0X/mfKN
HI8Xo/3xxU/i2j2ImNHJhRaXti41GV8fqXl+KbbCXIgTxyvwI/7Pvxm1S0lW+3qa
A4g7WNDRlA3BW9cmk7VzOMdXOFhKqX6D+uHE+BHvOS1LAPkGwEVFb9kQi3sEfjTm
2h8VfuNOHzonxWCXk6zLrajxSnPf34rDBuHpqK56N/wY7tBM3do7QT+A5zzJYaJD
wRlG9KYSajBj89wlDS0XIb6MSNaf6kQ+kfaHztvrK1lm0MpBjh3zE5VipR5UZgk/
O/j/dLBuB1dZzYvLd7kB2hUrAumf2QorhKWF74Gm9joFAqI2Kf930Gb06p8oVm++
0lH53vkrR9JDx/wbLqRJPWbsr81Yk6s5kOubZ+oRanHo1KdLqj+jqdnSebEd6yHc
6BdR+GSh02rmrJ6Ovw==
=XAW/
-END PGP SIGNATURE-


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

Re: A postmortem on Efail

[Phil Pennock]

On 2018-05-20 at 02:26 -0400, Rob J Hansen wrote:
> https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08

Excellent post.  I favor breaking backwards compatibility and including
in the shipped README a description of "The conditions under which we
anticipate future backwards compatibility breaks".

Maintaining code, with the added code-paths, for handling obsolete
crypto has a cost.  Rarely exercised code-paths are security attack
surface.

I favor:

1. Branch GnuPG 1.x, remove all ability to encrypt or generate
   signatures, have something like "gpgv" but able to decrypt too (so
   still needs access to private keys).
   Call it `gpg-legacy-reader`.  The name makes it clear that future
   updates won't add new crypto support (until such time as something
   else has to be declared legacy).
   Explicitly state that the legacy reader must not be automatically
   used in an online mode which enables oracles and that timing attacks
   are out-of-scope.  Simplify.  Do not support people deploying this to
   untrusted hardware platforms or VMs where they need to defend against
   other users/occupants.  This should be a last-resort tool,
   invoked/triggered manually.

2. Drop all support, always, for non-MDC and other ancient modes,
   algorithms and packet formats from GnuPG.  Simplify the code-base,
   reduce the burden on the maintainers for the actively maintained
   branch.

3. _Possibly_ consider an API in gpgme to trigger using
   gpg-legacy-reader behind the scenes, to make it easier for
   mail-clients to have a Big Red Decrypt Button to deal with ancient
   crap.  Make it clear that this MUST NOT be automatically used and
   that the user should be prompted with warnings of the danger.

4. Get together actual MUA maintainers who are users of the GnuPG
   code-base in a mailing-list and hammer out details of "what should be
   done about old mail".  Cryptographers have long said to decrypt
   inbound mail and re-encrypt it to a storage key, which can
   periodically be rotated, but AFAIK mail-clients don't have sane ways
   to do this.  There's no handling of recording verification state of
   things such as DKIM/ARC on the _original_ message in such a way that
   it could be used in future; perhaps a client signing key for a new
   header, only used to add to headers in the mailstore?  Without all
   the need for canonicalization, could be much simpler than DKIM.
   There's no tooling/expectations around lifecycle of reencryption when
   using open protocol mailstores via IMAP, there's no discussion of key
   management and recovery, there's no discussion of impact upon
   backups.  Instead, we have a lot of talking at the "nobody should do
   that" level and no contributions to actual practices to keep people
   from having to do "that".  It's time for this to change.
   I don't know if the MTA side can do _anything_ to help here, but if
   there's anything sane the MTA side can do to help, I can work to get
   Exim doing it.

If there's anything I can do to help, please let me know.

-Phil


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

Re: A postmortem on Efail

[Jürgen Polster]

Am 20.05.2018 um 09:28 schrieb Robert J. Hansen :

>> Break backwards compatibility already: it’s time. Ignore the haters. I
>> trust you.
> 
> :) :) :) :) :)

Yes, please! I DO trust you!

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

A postmortem on Efail

[Damien Goutte-Gattat via Gnupg-users]

On 05/20/2018 08:45 PM, Mark Rousell wrote:

I presume that one day the 1.x.y code will reach end of life.


There's no plan to terminate the 1.x branch. It will not gain any new 
features, but as stated by Werner Koch a few months ago, it "will be 
kept alive for use with PGP 2 encrypted and signed data" [1].




I think it is important that they can still do this with a maintained (2.x.y) 
code base.


Support for PGP 2 has already been dropped from the current stable 
branch, I don't think it will ever be brought back. But the 1.4.x branch 
*is* maintained, even if only for critical bugfixes.



Damien


[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-January/059815.html



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

Re: A postmortem on Efail

[Mark Rousell]

On 20/05/2018 20:16, Damien Goutte-Gattat via Gnupg-users wrote:
> On 05/20/2018 02:51 PM, Dirk Gottschalk via Gnupg-users wrote:
>> It would be possible to implement something like --legacy to
>> re-enable the old functionality.
>
> For information, for the problem at hand, two things have been done in
> that direction:
>
> In GnuPG itself: GnuPG will now error out when attempting to decrypt
> *any* message that is not integrity-protected, *unless* the
> --ignore-mdc-error flag has been set. This has only been done in the
> master branch of GnuPG (to be released as GnuPG 2.3 at some point),
> *not* in the current stable 2.2 branch.
>
> In GpgME: GpgME will return a failure when attempting to decrypt *any*
> message that is not integrity-protected, inconditionnally and even if
> GnuPG itself only emits a warning.
>
> What this all means is that all clients using GpgME will lose the
> ability to decrypt old, unprotected message upon the next GpgME
> release (i.e., those clients will be completely immune to Efail even
> if they currently ignore the no-MDC warning). Users will still be able
> to decrypt such unprotected messages by calling gpg directly (with the
> --ignore-mdc-error flag, if needed).
>
> Clients that spawn gpg themselves without using GpgME will still be
> able to decrypt unprotected messages (and therefore, be potentially
> vulnerable to Efail if they don't pay attention to GnuPG warnings)
> until GnuPG 2.3 is released.

This seems reasonable to me. It means that legacy decryption is still
available in current and future code even if it requires users to take
some kind of action.

> And more generally on the backward compatibility problem: to decrypt
> all kind of "legacy" messages there will always be the option of using
> GnuPG 1.4.x, which is still maintained especially for compatibility
> with 1990-era PGP (it notably retains support for things like PGP 2.6
> keys or the MD5 hash algorithm).

I presume that one day the 1.x.y code will reach end of life. If and
when that happens, I strongly suspect that there will still be users who
will need to decrypt legacy-encrypted data and I think it is important
that they can still do this with a maintained (2.x.y) code base. (And I
realise that this is easy for me to say since I'm not contributing to
maintaining the code.)



-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162
 
 
 

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

A postmortem on Efail

[Damien Goutte-Gattat via Gnupg-users]

On 05/20/2018 02:51 PM, Dirk Gottschalk via Gnupg-users wrote:

It would be possible to implement something like --legacy to
re-enable the old functionality.


For information, for the problem at hand, two things have been done in 
that direction:


In GnuPG itself: GnuPG will now error out when attempting to decrypt 
*any* message that is not integrity-protected, *unless* the 
--ignore-mdc-error flag has been set. This has only been done in the 
master branch of GnuPG (to be released as GnuPG 2.3 at some point), 
*not* in the current stable 2.2 branch.


In GpgME: GpgME will return a failure when attempting to decrypt *any* 
message that is not integrity-protected, inconditionnally and even if 
GnuPG itself only emits a warning.


What this all means is that all clients using GpgME will lose the 
ability to decrypt old, unprotected message upon the next GpgME release 
(i.e., those clients will be completely immune to Efail even if they 
currently ignore the no-MDC warning). Users will still be able to 
decrypt such unprotected messages by calling gpg directly (with the 
--ignore-mdc-error flag, if needed).


Clients that spawn gpg themselves without using GpgME will still be able 
to decrypt unprotected messages (and therefore, be potentially 
vulnerable to Efail if they don't pay attention to GnuPG warnings) until 
GnuPG 2.3 is released.



And more generally on the backward compatibility problem: to decrypt all 
kind of "legacy" messages there will always be the option of using GnuPG 
1.4.x, which is still maintained especially for compatibility with 
1990-era PGP (it notably retains support for things like PGP 2.6 keys or 
the MD5 hash algorithm).



Damien



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

Re: A postmortem on Efail

[Mark Rousell]

On 20/05/2018 11:44, Aleksandar Lazic wrote:
> I do not want to create a conspiracy theory but it's wiggy that
> EFF favors *NO* security ,pgp or s/mime, instead to fix the current
> possibilities and promote signal.
>
> As serveral people mentioned in the different Internet medias is signal
> not a replaceable for e-mail, until the signal company does not offer a
> own e-mail service.
>
> That's just my gut instincts the future will share some lights into this
> EFAIL scandal.

I share this view.


-- 
Mark Rousell

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

Re: A postmortem on Efail

[Mark Rousell]

On 20/05/2018 14:51, Dirk Gottschalk via Gnupg-users wrote:
> I think the backwards compatiblity should be broken to improve things.
> It would be possible to implement something like --legacy to re-enable
> the old functionality.

Agreed.

> This could also be implemented in email clients
> and plug-ins like enigmail as a checkbox.

Personally I'd prefer that mail client did not provide an interface to
any "--legacy" options but it's up to mail client authors of course.


-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162
 
 
 

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

Re: A postmortem on Efail

[Mark Rousell]

On 20/05/2018 12:11, Philipp Klaus Krause wrote:
> I don't think breaking backwards-compability is an all-or-nothing question.
>
> IMO, it is important to still be able to decrypt old data. On the other
> hand one wants sane, secure use with current data.
> The functionality needed to decrpyt old files should still be there.
> Possibly hidden behind some new option, if that helps security for
> typical users.
>
> If my mail client will no longer be able to display some old encrypted
> message, that's ok. But I should be still able to read that message by
> invoking GPG from the command-line with suitable options.
>
> Philipp
>

I must agree with this. Absolutely losing a decryption ability that many
people clearly do still require is not a sensible path, but putting
'legacy decryption' ability behind a brand new option that requires some
kind of active change by users who do need it is a reasonable and
sensible compromise imo.

In short, it is not necessary to entirely remove the ability to decrypt
legacy-encrypted data to have the effect of deprecating its use.


-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162
 
 
 

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

Re: A postmortem on Efail

[Dirk Gottschalk via Gnupg-users]

Hi.

Am Sonntag, den 20.05.2018, 02:26 -0400 schrieb Robert J. Hansen:
> Writing just for myself -- not for GnuPG and not for Enigmail and
> definitely not for my employer -- I put together a postmortem on
> Efail.
> You may find it worth reading.  You may also not.  Your mileage will
> probably vary.  :)
> 
> https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08

Thank you for this real good post. You have some real good arguments.

I use GnuPG for many, many years now and for all purposes it is usable
for. Encrypting/Signinmg files, emails, backups, and, as you wrote, it
is used to check packages for my distribution (Fedora). And I even
"abuse" GnuPG to do things, which are not part of the "official" use
cases, but it works even in this cases.

I think the backwards compatiblity should be broken to improve things.
It would be possible to implement something like --legacy to re-enable
the old functionality. This could also be implemented in email clients
and plug-ins like enigmail as a checkbox.

Increment your numnber of natively OpenPGP supporting email clients
from zero to one. Evolution has this implemented. At least as an
interface to gnupg-agent.

Okay, I should say I am one of the very few users, which are using
GnuPG on a regular basis for many use cases. I even have a few
Smartcards with keys and so on. And I would like to help improving
things, if help is welcome. 

Again, thank you for posting this statement, it wasw really nice to
read.

Regards,
Dirk


-- 
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350

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: A postmortem on Efail

[Philipp Klaus Krause]

Am 20.05.2018 um 08:26 schrieb Robert J. Hansen:
> Writing just for myself -- not for GnuPG and not for Enigmail and
> definitely not for my employer -- I put together a postmortem on Efail.
> You may find it worth reading.  You may also not.  Your mileage will
> probably vary.  :)
> 
> https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08

I don't think breaking backwards-compability is an all-or-nothing question.

IMO, it is important to still be able to decrypt old data. On the other
hand one wants sane, secure use with current data.
The functionality needed to decrpyt old files should still be there.
Possibly hidden behind some new option, if that helps security for
typical users.

If my mail client will no longer be able to display some old encrypted
message, that's ok. But I should be still able to read that message by
invoking GPG from the command-line with suitable options.

Philipp

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

Re: Efail or OpenPGP is safer than S/MIME

[Aleksandar Lazic]

On 19/05/2018 14:15, Werner Koch wrote:
> On Fri, 18 May 2018 12:18, patr...@enigmail.net said:
> 
> > How far back will that solution work? I.e. is this supported by all
> > 2.0.x and 2.2.x versions of gpg?
> 
> 2.0.19 (2012) was the first to introduce DECRYPTION_INFO  In any case
> 2.0 is end-of-life.  In theory we could backport that to 1.4 but I don't
> think that makes sense.

On windows is the situtiaon really bad.

###
aleks@aleks-PC MINGW64 ~
$ uname -a
MINGW64_NT-6.1 aleks-PC 2.10.0(0.325/5/3) 2018-02-09 15:25 x86_64 Msys

aleks@aleks-PC MINGW64 ~
$ pacman -Ss gpg
mingw32/mingw-w64-i686-gpgme 1.11.1-1
A C wrapper library for GnuPG (mingw-w64)
mingw32/mingw-w64-i686-libgpg-error 1.29-1
Support library for libgcrypt (mingw-w64)
mingw64/mingw-w64-x86_64-gpgme 1.11.1-1
A C wrapper library for GnuPG (mingw-w64)
mingw64/mingw-w64-x86_64-libgpg-error 1.29-1 [Installiert]
Support library for libgcrypt (mingw-w64)
msys/libgpg-error 1.27-1 (libraries) [Installiert]
Support library for libgcrypt
msys/libgpg-error-devel 1.27-1 (development) [Installiert]
Libgpg-error headers and libraries
msys/libgpgme 1.6.0-1 (libraries) [Installiert]
A C wrapper library for GnuPG
msys/libgpgme-devel 1.6.0-1 (development)
Libgpgme headers and libraries
###

I have installed the latest gpg4win 3.1.1 and then you are able to run a
more or less recent version of gpg

###
aleks@aleks-PC MINGW64 ~
$ LANG=C /c/Program\ Files\ \(x86\)/GnuPG/bin/gpg --version
gpg (GnuPG) 2.2.7
libgcrypt 1.8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: C:/Users/aleks/AppData/Roaming/gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
###

The point is that as long as the distribution does not update there
packages they will be always complains from the users.


> Shalom-Salam,
> 
>Werner
> 
> -- 
> #  Please read:  Daniel Ellsberg - The Doomsday Machine  #
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Best regards
Aleks

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

Re: A postmortem on Efail

[Aleksandar Lazic]

Hi Robert.

On 20/05/2018 02:26, Robert J. Hansen wrote:
> Writing just for myself -- not for GnuPG and not for Enigmail and
> definitely not for my employer -- I put together a postmortem on Efail.
> You may find it worth reading.  You may also not.  Your mileage will
> probably vary.  :)
> 
> https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08

As a long time reader and partly gpg user I would like to thank you for
the post.

>From my point of view must be something more behind the curtain.

I do not want to create a conspiracy theory but it's wiggy that
EFF favors *NO* security ,pgp or s/mime, instead to fix the current
possibilities and promote signal.

As serveral people mentioned in the different Internet medias is signal
not a replaceable for e-mail, until the signal company does not offer a
own e-mail service.

That's just my gut instincts the future will share some lights into this
EFAIL scandal.

jm2c

Best regards
Aleks

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

Re: A postmortem on Efail

[Jim Dever]

I've used PGP ever since I discovered it when I ran a BBS back in the
late 80's early 90's. I rarely post but always listening.  Definitely
time to break backward compatibility if it will help move it forward!
Go for it!

On 5/20/2018 3:28 AM, Robert J. Hansen wrote:
>> Break backwards compatibility already: it’s time. Ignore the haters. I
>> trust you.
> 
> :) :) :) :) :)
> 
> ___
> 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: A postmortem on Efail

[Andrew Gallagher]

> On 20 May 2018, at 07:26, Robert J. Hansen  wrote:
> 
> Writing just for myself -- not for GnuPG and not for Enigmail and
> definitely not for my employer -- I put together a postmortem on Efail.
> You may find it worth reading.  You may also not.  Your mileage will
> probably vary.  :)

I wouldn’t call myself a cryptography expert, although I do try my best to keep 
up. I speak as a tinkerer who wants to humanise cryptography, because it’s 
still too hard for ordinary people to understand, and you shouldn’t need to 
understand everything about a technology to be able to use it properly, because 
that defeats the purpose of technology. 

I find a lot of things about the whole PGP ecosystem interminably frustrating. 
But the worst thing is the inertia. We know there are things that need done, 
but getting them done often seems politically impossible. Not to mention the 
small number of people who are actually getting paid a salary to fix these 
things. TLS at least gets attention because the Googles, Apples and Facebooks 
of the internet are beating people over the head saying “we need to push 
forward”. TLS breaks backwards compatibility regularly. That’s the price of 
improved security.

I said earlier that deprecation has to happen, but I’ll reiterate here. If 
doing the things that we know need to be done requires breaking backwards 
compatibility, then so be it.

A

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

Re: A postmortem on Efail

[Dmitrii Tcvetkov]

On Sun, 20 May 2018 02:26:47 -0400
"Robert J. Hansen"  wrote:

> Writing just for myself -- not for GnuPG and not for Enigmail and
> definitely not for my employer -- I put together a postmortem on
> Efail. You may find it worth reading.  You may also not.  Your
> mileage will probably vary.  :)
> 
> https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08
> 
Thank you for the postmortem.

I don't know any users of GnuPG who still have to work with non-MDC
OpenPGP messages (frankly, don't know any GnuPG users IRL, but working
on it). But it seems to me that GnuPG is so widely widespread because
it was so stable and there was no breaking upgrades, so users didn't
expect any breaking change at all.

I, as a user, don't need support for non-MDC messages and surely PGP
2.6, but I can imagine how challenging it can be to upgrade a system,
which was state-of-the-art years ago, but right now is obsolete. Really
it's not an upgrade, but rebuild from the scratch. And some parts of
the system are probably proprietary, so cooperation from vendors is
required. And the fact that obsolete features weren't dropped due to
users feedback means that GnuPG upstream understands this too. But
something has to change, it can't go like this forever, we do need
breaking changes to remove outdated parts. 
I trust upstream's judgement.

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

Re: A postmortem on Efail

[Dmitry Gudkov]

I want to get involved and give a damn!

Break backwards compatibility already: it’s time. Ignore the haters. I
trust you.

On 20/05/2018 09:26, Robert J. Hansen wrote:
> Writing just for myself -- not for GnuPG and not for Enigmail and
> definitely not for my employer -- I put together a postmortem on Efail.
> You may find it worth reading.  You may also not.  Your mileage will
> probably vary.  :)
> 
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40cipherpunk%2Fefail-a-postmortem-4bef2cea4c08=02%7C01%7C%7Cc13b709433394c96d61608d5be1ad73d%7C84df9e7fe9f640afb435%7C1%7C0%7C636623944863861029=4yVPteoBQ3e9eSB%2FMm%2B4NMt95nSicgfxxAFeJIqkc0g%3D=0
> 
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.gnupg.org%2Fmailman%2Flistinfo%2Fgnupg-users=02%7C01%7C%7Cc13b709433394c96d61608d5be1ad73d%7C84df9e7fe9f640afb435%7C1%7C0%7C636623944863861029=xuw5k7vuQmyKKsGlpmoY3xL5Ol3fETl2sTQKxPrCZ%2Fs%3D=0
> 
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

S/MIME and AE

[Earle Lowe]

I can't see anyway that S/MIME gets resolved with anything other than
heuristics that look for the footprints of the CBC malleability in efail
(random blocks and/or 8bit content) etc.

There are two other alternatives, only one is plausible, IMO

1) Only allow emails where the signature verifies. It doesn't have to be
valid in terms of chaining to a trusted root, but it does need to verify.
This also means you throw out anything not signed (or signed first, then
encrypted) (both of which are allowed).

This option may turn out to be plausibly implemented - but is a pretty big
change to how most S/MIME implementations in actual clients work - they
usually hardly do anything even with bad signatures.

2) Use the various AE CMS RFCs - This is a long-term effort given the
experience with OpenPGP in deprecating non-MDC packets. First either the
S/MIME RFC needs to be updated to remove AES-CBC as essentially the default
and replace it with another one - AND certificates need to start using the
SMIMECapabilitiesExtensions - or vendors start ignoring the existing RFC
and just go ahead. I don't see any way a sender can have some plausible
idea what the recipient can decrypt without having some knowledge of the
version of S/MIME they are using - and this is what SMIMECapabilities is
for in the certificate.

Then once the vendors get together and decide on the new behaviour, and the
certs get updated with new Capabilities - we can wait about how many years
for it all to percolate through the ecosystem? There is a reason no one
bothered to implement any of those RFCs in the first place.

For OpenPGP and MDC, I vote for completely and fully removing non-MDC SE
Packets - no more generating SE packets for any version of keys or ciphers,
ignoring the MDC feature packet in V4 keys, and refusing to decrypt
anything without MDC. I'm ok if some kind of user option needs to exist to
decrypt old content - but I think it should be clearly seen as a dangerous
and insecure option.

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

Re: A postmortem on Efail

[Dmitry Gudkov]

“We be of one blood, ye and I”


― Rudyard Kipling, The Jungle Books

On 20/05/2018 10:28, Robert J. Hansen wrote:
>> Break backwards compatibility already: it’s time. Ignore the haters. I
>> trust you.
> 
> :) :) :) :) :)
> 
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: A postmortem on Efail

[Mirimir]

On 05/19/2018 08:28 PM, Robert J. Hansen wrote:
>> Break backwards compatibility already: it’s time. Ignore the haters. I
>> trust you.
> 
> :) :) :) :) :)

I'm OK with that :)

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

Re: A postmortem on Efail

[Robert J. Hansen]

> Break backwards compatibility already: it’s time. Ignore the haters. I
> trust you.

:) :) :) :) :)

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

A postmortem on Efail

[Robert J. Hansen]

Writing just for myself -- not for GnuPG and not for Enigmail and
definitely not for my employer -- I put together a postmortem on Efail.
You may find it worth reading.  You may also not.  Your mileage will
probably vary.  :)

https://medium.com/@cipherpunk/efail-a-postmortem-4bef2cea4c08

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