Re: A postmortem on Efail

[Ben McGinnes]

On Mon, May 21, 2018 at 11:19:18AM -1100, Mirimir wrote:
> On 05/21/2018 02:31 AM, Ben McGinnes wrote:
>> 
>> https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions
>> 
>> “What if I keep getting PGP emails?
>> 
>> You can decrypt these emails via the command line. If you prefer not
>> to, notify your contacts that PGP is, for the time being, no longer
>> safe to use in email clients and decide whether the conversation can
>> continue over another end-to-end encrypted platform, such as Signal.”
>> 
>> Because that couldn't possibly create a Chinese Whispers style
>> situation of self-perpetuating FUD … 臘
> 
> I hadn't seen that. Pretty stupid :(

I can understand not having wanted to look too much farther after the
articles on the Deep Links blog, especially the second one on the
14th.  I'd been concentrating on something else and only paid it more
attention a bit later, so by that stage the article also included a
link at the end about the SSD updates and onward I clicked (with a
sense of dread).


Regards,
Ben


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

Re: A postmortem on Efail

[Ben McGinnes]

On Wed, May 23, 2018 at 12:15:58AM +0200, Steffen Nurpmeso wrote:
> 
> I only use v1.4, and i will never never never never use anything
> newer because that is very large and consists of an immense amount
> of components that i really do not need.  I receive keys via hkps://
> and sign, verify, encrypt and decrypt.  Having no pinentry is a bit
> of a problem, also because ~/ expansion is not possible in gpg.conf;
> but i have a small mkfifo program that feeds in the passphrase as
> appropriate, so this works for me.

Which is fine as long as no one you correspond with uses an elliptic
curve key when corresponding with you.  1.4 has no support for any of
the curves and they're not being backported to it.  In fact the last
time I tried doing anything at all with a key containing a curve even
just what was supposed to be optional subkeys, 1.4 had significant
problems doing anything with those keys.

That sort of thing is part of the reason for maintaining a separate
~/.gnupg1 directory which was my original, pre-migration directory
(combined with some shell scripts as wrappers which invoke the right
version with the right configuration and enabling this:

bash-4.4$ gpg1 --version
gpg (GnuPG) 1.4.22
Copyright (C) 2015 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: /Users/ben/.gnupg1
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
bash-4.4$ 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: /Users/ben/.gnupg2
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
bash-4.4$

Though I believe 1.4 may have been slightly modified and/or using
whatever was last added to its branch rather than actually be 1.4.22's
stable release.

Anyway, even though my current key doesn't yet include any of the
curves, I do still need more than a few components of the current
branches.  There are people I correspond with who use keys with
curves, I also definitely need GPGME and the its Python bindings (not
having them would make my work very tricky indeed).  Plus the boss is
a huge proponent of the modern branch and arguably its greatest
advocate.  


Regards,
Ben


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

Re: A postmortem on Efail

[Steffen Nurpmeso]

Ben McGinnes  wrote:
 |On Tue, May 22, 2018 at 02:19:37AM +0100, Mark Rousell wrote:
 |> On 21/05/2018 13:34, Ben McGinnes wrote:
 |> 
 |>> I agree with most of the article and largely with the need to break
 ...
 |Mine too, it's why I keep a copy of 1.4 installed at all.  It's been a

I only use v1.4, and i will never never never never use anything
newer because that is very large and consists of an immense amount
of components that i really do not need.  I receive keys via
hkps:// and sign, verify, encrypt and decrypt.  Having no pinentry
is a bit of a problem, also because ~/ expansion is not possible
in gpg.conf; but i have a small mkfifo program that feeds in the
passphrase as appropriate, so this works for me.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

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

Re: A postmortem on Efail

[Ben McGinnes]

On Tue, May 22, 2018 at 02:19:37AM +0100, Mark Rousell wrote:
> On 21/05/2018 13:34, Ben McGinnes wrote:
> 
>> I agree with most of the article and largely with the need to break
>> compatibility to an ancient flawed design.  Particularly since we
>> still have a means of accessing those ancient formats if we have to in
>> the form of the GPG 1.4 branch.  The ancient archives are as safe as
>> they've ever been (for whatever definition of "safe" is being implied
>> by the user/archivist).
> 
> Indeed, this satisfies my archive retrieval concerns.

