| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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.
|
|
|
|
|
| |
Pretty much useless and unused, except for listing the module names in
build.h and the short versions totally suffice for that.
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
files. Were missed by the automated script that added them to the cpp/h
files, it appears.
|
|
|
|
| |
Contributed by Patrick Georgi
|
|
|
|
|
|
| |
the info.txt files with the right module dependencies.
Apply it across the codebase.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
and all CPU-specific implementations now depend on the appropriate engine
module.
The most common problem before with this was that the SSE2 module was built,
but the sole SSE2 code (SHA-1) was not (for instance, on an i686). This would
cause a compile warning about the unused request object.
Preventing unused engines from being built will also (very slightly) speed
up the lookup process on most system.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
| |
conflicts/collisions
|
|
|