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
> 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
> 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
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
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
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
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 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
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
> 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
44 matches
Mail list logo
