aboutsummaryrefslogtreecommitdiffstats
path: root/src/hash/md4
Commit message (Collapse)AuthorAgeFilesLines
* Doxygenlloyd2010-11-021-1/+9
|
* Remove BufferedComputation::OUTPUT_LENGTHlloyd2010-10-291-2/+4
|
* Remove most uses of HASH_BLOCK_SIZElloyd2010-10-131-1/+1
|
* Use output_length() instead of OUTPUT_LENGTH pseudo-propertylloyd2010-10-131-1/+1
|
* Use size_t for BufferedComputation::add_datalloyd2010-10-122-5/+5
|
* Completely remove the second parameter to SecureVector which specifieslloyd2010-09-141-3/+4
| | | | | | | | | | | | | | | | | | | | the initial/default length of the array, update all users to instead pass the value to the constructor. This is a old vestigal thing from a class (SecureBuffer) that used this compile-time constant in order to store the values in an array. However this was changed way back in 2002 to use the same allocator hooks as the rest of the containers, so the only advantage to using the length field was that the initial length was set and didn't have to be set in the constructor which was midly convenient. However this directly conflicts with the desire to be able to (eventually) use std::vector with a custom allocator, since of course vector doesn't support this. Fortunately almost all of the uses are in classes which have only a single constructor, so there is little to no duplication by instead initializing the size in the constructor.
* Anywhere where we use MemoryRegion::begin to get access to the raw pointerlloyd2010-09-131-1/+1
| | | | | representation (rather than in an interator context), instead use &buf[0], which works for both MemoryRegion and std::vector
* Big, invasive but mostly automated change, with a further attempt atlloyd2010-09-071-1/+1
| | | | | | | | | | | | | | harmonising MemoryRegion with std::vector: The MemoryRegion::clear() function would zeroise the buffer, but keep the memory allocated and the size unchanged. This is very different from STL's clear(), which is basically the equivalent to what is called destroy() in MemoryRegion. So to be able to replace MemoryRegion with a std::vector, we have to rename destroy() to clear() and we have to expose the current functionality of clear() in some other way, since vector doesn't support this operation. Do so by adding a global function named zeroise() which takes a MemoryRegion which is zeroed. Remove clear() to ensure all callers are updated.
* More Doxygenlloyd2010-06-151-1/+0
|
* More Doxygen updates/fixeslloyd2010-06-151-1/+1
|
* Remove SecureBuffer, which is the fixed-size variant of SecureVector.lloyd2010-03-231-2/+2
| | | | | | | | | | | | | | Add a second template param to SecureVector which specifies the initial length. Change all callers to be SecureVector instead of SecureBuffer. This can go away in C++0x, once compilers implement N2712 ("Non-static data member initializers"), and we can just write code as SecureVector<byte> P{18}; instead
* MD4's M buffer was set to be 48 words instead of 16. This had beenlloyd2010-02-031-1/+1
| | | | | | | | | | | | | | extant for a long long time and was never caught because until recently the code did not depend on M.size(). However with the recent loadstore changes that use memcpy to load the entire array in one shot, an extra 128 bytes of memory would be read (but not used) in each iteration. This probably did not cause any problems except for Valgrind warnings, though in some situations it would be possible for the M buffer and MDx_HashFunctions buffer to be close enough that memcpy would be called with overlapping regions, which could cause arbitrarily weird failures since memcpy is allowed to assume they do not overlap.
* Un-internal loadstor.h (and its header deps, rotate.h andlloyd2009-12-211-2/+2
| | | | | | | | | | | | | | bswap.h); too many external apps rely on loadstor.h existing. Define 64-bit generic bswap in terms of 32-bit bswap, since it's not much slower if 32-bit is also generic, and much faster if it's not. This may be quite helpful on 32-bit x86 in particular. Change formulation of generic 32-bit bswap. It may be faster or slower depending on the CPU, especially the latency and throuput of rotate instructions, but should be faster on an ideally superscalar processor with rotate instructions (ie, what I expect future CPUs to look more like).
* Make many more headers internal-only.lloyd2009-12-161-2/+2
| | | | | | | | | | | | | Fixes for the amalgamation generator for internal headers. Remove BOTAN_DLL exporting macros from all internal-only headers; the classes/functions there don't need to be exported, and avoiding the PIC/GOT indirection can be a big win. Add missing BOTAN_DLLs where necessary, mostly gfpmath and cvc For GCC, use -fvisibility=hidden and set BOTAN_DLL to the visibility __attribute__ to export those classes/functions.
* Conver the rest of the hash functions to use the array-based load instructions.lloyd2009-11-031-25/+30
| | | | | | | I'm not totally happy with this - in particular in all cases the size is a compile time constant - it would be nice to make use of this via tempalate metaprogramming. Also for matching endian loads, a straight memcpy would do the work, which would probably be even faster.
* Add a new looping load_be / load_le for loading large arrays at once, andlloyd2009-10-291-0/+1
| | | | | | | | change some of the hash functions to use it as low hanging fruit. Probably could use further optimization (just unrolls x4 currently), but merely having it as syntax is good as it allows optimizing many functions at once (eg using SSE2 to do 4-way byteswaps).
* Remove the 'realname' attribute on all modules and cc/cpu/os info files.lloyd2009-10-291-2/+0
| | | | | Pretty much useless and unused, except for listing the module names in build.h and the short versions totally suffice for that.
* Remove all exception specifications. The way these are designed in C++ islloyd2009-10-222-2/+2
| | | | | | just too fragile and not that useful. Something like Java's checked exceptions might be nice, but simply killing the process entirely if an unexpected exception is thrown is not exactly useful for something trying to be robust.
* Remove add blocks from hash function info.txt fileslloyd2009-09-291-7/+0
|
* Many source files included bit_ops.h when what was really desired waslloyd2009-05-131-1/+1
| | | | | rotate.h, or when it was not needed at all. Remove or change the includes as needed.
* Thomas Moschny passed along a request from the Fedora packagers which camelloyd2009-03-302-29/+33
| | | | | | | | | | | | | | | up during the Fedora submission review, that each source file include some text about the license. One handy Perl script later and each file now has the line Distributed under the terms of the Botan license after the copyright notices. While I was in there modifying every file anyway, I also stripped out the remainder of the block comments (lots of astericks before and after the text); this is stylistic thing I picked up when I was first learning C++ but in retrospect it is not a good style as the structure makes it harder to modify comments (with the result that comments become fewer, shorter and are less likely to be updated, which are not good things).
* Do a minor optimization in some of the compression functions, loadinglloyd2008-11-231-3/+6
| | | | | the registers only once and carrying the values over between loop iterations.
* I had not anticipated this being really worthwhile, but it turns outlloyd2008-11-232-29/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to have been so! Change MDx_HashFunction::hash to a new compress_n which hashes an arbitrary number of blocks. I had a thought this might reduce a bit of loop overhead but the results were far better than I anticipated. Speedup across the board of about 2%, and very noticable (+10%) increases for MD4 and Tiger (probably b/c both of those have so few instructions in each iteration of the compression function). Before: SHA-1: amd64: 211.9 MiB/s core: 210.0 MiB/s sse2: 295.2 MiB/s MD4: 476.2 MiB/s MD5: 355.2 MiB/s SHA-256: 99.8 MiB/s SHA-512: 151.4 MiB/s RIPEMD-128: 326.9 MiB/s RIPEMD-160: 225.1 MiB/s Tiger: 214.8 MiB/s Whirlpool: 38.4 MiB/s After: SHA-1: amd64: 215.6 MiB/s core: 213.8 MiB/s sse2: 299.9 MiB/s MD4: 528.4 MiB/s MD5: 368.8 MiB/s SHA-256: 103.9 MiB/s SHA-512: 156.8 MiB/s RIPEMD-128: 334.8 MiB/s RIPEMD-160: 229.7 MiB/s Tiger: 240.7 MiB/s Whirlpool: 38.6 MiB/s
* Derive the x86 assembly implementations of MD4, MD5, and Serpent fromlloyd2008-09-291-1/+1
| | | | | | | | | | the normal Botan base classes. This required making data members of MD4, MD5, and Serpent protected rather than private, which is not very good style IMO. On the other hand it allows for removing a bit of duplicated code, and also has the nice effect that a pointer to a Serpent_IA32 can be used right as a Serpent object, which makes sense anyway since they implement the same algorithm. The C++ files in the *_ia32 modules are now simply hooks between the virtual function call runtime and the assembly code.
* Rename all modinfo.txt files to info.txt, since they are all (none) oflloyd2008-09-291-0/+0
| | | | | them modules now. In any case there is no distinction so info.txt seems better.
* Make mdx_hash also a module, which most of the hash functions depend on.lloyd2008-09-281-0/+4
| | | | | | Correct the configure program so modules are not autoloaded if their dependences are not available. (Eg, --no-module=mdx_hash will disable MD4, MD5, SHA-1, etc rather than cause a compliation failure)
* Move all modules into src/ directorylloyd2008-09-283-0/+142