lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 25 Sep 2010 14:23:17 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	David Miller <davem@...emloft.net>
Cc:	kaber@...sh.net, eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: ESP trailer_len calculation

On Fri, Sep 24, 2010 at 02:40:44PM -0700, David Miller wrote:
> 
> Eric Dumazet and I recently were looking into a strange artifact in
> ESP ->trailer_len calculations.
> 
> Eric was seeing values like "17" which looked strange.
> 
> He foudn that it's because of this line in esp4.c:esp_init_state()
> 
> 	x->props.trailer_len = align + 1 + crypto_aead_authsize(esp->aead);
> 
> which comes from commit:
> 
> commit c5c2523893747f88a83376abad310c8ad13f7197
> Author: Patrick McHardy <kaber@...sh.net>
> Date:   Mon Apr 9 11:47:18 2007 -0700
> 
>     [XFRM]: Optimize MTU calculation
> 
> which is based upon discussion threads:
> 
> http://marc.info/?l=linux-netdev&m=115468159401118&w=2
> 
> and
> 
> http://marc.info/?l=linux-netdev&m=117561805827241&w=2
> 
> Even more strange, in the orignal version of this patch the
> calcaluation is actually:
> 
> 	x->props.trailer_len = align - 1 + esp->auth.icv_trunc_len;
> 
> (ie. 'align - 1' instead of 'align + 1')
> 
> It seems that this "- 1 " or "+ 1" term can be completely eliminated,
> unless there are some funny semantics wrt. the padding area of ESP.
> 
> Patrick and Herbert, what do you guys think?

The number 17 does look very strange, however, after going through
the logic it does seem correct.

To calculate the minimum safe trailer length we need to consider
the worst-case scenario, and that is a packet where the payload
just happens to be one byte less than the cipher block size.

ESP always adds two bytes, then pads to at least the cipher
block size, follwed by the authentication value.  So in the
worst case we need to add

	2 + (blocksize - 1) + authlen	=
	blocksize + 1 + authlen

which is exactly what Patrick's patch does.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists