| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
fine with latest SVN.
|
|
|
|
| |
an .S file is, so allow it for x86-64. Tested/works with Clang SVN.
|
|
|
|
|
|
| |
(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.
|
|
|
|
|
| |
things, just share the compression function via an anon namespace
member, and replicate the simple stuff like copy_out.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This caused Doxygen to think this was markup meant for it, which really
caused some clutter in the namespace page.
|
|
|
|
|
| |
More commentary posted to the list:
http://lists.randombit.net/pipermail/botan-devel/2010-May/001123.html
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
including loadstor.h actually just needed get_byte and nothing else.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
| |
Move most of the engine headers to internal
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
build magic, name them asm_macr_ARCH.h. Change all including files accordingly.
|
| |
|
|
|
|
| |
credits.txt and thanks.txt. Remove some various bits of formatting weirdness.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
|
|\
| |
| |
| |
| |
| | |
6e8c18515725a70923b34118951252723dd4c29a)
to branch 'net.randombit.botan' (head 77ba4ea5a4be36d6d029bcc852b2271edff0d679)
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |\
| | |
| | |
| | |
| | |
| | | |
4fd7eb9630271d3c1dfed21987ef864680d4ce7b)
to branch 'net.randombit.botan.general-simd' (head 91df868149cdc4754d340e6103028acc82182609)
|
| | | |
|
| | |
| | |
| | |
| | | |
and also make it stylistically much closer to the standard SHA-1 code.
|
| | | |
|
| | |
| | |
| | |
| | | |
the code stylistically, etc)
|
| | |\
| | | |
| | | |
| | | |
| | | |
| | | | |
8fb69dd1c599ada1008c4cab2a6d502cbcc468e0)
to branch 'net.randombit.botan.general-simd' (head c05c9a6d398659891fb8cca170ed514ea7e6476d)
|
| | | |
| | | |
| | | |
| | | | |
and Altivec (though Altivec is seemingly slower ATM...)
|
| | | | |
|
| |/ /
| | |
| | |
| | | |
SHA-256 gets ~7% faster, SHA-512 ~10%.
|
| |/
| |
| |
| |
| | |
Pretty much useless and unused, except for listing the module names in
build.h and the short versions totally suffice for that.
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|