| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
the LibraryInitializer class, rather than global functions floating
around inside the Init namespace.
Allow callers to provide an alternative Modules object.
|
|
|
|
|
| |
of the list. The only time when the other behavior was desired was inside
the load() function, which now simply appends to the engines vector itself.
|
| |
|
|
|
|
|
|
|
|
| |
allocation from, rather than the block after that one. This helps the
pathalogical case where there are many full blocks and some free blocks at
the very end of the list (as then it would loop through each one, trying
and failing to allocate from an already full block until it hit the end of
the list again).
|
|
|
|
|
|
|
|
|
|
| |
handle the case where an allocator is added that has the same name as one
already registered.
Flush the cached allocator pointer when the default is changed.
Mark comparison operations in Pooling_Allocator::Memory_Block as inline;
this seems to help the STL sort and binary search algorithms tremendously.
|
| |
|
|
|
|
|
|
| |
exposing the actual search objects to the user rather than wrapping them
in functions. Primarily this is to avoid the Visual Studio bug alluded to
in the last commit.
|
|
|
|
| |
for.
|
| |
|
|
|
|
|
|
|
|
|
| |
being performed.
Undefined the prototype creating macro in x509stat.cpp after use.
Avoid a possible type conversion in bigint_divop by storing high's top
bit in a word instead of a bool.
|
|
|
|
| |
the path limit integer to a boolean)
|
| |
|
|
|
|
| |
the interfaces previously included in X509_PublicKey and PKCS8_PrivateKey.
|
| |
|
| |
|
|
|
|
|
|
| |
X509_PublicKey object now offers interfaces that return encoder and
decoder objects. Eventually these changes will make it much easier to
support alternate key formats like OpenPGP.
|
|
|
|
| |
x509self.cpp, the other a block of code in X509_CA's constructor).
|
| |
|
|
|
|
|
| |
ever needed it to pull a few pieces of information from the key, which
it now gets by calling pure virtual functions implemented by its children.
|
|
|
|
| |
the various types it wants to cache.
|
|
|
|
| |
as well as the cipher name
|
|
|
|
|
| |
pipe.cpp; apparently GCC was eliding them completely from the shared library
otherwise, meaning Boost.Python couldn't reference them.
|
|
|
|
| |
as issuer names.
|
|
|
|
|
|
| |
string representations of the OIDs; anything for which a human-readable
version does not exist in the OID table is returned in the normal dotted
decimal representation.
|
|
|
|
|
| |
registered in the name database, or asked to lookup an OID with a bare
OID string representation.
|
|
|
|
| |
though it's clear that this whole naming system is very broken.
|
|
|
|
| |
use a little extra workspace, this makes that simpler to do.
|
| |
|
|
|
|
|
|
| |
was used.
Make a variant of bigint_simple_mul, bigint_simple_sqr, for mp_sqr.cpp
|
|
|
|
|
|
|
|
|
|
| |
Move the inner-most loop of Montgomery into bigint_mul_add_words, in
mp_muladd.cpp
Use bigint_mul_add_words for the inner loop of bigint_simple_multiply
Move the compare/subtract at the end of the Montomgery algorithm into
bigint_monty_redc
|
|
|
|
|
| |
running the test means the algorithm prototype is loaded into memory when
it will probably never be used later.
|
| |
|
| |
|
|
|
|
| |
between the Montgomery and fixed-window exponentiators.
|
|
|
|
| |
few lines.
|
| |
|
|
|
|
|
|
| |
always zero, so this is both a bit more efficient and more readable. It
won't be able to take advantage of asm implementations of word_add, but
the benefit from that with a single call per loop is small anyway.
|
|
|
|
|
| |
single function is using 30+% of the runtime during RSA operations,
making it a strong candidate for implementation in assembly.
|
|
|
|
|
|
| |
as C (for replacing by asm later), and another that performs a subtract
if needed (inside powm_mnt.cpp). That way an asm version of the Montgomery
algorithm won't have to deal with calling other functions.
|
| |
|
|
|
|
| |
shared between the C++ and assembly versions.
|
| |
|
|
|
|
|
| |
addressing rather than having to keep all four pointers around.
Unfortunately GCC does not seem to be taking advantage of this.
|
|
|
|
| |
if a bad key value is selected.
|
| |
|
|
|
|
| |
const pointers, as it doesn't actually need write access to anything.
|
|
|
|
|
| |
and force a deinitialization before throwing it further up the call
stack.
|
| |
|
|
|
|
|
|
|
| |
than always placing the first block into the temp buffer, we only
copy the data into there if we have to (ie, if we have an incomplete
block). So calling add_data with a block that is a multiple of the
hash function's internal block size is entirely zero-copy.
|
|
|
|
|
|
| |
otherwise any Engines added after startup (eg, application-specific
ones) would only be used for new algorithm - it wouldn't be possible
for them to override existing implementations.
|