From: Jussi Kivilinna <jussi.kivilinna@iki.fi>
To: Chaoxing Lin <Chaoxing.Lin@ultra-3eti.com>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Subject: Re: potential bug in GMAC implementation. not work in ESN mode
Date: Tue, 26 Mar 2013 22:16:21 +0200 [thread overview]
Message-ID: <51520215.4020300@iki.fi> (raw)
In-Reply-To: <BD54DDEB2546894FAB0731EA7B0EDF8D07C58F28@RockMX01.rock.corp>
[-- Attachment #1.1: Type: text/plain, Size: 2203 bytes --]
On 25.03.2013 18:12, Chaoxing Lin wrote:
> 2nd ping....
>
> Nobody is maintaining crypto/gcm.c?
>
>
>
> -----Original Message-----
> From: Chaoxing Lin
> Sent: Friday, March 08, 2013 11:38 AM
> To: 'linux-crypto@vger.kernel.org'
> Subject: potential bug in GMAC implementation. not work in ESN mode
>
> I was testing ipsec with GMAC and found that the rfc4543 GMAC implementation in kernel software crypto work in "esp=aes256gmac-noesn!" mode.
> It does not work in in "esp=aes256gmac-esn!" mode. The tunnel was established but no data traffic is possible.
>
> Looking at source code, I found this piece of code is suspicious.
> Line 1146~1147 tries to put req->assoc to assoc[1]. But I think this way only works when req->assoc has only one segment. In ESN mode, req->assoc contains 3 segments (SPI, SN-hi, SN-low). Line 1146~1147 will only attach SPI segment(with total length) in assoc.
>
> Please let me know whether I understand it right.
Your analysis seems correct. Does attached the patch fix the problem? (I've only compile tested it.)
-Jussi
> Thanks,
>
> Chaoxing
>
>
> Source from kernel 3.8.2
> path: root/crypto/gcm.c
>
> 1136: /* construct the aad */
> 1137: dstp = sg_page(dst);
> vdst = PageHighMem(dstp) ? NULL : page_address(dstp) + dst->offset;
>
> sg_init_table(payload, 2);
> sg_set_buf(payload, req->iv, 8);
> scatterwalk_crypto_chain(payload, dst, vdst == req->iv + 8, 2);
> assoclen += 8 + req->cryptlen - (enc ? 0 : authsize);
>
> sg_init_table(assoc, 2);
> 1146: sg_set_page(assoc, sg_page(req->assoc), req->assoc->length,
> 1147: req->assoc->offset);
> scatterwalk_crypto_chain(assoc, payload, 0, 2);
>
> aead_request_set_tfm(subreq, ctx->child);
> aead_request_set_callback(subreq, req->base.flags, req->base.complete,
> req->base.data);
> aead_request_set_crypt(subreq, cipher, cipher, enc ? 0 : authsize, iv);
> 1154: aead_request_set_assoc(subreq, assoc, assoclen);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 10-gcm-fix-assumption-that-assoc-has-one-segment.patch --]
[-- Type: text/x-patch; name="10-gcm-fix-assumption-that-assoc-has-one-segment.patch", Size: 1901 bytes --]
crypto: gcm - fix assumption that assoc has one segment
From: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
---
crypto/gcm.c | 17 ++++++++++++++---
crypto/tcrypt.c | 4 ++++
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/crypto/gcm.c b/crypto/gcm.c
index 137ad1e..13ccbda 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -44,6 +44,7 @@ struct crypto_rfc4543_ctx {
struct crypto_rfc4543_req_ctx {
u8 auth_tag[16];
+ u8 assocbuf[32];
struct scatterlist cipher[1];
struct scatterlist payload[2];
struct scatterlist assoc[2];
@@ -1133,9 +1134,19 @@ static struct aead_request *crypto_rfc4543_crypt(struct aead_request *req,
scatterwalk_crypto_chain(payload, dst, vdst == req->iv + 8, 2);
assoclen += 8 + req->cryptlen - (enc ? 0 : authsize);
- sg_init_table(assoc, 2);
- sg_set_page(assoc, sg_page(req->assoc), req->assoc->length,
- req->assoc->offset);
+ if (req->assoc->length == req->assoclen) {
+ sg_init_table(assoc, 2);
+ sg_set_page(assoc, sg_page(req->assoc), req->assoc->length,
+ req->assoc->offset);
+ } else {
+ BUG_ON(req->assoclen > sizeof(rctx->assocbuf));
+
+ scatterwalk_map_and_copy(rctx->assocbuf, req->assoc, 0,
+ req->assoclen, 0);
+
+ sg_init_table(assoc, 2);
+ sg_set_buf(assoc, rctx->assocbuf, req->assoclen);
+ }
scatterwalk_crypto_chain(assoc, payload, 0, 2);
aead_request_set_tfm(subreq, ctx->child);
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 87ef7d6..6b911ef 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1225,6 +1225,10 @@ static int do_test(int m)
ret += tcrypt_test("rfc4106(gcm(aes))");
break;
+ case 152:
+ ret += tcrypt_test("rfc4543(gcm(aes))");
+ break;
+
case 200:
test_cipher_speed("ecb(aes)", ENCRYPT, sec, NULL, 0,
speed_template_16_24_32);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 730 bytes --]
next prev parent reply other threads:[~2013-03-26 20:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 16:12 potential bug in GMAC implementation. not work in ESN mode Chaoxing Lin
2013-03-26 20:16 ` Jussi Kivilinna [this message]
2013-03-27 13:43 ` Chaoxing Lin
-- strict thread matches above, loose matches on Subject: below --
2013-03-14 19:57 Chaoxing Lin
2013-03-08 16:38 Chaoxing Lin
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=51520215.4020300@iki.fi \
--to=jussi.kivilinna@iki.fi \
--cc=Chaoxing.Lin@ultra-3eti.com \
--cc=linux-crypto@vger.kernel.org \
/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.