US-CERT now issuing a warning for OpenPGP-SMIME-Mail-Client-Vulnerabilities

[Jerry]

NCCIC encourages users and administrators to review CERT/CC’s Vulnerability
Note VU #122919.

https://www.us-cert.gov/ncas/current-activity/2018/05/14/OpenPGP-SMIME-Mail-Client-Vulnerabilities

-- 
Jerry

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

Re: Efail or OpenPGP is safer than S/MIME

[vedaal]

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 gnupg 1.4 every day because they seem to read mails
>From the last century on a regular base.  Well, they think and they were
quite vocal.  Now telling them they need to enable an option to read
certain not that old mail (e.g. creating by other OpenPGP
implementations) will a) lead to even more angry mails and b) they will
keep on using that option for all mails.  Thus my tentative plan was to
make the next major version hard fail on messages without MDC and slowly
start using our forthcoming AEAD encryption mode.

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

=

Yes.

As an Old PGP 2.x user, I can say that the majority of PGP 2.x users 
communicating among them selves, DON'T use GnuPG at all. 

Those who do use GnuPG, have a new V4 key and use exclusively that, and can 
easily handle the hardwired MDC fail, and will even be thankful for the GnuPG 
'protection'. 


vedaal


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

Re: Efail or OpenPGP is safer than S/MIME

[MFPA]

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 one signature?

-- 
Best regards

MFPA  

I think not, said Descartes, and promptly disappeared

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

Re: Don't Panic.

[Robert J. Hansen]

> I'm going to add this to the HN thread. I trust that's OK.

Go for it.  :)


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

Re: Don't Panic.

[Mirimir]

On 05/13/2018 08:27 PM, Robert J. Hansen wrote:
> [taps the mike]
> 
> Hi.  I maintain the official GnuPG FAQ.  So let me start off by
> answering a question that is certainly about to be asked a lot: "Should
> we be worried about OpenPGP, GnuPG, or Enigmail?  The EFF's advising us
> to uninstall it!"
> 
> https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now
> 
> Werner saw a preprint of this paper some time ago.  I saw it recently.
> Patrick Brunschwig of Enigmail saw it.  None of us are worried.  Out of
> respect for the paper authors I will skip further comment until such
> time as the paper is published.
> 
> It would've been nice if EFF had reached out to us for comment, rather
> than apparently only talking to the paper authors.  We hope they'll
> reach out next time.

Thanks. I didn't know what to think.

I'm going to add this to the HN thread. I trust that's OK.

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

Re: Don't Panic.

[Andrew Gallagher]

> On 14 May 2018, at 14:47, Dan Kegel  wrote:
> 
> Anyway, if you have a checkbox for 'automatically decrypt', you might
> consider unticking it.)

This may not be sufficient. It’s not just automatic decryption but any 
decryption at all in the client that can trigger a callback. In the PGP case 
the attack is noisy, so you *may* have a chance to protect yourself before the 
damage is done if manual decryption is required for each attempt. But that 
assumes that a human being can reliably distinguish the attempts, which assumes 
a high level of knowledge of the attack procedure. 

A

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

Re: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

> 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 a system which is also designed to
> protect data at rest.  Some users may want to restore their 2 year old
> backup to fix a problem with garbled tapes; some may want to read the
> real documents about WMD from 2003; some may even want to be able to
> decrypt their old love letters at the time of their silver wedding.

Indeed. This is why data must be treated as a living object. If tape drive 
technology moves on, the data must be moved on. Same with file formats, 
encryption systems and dying raid arrays. Librarians and archaeologists 
understand the process of care and feeding for physical artefacts. Digital 
artefacts are no exception. 

>> 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 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 day because they seem to read mails
> From the last century on a regular base.  Well, they think and they were
> quite vocal.  Now telling them they need to enable an option to read
> certain not that old mail (e.g. creating by other OpenPGP
> implementations) will a) lead to even more angry mails and b) they will
> keep on using that option for all mails.  Thus my tentative plan was to
> make the next major version hard fail on messages without MDC and slowly
> start using our forthcoming AEAD encryption mode.
> 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?

Yes, absolutely. I think this is the easiest and most effective technical 
mitigation available. If people have a problem with data archival, they should 
be pointed to a guide on how to re-encrypt their sensitive data in a modern 
format. Their data is probably horrendously insecure anyway, so we’re doing 
them a favour. :-)

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. 

