| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
The test vectors were generated by Crypto++ 5.5 on a Linux/x86-64 machine.
Test vectors for CBC-MAC(DES) all pass, for inputs up to 63 bytes. For
CBC-MAC(AES-128), all test vectors with inputs over 10 bytes fail to verify
against what Crypto++ produces. Unknown at this time where the bug lies.
|
|
|
|
| |
static_cast or reinterpret_cast, as needed.
|
|
|
|
| |
or other non-portable implementations as modules.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
under the name that the algorithm was originally requested by. This enables
proper caching for algorithm names which deref_alias fails to fully dereference
such as "HMAC(SHA-1)". The previous code had two major problems with names of
that type, firstly that the cache was effectively bypassed due to all prototype
objects in Algorithm_Cache_Impl being indexed by their canonical names rather
than the alias that they were requested under, and that there existed a race
condition where a prototype object might be deleted while in use in multithreaded
code.
The downside of this change is that using multiple names to refer to a single
algorithm causes multiple prototype objects to be created, one for each name
that is in use. However the memory overhead of this should be fairly minimal
and given the severity of the race condition this seems like a worthwhile tradeoff.
A more complete fix would be to fix deref_alias to properly derference all alias
names. That fix would be complimentary with this change in that if deref_alias
handled all names properly there would be a single prototype object and there
would then be no additional memory overhead to the cache.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into
account endian differences.
The current code does not take advantage of the knowledge of which endianness
we are running on; an optimization suggested by Yves Jerschow is to use (unsafe)
casts to speed up the load/store operations. This turns out to provide large
performance increases (30% or more) in some cases.
Even without the unsafe casts, this version seems to average a few percent
faster, probably because the longer loading loops have been partially or
fully unrolled.
This also makes the code implementing low-level algorithms like ciphers and
hashes a bit more succint.
|
|\
| |
| |
| |
| |
| | |
8a2b79c64a13d3f70b0211d4f985a678951a9663)
to branch 'net.randombit.botan' (head 677686443a5bb53b03d147999947448a9dc2679a)
|
| |
| |
| |
| | |
Studio users.
|
| |
| |
| |
| |
| |
| | |
caller. The resulting code is longer and somewhat harder to read, but it's
giving 25-30% performance increases on my Core2, and something a bit
lower but still measurable on the P4.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
how big q should be.
Add FIPS 186-3 DSA parameter generation, this allows for generating larger
(2048 and 3072 bit) DSA keys. At this time there do not seem to be official
test vectors for 186-3, and I have not checked against other implementations.
Tests will be constructed using the latest OpenSSL snapshot.
|
| |
| |
| |
| | |
current register size; reads return 0, writes extend the buffer.
|
| | |
|
| |
| |
| |
| | |
and actually reduced the total line count.
|
|/
|
|
|
|
| |
members of DL_Group (the only place they were called within the source, and
outside of some rather esoteric things probably the only place you would
ever need it).
|
| |
|
|
|
|
|
|
| |
newline should always be added, even if the output would normally fit
entirely on the current line. Monotone needs this for compatability with
the Crypto++ implementation of base64.
|
|
|
|
| |
mem_pool.cpp with debug enabled.
|
|
|
|
|
| |
as I can tell) the last of the global data, with the exception of the single
global_lib_state pointer in libstate.cpp
|
| |
|
|
|
|
|
| |
Add include directives for enums.h in the headers that need it now that
it isn't being pulled in by symkey.h
|
|
|
|
| |
of NO_CERT_PATH_LIMIT to enums.h
|
|
|
|
| |
RNG considers itself seeded.
|
|
|
|
|
|
|
| |
causing allocators that were never used to allocate (and thus, later
deallocate) memory. This was causing a noticable slowdown when the mmap
based allocator was in used (based on the strace output, this was mostly
due to the calls to msync).
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
the path limit integer to a boolean)
|
|
|
|
| |
ones which were visible via base classes, and the empty constructors.
|
| |
|
|
|
|
| |
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.
|
|
|
|
| |
class definition in 1.4.12
|
|
|
|
|
| |
clear(), which have been declared in the appropriate places in (former)
subclasses of Algorithm
|
|
|
|
| |
the various types it wants to cache.
|
|
|
|
|
| |
since the RNG merger in 1.5.0, they have been effectively the same type
anyway.
|
|
|
|
| |
way back around 0.7.7, and has served no useful purpose since.
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
use a little extra workspace, this makes that simpler to do.
|