| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
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)
|
| | |
|
| | |
|
| |
| |
| |
| | |
Wrap the EVP_ calls in OPENSSL_NO_XXX checks to handle this.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
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)
|
| |
| |
| |
| | |
to get the version #
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
in a reasonable way. Low on features, which is rather intentional. There
is a version code included in the format so further extensions are possible, if
warranted.
Inspired by the n-th mailing list request for such a class. Realized it was
probably better that I design such code than random people who just want
'something that works'.
|
| | |
|
| |
| |
| |
| |
| |
| | |
handle recursive dependencies, so explicitly disabling, say, ecc_key, doesn't
disable cvc as it should. However it does fix the problem of building with
--with-tr1=none, which was the main problem people were having WRT to this.
|
| |
| |
| |
| | |
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)
|
| |
| |
| |
| | |
bad info.txt files
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
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.
|
|
|
|
|
| |
files. Were missed by the automated script that added them to the cpp/h
files, it appears.
|
|
|
|
|
| |
Serpent seems very nicely suited to a SSE2 SIMD implementation, and CTR
mode can handle multiple blocks in parallel. Input lens 1 to 128 bytes.
|