From: Martin Willi <martin@strongswan.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 3/5] xfrm: Traffic Flow Confidentiality for IPv4 ESP
Date: Mon, 06 Dec 2010 16:10:25 +0100 [thread overview]
Message-ID: <1291648225.1954.179.camel@martin> (raw)
In-Reply-To: <20101203083908.GA2940@gondor.apana.org.au>
Hi Herbert,
> I know why you want to do this, what I'm asking is do you have any
> research behind this with regards to security
>
> Has this scheme been discussed on a public forum somewhere?
No, sorry, I haven't found much valuable discussion about TFC padding.
Nothing at all how to overcome the ESPv2 padding limit.
> using an insecure RNG to generate a value that is then used as the
> basis for concealment
Using get_random_bytes() adds another ~10% processing overhead due to
the underlying sha_transform. But this is probably negligible, we add
much more with the additional padding to encrypt/MAC.
I'll re-spin the patchset with get_random_bytes(). Even if the ESPv2
padding fallback makes TFC in this case less efficient, it shouldn't
harm. Or do you see this differently?
Regards
Martin
next prev parent reply other threads:[~2010-12-06 15:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-30 15:49 [PATCH 0/5] xfrm: ESP Traffic Flow Confidentiality padding Martin Willi
2010-11-30 15:49 ` [PATCH 1/5] xfrm: Add Traffic Flow Confidentiality padding XFRM attribute Martin Willi
2010-11-30 15:49 ` [PATCH 2/5] xfrm: Remove unused ESP padlen field Martin Willi
2010-11-30 15:49 ` [PATCH 3/5] xfrm: Traffic Flow Confidentiality for IPv4 ESP Martin Willi
2010-12-03 7:34 ` Herbert Xu
2010-12-03 8:32 ` Martin Willi
2010-12-03 8:39 ` Herbert Xu
2010-12-06 15:10 ` Martin Willi [this message]
2010-12-06 15:22 ` Herbert Xu
2010-11-30 15:49 ` [PATCH 4/5] xfrm: Traffic Flow Confidentiality for IPv6 ESP Martin Willi
2010-11-30 15:49 ` [PATCH 5/5] xfrm: Add TFC padding option to automatically pad to PMTU Martin Willi
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=1291648225.1954.179.camel@martin \
--to=martin@strongswan.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=netdev@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox