From: Steffen Klassert <steffen.klassert@secunet.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>,
Paul Wouters <pwouters@redhat.com>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: CCM/GCM implementation defect
Date: Thu, 23 Apr 2015 13:45:34 +0200 [thread overview]
Message-ID: <20150423114533.GI8928@secunet.com> (raw)
In-Reply-To: <20150423032619.GA17648@gondor.apana.org.au>
On Thu, Apr 23, 2015 at 11:26:20AM +0800, Herbert Xu wrote:
> Hi:
>
> It looks like our IPsec implementations of CCM and GCM are buggy
> in that they don't include the IV in the authentication calculation.
Seems like crypto_rfc4106_crypt() passes the associated data it
got from ESP directly to gcm, without chaining with the IV.
>
> This definitely breaks interoperability with anyone who implements
> them correctly. The fact that there have been no reports on this
> probably means that nobody has run into this in the field yet.
>
> On the security side, this is probably not a big deal for CCM
> because it always verifies the authentication tag after decryption.
> But for GCM this may be a DoS issue as an attacker could modify
> the IV without triggering the authentication check and thus cause
> an unnecessary decryption. For both CCM and GCM this will result
> in random data injected as a packet into the network stack which
> hopefully will be dropped.
>
> In order to fix this without breaking backwards compatibility,
> my plan is to introduce new templates such as rfc4106v2 which
> implement the RFC correctly. The existing templates will be
> retained so that current users aren't broken by the fix.
Adding a second template for the correct implementation is
probaply the only thing that we can do if we don't want to
break backwards compatibility. But maybe we can add a warning
to the old implementation, such that users notice that they
use a broken version.
next prev parent reply other threads:[~2015-04-23 11:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-23 3:26 CCM/GCM implementation defect Herbert Xu
2015-04-23 3:36 ` David Miller
2015-04-23 9:03 ` Horia Geantă
2015-04-23 9:05 ` Herbert Xu
2015-04-23 9:58 ` Martin Willi
2015-04-23 10:01 ` Herbert Xu
2015-04-23 11:45 ` Steffen Klassert [this message]
2015-04-23 13:24 ` Martin Willi
2015-04-23 23:12 ` Herbert Xu
2015-04-24 5:30 ` Herbert Xu
2015-04-24 5:35 ` Herbert Xu
2015-04-23 15:21 ` Paul Wouters
2015-04-23 23:17 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150423114533.GI8928@secunet.com \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pwouters@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.