| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
16 KiB buffer. Also reorder the parameters to make somewhat more sense, with the
first arguments being totally mandatory and the later ones potentially optional.
Provide inlined version matching the old interface that just forwards to the
new call, marking it as deprecated.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Linux, Solaris, and the BSDs.
Solaris and BSD are untested, but it seems like they should work.
Using libdl on Solaris is seemingly only required in Solaris 9 and
earlier, but 10 has a stub library so it should work there as well.
|
|
|
|
|
| |
it relies on dyn_load which should be the sole source for this kind of
stuff, since dyn_engine itself does not touch the OS level APIs.
|
|
|
|
|
| |
expected value is 20100728 (ie, today). This will allow for checking
for and/or working around changes to interfaces.
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
the system dynamic linker (if any). Currently it only supports dlopen,
and is only enabled on Linux. It will almost certainly work on BSDs
and Solaris as well, though, and should be easy to extend to support
Win32-style dynamic loading.
Also add a new engine, Dynamically_Loaded_Engine, which loads up a new
Engine object from a shared library/DLL.
|
|
|
|
| |
(slightly) better.
|
|\
| |
| |
| | |
and 'ada4c9893d70affd8934ab9664e390087feab3c9'
|
| | |
|
| |
| |
| |
| | |
Rename CPUID::has_aes_intel to has_aes_ni.
|
| |
| |
| |
| |
| |
| | |
work for 32 and 64 bit integers. Using these instead of inline asm may
offer better scheduling on x86, and additionally offers native
byteswapping on other platforms (PPC, ARM, etc).
|
| |
| |
| |
| |
| | |
initialize() call which must be called prior to use of any other
functions.
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
| |
(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.
|
| |
|
|
|
|
|
|
|
|
|
| |
removing several workarounds for limitations in optparse in that
release, and also allows using the ternary operator added in 2.5.
As far as I can tell, the only still active release of any Linux/BSD
distro that uses 2.4 is RHEL5. The beta of RHEL6 has 2.6, and it seems
likely that RHEL6 will be out before 1.10.0.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
really is only used by OpenPGP, and largely it was named S2K here
because the OpenPGP S2K was implemented years before the ones in PKCS
#5. We have a typedef of PBKDF to S2K, and an inlined get_s2k that
calls get_pbkdf for source compatability.
There doesn't seem to be any reason to have a forward for the renamed
s2k.h header - to actually use a PBKDF, you'd have to either include
lookup.h and call get_s2k / get_pbkdf, or else include an
algorithm-specific header and use it directly. In either case,
including s2k.h is neither necessary nor sufficient.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
depending on if INITIAL_LEN is non-zero. Normal semantics are the
vector will change size based on whatever it is constructed with,
but that's bad in cases like
SecureVector<byte, 4> val(buffer, 3);
which in the past would be a 4 valued thing with 3 elements set
and one zero trailing. (This construct showed up in base64 and
possibly elsewhere). If INITIAL_LEN is set, use copy instead so
the length does not change.
C++0x cannot come soon enough.
|
|
|
|
| |
BOTAN_DLL
|
| |
|
|
|
|
|
| |
filter doesn't support IVs at all), throw an exception unless the IV
has zero length.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
things, just share the compression function via an anon namespace
member, and replicate the simple stuff like copy_out.
|
|
|
|
|
| |
set of warning flags. Use just plain '-Wall -W' for regular GCC so the
default build is happy on arbitrarily old versions.
|
|
|
|
| |
its constructor directly, instead of going through LibraryInitializer.
|
| |
|
| |
|
| |
|
|
|
|
| |
are forward declared in the headers.
|
|
|
|
| |
process
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
triggers Doxygen generating warnings for global functions declared in
the namespace that aren't documented.
|