Re: Efail or OpenPGP is safer than S/MIME

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

Re: EFAIL countermeasure recommendations on your site

Would it be possible for you to make recommendations about how to respond to the EFAIL vulnerability on your site? This is the sort of thing better addressed to email plugin authors. Efail had very limited applicability to GnuPG itself. signature.asc Description: OpenPGP digital signature

EFAIL countermeasure recommendations on your site

Hello GNUPG mailing list, Would it be possible for you to make recommendations about how to respond to the EFAIL vulnerability on your site? I see that you link to emailselfdefense.org, which encourages users to use the latest version of enigmail. However I see that there are mentions of

Backchannels via OCSP and CRL in S/MIME (Was: efail is imho only a html rendering bug)

Am 06.06.2018 um 20:19 schrieb Werner Koch: > Thanks for responding. However, my question was related to the claims > in the paper about using CRL and OCSP as back channels. This created the > impression that, for example, the certificates included in an encrypted > CMS object could be modified i

Re: efail is imho only a html rendering bug

Hi! Thanks for responding. However, my question was related to the claims in the paper about using CRL and OCSP as back channels. This created the impression that, for example, the certificates included in an encrypted CMS object could be modified in a way that, say, the DP could be change in th

Re: efail is imho only a html rendering bug

Am 06.06.2018 um 10:04 schrieb Werner Koch: > On Mon, 21 May 2018 19:11, r...@sixdemonbag.org said: > >> Efail is not just an HTML rendering bug. It includes very real >> attacks against S/MIME as it's used by thousands of corporations. > > I have not yet seen an

Re: efail is imho only a html rendering bug

On Mon, 21 May 2018 19:11, r...@sixdemonbag.org said: > Efail is not just an HTML rendering bug. It includes very real > attacks against S/MIME as it's used by thousands of corporations. I have not yet seen any hints on how a back-channel within the S/MIME protocol can work. There

Re: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

On Tue, May 29, 2018 at 08:22:33AM -1100, Mirimir wrote: > On 05/28/2018 12:15 AM, Werner Koch wrote: > > On Thu, 24 May 2018 00:05, gnupg-us...@spodhuis.org said: > > > >> up at . > > > > Given that I see more and more mails with "Encrypted mail" as subje

Re: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

On 05/28/2018 12:15 AM, Werner Koch wrote: > On Thu, 24 May 2018 00:05, gnupg-us...@spodhuis.org said: > >> up at . > > Given that I see more and more mails with "Encrypted mail" as subject, > this feature is getting more and more annoying. It will eventu

Re: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

> Regarding the subject there is a simple and also fun solution: If you > need to hide the subject, use a nonsense phrase instead. Such a phrase > makes mental pre-sorting as effecitive as an on-topic subject. Or, better, use a system of random nonsense phrases. Let's say you have seven differen

Re: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

On Thu, 24 May 2018 00:05, gnupg-us...@spodhuis.org said: > up at . Given that I see more and more mails with "Encrypted mail" as subject, this feature is getting more and more annoying. It will eventually not anymore possible to pre-sort mails as it is c

Re: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

Thanks Phil. Very interesting! I will look into that. On Wed, May 23, 2018 at 3:05 PM, Phil Pennock wrote: > On 2018-05-22 at 19:35 -0700, Craig P Hicks wrote: > > "A Solution for Sending Messages Safely from EFAIL-safe Senders to > > EFAIL-unsafe Receivers" &

Re: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

On 2018-05-22 at 19:35 -0700, Craig P Hicks wrote: > "A Solution for Sending Messages Safely from EFAIL-safe Senders to > EFAIL-unsafe Receivers" > > https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki There's an existing semi-standard for trying to impro

Re: A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

Il 23/05/2018 04:35, Craig P Hicks ha scritto: > When decrypted by the user in its raw form the total message will be > human readable but a little ugly because it contains the obfuscation > string *o*, but it will be safe from EFAIL. While that could be OK for human-readable files, it

A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

At some finite date in the (hopefully) near future, most email client over GnuPG users will have an EFAIL-reading safe system setup, if they don't already. MDC will be strictly enforced. However, the situation for a secret message sending is not so good. There is no way to guarantee tha

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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 v

Re: A postmortem on Efail

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 c

Re: A postmortem on Efail

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 f

Re: efail is imho only a html rendering bug

the finger at the real bug) You only refer to one type of possible vulnerabilities that Efail discovered. Even if there are no remote calls involved, it is still possible to trick the user into sending a reply that contains decrypted content. -Patrick _

Re: [Autocrypt] [openpgp-email] Efail - Possible Measures?

, 2018 9:47 AM, Patrick Brunschwig wrote: > > > In the light of the Efail vulnerability I am asking myself if it's > > really needed to decrypt non-regular types of emails at all. In other > > words, should we decrypt a multipart/encrypted MIME part at all if we > >