>> the obsolete ciphersuites by default (again, we can provide an
> 
> They are not used by default.  3DES is a MUST algorithm and will only be
> deprecated with RFC_4990bis and thus GnuPG 2.3. 

OK.

As an aside, I think we have to be careful about the meaning of “use”. They are 
not used by default in encryption, but they are in decryption. I’ve had 
multiple conversations today over this ambiguity. 

>> 2. AND the MUAs need to make sure they fail hard on integrity warnings,
>> because old versions of GPG may hang around for a while. Also ensure
> 
> Fortunately the majority of them do.

Yes, nevertheless I don’t think it is good practice to rely on one single layer 
for security protection, because then we have a single point of failure. With 
two interacting systems, neither should assume that the other is behaving 
correctly. Trust but verify, belt and braces, measure twice cut once.

That means security policy should be enforced by both applications, so that a 
single failure doesn’t blow open the entire system. This is especially 
important when there are potentially unlimited kinds of systems, of varying 
compliance, that could be involved in any interaction. 

I think also that we should be mindful that “be strict about what you send but 
liberal about what you receive” is great advice for interoperability, but 
absolutely disastrous advice for security. 

>> that links aren't followed by default, that the capabilities of
>> encrypted HTML mail are constrained, etc.
> 
> Yes please, I consider this the minimum requirement for HTML based
> mails.  Why sending email when you need to go online for reading them.
> And also disallow Javascript.  How you only need to convince the mail
> content designers that they can't simply use the web page and send it as
> mail.  That will be the hard part.

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. 
The context changes the risk profile. So mail clients (tbird) that disable 
risky HTML (such as loading images) by default but provide user overrides are 
doing so justifiably from a privacy standpoint, where a warning about the 
privacy implications may be sufficient. 

But encryption has to change this risk analysis - in an encrypted mail there 
can’t be an easy override because the stakes are much 

Re: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

> 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. If today has taught us anything, surely 
it is that flaws in decryption are just as dangerous as flaws in encryption. 

A

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

Re: Efail or OpenPGP is safer than S/MIME

[Werner Koch]

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.  Some users may want to restore their 2 year old
backup to fix a problem with garbled tapes; some may want to read the
real documents about WMD from 2003; some may even want to be able to
decrypt their old love letters at the time of their silver wedding.

> 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 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 day because they seem to read mails
From the last century on a regular base.  Well, they think and they were
quite vocal.  Now telling them they need to enable an option to read
certain not that old mail (e.g. creating by other OpenPGP
implementations) will a) lead to even more angry mails and b) they will
keep on using that option for all mails.  Thus my tentative plan was to
make the next major version hard fail on messages without MDC and slowly
start using our forthcoming AEAD encryption mode.

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?

> the obsolete ciphersuites by default (again, we can provide an

They are not used by default.  3DES is a MUST algorithm and will only be
deprecated with RFC_4990bis and thus GnuPG 2.3. 

> 2. AND the MUAs need to make sure they fail hard on integrity warnings,
> because old versions of GPG may hang around for a while. Also ensure

Fortunately the majority of them do.

> that links aren't followed by default, that the capabilities of
> encrypted HTML mail are constrained, etc.

Yes please, I consider this the minimum requirement for HTML based
mails.  Why sending email when you need to go online for reading them.
And also disallow Javascript.  How you only need to convince the mail
content designers that they can't simply use the web page and send it as
mail.  That will be the hard part.

> The PGP ecosystem will survive this, because the tech is in place. The

I am not so sure for S/MIME - but that is whishful thinking ;-)


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Don't Panic.

[Mark Rousell]

On 14/05/2018 08:27, Robert J. Hansen wrote:
> Werner saw a preprint of this paper some time ago.  I saw it recently.
> Patrick Brunschwig of Enigmail saw it.  None of us are worried.  Out of
> respect for the paper authors I will skip further comment until such
> time as the paper is published.
>
> It would've been nice if EFF had reached out to us for comment, rather
> than apparently only talking to the paper authors.  We hope they'll
> reach out next time.

I see that the Inquirer is passing on the FUD. May I suggest that
someone authoritative gets in touch with them to correct them.

PGP is leaking your emails in plaintext and there's no known fix


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 sensitive communication, you should
disable it in your email client for now," said Sebastian Schinzel
, a
professor of computer security at the University.




-- 
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: Don't Panic.

[Mark Rousell]

On 14/05/2018 08:27, Robert J. Hansen wrote:
> Werner saw a preprint of this paper some time ago.  I saw it recently.
> Patrick Brunschwig of Enigmail saw it.  None of us are worried.  Out of
> respect for the paper authors I will skip further comment until such
> time as the paper is published.
>
> It would've been nice if EFF had reached out to us for comment, rather
> than apparently only talking to the paper authors.  We hope they'll
> reach out next time.

I see that the Inquirer is passing on the FUD. May I suggest that
someone authoritative gets in touch with them to correct them.

PGP is leaking your emails in plaintext and there's no known fix


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 sensitive communication, you should
disable it in your email client for now," said Sebastian Schinzel
, a
professor of computer security at the University.