Mine too, it's why I keep a copy of 1.4 installed at all.  It's been a
while since I've needed to access something encrypted to the first key I
ever made way back in 1995, but I know there are archives which might
require it and possibly even some which have not already been migrated
to a newer key and encryption method.

That's okay, though and it doesn't need current dev practices to
retain those functions since there is a means of still opening that
door, even if I'm no longer using DOS and thus PGP 2.3a for DOS is no
longer available.  No doubt the worst issue would be sanitizing such
an old file of carriage returns or something like that.

Depending on what it was, though there may even be WordPerfect 5.1
files buried in those archives and IIRC LibreOffice dropped support
for those files a while back.  I suspect that sort of issue is more
likely to be a cause of angst for people needing to access old data
than whether they need to run GPG 1.4.x manually to decrypt it first.

>> There is, however, one aspect of this issue that you touched on
>> lightly, but didn't really delve into and which is at the centre of
>> my, mostly unvoiced (until this email), criticism of the Efail team.
>> That being the *incredibly* unhelpful and likely actively harmful
>> recommendation to remove encryption and decryption functionality from
>> vulnerable MUAs.
>>
>> To say, “we have this edge case scenario that really needs an active
>> targeted attack on a case by case basis, so everyone should just stop
>> integrating encryption” is the kind of thing that can get people
>> killed.
> 
> This has been commented on by a few people on this list, myself
> included: [1]

It gets mentioned here periodically, usually in conjunction with
discussions of differing threat models.

The EFF even have a great big section on their SSD site about
conducting your own risk or threat assessment and that these things
will be different for people in different circumstances.  Then they
decided to ignore their own advice in its entirety.

> To my mind, it reeks of slanted propaganda for Signal, and there
> does seem to be a lot of it around at the moment.

Hmm, maybe, but I'm not entirely certain that's instigated by Signal
or Whisper Systems.  No doubt they're enjoying it, but I think there's
another reason for that.

> Signal has security benefits but it's not (yet?) a replacement for
> encrypted email,

It's completely incapable of replacing either email or OpenPGP.  Here
are two things I do regularly or constantly which Signal is
fundamentally incapable of:

 1. Running my own server which enables me to set certain types of
 controls or filters on my own server and not shared with any third
 party (including Moxie).

 2. Encrypt files which are not intended to be sent to anyone and
 never were intended to be so.  The same is true of certain files
 which are digitally signed and archived in a way which lets me prove
 when they were written later (it's a copyright thing and set to
 specifically circumvent a particular niche of morons that are
 unrelated to the issue at hand).  Mostly, however, I mean things like
 keeping a journal and making damn sure that it won't be used against
 me.

Signal can't do any of that.  At all.  It also can't provide a genuine
means of establishing a pseudonymous identity unless you live in a
country that lets you buy lots of cheap "burner" phones and/or SIMs.

Maybe that is easy in the USA, maybe even elsewhere too.  It's pretty
much impossible in Australia.

So if there were something I needed to raise somewhere pseudonymously,
say via Tor and some web forum, what does the EFF suggest I use?
Signal?  How?

> whereas a number of commentators seem to treat it as if all email,
> encrypted or not, should be deprecated in favour of Signal. This is
> not sensible or good advice without considering individual use cases
> (regardless of Efail).

Absolutely!

I'm guessing that none of these commentators have ever actually
personally faced a threat which threatened their lives, especially as
part of some kind of minority, where the threat is both targeted and
impersonal simultaneously.  There are still millions of people in the
world facing torture or even death just because of something they were
born with (even something which may not be apparent until they reach a
certain point after birth).

In fact one minority I'm aware of is still so greatly at risk that
there's only 

Re: A postmortem on Efail

[Mark H. Wood]