Re: A postmortem on Efail

t 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

Re: A postmortem on Efail

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 change

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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 GnuP

Re: A postmortem on Efail

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

Re: efail is imho only a html rendering bug

(Only to point the finger at the real bug) Efail is not just an HTML rendering bug. It includes very real attacks against S/MIME as it's used by thousands of corporations. It's true that the cryptanalytic attack on OpenPGP is pretty much nothing. But even then, there'

Re: A postmortem on Efail

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 bl

efail is imho only a html rendering bug

Internet works because we have standards. Rfc 3986 states that URLs have to be ecoded. Redering-Engies which send unencodes content including whitespaces and newlines to an external Server are seriously broken. (Only to point the finger at the real bug) Kind Regards, Klaus ___

Re: A postmortem on Efail

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 firs

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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

A postmortem on Efail

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 b

Re: A postmortem on Efail

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 thin

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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 b

Re: A postmortem on Efail

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

A postmortem on Efail

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 sign

Re: A postmortem on Efail

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 unp

A postmortem on Efail

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

Re: A postmortem on Efail

dias 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

Re: A postmortem on Efail

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 pl

Re: A postmortem on Efail

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 f

Re: A postmortem on Efail

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 wil

Re: A postmortem on Efail

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

Re: Efail or OpenPGP is safer than S/MIME

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-

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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 compatibilit

Re: A postmortem on Efail

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

Re: A postmortem on Efail

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

Re: A postmortem on Efail

ther 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&data=02%7C01%7C%7Cc13b709433

Re: A postmortem on Efail

“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

Re: A postmortem on Efail

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

Re: A postmortem on Efail

> 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

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

Re: [openpgp-email] Efail - Possible Measures?

(Also cross-posting to Autocrypt) Patrick Brunschwig(patr...@enigmail.net)@Sat, May 19, 2018 at 06:47:08PM +0200: > In the light of the Efail vulnerability I am asking myself if it's > really needed to decrypt non-regular types of emails at all. In other > words, should we decry

Re: Efail - Possible Measures?

> I would consider the following "regular" MIME structures: > > 1. top-level MIME part is multipart/encrypted. > 2. an attached email (Content-Type = message/rfc822) containing a > multipart/encrypted MIME part as direct child. We have been doing this in the past but changed it especially for Exc

Efail - Possible Measures?

In the light of the Efail vulnerability I am asking myself if it's really needed to decrypt non-regular types of emails at all. In other words, should we decrypt a multipart/encrypted MIME part at all if we detect an irregular MIME structure? If we would not decrypt irregular MIME struc

Re: Efail or OpenPGP is safer than S/MIME

On 05/19/2018 09:00 AM, Patrick Brunschwig wrote: > On 19.05.18 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 int

Re: Efail or OpenPGP is safer than S/MIME

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

Re: Efail or OpenPGP is safer than S/MIME

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 d

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

On 05/18/2018 08:51 AM, Mark Rousell wrote: > On 18/05/2018 20:27, Martin wrote: >> Hello Matthias, >> >> Friday, May 18, 2018, 3:40:53 PM, you wrote: >> >>> Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just >>> ignore this comment. >> And again recommandatioin for Signal. It seem

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

On 18/05/2018 20:27, Martin wrote: > Hello Matthias, > > Friday, May 18, 2018, 3:40:53 PM, you wrote: > >> Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just >> ignore this comment. > And again recommandatioin for Signal. It seems to be a PR campaign - > but a very bad one. Indeed

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