(Re-sent as my outgoing server got a
"451-xx.xx.xx.xx+is+not+yet+authorized+to+deliver+mail+from" error first
time round.)

-- 
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: Don't Panic.

[Dan Kegel]

Thanks for the heads up!

(The eff alert only suggests disabling tools that *automatically*
decrypt messages,
Stumbling around a bit on the net, this sounds like a rehash of
https://sourceforge.net/p/enigmail/bugs/226/
Anyway, if you have a checkbox for 'automatically decrypt', you might
consider unticking it.)
- Dan

On Mon, May 14, 2018 at 12:27 AM, Robert J. Hansen  wrote:
> [taps the mike]
>
> Hi.  I maintain the official GnuPG FAQ.  So let me start off by
> answering a question that is certainly about to be asked a lot: "Should
> we be worried about OpenPGP, GnuPG, or Enigmail?  The EFF's advising us
> to uninstall it!"
>
> https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now
>
> Werner saw a preprint of this paper some time ago.  I saw it recently.
> Patrick Brunschwig of Enigmail saw it.  None of us are worried.  Out of
> respect for the paper authors I will skip further comment until such
> time as the paper is published.
>
> It would've been nice if EFF had reached out to us for comment, rather
> than apparently only talking to the paper authors.  We hope they'll
> reach out next time.
>
>
> ___
> 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: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

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 of it), and not in MUAs?
> 
> MDCs stop it dead.  If a message has no MDC or an invalid MDC, GnuPG
> _will_ warn you about it.  Now, whether your email client does the right
> thing upon being warned, that's between you and your email client...

This all exposes one of the difficulties with trying to manage security
software in a decentralised ecosystem. We end up in arguments over whose
responsibility it is when the joints come apart.

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

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
override for those that really need it). For belt and braces, disable
the obsolete ciphersuites by default (again, we can provide an
override). We have assumed that so long as you don't *generate* poor
crypto you're safe. That's just not true.

2. AND the MUAs need to make sure they fail hard on integrity warnings,
because old versions of GPG may hang around for a while. Also ensure
that links aren't followed by default, that the capabilities of
encrypted HTML mail are constrained, etc.

The PGP ecosystem will survive this, because the tech is in place. The
enforcement has just erred a little too far on the side of
compatibility. It's all fixable.

-- 
Andrew Gallagher



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

AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> 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
> integrity check failure is thrown by gnupg? That would mitigate the
> current issue, but allow for reading pre-MDC emails as per Werner's
> earlier link.
> 
> The problem here is that an integrity failure is a serious error when it
> occurs in a context where oracle behaviour is possible (such as email),
> but it's much less serious when used outside that context. Just because
> gnupg says it's only a warning-level offence doesn't mean enigmail
> should agree...

In my opinion, the problem is related to the general gnupg interface design. An 
optional error or warning is always somehow problematic in interfaces:

1) you have to read and understand the complete documentation to know of any 
message that may occur

2) if it is not here, you simply do not know, if everything is right, if you 
just missed the message or an attacker managed to "suppress" it somehow. Makes 
it easier on the attacker - like here

In my opinion, gnupg would do itself a favour by avoiding optional messages - 
without any other reference to it. With such a protocol I would expect gnupg to 
end somehow like ...

[END_STATUS]: Messages: 3, Valid MDCs 2, Signed Messages 2, , Warnings: 1, 
Errors: 0 ... (put here everything you deem important and document it)

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. If just any of the numbers do not match, any good mail 
client should bail out immediately, e.g. if warn=1 but the client did not 
understand the warning.

LG R

PS: A end message as single line sorted JSON dictionary might make parsing less 
error prone and increase the number of developers really parsing and using them.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Efail or OpenPGP is safer than S/MIME

[Robert J. Hansen]

> 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.  If a message has no MDC or an invalid MDC, GnuPG
_will_ warn you about it.  Now, whether your email client does the right
thing upon being warned, that's between you and your email client...

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

Re: Efail or OpenPGP is safer than S/MIME

[Leo Gaspard via Gnupg-users]

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 seem to
> do again; see all these newsletters).  Due to broken MIME parsers a
> bunch of MUAs seem to concatenate decrypted HTML mime parts which makes
> it easy to plant such HTML snippets.

The full details appear to be out [1].

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?


[1] https://efail.de/

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

Efail press release

[Robert J. Hansen]

Over the last few hours, Werner, Andre, and I have been working on an
official statement about the Efail paper.  Without further ado, here it is.



An Official Statement on New Claimed Vulnerabilities
==  = == === === ===
by the GnuPG and Gpg4Win teams

