| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| | |
5cadcc57872bef55226579df57349fe09a93d1f5)
to branch 'net.randombit.botan.c++0x' (head d1747f0394aa4442e5b32b9102b830e1a86f0e5a)
|
| |\
| | |
| | |
| | |
| | |
| | | |
95eb8083f5884531e5ca0667388f8a6fb6d05c41)
to branch 'net.randombit.botan.c++0x' (head 56e105e678540c8bcafa4d0198c19a9489fbf8d1)
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | | |
5438defd358f82e876917a8bd6d735305ecb0a8e)
to branch 'net.randombit.botan.c++0x' (head cbdb2fd418557add29a536f7bdb6e78db16f725c)
|
| | | | |
|
| | |\ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
d6d32791adfa878b6fc0dd3a5b65a665b7bbb549)
to branch 'net.randombit.botan.c++0x' (head 54deb0e078aab8cd91c8fd8819d1e6668fc762da)
|
| | | | | |
|
| | | | | |
|
| | |\ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
6a746ccf1e957dba703e65372050a7bd4d6b117d)
to branch 'net.randombit.botan.c++0x' (head f54bb7b391eb3b71f380a68ddd460debdc31545d)
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This was mostly a s/auto_ptr/unique_ptr/, except in the CVC code and one
function in ECDSA, which relied on auto_ptr's move semantics (ugh) and had
to be modified in various ways.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
be much cleaner, though I am looking forward to the new for syntax which
will simplify a lot of these uses further.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
in the source).
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
With GCC, build as C++0x (set the binary name to my particular installed
GCC 4.4 snapshot).
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
is enabled in the build.
|
| | | | | | |
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | | | |
|
|\| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
378e7464abc6b3efcf9cb433f7fcec0adfbb9de0)
to branch 'net.randombit.botan' (head dd9bdcc0cab8b761a1c9861f3a4fc625488c2ef5)
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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'.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
systems. This was something that for whatever reason that I have
long since forogotten was a good idea on IRIX running MIPS circa
a decade ago, but was reported to cause problems on the Debian
builds.
Add mipsel as an alias for the mips32 architecture for Debian.
The mips32 submodel names were badly typoed and did not work
correctly.
Remove the leading mips32- and mips64- from MIPS submodel names.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
based on the SGI Pro64 and Pathscale EKOpath compilers. Only tested on an
x86-64 system running Linux (v4.2.1). Miscompiles a few of the block ciphers
(segvs, didn't bother to diagnose further; recompile with -O1 to fix), other
than that seems OK.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
used on Visual C++
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Contributed by Patrick Georgi
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Don't read any file that is not world-readable. This avoids trouble when
running as root, since on Linux various special files can cause odd
interactions and/or blocking behavior when read (for instance /proc/kmsg).
ssumption is that no such files are world-readable. This also avoids any
issue of reading data that is potentially sensitive.
Instead of reading the first 1 KB of each file, only read the first 128
bytes. This prevents large files (like /proc/config.gz or /proc/kallsyms)
from swamping the input buffer; these inputs are pretty static and
shouldn't count for much. Reducing to 128 bytes causes a poll to read
about 400 different files, rather than ~30.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Python configure scripts. Previously Python version would give up, and
the Perl one would guess i686 (!)
|