| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
to give a 3-7% speed improvement on Core2 with GCC.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
the prefetch is called for each block of input, and so a total of
(4096+256)/64 = 68 prefetches are executed for each block. This reduces
performance of iterative modes dramatically.
I'm not sure what the right approach for dealing with this is.
|
|
|
|
|
|
|
|
|
|
| |
timing attacks, since once all the TE/SE tables are entirely in cache then
timing attacks against it become somewhat harder. However for this to be
a full defense it would be necessary to ensure the tables were entirely
loaded into cache, which is not guaranteed by the normal SSE prefetch
instructions. (Or prefetch instructions for other CPUs, AFAIK).
Much more importantly, it provides a 10% speedup.
|
| |
|
|
|
|
|
|
| |
enc/dec functions it replaces, these are public interfaces.
Add the first bits of a SSE2 implementation of Serpent. Currently incomplete.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
up during the Fedora submission review, that each source file include some
text about the license. One handy Perl script later and each file now has
the line
Distributed under the terms of the Botan license
after the copyright notices.
While I was in there modifying every file anyway, I also stripped out the
remainder of the block comments (lots of astericks before and after the
text); this is stylistic thing I picked up when I was first learning C++
but in retrospect it is not a good style as the structure makes it harder
to modify comments (with the result that comments become fewer, shorter and
are less likely to be updated, which are not good things).
|
| |
|
|
|
|
| |
encryption.
|
|
|
|
|
|
|
|
|
|
|
| |
This seems to have a significant impact on overall speed, now measuring
on my Core2 Q6600:
AES-128: 123.41 MiB/sec
AES-192: 108.28 MiB/sec
AES-256: 95.72 MiB/sec
which is roughly 8-10% faster than before.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
$ ./check --bench-algo=AES-128,AES-256 --seconds=10
AES-128: 101.99 MiB/sec
AES-256: 78.30 MiB/sec
After:
$ ./check --bench-algo=AES-128,AES-256 --seconds=10
AES-128: 106.51 MiB/sec
AES-256: 84.26 MiB/sec
|
| |
|
|
|
|
| |
conflicts/collisions
|
|
|