(This statement is only about the susceptibility of OpenPGP, GnuPG, and
Gpg4Win.  It does not cover S/MIME.)

Recently some security researchers published a paper named "Efail:
Breaking S/MIME and OpenPGP Encryption using Exfiltration Channels".
The EFF has gone so far as to recommend immediately uninstalling
Enigmail.  We have three things to say, and then we're going to show you
why we're right.

1. This paper is misnamed.

2. This attack targets buggy email clients.

3. The authors made a list of buggy email clients.

In 1999 we realized OpenPGP's symmetric cipher mode (a variant of cipher
feedback) had a weakness: in some cases an attacker could modify text.
As Werner Koch, the founder of GnuPG, put it: "[Phil Zimmermann] and Jon
Callas asked me to attend the AES conference in Rome to discuss problems
with the CFB mode which were on the horizon.  That discussion was in
March 1999 and PGP and GnuPG implemented a first version [of our
countermeasure] about a month later.  According to GnuPG's NEWS file,
[our countermeasure] went live in Summer 2000."

The countermeasure Werner mentions is called a Modification Detection
Code, or MDC.  It's been a standard part of GnuPG for almost eighteen
years.  For almost all that time, any message which does not have an MDC
attached has caused GnuPG to throw up big, clear, and obvious warning
messages.  They look something like this:

gpg: encrypted with 256-bit ECDH key, ID 7F3B7ED4319BCCA8, created
2017-01-01
  "Werner Koch "
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_INFO 0 7
[GNUPG:] PLAINTEXT 62 1526109594
[GNUPG:] PLAINTEXT_LENGTH 69
There is more to life than increasing its speed.
-- Mahatma Gandhi
gpg: WARNING: message was not integrity protected
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION

GnuPG also throws large warning messages if an MDC indicates a message
has been modified.  In both cases, if your email client respects this
warning and does the right thing -- namely, not showing you the email --
then you are completely protected from the Efail attack, as it's just a
modern spin on something we started defending against almost twenty
years ago.

If you're worried about the Efail attack, upgrade to the latest version
of GnuPG and check with your email plugin vendor to see if they handle
MDC errors correctly.  Most do.

You might be vulnerable if you're running an ancient version of GnuPG
(the 1.0 series; the current is 2.2), or if your email plugin doesn't
handle GnuPG's warning correctly.  You might also have had some exposure
in the past if back then you used a pre-2000 version of GnuPG, and/or an
email plugin which didn't handle the warning correctly.

We made three statements about the Efail attack at the beginning.  We're
going to repeat them here and give a little explanation.  Now that we've
explained the situation, we're confident you'll concur in our judgment.

1.  This paper is misnamed.  It's not an attack on OpenPGP.  It's an
attack on broken email clients that ignore GnuPG's warnings and do silly
things after being warned.

2.  This attack targets buggy email clients.  Correct use of the MDC
completely prevents this attack.  GnuPG has had MDC support since the
summer of 2000.

3.  The authors made a list of buggy email clients.  It's worth looking
over their list of email clients (found at the very end) to see if yours
is vulnerable.  But be careful, because it may not be accurate -- for
example, Mailpile says they're not vulnerable, but the paper indicates
Mailpile has some susceptibility.

The authors have done the community a good service by cataloguing buggy
email email clients.  We're grateful to them for that.  We do wish,
though, this thing had been handled with a little less hype.  A whole
lot of people got scared, and over very little.

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

Re: Mailpile on Efail

[Werner Koch]

On Mon, 14 May 2018 13:47, r...@sixdemonbag.org said:

> Short version: Mailpile isn't impressed, either, and is a little annoyed
> they were mistakenly listed as being vulnerable.

Yes, all green in the table for Mailpile.  GgpOL (Gpg4win's Outlook
plugin) is also claimed to be vulnerable but the table shows tha this is
only the case when used with Outlook 2007 - which is not anymore
supported and brings up a warning when used with GpgOL.

BTW, the lack of all version numbers of the plugins or crypto engines is
a major flaw in the paper.  With version numbers it would be much easier
to see what is wrong with some claims.


Salam-Shalom,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

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 allow for reading pre-MDC emails as per Werner's
earlier link.

The problem here is that an integrity failure is a serious error when it
occurs in a context where oracle behaviour is possible (such as email),
but it's much less serious when used outside that context. Just because
gnupg says it's only a warning-level offence doesn't mean enigmail
should agree...

-- 
Andrew Gallagher



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

Mailpile on Efail

[Robert J. Hansen]

https://www.mailpile.is/blog/2018-05-14_PGP_Security_Alert.html

Short version: Mailpile isn't impressed, either, and is a little annoyed
they were mistakenly listed as being vulnerable.



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

