| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
- rounding.h (round_up, round_down)
- workfactor.h (dl_work_factor)
- timer.h (system_time)
And update all users of the previous util.h
|
|
|
|
| |
Inline round_up and round_down
|
|
|
|
|
|
| |
Add support for SHA-2 and SEED.
Wrap block cipher usage in checks for OPENSSL_NO_XXX
|
| |
|
|
|
|
| |
info leakage.
|
| |
|
|\
| |
| |
| |
| |
| | |
ef51dd2869ed38dae3aeb1c3b931ca9d595580e1)
to branch 'net.randombit.botan' (head fc1942640045423f411fd865cbd584090b28d7eb)
|
| | |
|
| | |
|
| |
| |
| |
| | |
Visual C++.
|
| | |
|
| | |
|
| |\
| | |
| | |
| | |
| | |
| | | |
c7f7c5092848b9c230d1757c74ed25ee9ea52262)
to branch 'net.randombit.botan' (head a1315b63e5c3a6101df388c70ad69dc039437fe8)
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
passed as a 'const std::string' instead of a const reference. Can't fix
in 1.8 since it is ABI breaking.
|
| | |
| | |
| | |
| | | |
is enabled in the build.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
accesses, if we are.
Add new options --with-unaligned-mem and --without-unaligned-mem to override
the arch-specific guess. The only usage I specifically know for this is to
allow unaligned accesses on m68k machines, when use on Coldfire is not
expected. Other cases where most CPUs of a particular type support unaligned
accesses but a specific target doesn't (or it is very slow) can also use this.
|
| | | |
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | | |
75371777750b63ef94693602202c5104f217a987)
to branch 'net.randombit.botan' (head 3f53f01c349eeee89288b1922fbde45b283c958c)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
memory accesses. Since this can be a pretty big win, enable it for them.
The m68k apparently also can, except in its (modern) Coldfire version,
but it's always big endian so mark that as such.
|
| | | | |
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
c2624292793f396cf940403e0d12073a9b2c7b17)
to branch 'net.randombit.botan' (head 07a71effa1ba495b6ea57b2490ad38bf58a23bd0)
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
computed in parallel. Not a huge win but slightly faster (which affects
things like Lion when using Turing), most likely due to more available ILP
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
works on, have sse2_eng rely on a specific compiler/arch; each sse2 impl
depends on the engine anyway, so they will only be loaded if OK.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
output with a script after the fact to generate such things, especially
as often for HTML I want to do multiple side-by-side results.
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
378e7464abc6b3efcf9cb433f7fcec0adfbb9de0)
to branch 'net.randombit.botan' (head dd9bdcc0cab8b761a1c9861f3a4fc625488c2ef5)
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
for both Serpent and AES-128 in CTR mode.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
however many blocks remain, rather than looping calling encrypt_n with
a block size of 1 each time.
|
| |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
ea6531b1e5b0aa67db295a3d3617265b912aa3a1)
to branch 'net.randombit.botan.encrypt-n' (head 563c4447d6fa61869158874c2dbfa6e9be106803)
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
About 10% faster than previous. Currently 112 MiB/s in ECB mode, versus about
40 MiB/s in scalar mode, on my 2.4 GHz Core2
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
unions and can be made much faster using interleave operations I think.
Currently ~2.5x faster in ECB or CTR mode on a Core2, which isn't too bad.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
enc/dec functions it replaces, these are public interfaces.
Add the first bits of a SSE2 implementation of Serpent. Currently incomplete.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Modify ECB to use parallel encryption/decryption where possible
Add toggles in build.h specifying how many blocks to process in parallel.
Defaults to 8 blocks for all modes, which is sufficient that any likely
parallelism can be extracted (via SIMD or concurrent execution) but not
so much as to seem likely to cause cache problems (8*128 bits = 128 bytes,
or two x86 cache lines)
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
decryption. Currently only used for counter mode. Doesn't offer much
advantage as-is (though might help slightly, in terms of cache effects),
but allows for SIMD implementations to process multiple blocks in parallel
when possible. Particularly thinking here of Serpent; TEA/XTEA also seem
promising in this sense, as is Threefish once that is implemented as a
standalone block cipher.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
in the Threefish cipher have changed to increase diffusion.
|
| | | | | | | |
|
| |_|_|_|_|/
|/| | | | | |
|
| |_|_|_|/
|/| | | | |
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
build (only libstate, utils, plus dependencies), which can be extended with
use of --enable-modules.
To add new modules to the set of always-loaded, use 'load_on always' in info.txt
Also fix a few small build problems that popped up when doing a minimal build.
Requested by a user.
|