summaryrefslogtreecommitdiffstats
path: root/crypto/md5.c
AgeCommit message (Collapse)AuthorFilesLines
2015-12-22crypto: hash - add zero length message hash for shax and md5LABBE Corentin1-0/+6
Some crypto drivers cannot process empty data message and return a precalculated hash for md5/sha1/sha224/sha256. This patch add thoses precalculated hash in include/crypto. Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-05-18crypto: md5 - use md5 IV MD5_HX instead of their raw valueLABBE Corentin1-4/+4
Since MD5 IV are now available in crypto/md5.h, use them. Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-11-24crypto: prefix module autoloading with "crypto-"Kees Cook1-0/+1
This prefixes all crypto module loading with "crypto-" so we never run the risk of exposing module auto-loading to userspace via a crypto API, as demonstrated by Mathias Krause: https://lkml.org/lkml/2013/3/4/70 Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-08-06crypto: Move md5_transform to lib/md5.cDavid S. Miller1-91/+1
We are going to use this for TCP/IP sequence number and fragment ID generation. Signed-off-by: David S. Miller <davem@davemloft.net>
2010-03-02crypto: md5 - Set statesizeHerbert Xu1-0/+1
As md5 now has export/import functions, it must set the attribute statesize. Otherwise anything that relies on import/export may fail as they will see a zero statesize. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-01-17crypto: md5 - Add export supportMax Vozeler1-16/+24
This patch adds export/import support to md5. The exported type is defined by struct md5_state. This is modeled after the equivalent change to sha1_generic. Signed-off-by: Max Vozeler <max@hinterhof.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25crypto: md5 - Switch to shashAdrian-Ken Rueegsegger1-22/+28
This patch changes md5 to the new shash interface. Signed-off-by: Adrian-Ken Rueegsegger <ken@codelabs.ch> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-04-21[CRYPTO] all: Clean up init()/fini()Kamalesh Babulal1-4/+4
On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote: > Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: > > > This patch cleanups the crypto code, replaces the init() and fini() > > with the <algorithm name>_init/_fini > > This part ist OK. > > > or init/fini_<algorithm name> (if the > > <algorithm name>_init/_fini exist) > > Having init_foo and foo_init won't be a good thing, will it? I'd start > confusing them. > > What about foo_modinit instead? Thanks for the suggestion, the init() is replaced with <algorithm name>_mod_init () and fini () is replaced with <algorithm name>_mod_fini. Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-06-26[CRYPTO] all: Pass tfm instead of ctx to algorithmsHerbert Xu1-6/+6
Up until now algorithms have been happy to get a context pointer since they know everything that's in the tfm already (e.g., alignment, block size). However, once we have parameterised algorithms, such information will be specific to each tfm. So the algorithm API needs to be changed to pass the tfm structure instead of the context pointer. This patch is basically a text substitution. The only tricky bit is the assembly routines that need to get the context pointer offset through asm-offsets.h. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2006-01-09[CRYPTO] Use standard byte order macros wherever possibleHerbert Xu1-0/+1
A lot of crypto code needs to read/write a 32-bit/64-bit words in a specific gender. Many of them open code them by reading/writing one byte at a time. This patch converts all the applicable usages over to use the standard byte order macros. This is based on a previous patch by Denis Vlasenko. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+244
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!