Re: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

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/MIME yet simply
because it's harder to construct the test message. The important point
is that we can't rely on gnupg's message integrity check to prevent
automatic decryption - so there's no good reason to believe that PGP
mail is any less vulnerable than S/MIME.

Note to anyone coming fresh to the conversation: disabling the display
of HTML email is *probably* a sufficient mitigation in either case.

-- 
Andrew Gallagher



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

Re: Efail or OpenPGP is safer than S/MIME

[Robert J. Hansen]

... 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 5F5FDF400616A9CF 1 0
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
gpg: WARNING: cipher algorithm CAST5 not found in recipient preferences
[GNUPG:] DECRYPTION_KEY 530187ED159A04E6F53ED1385F5FDF400616A9CF
4F9F89F5505AC1D1A260631CDB1187B9DD5F693B u
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
gpg: encrypted with 4096-bit RSA key, ID 5F5FDF400616A9CF, created
2018-01-17
  "Patrick Brunschwig "
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_INFO 0 3
[GNUPG:] PLAINTEXT 62 1526296937
[GNUPG:] PLAINTEXT_LENGTH 4
abc
[GNUPG:] NEWSIG
gpg: Signature made Mon May 14 13:22:17 2018 CEST
gpg:using RSA key 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
[GNUPG:] SIG_ID Rh02jRM7bb5K0OOXQaEgmdJF+Bo 2018-05-14 1526296937
[GNUPG:] KEY_CONSIDERED 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 0
[GNUPG:] GOODSIG DB1187B9DD5F693B Patrick Brunschwig 
gpg: Good signature from "Patrick Brunschwig "
[ultimate]
gpg: aka "Patrick Brunschwig "
[ultimate]
gpg: aka "[jpeg image of size 13251]" [ultimate]
[GNUPG:] VALIDSIG 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 2018-05-14
1526296937 0 4 0 1 10 00 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B
[GNUPG:] TRUST_ULTIMATE 0 direct
[GNUPG:] VERIFICATION_COMPLIANCE_MODE 23
[GNUPG:] DECRYPTION_OKAY
gpg: WARNING: message was not integrity protected
[GNUPG:] END_DECRYPTION



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

Re: Efail or OpenPGP is safer than S/MIME

[Robert J. Hansen]

> 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 fixed.  ;)

I can recreate the bug; I'll be bringing it up to Patrick soon.



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

Re: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

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
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Efail or OpenPGP is safer than S/MIME

[Robert J. Hansen]

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

Re: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

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@fred:~$ gpg --recipient 0xFB73E21AF1163937 --cipher-algo CAST5
--disable-mdc --encrypt --sign --armor reply.txt
gpg: using "00CC54C6A0C601691AF4931FFB73E21AF1163937" as default secret
key for signing
File 'reply.txt.asc' exists. Overwrite? (y/N) y
andrewg@fred:~$ gpg reply.txt.asc
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: encrypted with 4096-bit RSA key, ID 0x6B09069314549D4B, created
2013-07-02
  "Andrew Gallagher "
File 'reply.txt' exists. Overwrite? (y/N)
Enter new filename: foo
gpg: Signature made Mon 14 May 2018 11:57:17 IST
gpg:using RSA key 291E79A1DC55AE27A52EEF835C1EC404D5906629
gpg: Good signature from "Andrew Gallagher " [ultimate]
gpg: aka "Andrew Gallagher " [ultimate]
gpg: aka "Andrew Gallagher "
[ultimate]
gpg: aka "Andrew Gallagher
" [ultimate]
gpg: aka "[jpeg image of size 18803]" [ultimate]
gpg: aka "Andrew Gallagher "
[ultimate]
Primary key fingerprint: 00CC 54C6 A0C6 0169 1AF4  931F FB73 E21A F116 3937
 Subkey fingerprint: 291E 79A1 DC55 AE27 A52E  EF83 5C1E C404 D590 6629
gpg: WARNING: message was not integrity protected
```

So far so good - gnupg correctly throws a warning. But:

```
andrewg@fred:~$ cat reply.txt.asc | mailx andr...@andrewg.com -s "test
message"
```

Now in Enigmail, I get a decrypted message with a green bar and no
warnings whatsoever:

```
Enigmail Security Info

Decrypted message
Good signature from Andrew Gallagher 
Key ID: 0xF1163937 / Signed on: 14/05/18, 11:57
Key fingerprint: 00CC 54C6 A0C6 0169 1AF4 931F FB73 E21A F116 3937

Used Algorithms: RSA and SHA512

Note: The message is encrypted for the following User ID's / Keys:
  0x6B09069314549D4B (Andrew Gallagher )
