| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
benchmark
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
this if desired)
|
| |
|
| |
|
|
|
|
|
| |
so that algo_cache.h does not have to be visible in the source of all
callers who include libstate.h/algo_factory.h
|
| |
|
|
|
|
| |
template to share the search and cache management logic across all types
|
|
|
|
|
|
|
|
| |
replacing with an updated constructor to Algorithm_Factory taking a
vector of Engine*. The semantics of adding engines at runtime were not
defined nor very clear, it seems best to prohibit this unless and
until it is explicitly thought through (and until a need for it
presents itself).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
algo_factory and algorithm_factory. This is confusing
so for consistency/simplicity, remove algo_factory, making
algorithm_factory the function to call.
In 1.7.14, several functions in lookup.h, including
retrieve_block_cipher, retrieve_hash, etc were changed to accept
a Library_State& reference. However it turns out with the
modified design I've settled upon for 1.8 that it is not
necessary to change those interfaces; instead they always refer
to the global_state algorithm factory which is exactly the
semantics one would expect/desire 99% of the time (and is source
compatible with code written for 1.6, also a plus)
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Engine_Iterator (and thus the public key engine code) still processes
in order of first engine to last in the list.
Benchmarking confirmed that GNU MP is still faster than both OpenSSL
and Botan for public key operations (at least on my machine).
|
|
|
|
|
| |
integers where we manipulate values denominated in nanoseconds to avoid
overflow (2^64 nanoseconds = 584.55 years, aka long enough)
|
|
|
|
|
|
|
|
|
| |
instantiated directly, which seemd a useful thing since a Timer ref
must be passed to the benchmark system. However I think due to the
low resolution of clock() the results were highly variable. Using
gettimeofday or clock_gettime (Unix_Timer, POSIX_Timer) proved more
consistent and in sync with what the existing benchmarks show, so
use one of those if possible.
|
|
|
|
|
|
|
|
|
|
|
|
| |
was not the right place to keep track of this information. Also modify
all Algorithm_Factory constructor functions to take instead of a SCAN_Name
a pair of std::strings - the SCAN name and an optional provider name. If
a provider is specified, either that provider will be used or the request
will fail. Otherwise, the library will attempt best effort, based on
user-set algorithm implementation settings (combine with benchmark.h for
choosing the fastest implementation at runtime) or if not set, a static
ordering (preset in static_provider_weight in prov_weight.cpp, though it
would be nice to make this easier to toggle).
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Algorithm_Factory)
|
|
|
|
| |
a name.
|
|
|
|
|
|
| |
As with HMAC_RNG, instead assume one bit of conditional entropy per byte
of polled material. Since they are no longer used, drop the entropy
estimation routines entirely.
|
| |
|
| |
|
|
|
|
|
| |
the other half was relied upon by pubkey. Move the contents into those two
modules. Update deps.
|
| |
|
|
|
|
|
| |
be able to get the global_state so as to get a reference to the
Algorithm_Factory
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the engines.
Unfortunately right now Botan doesn't understand that a construction
like HMAC, while the basic HMAC class lives only in core, can use any
of a variety of implementations as the underlying algorithm. The previous
version got this completely wrong (basically the first time a particular
HMAC was requested, one hash provider would be chosen at random). Now instead
we always use the same subprovider. This means HMAC(SHA-1) won't see
a speedup even if there is an asm version available (similarly, CMAC(AES)
wouldn't see a speedup with OpenSSL's AES or an engine that provided
AES using VIA's or Intel's extensions). Certainly a major deficiency, but
I haven't worked out how to fix it yet.
|
|
|
|
|
| |
back to the toplevel since most othe dependencies have been removed now
(except get_cipher which still needs changes)
|
| |
|
| |
|
| |
|
|
|
|
| |
couldn't really figure out how the semantics should work.
|
|
|
|
|
|
|
| |
the caches included in the Engines, allowing faster search/query along
and making the Engine implementations mostly or entirely stateless, also
removing the need for a two-phase initialization there.
Stil buggy + incomplete.
|
| |
|
| |
|
|
|
|
| |
them to be individually requested as providers on lookup.
|
|
|
|
| |
this allows provider preferences to be passed down to sub-algorithms.
|
| |
|
| |
|
| |
|