On Tue, May 22, 2018 at 01:42:07AM +0100, Mark Rousell wrote:
> On 21/05/2018 15:17, Mark H. Wood wrote:
> >> Break backwards compatibility already: it’s time. Ignore the haters. I
> >> trust you.
> > (I understand that that's a quote of a discussion-opener from the write-up.)
> >
> > I'd like to first see how many haters can be won over by selling the
> > necessary changes.
> >
> > By "selling" I mean addressing the concerns of those who aren't
> > convinced that they want something:
> >
> > o  Why this is important *to you*, even though its importance was not
> >immediately obvious.
> 
> To my mind it is at the outset counter-productive to refer to "haters".
> To use the term "haters" implies that anyone who does not share one's
> own view is somehow wrong and/or that their arguments can potentially be
> dismissed on the grounds or emotionalism rather than rationality.

*sigh*  Imagine that I wore a wry expression as I wrote that.  I think
 we are mostly in violent agreement.  I tend to play off of the
 wording of a previous statement when replying, especially when I want
 to bend the discussion in a different direction.

> In practice, those like myself who recognise that the ability to decrypt
> legacy-encrypted data is a basic requirement for many users with
> archival needs do not "hate" anything. We just recognise that decryption
> of legacy-encrypted data is a real world requirement right now and will
> continue to be for many years, and so I think it is right and proper for
> this project to continue to support this activity with maintained
> software (albeit with a requirement for users to make some changes to
> support such activity).

Yes.  I, too, have encrypted stuff from way back that I would like to
be able to read.  Addressing such needs is part of selling the
selected way forward.

Another part of selling is dialogue.  I see lots of confident
assertions about what we should do.  Is anyone taking this back to the
affected users to see if any of it makes sense to them?

> > o  What we have done, and are doing, to keep *your* cost down.
> 
> If the aim is to keep end-users' costs down then do not completely
> remove legacy features that are still needed in the real world.
> Decryption of legacy-encrypted data is one of those features, like it or
> not.

Yes, but don't just do it silently; tell people who need this that it
is being done, because of their concerns, and how it is being done.
Sell it.

> > o  What else would we need to do, to make this something *you* want?
> 
> Go back in time and change history!  [snip]

I was hoping for practical ideas which show that the community
understands the needs of all its members and is working to minimize
the cost of necessary evolution.  I'd like to be one community, but
apparently at the moment we are two.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP 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 21/05/2018 13:34, Ben McGinnes wrote:

> I agree with most of the article and largely with the need to break
> compatibility to an ancient flawed design.  Particularly since we
> still have a means of accessing those ancient formats if we have to in
> the form of the GPG 1.4 branch.  The ancient archives are as safe as
> they've ever been (for whatever definition of "safe" is being implied
> by the user/archivist).

Indeed, this satisfies my archive retrieval concerns.

> There is, however, one aspect of this issue that you touched on
> lightly, but didn't really delve into and which is at the centre of
> my, mostly unvoiced (until this email), criticism of the Efail team.
> That being the *incredibly* unhelpful and likely actively harmful
> recommendation to remove encryption and decryption functionality from
> vulnerable MUAs.
>
> To say, “we have this edge case scenario that really needs an active
> targeted attack on a case by case basis, so everyone should just stop
> integrating encryption” is the kind of thing that can get people
> killed.

This has been commented on by a few people on this list, myself
included: [1]

To my mind, it reeks of slanted propaganda for Signal, and there does
seem to be a lot of it around at the moment. Signal has security
benefits but it's not (yet?) a replacement for encrypted email, whereas
a number of commentators seem to treat it as if all email, encrypted or
not, should be deprecated in favour of Signal. This is not sensible or
good advice without considering individual use cases (regardless of Efail).

