| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
| |
using a custom allocator. Currently our allocator just does new/delete
with a memset before deletion, and the mmap and mlock allocators have
been removed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the parameters of the key length. Instead define a new function which
returns a simple object which contains this information.
This definitely breaks backwards compatability, though only with code
that directly manipulates low level objects like BlockCipher*s
directly, which is probably relatively rare.
Also remove some deprecated accessor functions from lookup.h. It turns
out block_size_of and output_size_of are being used in the TLS code; I
need to remove them from there before I can delete these entirely.
Really that didn't make much sense, because they assumed all
implementations of a particular algorithm will have the same
specifications, which is definitely not necessarily true, especially
WRT key length. It is much safer (and probably simpler) to first
retrieve an instance of the actual object you are going to use and
then ask it directly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters are as well. So make them template paramters.
The sole exception was AES, because you could either initialize AES
with a fixed key length, in which case it would only be that specific
key length, or not, in which case it would support any valid AES key
size. This is removed in this checkin; you have to specifically ask for
AES-128, AES-192, or AES-256, depending on which one you want.
This is probably actually a good thing, because every implementation
other than the base one (SSSE3, AES-NI, OpenSSL) did not support
"AES", only the versions with specific fixed key sizes. So forcing
the user to ask for the one they want ensures they get the ones
that are faster and/or safer.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
sets the block size statically and also creates an enum with the
size. Use the enum instead of calling block_size() where possible,
since that uses two virtual function calls per block which is quite
unfortunate. The real advantages here as compared to the previous
version which kept the block size as a per-object u32bit:
- The compiler can inline the constant as an immediate operand
(previously it would load the value via an indirection on this)
- Removes 32 bits per object overhead (except in cases with actually
variable block sizes, which are very few and rarely used)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This caused Doxygen to think this was markup meant for it, which really
caused some clutter in the namespace page.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the implementation rather than the preferred one. Update all
implementations.
Add a new function parallel_bytes() which returns
parallelism() * BLOCK_SIZE * BUILD_TIME_CONSTANT
This is because i noticed all current calls of parallelism() just
multiplied the result by the block size already, so this simplified
that code.
The build time constant is set to 4, which was the previous default
return value of parallelism(). However the SIMD versions returned
2*native paralellism rather than 4*, so this increases the buffer
sizes used for those algorithms.
The constant multiple lives in buildh.in and build.h, and is named
BOTAN_BLOCK_CIPHER_PAR_MULT.
|
| |
|
|
|
|
|
|
| |
Default unless specified is now 4.
For SIMD code, use 2x the number of blocks which are processed in
parallel using SIMD by that cipher. It may make sense to increase this to
4x or even more, further experimentation is necessary.
|
| |
|
|
|
|
|
|
|
| |
depend on the particular implementation. Add a new virtual function to
BlockCipher named parallelism that returns the number of blocks the
cipher object could or might want to process in parallel. Currently
set to 1 by default but may make sense to increase this for even
scalar implementations since it seems like better caching behavior
makes it a win.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
| |
to support multiple blocks.
|
| | |
|
| | |
|
| |
|
