| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| | |
and 'a4d88442d5f6b8554234c7f7468856868919b614'
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
especially in a multithreaded environment, and doesn't seem like a
useful operation to support.
(In principle, we could support this by adding a clone() call to
Algorithm_Cache, which would in turn call clone on each of it's held
prototype objects, plus adding a clone to Engine. Doesn't seem worth the
bother, though.
|
|/
|
|
| |
reason to say `class Engine*` later on.
|
|
|
|
|
| |
caches; this might be useful for applications which are, say,
particularly sensitive to memory usage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The library initializer runs some self tests; this brings objects for
a few select types (AES, SHA-1, etc) into the caches. Later on, when
we add a dynamic engine, the engines aren't requeried because the
cache has hits. So, for instance an dlopen'ed engine that provided
AES-128 would not actually be used unless you called on the algo
factory with a provider of "blah" - even using set_preferred_provider
would have no effect, because that's just a request.
Add a new function to Algorithm_Cache, clear_cache, which just deletes
everything that is currently loaded (this is 90% of the destructor).
Then call this on each cache in Algorithm_Factory when a new Engine is
loaded. In normal use, this should be very fast because on init the
engines are loaded one after another so clear_cache() won't do much
work at all, but it ensures that if you load an engine later on in
runtime it will always be found. It does have the downside that the
app will then requery each Engine for each new algo after this point,
but I think typically loading a dynamic engine will happen very early
on so this won't be too much of a hassle. (And even if it happens in
the middle of execution, everything still works, it just means some
overhead the first time you ask for algo X).
|
|
|
|
|
|
|
|
| |
rather than before. Otherwise, we run into a problem with dynamically
loaded engines: the engine will be deleted (and thus, the external
library unloaded), before calling the destructors on any objects which
may have been cached, so we jump to a now invalid address instead of
the destructor code.
|
|
|
|
|
|
| |
(amd64_eng and ia32_eng) into a new asm_engine. This same engine could
also be used in the event that asm code for other CPUs was added later
on.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This caused Doxygen to think this was markup meant for it, which really
caused some clutter in the namespace page.
|
|
|
|
| |
that enable botan to be built under the clang C++ compiler.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes for the amalgamation generator for internal headers.
Remove BOTAN_DLL exporting macros from all internal-only headers;
the classes/functions there don't need to be exported, and
avoiding the PIC/GOT indirection can be a big win.
Add missing BOTAN_DLLs where necessary, mostly gfpmath and cvc
For GCC, use -fvisibility=hidden and set BOTAN_DLL to the
visibility __attribute__ to export those classes/functions.
|
| |
|
| |
|
|
|
|
|
| |
Pretty much useless and unused, except for listing the module names in
build.h and the short versions totally suffice for that.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
the info.txt files with the right module dependencies.
Apply it across the codebase.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
via two-stage initialization.
|
| |
|
|
algo_factory/
|