| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
static_cast or reinterpret_cast, as needed.
|
|
|
|
| |
(nominally) more accurate results.
|
|
|
|
| |
or other non-portable implementations as modules.
|
|
|
|
|
| |
just want access to the underlying data representation but don't care if
the return value is NULL terminated or not.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
of the line rather than the start.
|
|
|
|
| |
into mainline rather than stable.
|
|\
| |
| |
| |
| |
| | |
e92fe807f749c526669303bd1530dd76a4d10a86)
to branch 'net.randombit.botan' (head 04a56f961f413296df6637b77ec45aa444513cfc)
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
be marked as 1.7.0 at least.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| | |
hurt and might help. From Yves Jerschow.
|
| |
| |
| |
| | |
support until SPARCv9.
|
| |
| |
| |
| |
| |
| | |
Currently it is only set for x86 and x86-64 as they are two of the few
architectures which are not bi-endian, and we're not doing any detection
(nor is there any way for a user to override the selection yet).
|
| |
| |
| |
| |
| | |
Seems to be about 2-3 times faster in the case where the key is smaller
than the hash's block size, which is almost always the case.
|
|\ \
| | |
| | |
| | | |
and '70af033ad11d389159632ebcf9cae091bde8b544'
|
| | | |
|
|\ \ \
| |/ /
|/| /
| |/
| |
| | |
8a2b79c64a13d3f70b0211d4f985a678951a9663)
to branch 'net.randombit.botan' (head 677686443a5bb53b03d147999947448a9dc2679a)
|
| |
| |
| |
| | |
Studio users.
|
| |
| |
| |
| | |
fairly massive way.
|
| |
| |
| |
| | |
from a void* to a Memory_Block, so call the constructor explicitly.
|
|\|
| |
| |
| |
| |
| | |
63c067b5454498ee48466101aedb54613615a983)
to branch 'net.randombit.botan' (head 2444e9d08f77852cf2df58c34ca38145c2f416ba)
|
| |
| |
| |
| | |
folks (I think this was also required under QNX, actually).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
and bigint_mul_add_words since those are the major hot spots for
public key operations.
|
| |
| |
| |
| |
| | |
It is not amazingly optimized, about 5% faster than what GCC 4.1.1 does
on my Core2 with the normal C++ code, but it's a start.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
stack. At least SuSE and Gentoo are using a patch for this in their trees,
probably others are as well.
I still have not had a chance to check the portability aspects of this,
especially on Solaris (the only ELF-based x86/amd64 operating system that
I know of that does not use the GNU toolchain).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now three classes are defined: 'request', 'auto', and 'asm_ok'. The 'auto'
class is loaded automatically if the platform support matches up with
what we are building for (this is the former default). The 'request' mode
means it is only loaded if specifically requested by name. The 'asm_ok'
module is marked for all modules that use any assembler (including inline
assembler). This normally functions like 'auto', unless --debug is passed
to configure, in which case it is treated as 'request'.
Modules which do not specify a load behavior are given a default of
'request'.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
These were allocated out of my IANA assigned arc, which is documented at
http://www.randombit.net/text/oids.html
|
| |
| |
| |
| | |
if we found a human readable name for it (in that case we print both).
|
| |
| |
| |
| |
| |
| | |
encode a public key that did not have an OID for its key format resulted
in a very confusing exception (thrown from char2digit) that was completely
meaningless to anyone.
|
| |
| |
| |
| | |
projects.
|
| | |
|
| |
| |
| |
| | |
'standard' groups (I may just go ahead and do this).
|
| | |
|
| | |
|