summaryrefslogtreecommitdiff
path: root/include/net/ah.h
AgeCommit message (Collapse)AuthorFilesLines
2014-09-18ipsec: Remove obsolete MAX_AH_AUTH_LENHerbert Xu1-3/+0
While tracking down the MAX_AH_AUTH_LEN crash in an old kernel I thought that this limit was rather arbitrary and we should just get rid of it. In fact it seems that we've already done all the work needed to remove it apart from actually removing it. This limit was there in order to limit stack usage. Since we've already switched over to allocating scratch space using kmalloc, there is no longer any need to limit the authentication length. This patch kills all references to it, including the BUG_ONs that led me here. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2011-01-14ipsec: update MAX_AH_AUTH_LEN to support sha512Nicolas Dichtel1-1/+1
icv_truncbits is set to 256 for sha512, so update MAX_AH_AUTH_LEN to 64. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-01-12ah: update maximum truncated ICV lengthNicolas Dichtel1-1/+1
For SHA256, RFC4868 requires to truncate ICV length to 128 bits, hence MAX_AH_AUTH_LEN should be updated to 16. Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-11-04net: cleanup include/netEric Dumazet1-2/+1
This cleanup patch puts struct/union/enum opening braces, in first line to ease grep games. struct something { becomes : struct something { Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-10-19ah: Remove obsolete codeSteffen Klassert1-26/+3
ah4 and ah6 are converted to ahash now, so we can remove the code for the obsolete hash algorithm. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-10-19ah: Add struct crypto_ahash to ah_dataSteffen Klassert1-0/+1
To support for ahash algorithms, we add a pointer to a crypto_ahash to ah_data. Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-10-11[IPSEC]: Get rid of ipv6_{auth,esp,comp}_hdrHerbert Xu1-0/+7
This patch removes the duplicate ipv6_{auth,esp,comp}_hdr structures since they're identical to the IPv4 versions. Duplicating them would only create problems for ourselves later when we need to add things like extended sequence numbers. I've also added transport header type conversion headers for these types which are now used by the transforms. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2007-10-11[IPSEC] ah: Remove keys from ah_data structureHerbert Xu1-2/+0
The keys are only used during initialisation so we don't need to carry them in esp_data. Since we don't have to allocate them again, there is no need to place a limit on the authentication key length anymore. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[IPSEC]: Use HMAC template and hash interfaceHerbert Xu1-11/+18
This patch converts IPsec to use the new HMAC template. The names of existing simple digest algorithms may still be used to refer to their HMAC composites. The same structure can be used by other MACs such as AES-XCBC-MAC. This patch also switches from the digest interface to hash. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2006-09-21[IPSEC]: Move linux/crypto.h inclusion out of net/xfrm.hHerbert Xu1-0/+1
The header file linux/crypto.h is only needed by a few files so including it in net/xfrm.h (which is included by half of the networking stack) is a waste. This patch moves it out of net/xfrm.h and into the specific header files that actually need it. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-04-17Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+35
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!