No 'MDC' Feature in Generated keys, but is required by RFC-6637

[koto]

From the...@gmail.com on July 11, 2014 04:55:19

Is this report about the crypto library or the extension?

library

What is the security bug?

Public keys generated by the library don't have a "Features" signature subpacket showing support for MDC. As a result, encrypting with GPG v2.1 won't encrypt to packet #18s, but will instead encrypt to packet #9s.

It's worth noting that RFC-6637 requires MDCs with ECDH in Section 8.

How would someone exploit it?

Chosen ciphertext attack on 3DES (see previous bug report).

Original issue: http://code.google.com/p/end-to-end/issues/detail?id=110

[koto]

From evn@google.com on July 17, 2014 17:05:24

Thanks Max

Cc: adhintz@google.com koto@google.com

[koto]

From evn@google.com on July 17, 2014 17:12:33

Labels: Component-Logic

[koto]

From evn@google.com on July 18, 2014 14:05:37

Max, shouldn't GPG be encrypting with MDC?

I agree we should generate the signature subpacket (and we'll do), but I think GnuPG must do this on their side too? Did you also file a bug with them.

Status: Accepted

[koto]

From the...@gmail.com on July 18, 2014 14:15:32

I don't think it's a bug with GPG.

If you want to encrypt a message for me with GPG, but my public key says that I don't support MDC, then GPG won't encrypt with MDC. You can override this behavior with the --force-mdc flag to GPG, but most users won't do that; they'll just implicitly get non-MDC-protected ciphertexts.

Here are the preferences on a key that GPG would itself generate (as displayed by gpg --edit-key)

gpg> showpref unknown. test@test.cc Cipher: AES256, AES, 3DES Digest: SHA512, SHA256, SHA1 Compression: ZIP, Uncompressed Features: MDC, Keyserver no-modify

Here are the prefs on the key generated by Google End-to-End:

gpg> showpref unknown. themax@gmail.com Cipher: 3DES Digest: SHA1 Compression: ZIP, Uncompressed

Note the lack of "Features: MDC" on the Google End-To-End key.

[koto]

From evn@google.com on July 21, 2014 17:15:31

Yup, you are right. I thought the standard required implementations to imply MDC for new algorithms, but it's defined as a MAY =( http://tools.ietf.org/html/rfc4880#section-5.2.3.24 We'll add that. Could you add it while you are at it koto?

Also, this will be considered as part of the VRP.

[koto]

From koto@google.com on July 23, 2014 04:22:47

Status: Started
Owner: koto@google.com

[koto]

From koto@google.com on July 23, 2014 10:18:31

Status: FixedInStaging

[koto]

From evn@google.com on July 23, 2014 11:25:28

This issue should be fixed in head.

If it's still a problem, please open a new bug.

Status: Fixed
Labels: Restrict-AddIssueComment-CoreTeam

[koto]

From evn@google.com on August 05, 2014 12:56:20

sorry, I forgot to make it public (we'll have news about the reward today)

Labels: -Restrict-View-CoreTeam

[koto]

From evn@google.com on August 05, 2014 14:49:50

Hi themax.

We decided to make this report the first to receive a reward for end-to-end as part of Google's Vulnerability Reward Program.

The reward amount is not high ($100 USD), and if you decide to donate it, we'll double it, but we just wanted to say thank you for your help. We also want to publicly acknowledge your help in our Security Research page, if you are interested.

I'll send you an email from security@google.com we can use to track the reward.