aboutsummaryrefslogtreecommitdiffstats
path: root/src/hash
Commit message (Collapse)AuthorAgeFilesLines
* Remove most uses of HASH_BLOCK_SIZElloyd2010-10-1319-44/+49
|
* Use output_length() instead of OUTPUT_LENGTH pseudo-propertylloyd2010-10-1316-23/+23
|
* More size_tlloyd2010-10-131-1/+1
|
* Use size_t for BufferedComputation::add_datalloyd2010-10-1244-161/+165
|
* Split SHA-2 into 32 and 64 bit versions; they are totally independentlloyd2010-09-306-1/+6
| | | | of each other anyway.
* Make configure output more sensible wrt incompatible moduleslloyd2010-09-284-0/+16
|
* Do the prep/unroll phase 4 rounds before it is needed instead of 3;lloyd2010-09-211-97/+92
| | | | tests on Nehalem indicate a small but measurable win there (about 3%).
* Clean up, hide union accesses with a macro to make it easier to testlloyd2010-09-211-40/+92
| | | | alternative methods of getting pieces of the expanded message.
* Implicit conversionslloyd2010-09-141-7/+7
|
* More changes to avoid vector to pointer implicit conversionslloyd2010-09-141-2/+2
|
* Completely remove the second parameter to SecureVector which specifieslloyd2010-09-1418-53/+69
| | | | | | | | | | | | | | | | | | | | 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.
* Remove more uses of vector to pointer implicit conversionslloyd2010-09-136-18/+38
|
* More vector->pointer conversion removals.lloyd2010-09-131-3/+3
| | | | | | | | | | | Add RandomNumberGenerator::random_vec, which takes an length n and returns a new SecureVector with randomized contents of that size. This nicely covers most of the cases where randomize was being called on a vector, and is a little cleaner in the code as well, instead of vec.resize(length); rng.randomize(&vec[0], vec.size()); we just write vec = rng.random_vec(length);
* Anywhere where we use MemoryRegion::begin to get access to the raw pointerlloyd2010-09-1315-18/+18
| | | | | 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-0715-25/+25
| | | | | | | | | | | | | | 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.
* Also allow clang with 32-bit assembly code, everything seems to worklloyd2010-08-084-75/+0
| | | | fine with latest SVN.
* Clang understands at least some GCC inline asm syntax as well as whatlloyd2010-08-081-0/+1
| | | | an .S file is, so allow it for x86-64. Tested/works with Clang SVN.
* Consolidate the two engines that provided assembler implementationslloyd2010-07-131-1/+1
| | | | | | (amd64_eng and ia32_eng) into a new asm_engine. This same engine could also be used in the event that asm code for other CPUs was added later on.
* For the SHA-2 classes, don't use inheritence to share a handful oflloyd2010-06-284-85/+106
| | | | | things, just share the compression function via an anon namespace member, and replicate the simple stuff like copy_out.
* Replace "@return a blah" and "@return the blah" with just "@return blah"lloyd2010-06-161-1/+1
|
* Yet more Doxygen commentslloyd2010-06-162-6/+18
|
* More Doxygen commentslloyd2010-06-167-2/+32
|
* Tiger::clone's result always used 3 passeslloyd2010-06-161-1/+5
|
* More Doxygenlloyd2010-06-153-4/+18
|
* More Doxygen updates/fixeslloyd2010-06-1519-32/+44
|
* More Doxygen fixeslloyd2010-06-151-2/+3
|
* Use "/*" instead of "/**" in starting comments at the begining of a file.lloyd2010-06-079-9/+9
| | | | | This caused Doxygen to think this was markup meant for it, which really caused some clutter in the namespace page.
* Remove FORK-256; it's obscure and has been definitively broken.lloyd2010-05-253-189/+0
| | | | | More commentary posted to the list: http://lists.randombit.net/pipermail/botan-devel/2010-May/001123.html
* Check to make sure the user didn't provide two of the same has forlloyd2010-04-231-0/+3
| | | | | | Comb4P. If you do this, the first N bytes are all zero, which could expose some problems, especially if the caller truncates or is relying on Comb4P acting like a random function.
* Remove some C-style castslloyd2010-04-231-1/+1
|
* Comb4P: hashes must be the same lengthlloyd2010-04-221-2/+0
|
* Add Comb4P hash combiner, as described in Anja Lehmann's thesis.lloyd2010-04-173-0/+152
|
* Remove SecureBuffer, which is the fixed-size variant of SecureVector.lloyd2010-03-2317-33/+33
| | | | | | | | | | | | | | 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
* Line wraplloyd2010-03-021-6/+12
|
* 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.
* Move the get_byte template to its own header, because many fileslloyd2010-02-023-3/+0
| | | | including loadstor.h actually just needed get_byte and nothing else.
* s/j/i/ in looplloyd2010-01-211-2/+2
|
* Move Tiger::mix to anon namespace lloyd2010-01-042-14/+17
|
* Use a u32bit for the length argument to ubi_512. That value cannot possiblylloyd2009-12-231-2/+2
| | | | | | be larger than 4294967232 because you can give at most 2^32-1 bytes of data at a time to Skein_512::add_data, and Skein always needs to buffer at least one byte.
* Un-internal loadstor.h (and its header deps, rotate.h andlloyd2009-12-2119-30/+31
| | | | | | | | | | | | | | 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).
* Add missing BOTAN_DLL exports.lloyd2009-12-161-1/+1
| | | | Move most of the engine headers to internal
* Make many more headers internal-only.lloyd2009-12-1620-32/+32
| | | | | | | | | | | | | 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.
* Full working amalgamation build, plus internal-only headers concept.lloyd2009-12-167-12/+10
|
* Remove extern decl of no longer used/included SHA-1 SSE2 functionlloyd2009-11-231-2/+0
|
* Instead of having two asm_macr.h files being switched in based on modulelloyd2009-11-144-4/+4
| | | | build magic, name them asm_macr_ARCH.h. Change all including files accordingly.
* Slightly cleaner SHA-256 F1 func; ~1% fasterlloyd2009-11-101-3/+3
|
* Cleanups - remove emails from source files, they should only live inlloyd2009-11-105-6/+6
| | | | credits.txt and thanks.txt. Remove some various bits of formatting weirdness.
* Add a new need_isa marker for info.txt that lets a module dependlloyd2009-11-061-13/+2
| | | | | | | | | | | | on a particular ISA extension rather than a list of CPUs. Much easier to edit and audit, too. Add markers on the AES-NI code and SHA-1/SSE2. Serpent and XTEA don't need it because they are generic and only depend on simd_32 which will silenty swap out a scalar version if SSE2/AltiVec isn't enabled (since it turns out on supersclar processors just doing 4 blocks in parallel can be a win even in GPRs). Add pentium3 to the list of CPUs with rdtsc, was missing. Odd!
* propagate from branch 'net.randombit.botan.1_8' (head ↵lloyd2009-11-0359-688/+718
|\ | | | | | | | | | | 6e8c18515725a70923b34118951252723dd4c29a) to branch 'net.randombit.botan' (head 77ba4ea5a4be36d6d029bcc852b2271edff0d679)
| * Conver the rest of the hash functions to use the array-based load instructions.lloyd2009-11-035-40/+41
| | | | | | | | | | | | | | 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.