| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
botan.h includes unconditionally.
Remove obsolete seed_rng code from init.h
|
|
|
|
| |
Add some missing info.txts
|
|
|
|
|
| |
basically). buf_comp and data_src might need their own directory, but it
doesn't really feel like it.
|
|
|
|
| |
Move core/sym_algo.{h,cpp} to sym_algo
|
| |
|
|
|
|
|
| |
implementation), remove freestanding estimate_entropy function, change
Randpool to use entropy estimator.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is requested, Randpool will first do a fast poll on each entropy
source that has been registered. It will count these poll results
towards the collected entropy count, with a maximum of 96
contributed bits of entropy per poll (only /dev/random reaches
this, others measure at 50-60 bits typically), and a maximum of
256 for sum contribution of the fast polls.
Then it will attempt slow polls of all devices until it thinks enough
entropy has been collected (using the rather naive entropy_estimate
function). It will count any slow poll for no more than 256 bits (100 or
so is typical for every poll but /dev/random), and will attempt to collect
at least 512 bits of (estimated/guessed) entropy.
This tends to cause Randpool to use significantly more
sources. Previously it was common, especially on systems with a
/dev/random, for only one or a few sources to be used. This
change helps assure that even if /dev/random and company are
broken or compromised the RNG output remains secure (assuming at
least some amount of entropy unguessable by the attacker can be
collected via other sources).
Also change AutoSeeded_RNG do an automatic poll/seed when it is
created.
|
|
|
|
|
|
| |
implementations
to decouple from knowing about RandomNumberGenerator).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new class AutoSeeded_RNG that is a RandomNumberGenerator that wraps
up the logic formerly in RandomNumberGenerator::make_rng. make_rng in
fact now just returns a new AutoSeeded_RNG object.
AutoSeeded_RNG is a bit more convenient because
- No need to use auto_ptr
- No need to dereference (same syntax everywhere - it's an underestimated
advantage imo)
Also move the code from timer/timer_base to timer/
|
| |
|
| |
|
|
|
|
|
| |
Add a comment explaining why these functions are compiled rather than
inlined.
|
|
|
|
| |
written by Yves Jerschow (sent to me in a personal email 2007-10-23).
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
fd327b29aa542e0ad5ff6d37d8392321670f0369)
to branch 'net.randombit.botan.modularized' (head 3f8d05493d4b192243fdc8a7f518ed1013c3be54)
|
| |
|
|
|
|
|
|
| |
lookup/global_state piece).
Move timer and mutex directories into utils/
|
| |
|
|
|
|
|
|
|
|
| |
inline asm (currently, if __GNUG__ is defined, which works with both
GNU C++ and Intel C++, which are the only two compilers I know of that
accept GCC's inline asm syntax). Use that in bswap.h - previously we
would try to use inline asm even with VC++ or other compilers not supporting
inline asm.
|
| |
|
|
|
|
|
|
| |
in utils.
Support OS feature macros, eg BOTAN_TARGET_OS_HAS_POSIX_MLOCK (how very autoconf)
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rather than silently replacing the C++ versions. Instead they are silently
replaced (currently, at least) at the lookup level: we switch off the set
of feature macros set to choose the best implementation in the current
build configuration. So you can have (and benchmark) MD5 and MD5_IA32
directly against each other in the same program with no hassles, but if
you ask for "MD5", you'll get maybe an MD5 or maybe MD5_IA32.
Also make the canonical asm names (which aren't guarded by C++ namespaces)
of the form botan_<algo>_<arch>_<func> as in botan_sha160_ia32_compress,
to avoid namespace collisions.
This change has another bonus that it should in many cases be possible to
derive the asm specializations directly from the original implementation,
saving some code (and of course logically SHA_160_IA32 is a SHA_160, just
one with a faster implementation of the compression function, so this seems
reasonable anyway).
|
|
|
|
|
| |
them modules now. In any case there is no distinction so info.txt seems
better.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
a lot of public key stuff in here that needs to be extracted however,
and probably 2-3 other modules worth of stuff to split off (engines, etc)
|
| |
|
| |
|
| |
|
| |
|
|
|