p.ark3
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
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-
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
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
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
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
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
> 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
> 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
> 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
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
> 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
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
> 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
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
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
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
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
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
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
> Von: Andrew Gallagher [mailto:andr...@andrewg.com]
>
> > 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 proce
> 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
> 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
> Von: Werner Koch [mailto:w...@gnupg.org]
>
> On Tue, 15 May 2018 11:44, roman.fied...@ait.ac.at said:
>
> > The status line format should be designed to support those variants to
> > allow a "logical consistency check" of the communication with GnuPG
>
> There is a
>
> DECRYPTION_FAILED
>
> and t
On Tue, 15 May 2018 11:44, roman.fied...@ait.ac.at said:
> The status line format should be designed to support those variants to
> allow a "logical consistency check" of the communication with GnuPG
There is a
DECRYPTION_FAILED
and that is all what it takes. If the integrity check fails the
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
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
> 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
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
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
> 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,
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.
https://dev.gnupg.org
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 rem
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 with potentially active
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 optio
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 we consider this
.. 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
* th
Werner Koch, wk, at gnupg.org wrote on
Mon May 14 19:32:18 CEST 2018:
...
I am all in favor of this and even considered to that some time ago.
However, not too long ago we removed support for PGP-2 keys which
unfortunately resulted in lots of angry mails from people who now think
they need to use
Hi
On Monday 14 May 2018 at 1:33:03 PM, in
,
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,
> that it also received two "GOOD_SIG" messages.
What if a message has more than o
> 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 ecosystem. We end up in arguments over whose
>
> That is actually easy compared to
> On 14 May 2018, at 18:57, Lars Noodén wrote:
>
> How feasible would it be to strip or disable encryption in a fork of an
> old version and just leave it capable of decryption?
I’m sure it’s feasible, but it doesn’t address this issue or any other kind of
oracle, replay or chosen-text attack.
On 05/14/2018 08:32 PM, Werner Koch wrote:
[snip]
> I am all in favor of this and even considered to that some time ago.
> However, not too long ago we removed support for PGP-2 keys which
> unfortunately resulted in lots of angry mails from people who now think
> they need to use gnupg 1.4 every d
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 ecosystem. We end up in arguments over whose
That is actually easy compared to a system which is also designed to
protect data at rest. Som
On 14/05/18 13:42, Robert J. Hansen wrote:
>> If I read it correctly, it also has another attack, no longer based on
>> user agents concatenating HTML mime parts, but also based on CFB
>> gadgets. Which, here, looks like a flaw in the OpenPGP specification
>> indeed (and thus GnuPG's implementation
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von
>
> On 14/05/18 12:25, Robert J. Hansen wrote:
> > The problem is that gpg doesn't say anything. I would expect a
> > DECRYPTION_FAILED message here:
>
> So perhaps the solution is to throw a big warning and prompt when an
>
> If I read it correctly, it also has another attack, no longer based on
> user agents concatenating HTML mime parts, but also based on CFB
> gadgets. Which, here, looks like a flaw in the OpenPGP specification
> indeed (and thus GnuPG's implementation of it), and not in MUAs?
MDCs stop it dead.
On 05/14/2018 09:45 AM, Werner Koch wrote:> The topic of that paper is
that HTML is used as a back channel to create
> an oracle for modified encrypted mails. It is long known that HTML
> mails and in particular external links like
> are evil if the MUA actually honors them (which many meanwhile
On 14/05/18 12:25, Robert J. Hansen wrote:
> The problem is that gpg doesn't say anything. I would expect a
> DECRYPTION_FAILED message here:
So perhaps the solution is to throw a big warning and prompt when an
integrity check failure is thrown by gnupg? That would mitigate the
current issue, but
On 14/05/18 12:23, Robert J. Hansen wrote:
> It's worth noting, incidentally, the #Efail attack flat-out requires
> MIME. So inline PGP messages are not vulnerable, as there's no MIME
> parsing pass which can be exploited. So you're *still* safe
I wouldn't be that confident. I haven't tested PGP
... and Patrick, moving faster than the speed of light, already has the
bug triaged and bounced back. This is actually a GnuPG bug, not an
Enigmail bug. From Patrick:
=
The problem is that gpg doesn't say anything. I would expect a
DECRYPTION_FAILED message here:
[GNUPG:] ENC_TO 5F5FDF4006
> Argh, I meant to say 3DES of course, not MD5. Sorry.
It's worth noting, incidentally, the #Efail attack flat-out requires
MIME. So inline PGP messages are not vulnerable, as there's no MIME
parsing pass which can be exploited. So you're *still* safe, although
this is still a bug that should be
On 14/05/18 12:13, Andrew Gallagher wrote:
> I tried again using CAST5 instead of MD5 to bypass the smartcard bug.
Argh, I meant to say 3DES of course, not MD5. Sorry.
--
Andrew Gallagher
signature.asc
Description: OpenPGP digital signature
___
Gnup
Fascinating. I've thrown it over to Patrick: we'll look into it and get
back in touch soon.
signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
On 14/05/18 10:42, Robert J. Hansen wrote:
> ... Yep, GnuPG will warn you the message was not integrity protected.
> Your email client should see this warning and refuse to render the message.
I tried again using CAST5 instead of MD5 to bypass the smartcard bug.
The news is not good.
```
andrewg@
On 14/05/18 10:42, Robert J. Hansen wrote:
> ... Yep, GnuPG will warn you the message was not integrity protected.
> Your email client should see this warning and refuse to render the message.
Yes, but that's not as serious as the error thrown for an unprotected
AES message. Do mail clients treat
>> 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 gpg still support reading 3DES?
Let's try it and find
On 14/05/18 10:15, Robert J. Hansen wrote:
>> I see that MDC is the default for all modern ciphers, but does that imply
>> that MDC *checking* is the default?
> MDC is an attribute of the packet, not the cipher. By default, all
> ciphers in the GnuPG suite use MDC.
OK, but from Werner's link earl
> So how do we enforce MDC checking at the receiving end? I assume this is
> something that has to be handled by the calling program at the moment.
By default, GnuPG will scream bloody murder if a message lacks an MDC or
if the MDC is invalid. At that point it's up to your email client to
pay att
Hi!
I digged in my mail archives and found a discussion with Sebastian
Schinzel about a work in progress thing which turned out to not being a
GnuPG problem. Here is a timeline with my messages.
On 2017-11-24 we were asked for the encryption keys of the security at
gnupg.org address. On the sam
On 14/05/18 08:45, Werner Koch wrote:
> The topic of that paper is that HTML is used as a back channel to
> create an oracle for modified encrypted mails.
This confirms that my forensic analysis of the wording of the
announcement was sound. ;-)
The good thing is that oracle attacks are *noisy*,
The following is what I wrote to a journalist covering the story:
=
We've known about problems in OpenPGP's feedback mode for at least
thirteen years. (See https://eprint.iacr.org/2005/033.pdf for an
example.) The OpenPGP working group resolved these problems by adopting
modification detect
Hi!
Some may have noticed that the EFF has warnings about the use of PGP out
which I consider pretty overblown. The GnuPG team was not contacted by
the researchers but I got access to version of the paper related to
KMail. It seems to be the complete paper with just the names of the
other MUAs r
62 matches
Mail list logo