I think heise is generally becoming more and more part of the rainbow press in gerneral.. but their repeated fake news about crypto and weird claims "crypto must become easy" (in the sense of: people shouldn't need to mutually authenticate) starts to get really dangerous for the unaware people beli

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

Hello Matthias, Friday, May 18, 2018, 3:40:53 PM, you wrote: > Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just > ignore this comment. And again recommandatioin for Signal. It seems to be a PR campaign - but a very bad one. -- Best regards, Martin _

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

> Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just > ignore this comment. He's also not exactly wrong. The continuing support for SE packets is an embarrassment to us. In our defense, though, the GnuPG userbase revolts whenever Werner mentions something as mild as dropping PGP

Re: Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

On 18.05.18 15:40, Matthias Mansfeld wrote: > Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just > ignore this comment. > > https://heise.de/-4051354 Fortunately not everybody at Heise is clueless and/or a PGP hater: https://heise.de/-4050153 -Ralph _

Kommentar: Efail ist ein Megafail für E-Mail-Verschlüsselung | heise online

OK, maybe someones weekend will be spoilt after reading this comment, but hey, it's an original Jürgen Schmidt (responsible redactor seems to be Martin Holland), what else would you expect Jürgen Schmidt is a dedicated OpenPGP hater. Be warned and/or just ignore this comment. https://heise

Re: Efail or OpenPGP is safer than S/MIME

On 17.05.18 13:03, Werner Koch wrote: > If you parse DECRYTPION_INFO beplease consider that its current > defineion (in master) is: > > *** DECRYPTION_INFO [] > Print information about the symmetric encryption algorithm and the > MDC method. This will be emitted even if the decryption f

Re: AW: AW: AW: AW: Efail or OpenPGP is safer than S/MIME

On Thu, 17 May 2018 13:11, roman.fied...@ait.ac.at said: > How could that work together with the memory based "wipe" approach, you > envisioned in your message > https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html , last > paragraph? Tha is a different layer. Basically a part o

Re: Efail or OpenPGP is safer than S/MIME

> Am 17.05.2018 um 13:03 schrieb Werner Koch : > > The important print is that MDC_METHOD will be 0 with the forthcoming > AEAD algorithm. Thus you need to check whether 3rd argument is there. > > mdc_method = atoi(arg_1) > aead_algo = have_3_args? atoi(arg_3) : 0 > if (!mdc_method

AW: Efail or OpenPGP is safer than S/MIME

> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von > > On 17 May 2018, at 11:50, Patrick Brunschwig > wrote: > > > >> On 17.05.18 10:07, Werner Koch wrote: > >> On Thu, 17 May 2018 08:59, patr...@enigmail.net said: > >> > >>> Within 12 hours after the release I got 5 bug repo

Re: Efail or OpenPGP is safer than S/MIME

> On 17 May 2018, at 11:50, Patrick Brunschwig wrote: > >> On 17.05.18 10:07, Werner Koch wrote: >> On Thu, 17 May 2018 08:59, patr...@enigmail.net said: >> >>> Within 12 hours after the release I got 5 bug reports/support requests >> >> Kudos to Enigmail for acting as our guinea pig. I imple

Re: Efail or OpenPGP is safer than S/MIME

On Thu, 17 May 2018 11:21, luk...@gpgtools.org said: > Is there any particular reason why these have not been added to > doc/DETAILS? They don't make much sense. I can't remember why I added them. > If we check for DECRYPTION_INFO 0 X (0 being NO MDC) and the > BADMDC status line (in addition t

AW: AW: AW: AW: Efail or OpenPGP is safer than S/MIME

> Von: Werner Koch [mailto:w...@gnupg.org] > > On Wed, 16 May 2018 16:24, roman.fied...@ait.ac.at said: > > > In my opinion it is hard to find such a "one size fits all" > > solution. Like Werner's example: disabling decryption streaming > > The goal of the MDC is to assure that the message has bee

Re: Efail or OpenPGP is safer than S/MIME

On 17.05.18 10:07, Werner Koch wrote: > On Thu, 17 May 2018 08:59, patr...@enigmail.net said: > >> Within 12 hours after the release I got 5 bug reports/support requests > > Kudos to Enigmail for acting as our guinea pig. I implemented the same > thing in GPGME this morning (see my mail to enigm

Re: Efail or OpenPGP is safer than S/MIME

> Am 17.05.2018 um 10:07 schrieb Werner Koch : > > On Thu, 17 May 2018 08:59, patr...@enigmail.net said: > >> Within 12 hours after the release I got 5 bug reports/support requests > > Kudos to Enigmail for acting as our guinea pig. I implemented the same > thing in GPGME this morning (see my

Re: Efail or OpenPGP is safer than S/MIME

On 17/05/18 07:59, Patrick Brunschwig wrote: > Within 12 hours after the release I got 5 bug reports/support requests > from users who can't read their (old?) mails anymore. And the day in > Europe has only just begun -- many users did not yet upgrade ... Are we confident so far that this is limit

Re: Efail or OpenPGP is safer than S/MIME

On Thu, 17 May 2018 08:59, patr...@enigmail.net said: > Within 12 hours after the release I got 5 bug reports/support requests Kudos to Enigmail for acting as our guinea pig. I implemented the same thing in GPGME this morning (see my mail to enigmail users). What shall we do now? Provide a sep

Re: Efail or OpenPGP is safer than S/MIME

On 15.05.18 11:14, Andrew Gallagher wrote: > On 14/05/18 14:44, Andrew Gallagher wrote: >> I would humbly suggest that we stop worrying about which side of the >> GPG/MUA fence the ball is on, and fix it on *both* sides. > > I have just opened tickets in both GnuPG and Enigmail for the respective

Re: Efail or OpenPGP is safer than S/MIME

On 05/16/2018 05:48 AM, Werner Koch wrote: > On Tue, 15 May 2018 11:56, andr...@andrewg.com said: > >> We should also be very careful to note that none of this discussion >> thread applies to the MIME concatenation vulnerability, which is a >> problem in Thunderbird and other mail clients, and whi

Re: Efail or OpenPGP is safer than S/MIME

On Tue, 15 May 2018 11:56, andr...@andrewg.com said: > We should also be very careful to note that none of this discussion > thread applies to the MIME concatenation vulnerability, which is a > problem in Thunderbird and other mail clients, and which cannot be While we are at that point. Can we

Re: AW: AW: AW: Efail or OpenPGP is safer than S/MIME

On Wed, 16 May 2018 16:24, roman.fied...@ait.ac.at said: > In my opinion it is hard to find such a "one size fits all" > solution. Like Werner's example: disabling decryption streaming The goal of the MDC is to assure that the message has been received exactly as the sender set it. Thus there is

Re: Efail

Oh man.. check a few of the previous list emails on this subject. They're fairly detailed. Farhan On Wed, May 16, 2018 at 3:04 AM, eira wahlin wrote: > Hi. > I've been looking at a vulnerability in mail clients using pgp, described > at efail.de. It is a technique where an attacker would inject

AW: AW: AW: Efail or OpenPGP is safer than S/MIME

cryption/validation-process models (requiring loads of parameters, complex models, lot of implementation, risk to invoke gpg with wrong parameters) 3) Supporting one generic use-case/process model and leaving it to the caller (other side of interface) to decide what to make from it (risk, that ot

Re: AW: AW: Efail or OpenPGP is safer than S/MIME

> I’m going to preemptively quote RJH here before he gets around to it. Use the > defaults! ;-) :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: AW: Efail or OpenPGP is safer than S/MIME

> On 16 May 2018, at 13:44, Fiedler Roman wrote: > > I am not sure, if gpg could support implementation/testing/life-cycle-efforts > to establish all those parameters and different process models for most of > the decryption processes gpg users envision to use gpg for. Why do we need a pletho

AW: AW: Efail or OpenPGP is safer than S/MIME

the integrity of the received content >before releasing any information, especially the plaintext of the >content. If the integrity verification fails, the receiver MUST >destroy all of the plaintext of the content. > > Unfortunately this can't be done by tools prepare

Re: AW: Efail or OpenPGP is safer than S/MIME

destroy all of the plaintext of the content. Unfortunately this can't be done by tools prepared to process huge amounts of data. And in contrast to the Efail claims this is an important feature. How would you else do your ZFS backups without having a way to stream the data to the backup

Efail

Hi. I've been looking at a vulnerability in mail clients using pgp, described at efail.de. It is a technique where an attacker would inject a HTML IMG tag in an email, enveloping the encrypted text. This would send the cleartext message to the server inticated in the IMG tag. To me, it seems th

Re: Efail or OpenPGP is safer than S/MIME

r...@sixdemonbag.org (Robert J. Hansen) writes: >>> We hesitate to require the MDC also for old algorithms (3DES, CAST5> >>> because a lot of data has been encrypted using them in the first >>> years of OpenPGP. >> So if someone sends me a 3DES-encrypted mail it won't check the MDC? >> Doesn't gp

Re: efail -> improvements (was: Efail or OpenPGP is safer than S/MIME)

Just for information: Am Dienstag 15 Mai 2018 08:52:45 schrieb Bernhard Reiter: > .. to only display contents if there was integrity protection by either [..] I'll continue the discussion about what should technically be done to gnupg on gnupg-devel@ > if users or frontends still want to show c

AW: Efail or OpenPGP is safer than S/MIME

> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von > > > On 14 May 2018, at 18:32, Werner Koch wrote: > > > > On Mon, 14 May 2018 15:44, andr...@andrewg.com said: > > > >> This all exposes one of the difficulties with trying to manage security > >> software in a decentralised

Re: Efail or OpenPGP is safer than S/MIME

On 15/05/18 08:58, Werner Koch wrote: > > Unless you change the default options of gpg or you encrypt to at least > one old key there is no problem at all. I assume that 99.9% of all GPG > created messages are safe because they use MDC in away which allows the > receiving GPG to hard fail if the M

Re: efail -> improvements (was: Efail or OpenPGP is safer than S/MIME)

Am Dienstag 15 Mai 2018 10:29:45 schrieb Andrew Gallagher: > I’m not saying that active elements should be banned outright, just that > they should be handled more carefully in the encrypted case than they are > in plaintext. > so we may want to suppress the handy “load images” button or have > a

AW: Efail or OpenPGP is safer than S/MIME

> Von: MFPA [mailto:2017-r3sgs86x8e-lists-gro...@riseup.net] > > Hi > > On Monday 14 May 2018 at 1:33:03 PM, in > local>, > Fiedler Roman wrote:- > > > This would also prevent many other programming > > errors: e.g. if gpg > > claims to have processed 2 signed messages, a client > > has to verify,

  1   2   >