Re: Breaking MIME concatenation

On 15.05.18 17:53, Lukas Pitschl | GPGTools wrote: > >> Am 15.05.2018 um 17:44 schrieb Patrick Brunschwig : >> >> I already tried a while ago to trick the Thunderbird HTML rendering >> engine with tricks like this... They don't work. The rendering engine >> ignores the tag

GPGME progress callback no current or total

I was testing the progress callback of GPGME in python and got some strange results. I'm using GPGME v1.11.1 $ cat progresstest.py import gpg, tempfile # Borrowed from callbacks.py def progress_stdout(what, type, current, total, hook=None): print("PROGRESS UPDATE: what = %s, type =

Re: smartcards and GPGME

On 05/14/2018 02:02 AM, Andre Heinecke wrote: > Hi, > > On Sunday, May 13, 2018 6:26:04 PM CEST Jacob Adams wrote: >> As part of a program I'm writing this summer for GSoC, I'd like to be >> able to both move gpg private keys to a smartcard and generate keys on >> the smartcard from an

Re: Breaking MIME concatenation

> Am 15.05.2018 um 17:44 schrieb Patrick Brunschwig : > > I already tried a while ago to trick the Thunderbird HTML rendering > engine with tricks like this... They don't work. The rendering engine > ignores the tag (and also tags like ). > > I think the correct solution

Re: Breaking MIME concatenation

On 15/05/18 16:44, Patrick Brunschwig wrote: > I already tried a while ago to trick the Thunderbird HTML rendering > engine with tricks like this... They don't work. The rendering engine > ignores the tag (and also tags like ). OK, that particular trick won't work. But if content injection is

Re: Don't Panic.

On Mon, May 14, 2018 at 04:48:31PM +0100, Mark Rousell wrote: > Amongst other things this includes the following paragraph which, as I > understand it, is essentially untrue: > > "There are currently no reliable fixes for the vulnerability. If you > use PGP/GPG or S/MIME for very

Breaking MIME concatenation

It struck me at lunch that it might be possible for gnupg itself to scupper the MIME concatenation (direct exfiltration) technique mentioned in efail, and thereby plug the leaks in multiple vulnerable clients at once. This would however require it to be naughty with its output. MIME concatenation

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

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

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

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

Re: Efail or OpenPGP is safer than S/MIME

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 integrity check mitigations.

Re: Efail or OpenPGP is safer than S/MIME

On 14.05.18 19:32, Werner Koch wrote: [...] >> 1. change the default behaviour of GPG so that any integrity failure is >> fatal by default, even for old ciphersuites (we could have a flag to > > I am all in favor of this and even considered to that some time ago. > However, not too long ago we

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

On 15 May 2018, at 07:42, Bernhard Reiter wrote: >> Another thing we need to learn from this is that HTML elements may be a >> privacy concern in plaintext mail, but they are a *security* concern in >> encrypted mail. > > People clearly seem to want a way to send files

Re: Efail or OpenPGP is safer than S/MIME

On Mon, 14 May 2018 22:43, andr...@andrewg.com said: > If we believe that there will be more encrypted messages in the future than > there have been in the past, then protecting those future messages takes > priority, especially if an upgrade pathway exists. Unless you change the default

S/MIME implementation that uses authenticated-data?

Hi, do you know any S/MIME (or CMS) implementations that use authenticated-data type from STD 70 aka RFC 5652? If we wanted to implement this for GnuPG's gpgsm, it would be very cool to have implementations to test against. The ticket is https://dev.gnupg.org/T3979, you can also reply there.

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

Am Montag 14 Mai 2018 22:43:56 schrieb Andrew Gallagher: > > On 14 May 2018, at 18:32, Werner Koch wrote: > > Well okay, with the new support of the Ehtmlfail paper we could now > > point to that paper and always hard error out if no MDC is used even for > > old algorithms. Shall

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

.. to only display contents if there was integrity protection by either > a) MDC > b) AEAD > c) a signature over the whole contents from someone where it has been > encrypted to (if this is feasable to detect). if users or frontends still want to show contents, to me it seems good if *