> I *do*, however, care that their
> recommendations may have lasting and potential final consequences for
> OpenPGP users living with and attempting to mitigate real threats to
> their lives and/or liberty.
>
> Playing with that sort of thing with the recklessness with which the
> Efail team have done is, in my not so humble opinion, an absolute
> disgrace.
>
> You pointed out that the vast majority of OpenPGP use is no longer
> email or other communications encryption.  This is both true and a
> valid point of discussion.  Nevertheless, there are still a
> considerable number of people who do use it that way and a number of
> them have to deal with threat assessments with considerably higher
> levels of personal risk than security researchers in academia or
> cryptographic developers.
>
> We must not forget these people.  Ever.  Even if we never hear from
> them.  Their cases are also not a matter of being apathetic; it's that
> their priorities are surviving the world they're in, so they need to
> rely on the tools we provide (and I get the community apathy issue is
> actually a more general thing, so this isn' having a go at that part).
>
> The Efail researchers did forget them and their conduct demonstrates
> this.  While they may have made some useful technical contributions
> regarding S/MIME and highlighting certain poor implementations in
> MUAs, that's no justification for reckless disregard of the lives of
> end users.

Well said.

> So in my opinion it's not the merits or lack thereof in the
> demonstrated attacks they released that have the gravest consequence
> here, it's that the number one recommended mitigation technique is to
> remove cryptographic functions from MUAs.

Without wanting to sound like a conspiracy geek, removing encryption
from email would, of course, benefit Signal and its takeup.




[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060450.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 21/05/2018 15:17, Mark H. Wood wrote:
>> Break backwards compatibility already: it’s time. Ignore the haters. I
>> trust you.
> (I understand that that's a quote of a discussion-opener from the write-up.)
>
> I'd like to first see how many haters can be won over by selling the
> necessary changes.
>
> By "selling" I mean addressing the concerns of those who aren't
> convinced that they want something:
>
> o  Why this is important *to you*, even though its importance was not
>immediately obvious.

To my mind it is at the outset counter-productive to refer to "haters".
To use the term "haters" implies that anyone who does not share one's
own view is somehow wrong and/or that their arguments can potentially be
dismissed on the grounds or emotionalism rather than rationality.

In practice, those like myself who recognise that the ability to decrypt
legacy-encrypted data is a basic requirement for many users with
archival needs do not "hate" anything. We just recognise that decryption
of legacy-encrypted data is a real world requirement right now and will
continue to be for many years, and so I think it is right and proper for
this project to continue to support this activity with maintained
software (albeit with a requirement for users to make some changes to
support such activity).

> o  What we have done, and are doing, to keep *your* cost down.

If the aim is to keep end-users' costs down then do not completely
remove legacy features that are still needed in the real world.
Decryption of legacy-encrypted data is one of those features, like it or
not.

> o  What else would we need to do, to make this something *you* want?

Go back in time and change history! What is now archived is archived and
cannot be changed. Like it or not, it will need to be decrypted for a
very long time to come. Ideally this should be achievable with
maintained, current-version software. By all means, if that software
needs to be a special-use, decrypt-only, program that is hardly ever
updated except to patch code vulnerabilities then so be it.

But do not throw your long-time users or their data under the bus for
the sake of eliminating backwards compatibility. Stability and
compatibility really do matter to many classes of users.



-- 
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 21/05/2018 14:31, Ben McGinnes wrote:
> I could have given them that benefit of the doubt on the initial
> article too, but the FAQ they now have on the Surveillance
> Self-Defense website does rather eviscerate any hope of that:
>
> https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions
>
> “What if I keep getting PGP emails?
>
> You can decrypt these emails via the command line. If you prefer not
> to, notify your contacts that PGP is, for the time being, no longer
> safe to use in email clients and decide whether the conversation can
> continue over another end-to-end encrypted platform, such as Signal.”
>
> Because that couldn't possibly create a Chinese Whispers style
> situation of self-perpetuating FUD … 臘

Very foolish and very slanted indeed in a certain direction.



-- 
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 21/05/2018 09:54, Damien Goutte-Gattat via Gnupg-users wrote:
> On 05/21/2018 04:07 AM, Mark Rousell wrote:
>> I think you mean that support for 2.0.y has been dropped, surely?
> No, I do mean that support for all PGP 2-related stuff has been dropped
> from the current stable branch. Modern GnuPG (≥ 2.1) can neither read
> nor write anything that has been generated by PGP 2.x. Compatibility
> starts with PGP 5, which dates back to 1997.

Ah, gotcha. I was being careless over terminology.


>> 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.
> Well, that's already not the case. If you have pre-1997 data, you need
> to use GnuPG 1.4, which again *is* still supported precisely for this
> use case. (You could also, in theory, use GnuPG 2.0.x, but *that* branch
> is explicitly no longer supported.)

Thanks. This satisfies my preferences, that legacy-encrypted data can be
decrypted with maintained code.

-- 
Mark Rousell

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

Re: A postmortem on Efail

[Mirimir]

On 05/21/2018 02:31 AM, Ben McGinnes wrote:
> On Sun, May 20, 2018 at 01:43:07PM -1100, Mirimir wrote:
>> On 05/19/2018 11:44 PM, 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.
>>
>> 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.
> 
> I could have given them that benefit of the doubt on the initial
> article too, but the FAQ they now have on the Surveillance
> Self-Defense website does rather eviscerate any hope of that:
> 
> https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions
> 
> “What if I keep getting PGP emails?
> 
> You can decrypt these emails via the command line. If you prefer not
> to, notify your contacts that PGP is, for the time being, no longer
> safe to use in email clients and decide whether the conversation can
> continue over another end-to-end encrypted platform, such as Signal.”
> 
> Because that couldn't possibly create a Chinese Whispers style
> situation of self-perpetuating FUD … 臘
> 
> 
> Regards,
> Ben

I hadn't seen that. Pretty stupid :(

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

Re: A postmortem on Efail

[Ben McGinnes]

On Mon, May 21, 2018 at 08:51:17AM -0400, Robert J. Hansen wrote:
>> That being the *incredibly* unhelpful and likely actively harmful
>> recommendation to remove encryption and decryption functionality from
>> vulnerable MUAs.
> 
> I blame the EFF for that more than I blame the Efail developers.  I
> expect the people who develop new attacks to overstate their
> importance: it's not out of any intent to deceive, it's just that
> they're too close to the problem to have a clear perspective on the
> user impact.

That is a good point and a fairly common situation; possibly the
second most common form of engineering blindness (the first one being
having a favourite tool and applying it to every problem regardless of
relevance — when armed with one's favourite hammer, everything looks
like a nail).

> The EFF, though...

Indeed …

> But even then, I have some sympathy for their position.  The EFF
> works with many different activists in many different countries
> running many different setups.  They were in a difficult situation
> of needing to put out a press release that had useful
> recommendations for everyone, left no one out in the cold, while
> still not raising a panic.

Had their publications been limited to the articles on the 13th and
14th, I could buy that.  Unfortunately the updates to the SSD website
on the 15th really strain things, especially the FAQ.  Not only is it
potentially panic-inducing, but they recommend an approach of having
end users campaign against using OpenPGP at all with all of their
contacts with no regard for what additional circumstances those
contacts have.

They've literally created a FUD-virus as a meme which will
self-replicate throughout the web-of-trust.  I'm sure we'll be
encountering people advising others not to use OpenPGP long after the
last of those affected MUAs are patched and *that* is stretching the
edges of the term reckless (as it is usually used in legislation,
e.g. reckless endangerment of life as opposed to, say, wilful
endangerment of life).

I also don't believe they can actually fix this now that they've
created it without a complete reversal of their current position;
which they can't do because of the MUAs which are affected and some
users could be targeted.  By the time the conditions are such that
they can consistently give the “all clear” on the matter, the
FUD-virus will have spread too far and be too independent of them to
stop (but will still gain credibility and traction by trading off
their name and reputation).

> Let me be clear: I think the EFF behaved irresponsibly.  But I can
> be sympathetic to their situation, too.  It's not a one-or-the-other
> thing.

Sure; doing nothing and ignoring the affected MUAs does no one any
good, but this response is likely to do more harm than the thing it's
intended to stop and it didn't have to be that way.

Not to mention the little matter that their sole recommendation of a
viable alternative in all circumstances is a service which is entirely
dependent on a centralised server (or network of servers).  One which
explicitly cannot be implemented in a federated manner and all
attempts to fork it in order to do precisely that have been abandoned
as a result of Moxie's opposition to them trying to connect to his
network to communicate with Signal users.

It's simply not a complete replacement in spite of EFF's wish that it
is.  It's a great addition to a suite of of services and tools, but
relying on it as a replacement for OpenPGP is misguided (not to
mention impossible for some people and/or networks and/or pseudonymity
requirements).

> And I'm going to remain quiet on this further until I have
> time to see the EFF's postmortem.

I won't going beyond the current statement describing it as reckless
yet and I hope I don't have to.  Perhaps they will be able to do some
damage control in their own review.

>> Indeed, this particular release may still succeed in producing a body
>> count.  I am not yet aware of any confirmed fatalities stemming from
>> people panicking and stopping using crypto because they listened to
>> Efail and/or the EFF, but there is one particular community I'm
>> watching for just that issue right now.
> 
> If I can help in any way, please let me know.

Appreciated, but in this particular case it would probably be a crime
for you to do so, at least directly to said group, whereas it's
perfectly legal over here.  It might depend a little on the
interpretation of the First Amendment over there, though, and it is
still possible that those laws are unconstitutional, but it's too
early to know for sure yet and it doesn't look like there are too many
organisations over there wanting to challenge it (yet).


Regards,
Ben



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

Re: A postmortem on Efail

[Mark H. Wood]

On Sun, May 20, 2018 at 07:23:17AM +, Dmitry Gudkov wrote:
> I want to get involved and give a damn!

[applause]

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

(I understand that that's a quote of a discussion-opener from the write-up.)

I'd like to first see how many haters can be won over by selling the
necessary changes.

By "selling" I mean addressing the concerns of those who aren't
convinced that they want something:

o  Why this is important *to you*, even though its importance was not
   immediately obvious.

o  What we have done, and are doing, to keep *your* cost down.

o  What else would we need to do, to make this something *you* want?

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


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

Re: A postmortem on Efail

[Ben McGinnes]

On Sun, May 20, 2018 at 01:43:07PM -1100, Mirimir wrote:
> On 05/19/2018 11:44 PM, 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.
> 
> 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.

I could have given them that benefit of the doubt on the initial
article too, but the FAQ they now have on the Surveillance
Self-Defense website does rather eviscerate any hope of that:

https://ssd.eff.org/en/blog/pgp-and-efail-frequently-asked-questions

“What if I keep getting PGP emails?

You can decrypt these emails via the command line. If you prefer not
to, notify your contacts that PGP is, for the time being, no longer
safe to use in email clients and decide whether the conversation can
continue over another end-to-end encrypted platform, such as Signal.”

Because that couldn't possibly create a Chinese Whispers style
situation of self-perpetuating FUD … 臘


Regards,
Ben


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

Re: A postmortem on Efail

[Robert J. Hansen]

> That being the *incredibly* unhelpful and likely actively harmful
> recommendation to remove encryption and decryption functionality from
> vulnerable MUAs.

I blame the EFF for that more than I blame the Efail developers.  I
expect the people who develop new attacks to overstate their importance:
it's not out of any intent to deceive, it's just that they're too close
to the problem to have a clear perspective on the user impact.  The EFF,
though...

But even then, I have some sympathy for their position.  The EFF works
with many different activists in many different countries running many
different setups.  They were in a difficult situation of needing to put
out a press release that had useful recommendations for everyone, left
no one out in the cold, while still not raising a panic.

Let me be clear: I think the EFF behaved irresponsibly.  But I can be
sympathetic to their situation, too.  It's not a one-or-the-other thing.
 And I'm going to remain quiet on this further until I have time to see
the EFF's postmortem.

> Indeed, this particular release may still succeed in producing a body
> count.  I am not yet aware of any confirmed fatalities stemming from
> people panicking and stopping using crypto because they listened to
> Efail and/or the EFF, but there is one particular community I'm
> watching for just that issue right now.

If I can help in any way, please let me know.

> We must not forget these people.  Ever.

I entirely agree.



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

[Ben McGinnes]

On Sun, May 20, 2018 at 02:26:47AM -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

Very nice article and it will be a useful one to forward to a number
of people.

I also liked ProtonMail's more technical one which addressed the
specifics of their own setup and demonstrated that the allegations
levelled their way were not well founded.  On the other hand, they use
OpenPGP.js very differently to most, if not all, of the other projects
which have since adopted it and are acutely aware of the inherent
weaknesses within JavaScript itself, so they don't drive their entire
systems with it.

I agree with most of the article and largely with the need to break
compatibility to an ancient flawed design.  Particularly since we
still have a means of accessing those ancient formats if we have to in
the form of the GPG 1.4 branch.  The ancient archives are as safe as
they've ever been (for whatever definition of "safe" is being implied
by the user/archivist).

There is, however, one aspect of this issue that you touched on
lightly, but didn't really delve into and which is at the centre of
my, mostly unvoiced (until this email), criticism of the Efail team.
That being the *incredibly* unhelpful and likely actively harmful
recommendation to remove encryption and decryption functionality from
vulnerable MUAs.

To say, “we have this edge case scenario that really needs an active
targeted attack on a case by case basis, so everyone should just stop
integrating encryption” is the kind of thing that can get people
killed.

Indeed, this particular release may still succeed in producing a body
count.  I am not yet aware of any confirmed fatalities stemming from
people panicking and stopping using crypto because they listened to
Efail and/or the EFF, but there is one particular community I'm
watching for just that issue right now.

By comparison to that I don't really care so much that Efail dropped
the ball with disclosure to GnuPG or any of the other projects.  It's
a bit annoying, but we can all cope.  I *do*, however, care that their
recommendations may have lasting and potential final consequences for
OpenPGP users living with and attempting to mitigate real threats to
their lives and/or liberty.

Playing with that sort of thing with the recklessness with which the
Efail team have done is, in my not so humble opinion, an absolute
disgrace.

You pointed out that the vast majority of OpenPGP use is no longer
email or other communications encryption.  This is both true and a
valid point of discussion.  Nevertheless, there are still a
considerable number of people who do use it that way and a number of
them have to deal with threat assessments with considerably higher
levels of personal risk than security researchers in academia or
cryptographic developers.

We must not forget these people.  Ever.  Even if we never hear from
them.  Their cases are also not a matter of being apathetic; it's that
their priorities are surviving the world they're in, so they need to
rely on the tools we provide (and I get the community apathy issue is
actually a more general thing, so this isn' having a go at that part).

The Efail researchers did forget them and their conduct demonstrates
this.  While they may have made some useful technical contributions
regarding S/MIME and highlighting certain poor implementations in
MUAs, that's no justification for reckless disregard of the lives of
end users.

So in my opinion it's not the merits or lack thereof in the
demonstrated attacks they released that have the gravest consequence
here, it's that the number one recommended mitigation technique is to
remove cryptographic functions from MUAs.  Even though they still said
to basically perform those functions manually and independently, which
does imply not opposing using cryptography itself.  It's still a
recommendation which is sure to create far more dangerous outcomes for
end users.

It's a bit like that scene in Erik the Viking where a woman is being
raped and Erik kills the rapist, but his sword goes right through the
rapist and kills the woman too.  He did stop the rape, but that
doesn't make his action a successful one.

I think it's fair to say that most, if not all, of those of us working
with this tech are reasonably intelligent.  So surely we can operate
at a level with a bit more forethought than a viking, fictional or
otherwise.


Regards,
Ben


signature.asc
Description: PGP signature
___
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/21/2018 04:07 AM, Mark Rousell wrote:
> I think you mean that support for 2.0.y has been dropped, surely?

No, I do mean that support for all PGP 2-related stuff has been dropped
from the current stable branch. Modern GnuPG (≥ 2.1) can neither read
nor write anything that has been generated by PGP 2.x. Compatibility
starts with PGP 5, which dates back to 1997.


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

Well, that's already not the case. If you have pre-1997 data, you need
to use GnuPG 1.4, which again *is* still supported precisely for this
use case. (You could also, in theory, use GnuPG 2.0.x, but *that* branch
is explicitly no longer supported.)


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

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: 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 <r...@sixdemonbag.org> 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" <r...@sixdemonbag.org> 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

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