| 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 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 26 Sep 2010 18:46:54 -0700 (PDT) From: David Miller <davem@...emloft.net> To: herbert@...dor.apana.org.au Cc: kaber@...sh.net, eric.dumazet@...il.com, netdev@...r.kernel.org Subject: Re: ESP trailer_len calculation From: Herbert Xu <herbert@...dor.apana.org.au> Date: Sat, 25 Sep 2010 14:23:17 +0800 > 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. Thanks for explaining this Herbert, but I have to admit it's a bit disappointing :-) So what we have is that headerlen is actually a function f() which depends upon the payload length and the size of any IP options, rather than a fixed value that can be computed based upon the cipher blocksize, encap mode, and device MTU. I guess if we really cared about this we could make headerlen a method rather than a value, but I doubt it's that much of an issue. -- 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