```

So it would appear that Enigmail IS VULNERABLE.

I have reproduced this on debian's 2:1.9.9-1~deb9u1 (v1.9.9) and 2.0.3
on Mac. By comparison, the default cipher (AES) correctly throws a
decryption error in enigmail using the same test systems.

-- 
Andrew Gallagher



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

Re: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

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 such warnings as fatal? Should mail
clients *ever* treat mere warnings as fatal?

I can't test here because I'm suffering from https://dev.gnupg.org/T3576
 - guess that means I'm immune! ;-)

-- 
Andrew Gallagher



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

Re: Efail or OpenPGP is safer than S/MIME

[Robert J. Hansen]

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

PS C:\Users\rjh> gpg --recipient 0xB44427C7 --cipher-algo 3DES
--disable-mdc --encrypt --sign foo.cc
gpg: 0xB44427C7: skipped: public key already present
gpg: WARNING: encrypting without integrity protection is dangerous

PS C:\Users\rjh> gpg foo.cc.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
gpg: encrypted with 256-bit ECDH key, ID AA24CC81B8AED08B, created
2017-04-05
  "Robert J. Hansen "
File 'foo.cc' exists. Overwrite? (y/N) y
gpg: Signature made 05/14/18 05:40:46 Eastern Daylight Time
gpg:using EDDSA key 4BF2042AE28F62B81736E8CBA83CAE94D3DC3873
gpg: Good signature from "Robert J. Hansen " [ultimate]
gpg: aka "Robert J. Hansen " [ultimate]
gpg: aka "Robert J. Hansen "
[ultimate]
gpg: WARNING: message was not integrity protected



... Yep, GnuPG will warn you the message was not integrity protected.
Your email client should see this warning and refuse to render the message.



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

Re: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

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

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

-- 
Andrew Gallagher



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

Re: Efail or OpenPGP is safer than S/MIME

[Robert J. Hansen]

> 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 attention to the warning and do the right thing.  Enigmail 2.0 and
later are fine, but I can't speak for other systems.

Of course, if you're crazy enough to disable the MDC check
("--no-mdc-warning") then all bets are off, but really, you'll get what
you deserve.

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

Hope this puts your mind at ease.  :)



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

Re: Efail or OpenPGP is safer than S/MIME

[Werner Koch]

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 same day we received an advisory titled

  Efail: Full Plaintext Recovery in PGP via Chosen-Ciphertext Attack

with the notice 

  We ask you kindly to keep this advisory and the information therein
  confidential until we find a nearby date for coordinated public
  disclosure!

A few hours later my reply went out:

--8<---cut here---start->8---
Thanks for sharing the paper with us.  I may have missed something but I
can't see that you considered the use of MDC as specified in RFC-4880,
5.13 (Sym. Encrypted Integrity Protected Data Packet (Tag 18)).  Here is
the timeline of the introduction of the MDC.

  AES conference March 2000

* Meeting between PRZ, Jon Callas, and me to discuss how to make our
  encryption mode more robust without requiring signed content.

  GnuPG  1.0.3 (2000-09-18)

* Twofish and MDC enhanced encryption is now used.  PGP 7 supports
  this.  Older versions of GnuPG don't support it, so they should be
  upgraded to at least 1.0.2

  GnuPG 1.0.7 (2002-04-29)

* The MDC feature flag is supported and can be set by using
  the "updpref" edit command.

  GnuPG 1.1.92 (2002-09-11)

* The use of MDCs have increased.  A MDC will be used if the
  recipients directly request it, if the recipients have AES,
  AES192, AES256, or TWOFISH in their cipher preferences, or if
  the chosen cipher has a blocksize not equal to 64 bits
  (currently this is also AES, AES192, AES256, and TWOFISH).

* GnuPG will no longer automatically disable compression when
  processing an already-compressed file unless a MDC is being
  used.  This is to give the message a certain amount of
  resistance to the chosen-ciphertext attack while communicating
  with other programs (most commonly PGP earlier than version 7.x)
  that do not support MDCs.

  GnuPG 2.1.9 (2015-10-09)

* gpg: Fail with an error instead of a warning if a modern cipher
  algorithm is used without a MDC.

Your attack should not work if the MDC is in use.  And it is always in
use for AES.  In any case active content in mails should be discouraged
in all mails (see my mail headers ;-).

We are slowly working in the WG on RFC4880bis to introduce a new
encryption mode.  Unfortunately there are heavy opinions on the use of
OCB mode and thus we may need to come up with the choice of two new
modes.  Based on the experience with MDC I expect that the deployment of
a new mode will take at least 3 years.  Until then I hope that the MDC
hack will serve us fine.
--8<---cut here---end--->8---

In response to that they said that they did a simple rollback to the
non-MDC encryption.  This is a pretty old thing which we are aware of
and the reasons why a warning has always been printed in that case.

In a further response the same day they noted that gpg indeed returns an
error code but that Enigmail still displays the message.  My reply on
that went out on 2017-11-26:

--8<---cut here---start->8---
Enigmail does something wrong the.  Here is the respective code in GnuPG:

  else if (!result
   && !opt.ignore_mdc_error
   && !pkt->pkt.encrypted->mdc_method
   && openpgp_cipher_get_algo_blklen (c->dek->algo) != 8
   && c->dek->algo != CIPHER_ALGO_TWOFISH)
{
  /* The message has been decrypted but has no MDC despite that a
 modern cipher (blocklength != 64 bit, except for Twofish) is
 used and the option to ignore MDC errors is not used: To
 avoid attacks changing an MDC message to a non-MDC message,
 we fail here.  */
  log_error (_("WARNING: message was not integrity protected\n"));
  if (opt.verbose > 1)
log_info ("decryption forced to fail\n");
  write_status (STATUS_DECRYPTION_FAILED);

which was introduced with

  commit 625e292108cc0fd9077769587a8c22abe7805e33
  AuthorDate: Tue Oct 6 09:40:57 2015 +0200

gpg: Fail decryption for AES etc message w/o MDC.

* g10/mainproc.c (proc_encrypted): Fail for modern messages w/o MDC.
--

This change turns the missing MDC warning into an error if the message
has been encrypted using a cipher with a non-64 bit block length cipher
and it is not Twofish.

We can assume that such messages are created by code which should have
been able to create MDC packets.  AES was introduced with 1.0.3 on
2000-09-18 shortly after MDC (1.0.2 on 2000-07-12).  We need to
exclude Twofish because that might have been used before MDC.


GPGME based applications should get it correct because GPGME detects the

Re: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

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*, so you'll notice when
it happens.

> There are two ways to mitigate this attack
> 
>  - Don't use HTML mails.  Or if you really need to read them use a
>proper MIME parser and disallow any access to external links.

Unfortunately HTML mail is commonplace, so never reading an HTML mail
again may be too much to ask.

>  - Use authenticated encryption.

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. I
see that MDC is the default for all modern ciphers, but does that imply
that MDC *checking* is the default? If so, then all we would need to do
is disable non-modern ciphers.

Looks like S/MIME is pretty much buggered though...

-- 
Andrew Gallagher



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

Re: Efail or OpenPGP is safer than S/MIME

[Robert J. Hansen]

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 detection codes (MDCs).  GnuPG properly implements MDCs and
gives clear and unambiguous warnings if a message lacks an MDC.  The
paper authors acknowledge that if an email client handles these warnings
sensibly, their attack fails.

In other words, their attack is completely dependent on email clients
handling our warnings in a broken way.  Great: that they've found bugs
in major email clients is a good thing, but where's the flaw in the
OpenPGP protocol or GnuPG's implementation of it?  And does this really
deserve the hype-tastic title "Breaking S/MIME and OpenPGP Email
Encryption" when it really doesn't do that?

In grad school my adviser told me to follow Napoleon's Rule in paper
titles.  "If you tell the world you're going to conquer Russia, you'd
better conquer Russia."  This paper doesn't deliver on what its title
promises.



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

Don't Panic.

[Robert J. Hansen]

[taps the mike]

Hi.  I maintain the official GnuPG FAQ.  So let me start off by
answering a question that is certainly about to be asked a lot: "Should
we be worried about OpenPGP, GnuPG, or Enigmail?  The EFF's advising us
to uninstall it!"

https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now

Werner saw a preprint of this paper some time ago.  I saw it recently.
Patrick Brunschwig of Enigmail saw it.  None of us are worried.  Out of
respect for the paper authors I will skip further comment until such
time as the paper is published.

It would've been nice if EFF had reached out to us for comment, rather
than apparently only talking to the paper authors.  We hope they'll
reach out next time.


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

Attention PGP Users: New Vulnerabilities Require You to Take Action Now

[Mirimir]

| A group of European security researchers have released a warning
| about a set of vulnerabilities affecting users of PGP and S/MIME.
| EFF has been in communication with the research team, and can
| confirm that these vulnerabilities pose an immediate risk to
| those using these tools for email communication, including the
| potential exposure of the contents of past messages.
|
| The full details will be published in a paper on Tuesday at 07:00
| AM UTC (3:00 AM Eastern, midnight Pacific). In order to reduce the
| short-term risk, we and the researchers have agreed to warn the
| wider PGP user community in advance of its full publication.
|
| Our advice, which mirrors that of the researchers, is to
| immediately disable and/or uninstall tools that automatically
| decrypt PGP-encrypted email. Until the flaws described in the
| paper are more widely understood and fixed, users should arrange
| for the use of alternative end-to-end secure channels, such as
| Signal, and temporarily stop sending and especially reading
| PGP-encrypted email.

https://www.eff.org/deeplinks/2018/05/attention-pgp-users-new-vulnerabilities-require-you-take-action-now

| We'll publish critical vulnerabilities in PGP/GPG and S/MIME
| email encryption on 2018-05-15 07:00 UTC. They might reveal the
| plaintext of encrypted emails, including encrypted emails sent
| in the past.

https://twitter.com/seecurity/status/995906576170053633


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

Efail or OpenPGP is safer than S/MIME

[Werner Koch]

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

Given that the EFF suggests to deinstall GpgOL, we know tha it is not
vulnerable; see see https://dev.gnupg.org/T3714.).

Here is a response I wrote on the weekend to a reporter who inquired on
this problem.

=
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 seem to
do again; see all these newsletters).  Due to broken MIME parsers a
bunch of MUAs seem to concatenate decrypted HTML mime parts which makes
it easy to plant such HTML snippets.

There are two ways to mitigate this attack

 - Don't use HTML mails.  Or if you really need to read them use a
   proper MIME parser and disallow any access to external links.

 - Use authenticated encryption.

The latter is actually easy for OpenPGP because we started to use
authenticated encryption (AE) since 2000 or 2001.  Our AE is called MDC
(Modification detection code) and was back then introduced for a very
similar attack.  Unfortunately some OpenPGP implementations were late to
introduce MDC and thus GPG could not fail hard on receiving a mail
without an MDC.  However, an error is returned during decrypting and no
MDC is used:

  gpg: encrypted with 256-bit ECDH key, ID 7F3B7ED4319BCCA8, created 2017-01-01
"Werner Koch "
  [GNUPG:] BEGIN_DECRYPTION
  [GNUPG:] DECRYPTION_INFO 0 7
  [GNUPG:] PLAINTEXT 62 1526109594 
  [GNUPG:] PLAINTEXT_LENGTH 69
  There is more to life than increasing its speed.
  -- Mahatma Gandhi
  gpg: WARNING: message was not integrity protected
  [GNUPG:] DECRYPTION_FAILED
  [GNUPG:] END_DECRYPTION

When giving a filename on the command line an output file is even not
created.  This can't be done in pipe mode because gpg allows to process
huge amounts of data.  MUAs are advised to consider the DECRYPTION_FAILED
status code and not to show the data or at least use a proper way to
display the possible corrupted mail without creating an oracle and to
inform the user that the mail is fishy.

For S/MIME authenticated encryption is not used or implemented in
practice and thus there is no short term way to fix this in S/MIME
except for not using HTML mails.

The upshot of this is that OpenPGP messages are way better protected
against such kind of attacks than S/MIME messages.  Unless, well, the
MUAs are correctly implemented and check error codes!


Shalom-Salam,

   Werner


p.s.
Some cryptographers turn up their nose at the OpenPGP MDC which is an
ad-hoc AE mode from a time before AE received much research.  However,
it does it job and protects reliable against this and other attacks.
The next OpenPGP revision will bring a real AE mode (EAX or OCB
depending on key preferences) which has other benefits (early detection
of corrupted messages, speed) but it will takes years before it will be
widely deployed and can can actually be used to create messages.


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: smartcards and GPGME

[Werner Koch]

On Mon, 14 May 2018 00:26, tookm...@gmail.com said:

> the smartcard from an application. While this can be done from gpg, it
> doesn't look like I can do so from GPGME or any other wrappers that
> exist. Have I missed something or is this simply not possible yet?

GPGME allows to do that.  For example GPA has a card manager which can
manage different types of cards and for some cards it is able to create
keys.  IIRC, moving keys to the card is not yet implemented but GPGME
allows you to do implement that as well.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


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

Re: smartcards and GPGME

[Andre Heinecke]

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 application. While this can be done from gpg, it
> doesn't look like I can do so from GPGME or any other wrappers that
> exist. Have I missed something or is this simply not possible yet?
> 
> While I could wrap this functionality of gpg, I'd really prefer not to
> and I'd rather not drop the user to a gpg prompt if I don't have to.

This is both pretty complicated thorugh GPGME, as there is indeed not a direct 
interface. Kleopatra and GPA use the "AssuanEngine" of GPGME to connect to the 
gpg-agent's assuan interface and issue / parse commands directly through that 
connection.

You might want to take a look at GPA's implementation:

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpa.git;a=blob;f=src/cm-openpgp.c

Alternatively instead of wrapping gpg (and using the complicated edit 
interface) you could also wrap "gpg-connect-agent" and issue commands to 
scdaemon through that.

Best Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

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